Bug#895897: Further comments on apt purge
On Mon, Apr 29, 2024 at 04:16:14PM -0700, Andrew Athan wrote: > Note that > > apt purge ~c > > does something, but apt(8) does not mention the support for the ~c > parameter. It is relatively new and part of the aptitude-pattern backport. See apt-patterns(7). > On my system, it seems to be attempting to remove all packages that have the > "c" second character status in dpkg -l. Unfortunately, this includes > packages such as "locales" which I think are normally "ic", so this command > does not seem appropriate for removing "rc" packages as suggested elsewhere. A package is not "normally" 'ic'… that is your "desire" who made it so. As "dpkg -l" documents itself at the top, the first letter is a desired state, while the second is current status (and the third if present indicates an error state that is worse than the "normal" error states). So, 'rc' expresses the desire for the package to be removed and the current status is "removed, but not purged (conf-files remaining)". You could set it to 'pc' (to desire a purge) or like you did to 'ic', which would mean you desire it to be installed (again). Note that this "desire" is something used by dpkg/dselect and to some extend aptitude, but most (other) libapt-based tools including apt(-get) do not really work with it (except in fringe use cases like apt-get dselect-upgade) and/or internally while talking to dpkg. They prefer to receive the users desire directly on the command line if you want to interpret it this way. So, yes and no, ~c does indeed match 'ic' as well as 'rc', but that is because it looks at the current state – which is the same for them all, they only have conf-files remaining. Specifically, as you seem to think otherwise: "locales" in state 'ic' is not installed and behaves exactly like in state 'rc' – as in, they don't have a behaviour at all. If you want it to be installed, just install it and it will have the state 'ii'. Or purge it and it will be 'un'. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1069874: E: Problem parsing Provides line of perccli:all=007.2616.0000.0000
On Fri, Apr 26, 2024 at 08:30:42AM +0200, Harald Dunkel wrote: > If I put Dell's current debian package for perccli into my local > reprepro, then "apt update" complains Oh boy, that is some heavy package… and that not only because it claims to be 7GB large… I think the producer of that package meant 7 MB, but didn't realize that Installed-Size is in KiB, not Bytes. Anyway, this control file is not produced by dpkg-gencontrol; that wouldn't include bogus empty lines, too. Maybe you can get them to fix their package and in that process also clean it up… if they insist on producing it by hand. > E: Problem parsing Provides line of perccli:all=007.2616.. > E: Error occurred while processing perccli (NewVersion2) > E: Problem with MergeList > /var/lib/apt/lists/debian.ac.aixigo.de_debian_dists_bookworm-experimental_main_binary-amd64_Packages > E: The package lists or status file could not be parsed or opened. Seems like this was simple enough to "fix" in libapt code… https://salsa.debian.org/apt-team/apt/-/commit/c98bcdf00e5366fec101dd17094d36be21872a02 I would still advice to fix the package as this is somewhat unlikely to reach users 'soon' (with trixie of course, but I doubt that gets backports into oblivion). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1069585: apt: autoremoval forgets transitional packages in a OR dependency
Control: reassign -1 synaptic 0.91.3 On Sun, Apr 21, 2024 at 03:50:27AM +0200, Vincent Lefevre wrote: > "apt: autoremoval keeps all branches of an OR on the system even if > I don't want one". > > While I can understand the reason why this is wontfix, this reason > makes no sense on transitional packages. Instead of asking apt (and all other applications) to come up with a complex set of rules what a transitional package might be (case in point: policykit-1 is not in section oldlibs[0]) you should focus your energy on making that transition actually happen if you care that much about it. [0] https://wiki.debian.org/RenamingPackages > As an example: > > qaa:~> apt autoremove -s > NOTE: This is only a simulation! > apt needs root privileges for real execution. > Keep also in mind that locking is deactivated, > so don't depend on the relevance to the real current situation! > Summary: > Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 82 > > but policykit-1 (marked as automatically installed) could be removed: > > qaa:~> aptitude remove -s policykit-1 > The following packages will be REMOVED: > policykit-1 > 0 packages upgraded, 0 newly installed, 1 to remove and 82 not upgraded. > Need to get 0 B of archives. After unpacking 34.8 kB will be freed. > Would download/install/remove packages. > > I suppose that "apt autoremove" doesn't remove it because of > the OR dependency: > > qaa:~> aptitude why policykit-1 > i synaptic Depends pkexec | policykit-1 > > (at least, this seems to be one of the reasons). synaptics could drop the or on policykit-1 – or if for some reason keeping it is desirable make it a versioned on, like: | pkexec | policykit-1 (<< first-transitional-version~) Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1069275: apt: random display of the "Summary:" line
On Fri, Apr 19, 2024 at 02:06:44PM +0200, Antonio wrote:
> If you find the "apt autoremove --purge" command in the sequence of the
> commands I have indicated, you will notice that it appears three times:
>
> - in second position produces this output:
>
> $ apt autoremove --purge
^^^
> Summary:
> Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
>
> - in seventh position it produces the same output
>
> $ apt autoremove --purge
^^^
> Summary:
> Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
>
> but the same command, in the fifteenth position produces a different output:
>
> $ apt-get autoremove --purge
^^^
> 0 updated, 0 installed, 0 to be removed and 0 not updated.
>
> what has changed? I would always expect the same output...
(Lets play a game! Lets call it: Spot the difference. )
As Julian already mentioned, "apt" and "apt-get" have different output.
This is intended (for compat) and not random, but yes, it can be a bit
confusing if your muscle memory lets you end up mix their use.
(Note that not only their output is different; they also have behaviour
differences e.g. "apt-get upgrade" vs "apt upgrade")
As an interactive user, its is probably best to forget apt-{get,cache,…}
exist and get used to 'apt'. If that is missing something compared to
the others feel free to report a bug so we can add it – or suggest an
alternative as sometimes that might be better approach.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Bug#832473: synaptic: Cannot change mark from "complete removal" to "removal"
On Wed, Apr 17, 2024 at 12:14:14PM -0700, Philip Chung wrote: > > If I mark a package for complete removal, I cannot change the mark > > directly to simple removal. > > > > Steps to reproduce: > > > > 1. Select a package. > > > > 2. Mark the package for complete removal.[1] > > > > 3. Mark the package for removal.[1] […] > In the implementation of that method (source file apt-pkg/depcache.cc), > there is a particular check that suggests a deliberate design decision to > disallow moving from purging (complete removal) to simple removal but allow > moving in the other direction: I think the idea is that code that explicitly decided to mark a package for complete removal should not be overridden later on by code that just happens to want a package removed due to a Conflicts relation or some such. That could be resolved by looking at FromUser but the check you quoted is from 1999, while the FromUser parameter (that I added I might add) is "only" from 2009. After a quarter century of this behaviour, I am not sure it is worthwhile to "fix" this given, if I really tried, I could probably argue in favour of either way. I could frame that "decision" from 2009 a compat one given that FromUser was a new parameter and defaults to true, so that would have been a behaviour change if I had changed that… but I doubt I was thinking about that back then. So, absolutely not a fundamental design decision; just something that happened due to dumb luck/cosmic intervention/reasons. > I've CC'ed the APT team on this e-mail to get their input. If there are good (That CC'ed worked & the Fwd reached us a bit later, too. Some hop in between you, mailing list and you has probably greylisted the mail for a while making it look like it didn't reach us I suppose. No worries anyhow.) > fix." (I don't think there is a compelling reason for Synaptic to work > around this design decision in APT.) I think for an interactive graphical tool like Synaptic this behaviour of libapt might be unfortunate, but easy to work around: If you see in Step 3 that a package is marked for complete removal already, just MarkKeep it first before MarkDelete it again. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1069183: [Aptitude-devel] Bug#1069183: aptitude: already running package installs/upgrade get interrupted because of lost dpkg lock
pes that nothing grabs it in the meantime, which was the practice before dpkg gained the frontend lock (these are aptitudes own methods that wrap _system->Lock() from libapt that does acquire the frontend and the dpkg lock – and also releases both if told so). The solution here should be to hold onto the frontend lock for the entire run and do the lock dance for compatibility with the dpkg lock only. _system->LockInner() is part of that and grep has no hits for it in aptitude. So, my suspicion is that aptitude doesn't use the frontend lock and is hence prune to other front ends grabbing the dpkg (and front end) lock the moment it releases the dpkg lock for dpkg. Hence the two fails and the run of needrestart takes long enough for the other front end to finish so that the last dpkg call aptitude makes succeeds again. Someone who knows aptitude better – or at least has more than a passing interested in aptitude – should check the code to proof the suspicions made here (or disprove them of course). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068774: (No Subject)
On Sat, Apr 13, 2024 at 11:52:32AM +, mYnDstrEAm wrote: > > So, which is it: You install random things you don't care about because > > their name appeared in the kept-back list or you explicitly install that > > package from the kept-back list because you care very deeply about it? > > I and many others (this issue is not about me) install them like that because > their name appeared in the kept-back list. So it's the former and I never > said it wouldn't be that. And I tried to explain to you that many others believe in the exact opposite: That the package they asked to be installed is of course important enough for them that it should be marked manual. Just because you can find people who complain about the current behaviour doesn't mean there aren't people who like it – they just have no reason to complain. If everyone would always listen to complains we would have blasted the sun from orbit ages ago. All the glaring, sunburn and oh god, its so hot some times… and I heard the sun is the main cause of global warming… > > that isn't how apt sees it. You might remember that in a previous request > > you made apt might have said that about a package, but apt has no such > > memory > > Well then part of this would be to make it run a check if any of the packages > to be installed is currently kept-back. I never said it would have to keep > prior apt commands in mind, it just knows (can check) which packages are > kept-back. In the usual scenario the notice about a kept-package displays > during an apt-get upgrade/update command. 'update' doesn't display something about kept back because that makes no sense. kept-back is a property of the specific request you just made: Just like all the other packages listed as new, remove or upgrade. A package might be phased (repository) or put on hold (user) and for that reason appear in kept-back (or not, as said, phased is display nowadays in another list), but that is still related to the request as if you explicitly request that package name they are not considered kept-back and while the kept-back-reason package-was-put-on-old-by-user is checkable (and apt checks that and even prints a warning about that: Changing held packages) most reasons for kept-back are not as if you explicitly install a package the question if other packages can or should fiddle with its state never arises. "Worse" it might lead to other packages being kept-back like the other side of a transition that was previously winning the tug of war. Your sysv-rc-conf is kinda an example: A normal upgrade doesn't do it because it is deemed not a good idea to prefer this over 20 other packages. Removing the package serves no real purpose either through, at least not if the user isn't asking for it – after all, who likes packages being removed needlessly. If you explicitly request the installation that is no longer the case: Everything is okay for the benefit of respecting the user request, so 1, 20, or 2000 pkg to remove are not a problem even if it includes systemd-sysv, the default init process and the only one many packages are nowadays prepared to work with. Any package who looses the ability working with anything else but systemd-sysv would in that scenario be kept-back even through it happily upgrades if you don't ask for sysv-rc-conf explicitly. > > based on your explicit manual install request > > This issue is not about installs that are explicitly manual and it shouldn't > be merged with other issues that are about something else. You enter "apt install some-pkg". That is an explicit manual install request for some-pkg. Just because you wish it to be something else doesn't make it true. The observable difference is if some-pkg was previously not installed (in which case it is installed and tagged manual installed) or if some-pkg is currently installed. For the later, two cases exist: Either the candidate version is installed or it is not which both want to ensure the same outcome: The candidate version is installed. The only question that arises is: Should that ALSO, like the first scenario set the package to manually installed given its installation was manually requested. The answer so far is yes – and you insist on it being changed to no, while I keep telling you that there are usecases/scenarios for both, so an acceptable compromise might be to implement both and offer a choice… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068823: Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device"
On Thu, Apr 11, 2024 at 04:46:03PM +, mYnDstrEAm wrote: > With the two commands above one can already split it up into two steps but > especially the second command still requires a lot of disk space. I am going to assume that your "a lot of disk space" stems from the *.deb files that are downloaded. If so, you can e.g. attach an USB disk/ drive and mount it e.g. under /media/apt-archives Tell apt to use that directory instead of /var/cache/apt/archives, e.g.: apt upgrade -o dir::cache::archives=/media/apt-archives (for some more free MBs you could 'apt clean' and then move dir::cache elsewhere, but for that you need to create some directories in the target location and the binary caches are not THAT large to make it really worthwhile in practice. Similar for other files like /var/lib/apt aka dir::state::lists) Instead of an USB drive you could do the same with e.g. an SD card, drop them into RAM (if your device has surprisingly more RAM than disk) or even use a network share (NFS, sshfs, … you name it). The filesystem is not usually a concern (as in: even fat32 should work given we encode away the : in epochs). Note that whoever has write access to the files on the storage (or in case of unencrypted transfer, also everyone who can meddle with transfer over the network) could use that to attack you as apt (well, apt will casually check them first, but after that and dpkg, who actually interacts with them the most) will assume that the files in /var/cache/apt/archives (or where ever else you stored them and told apt to use them) are valid & trusted. Note also that apt uses for its space check statvfs(3) f_bavail, as in, depending on how you configured your disk, it should have a couple of additional free blocks in reserve (typically 5%, see tune2fs(8) -m). If you know what you are doing, you could decrease that value. Note that the value apt displays is only an estimate, powered by what the individual packages claim (via dpkg), which is an estimate. Also, if you happen to have a 2GB installed, the upgrade will roughly take an additional 2GB as dpkg would first extract the new files along the old ones and then replace them in one swoop – so for a bit, you have that package installed two times. Multiple this by group size, divide by unchanged files and sprinkle some salt over it for flavour. Predictions are hard, especially about the future. I would in general not recommend to try approaches like upgrading individual packages as that easily leads unsuspecting users into situations that nobody else has encountered before: aka bugs in packages that nobody else will encounter as they are either hidden by the involved set usually being upgraded together as intended™ or – which tends to be even worse – the breakage is known but ignored on purpose as the solution is far worse than the problem (at least for everyone doing upgrades the normal way – example: usrmerge). Also, but that is just an aside, people grossly overestimate how easy it is for packages to be upgraded individually (compare: t64 testing migration). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068774: (No Subject)
On Thu, Apr 11, 2024 at 10:43:38PM +, mYnDstrEAm wrote: > > You found with #956330 already a feature request that asks for that > > No, that other issue is not about kept-back packages in specific. I don't see > how the functionality of that issue would be very useful but for kept-back > packages asking the user or by default not marking them as manually installed > could be very useful and seems more like what one would expect it to do. So, which is it: You install random things you don't care about because their name appeared in the kept-back list or you explicitly install that package from the kept-back list because you care very deeply about it? APT isn't keeping back a package because its bored. It has reasons, different ones even, and the general reply from a user to it should be: "Okay" and not "Lets try to force it". In some cases that force will not work and end in failure (unsatisfied dependencies), in some cases it will lead to non-optional solution which might lead to problems later on (unsatisfied recommends), sometimes its an ongoing transition that apt decides to wait on instead of applying (which usually means a bunch of stuff has to be removed), sometimes the distro itself decides that newer versions are shipped piece meal to different users to avoid potential issues hitting them all at once (phasing) and sometimes a user has explicitly put that package on hold. I probably forgot a few more possibilities. > This is about kept-back packages where install is used to make them install. No it isn't because that isn't how apt sees it. You might remember that in a previous request you made apt might have said that about a package, but apt has no such memory. What would that memory even be given that your last request could have been something between complete bogus you would prefer to pretend to have never entertained and a heartfelt "I can't do without you" plea. Would that memory be time bound: If its two seconds later, its related, but if it was last week, it is not? That would turn quickly into a complete mess of unpredictable behaviour. So, even if you think you are forcing apt with an install request to install a package version it decided to keep back in a previous request, for apt you are "just" asking it to install the given package, period. apt could ask about if it should modify the auto/manual installed state based on your explicit manual install request (<- note the wording choice) for a package you attempt to upgrade (compared to new install), but it currently doesn't and that is what the request I merged it with is talking about. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068774: When installing a package that is kept back with apt-get install do not mark it as manually installed or ask the user whether the mark should be added
Control: forcemerge 956330 -1 On Wed, Apr 10, 2024 at 09:53:39PM +, mYnDstrEAm wrote: > Could you please make apt not mark packages as manually installed when > installing packages […] You found with #956330 already a feature request that asks for that, so I am merging this one with it as even in the best case this could only be considered a sub-task (if at all). > […] that have been kept back in specific? Note that "phases upgrades" have their own listing now, but you might be better of asking in Ubuntu support channels about this as Debian doesn't use the Phasing feature at all. > Alternatively, the user could be asked whether they want to have it marked if > the mark would be added but I think most users would not want that. In #956330 Алексей Шилин actually makes a good point about an install request having predictably the same outcome. In any case, I think in part this comes from a conceptional disagreement: I don't think 'install' is meant to "force" an upgrade of a package, but it can have that side effect and so some users end up using it for that side effect: > It makes little sense and only causes problems, partly because they then > won't uninstall when removing packages that depend on them. You mean they are protected from autoremove, right? Well, see, that is the thing: If you don't use 'install' to force random packages to upgrade it turns out that you 'install' things you care about and don't want removed as unneeded later on… But how should apt differentiate between "apt install firefox": - I dislike Chromium, let me try out this other browser - … that I had never installed before - … that I had installed in some old version years ago - … that happened to be removed recently - … oh, I have it already installed? Didn't know! - … that I have already installed as a dep, but now I am active user! - New version is phased, but I want it now now now because - … that's my beloved browser I want always latest and never removed - … friend said I should test this new version early - … I have no idea what it is, but upgrades are good, right? - Critical security bug! The announcement tells me to upgrade - … no time to upgrade everything, lets just pick that one - … unattended-upgrade did it all before me - Whoa! autoremove tells me it wants to remove my beloved browser, lets install it explicitly to make it stop that - Ups, I let autoremove remove it! Lets rectify that mistake! And that aren't even all… so I certainly have some sympathy for the predictable outcome mentioned and conversely not putting too much value in what it means that a package is marked manual or auto installed as it effectively just guards against suggesting auto-removing packages the user somehow showed they cared about at some point with a failure mode of just keeping some dead weight around. Giving it more value means we would need to involve users a lot more in the management of it, which many would probably be happy to do, but many also not appreciate much given the failure mode is so low key. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068637: apt does not always install Recommends
Control: reassign 1068637 debian-installer Control: reassign 1068560 debian-installer Control: forcemerge 931283 1068637 1068560 Summary of bug(s) so far: lvm2 installed by d-i without its Recommends Question: Can we solve this once and for all or do we need/want a workaround and/or downgrade for lvm2 only to make user happy [only pun intended] Merging both into #931283 that seems to be about the same thing. On Tue, Apr 09, 2024 at 02:17:18AM +0200, Vincent Lefevre wrote: > Then, I don't know the internals. But according to Bastian Blank[*]: > "It is installed like everything else." (but see the details below). > > [*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068560#22 He likely meant that you have installed it, "like everything else" because that is what users usually do and you weren't particular clear that you haven't – and what you used that did for you… lvm2 isn't "a core package", so there are certainly ways of installing Debian (even with d-i, which isn't the only way either) without lvm2. d-i seems to install packages without recommends: https://salsa.debian.org/installer-team/base-installer/-/blob/master/library.sh?ref_type=heads#L152 That is later dropped for "everything else", but I suppose lvm2 is installed before that – but I don't know much about d-i or lvm2. Anyway, it probably isn't a good idea to have d-i install all recommends while it sets up the machine – better things to do and all that –, but perhaps it can as one of the last actions (final_apt_preferences ?) run something like: | apt-get install --fix-policy (after the config is removed, or add --install-recommends). Likely involves demoting some 'Recommends' in the base set to 'Suggests' through, but they behave like that already if installed by d-i, so that is probably for the best for consistency alone. In any case, I will leave d-i folks have fun with this now, but feel free to ask apt-team if there is something we can help with. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068637: apt does not always install Recommends
On Mon, Apr 08, 2024 at 01:05:40PM +0200, Vincent Lefevre wrote: > On 2024-04-08 12:29:17 +0200, Julian Andres Klode wrote: > > On Mon, Apr 08, 2024 at 11:50:04AM +0200, Vincent Lefevre wrote: > > > The lvm2 package is installed, but not thin-provisioning-tools, > > > though lvm2 recommends it. This can yield a broken system: […] > It is not mandatory in all cases, but it some cases. In any case, > the "Recommends:" must be honored. You haven't mentioned AT ALL if we are talking about upgrade or a fresh install of lvm2, for the later see below. For the former: Are you absolutely, positively sure that you haven't ignored apt (aptitude) telling you that it wont install that recommends while installing lvm2? APT (and aptitude?) do not install old unsatisfied recommends on an upgrade, so the only way of not getting thin-provisioning-tools installed is either to not have it installed while it was new in which case apt (and I think aptitude has somewhat similar) output contains: | Recommended packages: | thin-provisioning-tools Same for Suggests btw which aren't installed by default (but lvm2 has none). Or you have removed thin-provisioning-tools at some point after it was once installed. And yes, as Julian explained, if a package is not installable, that also leads to a recommends not being installed but same output. (I somewhat doubt you have managed to install an lvm2 which had not yet a recommends on thin-provisioning-tools and upgraded that now to a version with that recommends. That would be a new recommends that apt tries to install, but might fail for reasons Julian mentioned already. Different upgrade-commands-implementations have different approaches to that – 'apt upgrade' e.g. tries to detect that and holds the upgrade off it does, while 'apt full-upgrade' ignores that. Both work better if the archive is a stable state… which tends to be the case with stable for obvious reasons. Less so for unstable.) > No, lvm2 was installed before the time_t transition. It actually > affects plain bookworm installations (on a machine where I installed > Debian 12.1 on 2023-10-07); you can see with the attached > "dpkg --get-selections" output I had at that time. What time? Before you installed lvm2? That output says lvm2 is installed. So after it, but what are you trying to tell us then? That you had lvm2 installed, upgraded it and it still didn't install thin-provisioning-tools? Well, as explained above, working as intended. I just bootstrapped a minimal stable chroot with mmdebstrap and behold: | # apt install --install-recommends lvm2 | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | The following additional packages will be installed: | dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 liblvm2cmd2.03 thin-provisioning-tools | The following NEW packages will be installed: | dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 liblvm2cmd2.03 lvm2 thin-provisioning-tools | 0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded. | Need to get 2662 kB of archives. | After this operation, 9729 kB of additional disk space will be used. | Do you want to continue? [Y/n] n | Abort. In other words your issue with a "plain bookworm" install is unreproducible (My chroots are configured to not install recommends by default, so I enable it explicitly on the command line here. There is no difference in behaviour for apt. I think aptitude reacts differently, but who knows). If I leave out the flag apt tells me it wont install the recommends as shown above. What am I doing wrong, where is the bug? So, if you want to have any chance of us investigating your problem as a bug rather than as a user-error you will have to tell us what you did exactly, preferably with easy to follow steps and output. Failing that, on your bookworm install you might be lucky and still have the installation/upgrade and such of lvm2 in your history.log(s). That might shine some light on it as well. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1067767: dpkg-gencontrol: Don't fail on syntax error in removed field
Package: dpkg-dev
Version: 1.22.6
Severity: normal
X-Debbugs-Cc: debhel...@packages.debian.org
Hi,
since recently my arch:any package `ycmd` fails to built from source in
a fresh unstable sbuild environment with at least dpkg 1.22.6 and
debhelper 13.15.2 (compat 13) while generating the dbgsym package:
|dh_gencontrol
-O--sourcedirectory=/<>/ycmd-0\+20231230\+git9e43034\+ds/cpp
-O--builddirectory=/<>/ycmd-0\+20231230\+git9e43034\+ds/ycm_build
| dpkg-gencontrol: warning: can't parse dependency ycmd-core-version (= )
| dpkg-gencontrol: warning: Depends field of package ycmd: substitution
variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package ycmd: substitution
variable ${python3:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package ycmd: substitution
variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Recommends field of package ycmd: substitution
variable ${misc:Clang-Ver} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package ycmd: substitution
variable ${misc:Core-Ver} used, but is not defined
| dpkg-gencontrol: warning: can't parse dependency ycmd-core-version (= )
| dpkg-gencontrol: error: parsing package 'ycmd' Provides field:
ycmd-core-version (= ), ycmd-core-version (= 48)
| dh_gencontrol: error: dpkg-gencontrol -pycmd -ldebian/changelog -T/dev/null
-Pdebian/.debhelper/ycmd/dbgsym-root -UPre-Depends -URecommends -USuggests
-UEnhances -UProvides -UEssential -UConflicts -DPriority=optional -UHomepage
-UImportant -DAuto-Built-Package=debug-symbols -UProtected -UBuilt-Using
-UStatic-Built-Using -DPackage=ycmd-dbgsym "-DDepends=ycmd (=
\${binary:Version})" "-DDescription=debug symbols for ycmd"
-DBuild-Ids=dc609a05ca957392f347883f157f1d84a1561dbe -DSection=debug
-UMulti-Arch -UReplaces -UBreaks returned exit code 25
| dh_gencontrol: error: Aborting due to earlier error
| make: *** [debian/rules:19: binary] Error 25
(`vim-youcompleteme` also from me uses something similar but doesn't
fail to build – that one is arch:all and doesn't have a -dbgsym)
The incorrect syntax comes from debian/control containing:
| Provides: ycmd-core-version (= ${misc:Core-Ver}), […]
and dpkg-gencontrol being called with -T/dev/null here (by debhelper).
I am not quite sure if dpkg or debhelper caused this regression with the
recent changes around substvars, but given that a substvar can only be
used to modify the contents of a field and can not embed other fields
in the modification it seems reasonable that if a field is removed from
the output with -U (or overridden with -D) dpkg-gencontrol should not
insist on its syntax being correct – or even warn about undefined
substvars within – as it will have no effect on the output and as
such this might be considered a feature request potentially fixing
a regression (and is as such upgraded from wishlist to normal):
I could easily resolve this error & ignoring the warnings by letting
the entire provides being generated instead of just the version number
here as a simple workaround, but given the choice I would prefer what
I have and it doesn't seem that strange, so others might be effected.
That might very well be a bug in debhelper (too), as I assume it does
this dance to have some fields copied from the package to its -dbgsym
offspring, which could contain substvars and hence the -T/dev/null might
be the regression here, but I am not sure as I did not dare too look too
deeply under the hood (or in version control) for the time being.
On a sidenote, while writing this, using "misc:Core-Ver" seems silly…
but deb-substvars(5) doesn't seem to offer a hint at a reasonable naming
scheme less likely to conflict with future changes. Other packages use
":" which seems more reasonable at a glance, so might that
be a good suggestion that could be added there?
Best regards
David Kalnischkies
P.S.: I do consider my sbuild setup reasonably normal/standard, so
I spare you the details, but I am happy to add them if it turns out
I am more of a unique snowflake here than I am assuming.
signature.asc
Description: PGP signature
Bug#990451: [EXT]Re: Bug#990451: (no subject)
On Fri, Mar 15, 2024 at 07:24:32PM -0700, Chandler Sobel-Sorenson wrote: > David Kalnischkies wrote on 3/13/24 2:28 AM: > > What would this achieve; what is the use case? > The use case is when a repo has too many versions of a software on it. > I'd only be interested in seeing the details for the Installed and > Candidate versions, so even my initial --versions suggestion is not good > enough for that. So, your request is to add a saw-blade to a hammer just in case you might have a need for tree chopping with policy some day? If you are about details about specific versions, I would suggest using e.g. "apt show foo=version" or "apt show foo" (= that displays only info about the candidate) or "apt show foo/now" (= currently installed). Or go crazy with some apt-patterns(8). Or, you use "apt-cache show foo" (for info about all versions) and select with some (dctrl-)grep'ing. > […] > Fax mentis incendium gloriæ culpum et cetera, et cetera... > > Memor bis punitor delicatum! Omnia dicta fortiora si dicta Latina.¹ I wasn't quiet sure if you are serious or not, but I see now that you are indeed just trying to troll. Very funny. Did I pass the test now? Can't wait for my life time supply of chocolate, Mr. Wonka. Reference: https://yewtu.be/watch?v=WW2qaBJWdaA (many more videos show a bit more or less of the scene – that one just has hard coded subs; spoiler alert for "Willy Wonka & the Chocolate Factory" from 1971 …) > > Best regards > You sure? "You lose! Good day, Sir." David Kalnischkies ¹ everything sounds more impressive when said in Latin signature.asc Description: PGP signature
Bug#1065831: document package specifiers for `upgrade`
(this reply has nothing to do with the bugreport in question) On Wed, Mar 13, 2024 at 10:00:56PM +0100, Miguel Angel Rojas wrote: > >> Julian provided an explanation in #74, > 20240312113620.ga1944...@debian.org > > I can't access this link.. It isn't a link, it is a message id of an email. Your mail client (or web frontend or whatever) should find the mail if you search for it – assuming you got that mail and haven't deleted it in the meantime of course. You can also make it a link by prepending https://lists.debian.org/, aka: https://lists.debian.org/20240312113620.ga1944...@debian.org That will search for the mail in Debians mailing list archives. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1065831: document package specifiers for `upgrade`
On Wed, Mar 13, 2024 at 09:44:02AM +0100, Miguel Angel Rojas wrote: > > If "apt upgrade" is saying that it removes packages, that is a bug, yes. > > @david: it is not a bug, apparently. Yeah, but for different reasons. I know that exists & even use it frequently… but its two different things for me as the modifiers are from the user and as such always correct and intended while what upgrade performs later on has restrictions applied (again from the user). Having the same restrictions that upgrade has also apply for the modifiers would make them less useful and in some sense be second guessing the user as they asked for this to happen… (modifiers btw is not a good word. I guess it was never documented so far partly as this is a rather advanced feature and mainly because naming things is hard) So, I said "apt upgrade" meaning exactly that, not "apt upgrade foo-". That could be interpreted in slightly different ways, but given how our other commands behave it seems most sensible to interpret it as: After the upgrade, foo is not installed, which if foo is currently installed means remove it. More frequently it will mean through that foo should not be part of the solution (as in, it is e.g. a non-pick for resolving an or-dependency, so e.g. not installed as a NEW package). An alternative interpretation could have been: Do upgrade all but foo, but that can be achieved differently (e.g. foo/now) and would be rather specific for upgrade, while behaving differently elsewhere. And yes, "apt upgrade foo" can lead to bar being removed, which seems surprising at first, but that depends on the foo. If its e.g. exim vs postfix that is clear for the user based on what those packages represent. I just tried, "--no-remove" catches that, it also catches "foo-" through which I am not super-happy about and I think we have a bug report for open… but I could see that go either way and in any case that leads us further away from the initial topic. > In the meantime, while the documentation is modified, can some developer > provide some explanation to the current "apt upgrade" behaviour? (*) […] > (*) I'm a bit confused because I don't know which of the people involved in > this bug are actually a developer of the apt package ;) Well, does it really matter who is and who isn't? I suppose we could have a borderline philosophical discussion about what makes someone an APT developer given this is a muddily self-defined non-delegated accumulation of people who for some reason feel some sort of responsibility for and/or derive enjoyment from it; like most other teams in Debian. We could look at uploaders, changelog entries, commit history or access right on e.g. salsa… but if either of those provide the full picture? Anyway, I suppose for practical proposes you can think of Julian and me as main APT developers in terms of who do the most and as such stir it in recentish years. If you are asking if that behaviour was added intentionally: https://salsa.debian.org/apt-team/apt/-/commit/d8a8f9d7f01c75a7bbad7a488bf359a94291d1de That said, you can be an APT developer, too: Propose the documentation text you had hoped to find in the first place. Nobody is born an APT developer, they are chosen based on their patch offerings… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#990451: (no subject)
On Wed, Mar 13, 2024 at 12:35:14AM -0700, Chandler Sobel-Sorenson wrote: > I concur and also request `--no-all-versions` apply to `apt-cache > policy` command as well. What would this achieve; what is the use case? I literally see no point in having 'policy' limited to a single version (and which one?) given its usually used to show which versions are available from where, how the pin values are for those and which one is considered the candidate as a result of that. > Perhaps, instead, a new option with argument `--versions=N` could be > implemented, allowing a limited number of versions to be returned, with > `--versions=0` or `--versions=none` being the equivalent of > `--no-all-versions`. Uhm… beside that the --no-all-versions flag switches the display from "display all versions" to "display the candidate version only" in e.g. 'show' (and one or the other is the default in apt-cache vs. apt), so the equivalent would be more like '1' … and '0' would display nothing? How would --versions=3 behave through: Assuming I have 5 different versions available in the sources, which of these are displayed and which are not… regardless of the choice, this seems rather unintuitive to discover without many paragraphs of documentation that basically duplicates the code in prose text. Again, what would this achieve and what is the use case for this? Sidenote: If a specific task has no people interested in working on it, its not a good idea to add additional tasks as that is the moral equivalent of saying: "Nobody bought it for 5€, lets ask for 20€"¹. Either create a compelling new task referencing related ones or much better yet do work on it yourself. Its open source after all and nothing will ever get done if everyone hopes someone else will do it. Best regards David Kalnischkies ¹ well, I suppose for e.g. life style products that might work, but somehow I doubt we can "sell" requests as a life style product… signature.asc Description: PGP signature
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
On Mon, Mar 11, 2024 at 05:09:47PM +0100, Miguel Angel Rojas wrote: > Yes, it is confusing for me too. Without considering this t64 migration, > “apt upgrade” should *NOT* remove any package (just upgrading a package to > a newer version or install new dependencies). But it is removing packages > right now! i.e. again, with this t64 migration, it makes the old libraries > to be uninstalled and install the new *t64 version. > > Any thoughts why “apt upgrade” is removing packages even when documentation > says it shouldn’t? or is it a bug? If "apt upgrade" is saying that it removes packages, that is a bug, yes. Please run: apt upgrade -s -o Dir::Log::Solver=/tmp/apt-upgrade-bug.edsp.xz (as normal user; the -s enables simulation so nothing bad can happen) That will create a /tmp/apt-upgrade-bug.edsp.xz file (a few MBs big) you can sent to me (it might be too big for a bug and/or the mailinglist). That file contains information about all packages currently available to you and which of them you have installed – as that changes quiet often and its near impossible to reproduce a problem, especially while a big transition is underway, otherwise. If that package-removing upgrade happened in the past, you can look it up in /var/log/apt/history.log – far less details and harder to reproduce, but at least some chance… I do have to note that I am somewhat dubious through. I have heard that claim quiet often recently and so far it turned out not to be an "apt upgrade" invocation in the end, confusing it with autoremove remarks or didn't expect that some non-t64 and t64 packages became co-installable… but never say never. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1061169: aptitude: "aptitude install debhelper-compat" fails with "virtual package provided by: debhelper debhelper debhelper"
(drive-by comment from an apt maintainer) On Sat, Jan 20, 2024 at 06:30:34AM +, Askar Safin wrote: > - Type "aptitude install debhelper-compat" > > The command will fail with the following absolutely absurd message: > > # aptitude install debhelper-compat > "debhelper-compat" is a virtual package provided by: > debhelper debhelper debhelper debhelper debhelper > You must choose one to install. > Unable to apply some actions, aborting debhelper has (currently) five versioned provides. I think aptitude doesn't support/expect versioned provides here (if at all): src/cmdline/cmdline_action.cc:278 ff although there are other places where a similar message is generated in src/pkg_item.cc and src/gtk/entitysummary.cc. Would be a good idea to check if a package is already in the pkgvector before adding it again – or make that vector a set. Note that libapt has wrappers like APT::PackageSet nowadays which should work better and more natural than typedef'ed std-containers… but that transition might be a bigger effort than just adding an (untested) `if (std::ranges::find(possible, j) == possible.end())` before the push_back. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1061148: apt: option -a has several meanings and is unusable
On Fri, Jan 19, 2024 at 05:10:40PM +0100, Vincent Lefevre wrote: > The -a=... version is not documented in the manual, only -a alone, Compare -t, which also doesn't say -t=foo. Probably mostly due to -t foo working as well or just because the manpages like their inconsistencies and would deserve some love, but who has the time to not just complain but also actually write all of it… (reordered for posterity) >-a, --host-architecture >This option controls the architecture packages are built for by >apt-get source --compile and how cross-builddependencies are >satisfied. > > There are 2 verbs "controls" and "are built". And I don't see how > to parse "for by". A package is "built for" the given (with -a) host architecture by "apt-get source --compile" – aka its instructed to cross-compile a package for the given host architecture instead of doing a "normal" compile where host and build architecture are the same. So, "apt-get source -b -a armhf foo" will (simplified) build a "foo_armhf.deb" on your (likely amd64) machine to be used on another (probably less powerful) armhf machine. Similar for build-dep, just that this won't build anything but interprets certain dependencies differently. Using the option properly requires preparations that would fill their own manpage to explain properly and its certainly not APTs place to do that as it is just a tiny cog in the cross-machinery. > Still, I don't see what this option does. So, long story short: You would if you would need that option, but you don't need it, so you don't. --print-uris prints URIs; nowhere is explained what URI stands for, it is just assumed that people who need it will know. Hey, quick, what is a "build profile" and can you name a few? Now go and ask that question another user and see how that goes. >By default is it not set which means that the host >architecture is the same as the build architecture (which is >defined by APT::Architecture). Configuration Item: >APT::Get::Host-Architecture. > In the next sentence: "is it". Should this be > "it is"? The comma is missing before "which". Perhaps it should, "is it not" has the hint of a question. In German I would write such a sentence without a comma as the added phrase isn't [that] optional, but not sure if a German – or English – teacher would actually agree on me claiming "definition phrase", which are not separated by commas in both languages. Could easily be done without a which if we were really trying. Doesn't matter that much through as I would agree that the manpage(s) need a revamp, but certainly not by me and not based on this. For this specific option in particular, 99% of the user base are probably better served if we were to remove its documentation entirely. What about the 1%? Well, they deserve to write the patches to improve the manpage and potentially fixup the translations (depending on how much they reword here). [Case in point, the option as documented doesn't work for years and nobody noticed – because 1% was an overstatement already; fixed in git] Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1061094: mmdebstrap vs. apt -o DPkg::Inhibit-Shutdown
tl;dr: Fine by me, just some explaining comments for the record.
On Thu, Jan 18, 2024 at 12:54:45PM +1100, Trent W. Buck wrote:
> This MIGHT affect someone else doing "apt -o Dir=⋯" to do custom installs, but
> everything I can think of offhand is a wrapper around debootstrap, except for
> https://github.com/openSUSE/obs-build/blob/master/obs-docker-support#L118
This one sets different sources.list files, doesn't change Dir and is
hence still effected by the inhibit… except that this probably runs
somewhere in docker, so likely without dbus, systemd and what not.
> Everything I can find seems to set e.g. Dir::Etc rather than Dir itself.
>
> https://codesearch.debian.net/search?q=apt.*-o.*Dir%5B%5E%3A%5D
> https://github.com/search?q=%2Fapt.*-o.*Dir%2F=code (requires
> Microsoft account, requires javascript)
Just for the record: To find more users you would need to look for
RootDir as well, which was used heavily before Dir. Looking for scripts
setting these options on the command line is probably not catching a lot
of users as command line parsing happens pretty late – after config
files are read – so setting {Root,}Dir is usually done in a config file
given via the APT_CONFIG environment variable.
Case in point: Our very own test cases do something akin to chrootless
mode of mmdebstrap with APT_CONFIG and Dir … and now I wonder how often
those tests inhibit and release the block on shutdown. I guess I never
tried to shutdown while running our tests. ☺
Also, as this is libapt, this isn't apt specific, could potentially be
used via apt-get, aptitude, python-apt, libapt-perl, synaptics, your run
of the mile software center, … its just increasingly unlikely.
A usecase I could imagine is someone trying to recover his main system
from a live CD. If your main system is sufficiently broken that
chrooting into it doesn't really work you could operate on it from the
outside similar to mmdebstrap (after all, the to be bootstrapped system
is sufficiently broken… given it doesn't really exist yet).
Anyway, this is a relatively new safeguard (60cc44d160 – April 2019)
nobody should really hard-depend on: Having it inhibited for too many
or for too few by default isn't that big of a problem and if someone
cares either way they can always set the option explicitly.
Given it is mainly supposed to avoid accidents for users who don't
interact with apt directly Dir == "/" is probably the closest we can
be to a sensible default value for the inhibition here if we ignore
that ideally the front ends would do the inhibition instead of our
low-level library, but that ship sailed…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Bug#1061048: RFS: RPGMod/1.3 ITP -- heyo!
On Tue, Jan 16, 2024 at 07:42:09PM -0300, peq42 wrote: > I am looking for a sponsor for my package "RPGMod": Package names are lowercase. No idea about the package or what it even is, but it looks a bit and mentions games, so the Debian Games Team might be a good place to find people/sponsors who know the field and can give hints: https://wiki.debian.org/Games/Team > * URL : http://peq42.com I suppose: https://peq42.com/projects/rpgmod/ > * Vcs : https://peq42.com/downloads/RPGmod%20-%20Linux.deb "Vcs" means "Version control system", while optional its strongly recommend to use one (also for your upstream development). Look it up on your preferred search engine; it might change your life. > Alternatively, you can download the package with 'dget' using this command: > > dget -x https://peq42.com/downloads/RPGmod%20-%20Linux.deb Usually, you upload a source package that builds one (or more) binary packages (= the deb files). Your deb uses zst as compressor, so I guess you built it on a semi recent Ubuntu release (older versions might have problems with it, Debian releases even more – read-only support exists rather recentish). You don't need to know what the first part of that sentence means to be a good packager (but feel free to look it up if you are interested), but packages for Debian should be built in the Debian release they are targeting (for a new package, that would usually be 'unstable') – you can use virtual machines, chroots and what not for that and use e.g. tools like sbuild. Your package installs (most) things in /opt – that isn't suitable for packages targeted at the Debian archive. I also note that your package claims to have no dependencies whatsever, which I find somewhat hard to believe even if it is technically possible. > additional comments: > I'm sorry if this e-mail is not exactly perfect or if anything is missing, > this is my first time packaging and submiting a package to the debian store. > I setup the package using my personal e-mail(gabrielpm2...@gmail.com) and > real name(Gabriel), but for the sake of lowering spam I get there, if > possible, utilize this one(admi...@peq42.com) in the store You can give any mail you like in the packaging… personally I am using my @debian.org address in the packages and my personal mail for communication on this and other lists, reply to bugreports and so on. Others do the reverse. None of it will help lower spam though as nobody and nothing can avoid an (un)healthy dosage of spam. Note that Debian doesn't have a "store". We have repository(s) which can mean the same thing and actually pre-dates stores, but usually involves a different mind set: (Personal opinion follows) We don't "sell" individual packages as products, but an entire catalog of 70.000+ packages that work (and play) well together. As said, I haven't looked too closely at the package, but even so I think you will need to invest a lot more work into making it fit for the Debian archive… or in other words: lots of documentation to read, policies to follow and friends to make on and off list(s). Good luck & Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.
Hi, On Thu, Jan 18, 2024 at 02:35:40PM +, Aidan wrote: > I am looking for a sponsor for my package "dpkg-buildenv": Similar to my recent "veto" of apt-verify in #1059267, which was subsequently ignored and pushed into the archive anyhow, I would like to call into question the naming of the package/application… There are various "dpkg-build*" tools already that grabbing 'env' feels wrong (I would confuse it probably with 'flag' on a bad day), especially if that isn't at least discussed with dpkg maintainers (I at least see no mention of it on the list) and given that this is something that "just" works with Docker. As explained in the other bug, there is no veto and as you can see its easy to completely ignore me (and anyone else) but I wanted to say it anyhow, so that nobody is surprised later on. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#922021: Bug still present in Apt 1.4.10
On Mon, Nov 06, 2023 at 04:59:56AM +0100, Christoph Franzen wrote: > I'm observing the same on Bullseye 11.6. […] > Apt is version 1.4.10 from Stretch. You are giving mixed signals here, you are either observing this on bullseye which is Debian 11 (current oldstable) with apt ~2.2.4 or you are indeed on stretch which is Debian 9. "no complete dist-upgrade" is not the same as hanging somewhere between (at least) three major Debian releases… fully upgrade to one release, everything else is a security as well as support nightmare. It isn't only that packages from 11 aren't tested on 9, they are not even intended to work on them as many maintainers intentionally "break" them (like removing obsolete version requirements). > If I move those problematic symlinks out of the way, they are > re-created. I have a system (fully upgraded, I might note) from between squeeze and wheezy to trixie (it follows unstable) which doesn't have your problem. I have set up an oldoldstable chroot (that is Debian 10 aka buster) and added your sources to no ill effect. I even went as far as creating a bad symlink (ln -s /var/lib/apt/lists/archive.debian.org_debian_dists_jessie_main_binary-amd64_Packages archive.debian.org_debian_dists_jessie_main_binary-amd64_Packages.xz) before a first and before a second run of apt update. Both behave the same, no ill effect and the bad symlink is even removed from the partial directory… I then set up a stretch (Debian 9) chroot which I was somewhat surprised that mmdebstrap managed to do that without issue and tried with 1.4.10, the version you claimed you were using, not seeing your issue either. So, you will have to provide more details upon how whatever you are seeing is reproducible. As a start, it might be a good idea to show us the entire output of: find /var/lib/apt/lists cat /etc/apt/sources.list /etc/apt/sources.list.d/* apt update find /var/lib/apt/lists And not cut that down to what you believe to be important. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#229775: apt 2.7.7: build-dep doesn't work if priority is 499
On Wed, Jan 03, 2024 at 11:13:49AM +, Askar Safin wrote: > Okay, then please apply the following patch. :) > (Or something with similar meaning.) > Feel free to close the bug when > the patch is released. This report is not about you and your misinterpretations. > -Subject to dependency constraints, apt-get selects the > +apt-get selects the You realize that you make it worse with that change, right, given I gave a few examples in which apt-get DOES NOT do what your + says and explicitly follows "dependency constraints" as said in - and by default, its just that it doesn't do that always because that would be – in your words – incorrect; at least according to the other constraints it has for a solution. > +If picking the version with the highest priority leads to violation > +of dependency constraints, then sometimes > +apt chooses low-priority correct version instead of high-priority ^^^ > +incorrect one. But sometimes apt simply fails with an error message ^ In my previously given example foo-a and foo-b, please explain in detail which version of bar is the correct vs. incorrect one. If you can't do that you might want to reevaluate if a binary believe system is adequate to represent the dependency world. Many people tried before you, its called SAT solving and works great if you give it problems not involving a choice as e.g. removing your entire system is also a valid solution according to dependency constraints, its just not a good solution for users, but users are not a constraint for general propose SAT solvers. Is that good/bad or correct/incorrect? Yes, no, maybe, depending on your use case: Use the right tool for the current job at hand. > +high-priority incorrect version in such situation, then use other package > +managers instead of apt. I already told you that you don't even need to use another package manager, you just have to use one of many possible non-default options depending on how far you wanna violate other constraints. Not gonna repeat myself (and Johannes) for the third time… Please ask in user support channels if you have further questions about what the right tool is for a given use case and how to use it correctly. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#229775: apt 2.7.7: build-dep doesn't work if priority is 499
On Tue, Jan 02, 2024 at 06:05:03PM +0300, Askar Safin wrote: > It follows from my interpretation of the phrase "Subject to > dependency constraints" from "man apt_preferences", that > first apt should exclude logically inconsistent solutions. So it I understand what you mean, but that isn't the intended interpretation – at least not in the universal applicability you want it to have. Imagine this: Package: foo-a Depends: bar (>= 2) Package: foo-b Depends: bar (<= 1) If logical exclusion would really be our fist principle here bar is likely to flip-flop happily between version 1 and 2 depending on which foo the user has most recently "forced" upon the system and the upgrade state is at least in doubt: An old, outdated, potentially dropped from Debian, foo-b is holding back bar for all of eternity due to "dependency constraints". Hopefully bar isn't server software with giant security bugs… apts strategy to avoid this and similar problems is to pick an installation candidate for all packages before its considering if it has to install anything at all. This is what preferences is all about, defining which version will get to be the candidate. Other strategies exist with their own set of shortcomings as finding a solution is not in general the same as finding a user-acceptable solution. All that small incomplete sentence in the summary section of the manpage provides is that a solver *might* deviate from installing the highest version. It would be subject to dependency constraints to not install any version, too (compare e.g. also apt keeping back packages). Subject to parking regulations, you can park everywhere. If you park your car in an area not for parking you are subject to a fine – if you are spotted and the officer feels like it. Nothing guarantees you that you will be fined nor that the officer is subject to provide help to you to find a parking spot. They might do it anyhow if you ask nicely. It is dangerous to read too much into a few weak words. Things like "apt build-dep foo/stretch-backports" exist which can change the candidate based on version constraints. Other solvers like aptitudes default one (or as said the ascpud solver usually tasked with backports) might be more willing to offer such solutions than apts default solver in general. It is a choice with (in general) non-trivial non-binary answer(s). Best regards David Kalnischkies P.S.: True, seems like I mixed up stretch and squeeze – don't know how that happened… stretch actually has (external) ELTS support still. On the upside, you can use most of the things I hinted at and that Johannes has pointed you to as well now. signature.asc Description: PGP signature
Bug#229775: apt 2.7.7: build-dep doesn't work if priority is 499
On Mon, Jan 01, 2024 at 09:13:54AM +, Askar Safin wrote: > This bug (#229775) is still reproducible with current apt version (apt > 2.7.7). The bug That is good, because it is documented to behave this way… > can be summarized so: "apt-get build-dep" fails to install a package from a > repo > if its priority is slightly less than priority of installed release. In more > details: > "apt-get build-dep" fails to install a package from backports if backports > priority > is set to 499 and installed release have its default priority (i. e. 500, as > well > as I understand). See apt_preferences(5) for the gory details, but in short: The version equal or higher than the current installed (if any) with the highest pin is the candidate – which is the one pinned to 500 as 499 is clearly lower than 500, end of the story. > I think this is a bug: dependecies can be satisfied if one really tries. > If I set backports priority to 500, then "apt-get build-dep" is able > to install needed packages. So, apt-get doesn't try hard enough. Sure, but in its default configuration apt is not supposed to try hard. > Go to Debian IRC (a. k. a. OFTC IRC), join #debian channel and write to > bot nicknamed "dpkg" the following text: "simple sid backport". The bot > will respond to you with the following *very* helpful text: Sometimes, "simple" is not enough. Sometimes backports are hard, but the bot can't help with that and that is for the better as hard equals dangerous in this case. You wouldn't complain about a bot telling you hat hiking up a mountain is easy, while that certainly doesn't apply to the 8k's. > I use stretch as my main system. So I often need to backport packages. And I Support for stretch ended nearly a decade ago, LTS extended that slight to 2016, but that is still a long time ago. Hoping that current documentation would apply to a system that old is a bit of a … stretch. > Hence there is simply no configuration, which meets my goals. Not that it helps in what you asked first, but the current default for backports is 100 – but I implemented the involved feature set after squeeze if I remember right… you can manually set it to 100 through for a "upgrade from backports if a backports version was installed previously" behaviour (as in that case the highest pin will be 100). > === > if ! apt-get build-dep -y "$PKG"; then > apt-get build-dep -t "$CODENAME"-backports -y "$PKG" > fi > === > > Well, I can write this. But this is a hack. Workaround for a bug! Well, I guess I would just go with -t always, but your choice really. Note that the "real" backports builder use an alternative apt configuration that frees it from its candidate shackles at the expense of other problems as choice, it turns out, is not always desired. The keywords are external solvers, aspcud and what not, but that isn't supported in squeeze either, I made that happen later… I think back in the day backports were using aptitude as builder as its solver is allowed by default to change candidates mid-flight. sbuild documentation is a good choice here as its part of the build infra. So, in summary, yes, apt doesn't switch candidates while running currently. Not even if they have the same pin value – where it might even make sense – and certainly not if they have different values. You may call that a bug, I call that a documented feature, and for the rest of the world lets call this report a wishlist item for a feature that might or might not be implemented in a future default solver (probably by writing said solver first). What I know is that we can't offer any assistance with your quest of backporting to the last decade. This is COMPLETELY unsupported. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1059267: ITP: apt-verify - extend apt's gpgv-based verification mechanism
On Fri, Dec 22, 2023 at 10:54:10AM +0100, Simon Josefsson wrote:
> * Package name: apt-verify
It is bad enough that apt-* is a free for all name grab outside of the
Debian archive, I would very much prefer if we would not encourage it
inside Debian at least…
Especially as this has zero mentions on deity@ and declares itself
a hack that you now want to ship with next stable even through it is
utterly unsupportable for Debian as at least I, as an APT developer,
am unwilling to declare the apt::key::gpgvcommand option a supported
interface & I don't see who else would step up…
I added this completely undocumented option in apt-key in 2015 in the
process of supporting gpgv2, so that our tests could be run against
gpgv, gpgv1 and gpgv2. As we no longer have such a need, that option
could disappear any second.
apt-key itself is heavily deprecated and might disappear in the future.
That it is used by libapt currently is also an implementation detail
(again, of the gpg2 supporting kind) we are unwilling to declare
a supported interface and could be changed any second.
I can't give you an exact time line, but I think Julian even already
wrote some PoC code for libapt, so that the parts from apt-key it
secretly reuses will no longer be needed. Its definitely on the (long)
todo list and has some likelihood of being done before trixie releases.
(And that is ignoring if calling gpgv will even remain the only option).
So, in summary, while no such thing as a VETO formally exists for ITPs,
I intend this mail to be as close to a VETO as possible – by the power
of our dear super cow.
In terms of what this actually does: I haven't looked too closely, but
it seem like you want libapt code not to just call its gpgv-method,
but to also (optionally) call a bunch of other methods before and/or
after it, which all have to approve before we can proceed. Certainly not
the easiest thing in the world to implement, but not that hard either…
after all, we have support for client-merged pdiffs (which isn't used
much nowadays, as Debian moved to server-merged pdiffs years ago) which
are downloaded in parallel and wait on each other before proceeding.
So, not rocket-science. It would also solve a bunch of problems you
already have ("it is currently not known how to find out which apt
repository (apt URL) was used") and the many you will have as soon as
you have actual users (I see e.g. apt-canary downloading files) that
you can solve only by being a proper part of the acquire process, not
by attaching yourself with duck tape and hot glue to its underbelly.
Especially not if you want this to be a security feature…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Bug#1058937: /usr-move: Do we support upgrades without apt?
On Thu, Dec 21, 2023 at 02:42:56PM +, Matthew Vernon wrote: > On 21/12/2023 09:41, Helmut Grohne wrote: > > Is it ok to call upgrade scenarios failures that cannot be reproduced > > using apt unsupported until we no longer deal with aliasing? > > I incline towards "no"; if an upgrade has failed part-way (as does happen), > people may then reasonably use dpkg directly to try and un-wedge the upgrade > (e.g. to try and configure some part-installed packages, or try installing > some already-downloaded packages). You can configure half-installed packages, no problem, this is about unpacking (which is the first step in an install, where only Conflicts and Pre-Depends matter, if you are not deep into dpkg vocabulary) The "try installing" part is less straight forward. In general, you are running into dpkg "features" (e.g. not handling pre-depends) or into dpkg bugs (e.g. #832972, #844300): In the best case your system state became a bit worse and hence harder to "un-wedge". In the worst case a maintainer script has run amok as nobody tested this. But yeah, most of the time you will indeed be lucky and hence come to the unreasonable conclusion that its reasonable to call dpkg directly. Anyway, if your upgrade failed part-way, you are probably in luck given that its more likely the upgrade failed in unpack/configure than in removal – so if you aren't too eager to install more packages by hand but limit yourself to e.g. (re)installing the ones who failed you are fine as apt will have removed the conflictors already for you (or upgraded them, if that can resolve the conflict). But lets assume you are not: As you are driving dpkg by hand you also have the time to read what it prints, which in the problematic case is (as exampled by #1058937): | dpkg: considering removing libnfsidmap-regex:amd64 in favour of libnfsidmap1:amd64 ... | dpkg: yes, will remove libnfsidmap-regex:amd64 in favour of libnfsidmap1:amd64 (and the same for libnfsidmap2:amd64 as well. If your terminal supports it parts of these messages will be in bold) Note that the similar "dpkg: considering deconfiguration of …" which is the result of Breaks relations is not a problematic case. (Also note that this exact situation is indeed another reason why interacting with dpkg by hand is somewhat dangerous as you might not expect packages to be removed from your system while you just told dpkg to unpack something… just remember that the next time you happen to "dpkg -i" some random deb file onto your system.) That is of course no hint that a file might have been lost due to aliasing if you don't know that this could be the case, but on the upside it is not entirely a silent file lose situation either. We could write something in the release notes if someone happens to read them AND also encounters this message. Query your memory: Did you encounter this message before? Nothing in the /usr merge plan makes that particularly more likely to be encountered for a user and not all of the encounters will actually exhibit the file lose. So if you haven't – and I would argue that most people haven't – there is a pretty good chance you wont have a problem in the future either… So, in summary: Yes, there are theoretic relatively easy ways to trigger it with dpkg directly. That isn't the question. The question is if a real person who isn't actively trying to trigger it is likely to run into it by accident (and/or if such a person can even reasonably exist) so that we have to help them by generating work for many people and potentially new upgrade problems for everyone – or if we declare them, existing or not, a non-issue at least for the upgrade to trixie. And on a sidenote: I would advise to reconsider interacting with dpkg too casually – but luck is probably on your side in any case. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1058937: /usr-move: Do we support upgrades without apt?
On Thu, Dec 21, 2023 at 03:31:55PM +0100, Marc Haber wrote: > On Thu, Dec 21, 2023 at 11:19:48AM -0300, Antonio Terceiro wrote: > > On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote: > > > Is it ok to call upgrade scenarios failures that cannot be reproduced > > > using apt unsupported until we no longer deal with aliasing? > > > > I think so, yes. I don't think it's likely that there are people doing > > upgrades on running systems not using apt. > > Do those GUI frontends that work via packagekit or other frameworks > count as "using apt"? I explained that in full detail in my mail to the pause-thread: https://lists.debian.org/debian-devel/2023/12/msg00039.html In short: helmuts "apt" (my "APT") includes everything that uses libapt. That is apt, apt-get, python-apt, aptitude, synaptics, everything based on packagekit, … I know of only cupt and dselect which don't count, but I have some suspicion that they would work anyhow. IF you don't run into other problems with them, like that they do not implement Multi-Arch. So this thread is really about: How much are people REALLY fiddling with dpkg directly in an upgrade and can we just say its unsupported – because, at least that is my view, in practice nobody does it and its therefore also completely untested. Case in point: We have this thread not because someone found it while working with dpkg directly even through they had potentially years, but because Helmut ended up triggering an edge case in which apt interacts with dpkg in this way and only after that people looked for how to trigger it with dpkg because triggering it with apt is hard (= as Helmut checked, no package (pair) in current unstable is known to exhibit the required setup). (I will write another mail in another subthread about the finer details of what interacting with dpkg in an upgrade means and what might be problematic if you aren't careful – in general, not just with aliasing) Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1059068: Upgrade problems due to libavcodec{59,60} and libsvtav1enc1{,d1}
Control: reassign -1 libsvtav1enc1d1 1.7.0+dfsg-2
Control: severity -1 serious
(While I am not a release team member, they tend to consider upgrade
problems a release-critical bug, so bumping accordingly, although they
do so usually much closer to a release… feel free to disagree.¹)
On Wed, Dec 20, 2023 at 12:20:10AM +0100, Vincent Lefevre wrote:
> I'm currently upgrading a stable machine to unstable (except some
> buggy packages), which is mostly done, but apt fails to resolve
> dependencies in order to upgrade vlc (aptitude is worse):
>
> qaa:~> apt install -s vlc
You should really know this by now as that isn't your first report, but
okay: Upgrade problems are NEVER a problem to be solved in apt,
they are ALWAYS a problem in the involved packages. NO EXCEPTIONS.
The reason is simply that we can't change apt/stable even if we wanted
to, so whatever apt/stable does is what maintainers have to make it work
with.
apt is also not a good place to report a bug to, in the hope they will
figure out where it belongs instead: Two active maintainers don't scale
to the task of bug triage for 70.000+ binary packages AT ALL. We hardly
manage to deal with the reports coming in which sorta belong here…
> [...]
> The following packages have unmet dependencies:
> vlc-plugin-base : Depends: libavcodec60 (>= 7:6.0)
>Depends: libavformat60 (>= 7:6.0)
> vlc-plugin-video-output : Depends: libavcodec60 (>= 7:6.0)
> E: Unable to correct problems, you have held broken packages.
>
> Why doesn't it try to install these packages, then?
Because it quickly tried and gave up on it as the debug output shows:
Installing libavcodec60 requires removing libavcodec59, the later is
deemed more important as (more) stuff still mentions it, so that isn't
done.
Or, well, its actually mostly a matter of libsvtav1enc1 vs
libsvtav1enc1d1 as that is what prevents the two libavcodecs to be
co-installable and why I am assigning this report there.
The gist of this for a package maintainer, especially if your package
is a library, is that you should really really really try to have your
different ABI versions co-installable as otherwise it
| is not ideal due to potential issues during upgrades
(^ foreshadowing in #1041302 introducing libsvtav1enc1{,d1})
The potential is gone, its an issue at least for this user. Not just
in this install request, but also in upgrades as can be reproduced with
the status file from the aptitude report #1059071. Simply telling apt
to "apt full-upgrade -o dir::state::status=./status -s libsvtav1enc1-"
makes that upgrade a lot more sensible than without the explicit removal
of libsvtav1enc1 (without it, it actually ends in a resolver error about
emacs-gtk which seems completely unrelated… except its only 4 stops
on the dependency tree away and so not unrelated at all).
Assuming this 1 vs 1d1 remains not co-installable it would help apt (and
aptitude and anyone else reasoning about this stuff) to make the conflict
between libavcodec60 and libavcodec59 more explicit. In local testing a
simple breaks of the later on the former does the trick.
Of course, that is pushing the potential for issues up the stack, so
another solution might be found (like upstream bumping SONAME, so that
different libsvtav packages from stable and future testing are co-
installable (ignoring the inbetween 1d1)) and hence also libavcodecs.
btw: Before someone asks: That this happens for libavcodecs is mostly
due to its rather unique circumstance of having multiple packages have
or-group dependencies on multiple ABI versions. That grants all of them
points which ideally would only go to the most recent one. The result is
that a resolver believes touching this package would affect many packages
negatively, which isn't [completely] true in this specific case, but a
key concept of apts current resolver and a very handy assumption to avoid
being all to eager to remove packages in transitions. To really detect
this without domain knowledge in reasonable code a solver would need to
try and see what happens, which apt can't – and given aptitude doesn't
see it either tells me that this is only "obvious" with domain knowledge.
I am therefore not considering this a bug in apt. At least not one that
can reasonably be resolved.
Long story short: That apt doesn't find the solution you ask for is sad,
but sometimes that is a good thing, too. And if not, its a problem for
the maintainers of the packages not providing a smooth upgrade path.
Oh and it doesn't matter in this case as it effects also upgrades, but
install is not an upgrade tool. Your system should be fully upgraded
before you install additional stuff as install is simple not up to the
task of making complicated upgrades work (by choice & design!).
Best regards
David Kalnischkies
¹ Ironically, its not a policy requirement to have a package be
upgradable. I could perhaps invoke 'cr
Bug#1058579: apt: gives misleading error when not finding Packages.xz in Release (not InRelease)
On Wed, Dec 13, 2023 at 11:29:29AM +0100, Yann Dirson wrote: > W: Skipping acquire of configured file 'Packages' as repository > 'https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 > ci/ InRelease' does not seem to provide it (sources.list entry misspelt?) Sadly, this relates to your later observation: > After more testing, it appears that the behavior is different > depending on the way the flat repository is used: […] > I'm a bit unsure whether this would be expected. The "funny" thing about flat repositories is that nearly everything can be one: http://deb.debian.org/debian/dists/sid/main/binary-amd64/ is e.g. a flat repository as well… unsigned and without any sort of hashes so apt will hate your guts by default, but with enough force it will gobble it up anyhow (it contains a Release file, but that is optional as well…). So… if a repository you added doesn't contain a Packages file there is a good chance that you misspelt something which happened to be still a valid repository. Perhaps nowadays, that apt even dislikes unsigned repos we could while not trim the support for these things at least review and edit messages assuming that users will nowadays only interact with proper repos… Messages referring to a repository will usually speak about InRelease as that is convenient to access from a code point of view. It doesn't mean the file is used – or even exists. Its just that the code who handles the file also handles if it doesn't exist, manages the fallbacks and so on. In an ideal world we would have an easier and better way of referring to a repository, but in this world we so far don't. There probably is an "upgrade path", but I don't have the cycles to think about it at the moment (nor while implementing part of that message a few years ago). It is somehwhat similar with how messages tend to talk nearly interchangeable about 'Packages' and 'Packages.xz' even if neither exists and we end up using 'Packages.gz' (and Packages.lz4). So, the gist is that yes, it can be misleading, but all individual parts are correct or have at least a good explanation. I also don't see a lot of ways to improve on it given that the message is already way too long and we can not go full analyse mode on untrusted data either… > root@debian:~# curl > https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64/ci/Release > Date: Wed, 13 Dec 2023 09:55:54 + > Description: xen-guest-agent CI packages > Label: xen-guest-agent-ci > Suite: ci > MD5Sum: > 4bbd32da77623285b8a54ef926a1f028 277 Contents-amd64.gz > 9c8c7743a78d4c850fbdffac54c5e159 340 Contents-amd64.xz > 557f3042ec38f51a838d518739ecf4c2 925 Packages.gz > a3b82abf0ab81c4d5f829ec631c9deb8 1008 Packages.xz APT wants checksums for the uncompressed Packages file – even if they are not shipped in the repository – the info has to be there so that apt can check that the data it got after uncompressing is really the intended one. It will also be needed "later" for updates for the data as files could be stored (re)compressed [different compressor versions can produce different files having different checksums. Also, we tend to use compressions for storage which aren't available online to begin with], not to mention reverify, pdiffs, … I said wants as there is still support for repos who don't have hashes and so if you play your cards right, you could manage to make apt accept your repo, but please don't. Just provide checksums for the uncompressed files and be done. So, in summary, I am not sure what to do about this… on some level I agree, others I consider a user error, but if I look at the cost- benefit ratio of it all I don't see the parts changing that would need changing anytime soon so that this report has a very good chance of staying open until the heat death of the universe (or apt being removed from Debian, but that is only a theoretical possibility of course). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1056356: apt-get update kernel BUG at mm/usercopy.c:101!
Control: reassign -1 src:linux 6.1.38-4 Control: forcemerge 1051643 -1 Control: affects -1 apt Hi, On Tue, Nov 21, 2023 at 11:04:18AM -0500, js1 wrote: > Running apt-get update causes kernel BUG as reported in 1051643. apt-get > update hangs: If that is as you describe, that the bug is in the kernel, we as apt maintainers can do nothing about it. We have also no other reports to that effect here or as far as I can see in Launchpad (= Ubuntu) against apt, so this might be highly dependent on your/specific hardware. So, keeping the bug open here seems to serve no purpose in my eyes and hence I am merging it with the existing one – but I tag it as affecting apt, so that it appears in its bug list should other users encounter this with apt (which I suppose was your intend). Beside you running apt I don't see any apt code in the trace, but from the apt output produced I suppose its triggering somewhere in the download step, so the following might help to simplify the reproducer a bit – if you can reproduce it that way of course as a lot of complexity is stripped away which might trigger it… $ cat > /tmp/testrequest <http://ftp.us.debian.org/debian/dists/bookworm/InRelease Filename: /dev/null EOF $ /usr/lib/apt/methods/http < /tmp/testrequest (yes, you can and are encouraged to run this as non-root user. While creating the testrequest file make sure copy everything between the two EOF. Especially the ending empty line. A successful run ends with a block starting with "201 URI Done". Your apt output suggests it triggers somewhere between "102 Status" and "200 URI Start".) Before giving up on this try using a real Filename and/or different URI in the testrequest (if you want to use a https URI, make sure to call the https method!). Hope that helps & good luck finding the cause & solution. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1052804: ycmd: FTBFS: make[1]: *** [debian/rules:28: override_dh_auto_test] Error 1
Control: forwarded -1 https://github.com/ycm-core/ycmd/issues/1718 Hi, the problem is that upstream code isn't supporting Unicode 15.1 yet, which introduced a new word break rule. They embed the code (for 13), but for Debian I opted to drop the embed and use whatever unicode-data ships to rebuild the files, which bites us in the rear end here – as it kinda should be. I reported upstream and they have a PR implementing the needed support already as well: https://github.com/ycm-core/ycmd/pull/1719 As said there it works fine for me in local tests, so this issue here should be resolvable in the near future. vim-youcompleteme (which is a rdepends of ycmd) is currently affected by a regression in vim through (https://bugs.debian.org/1055287) which makes updating ycmd with the unmerged upstream patch not that useful for now (as it would never migrate – or, well, battle with vim for a spot). So, I am currently waiting for either vim or upstream to act first while dealing with other housekeeping things (clang-17 support) in the meantime; so much as a status report in case anyone wonders. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1055287: Please package newer vim upstream release
Package: src:vim Version: 2:9.0.2018-1 Control: affects -1 vim-youcompleteme Hi, v9.0.2018 is currently blocked from entering testing due to failing vim-youcompleteme – who I am the maintainer of – autopkgtests. While I can't really reproduce the failures interactively, I can in a local autopkgtest run and while I currently don't have the serenity to start bisecting this properly I can at least confirm that while v9.0.2018 fails, a testrun with a no change (beside merging upstream) v9.0.2087 finishes successfully. I would therefore like to request a newer vim being released to unstable for our mutual benefit. I suppose your testing blockage might resolve itself in time as there are other issues in the vim-youcompleteme ecospace I have to deal with, which I might fail to get done before the removal clock ticks out, but even if I would any fix would then be blocked by failing to work in testing with the currently packaged vim… which I would like to avoid. I am placing this bug hence as "normal", not as customary "wishlist", while I am not raising it higher either as I haven't investigated why and if that effects (not) everyone interactively/in automation. (Sry, for opting here for the lazy shortcut skipping the break & fix bisects, to keep some time for the other things I should have a look at) Thanks for your help & Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#749788: I think this is an apt request, not an apt-listchanges
Control: reassign -1 apt-listchanges 2.85.13 Hi, On Mon, Oct 02, 2023 at 05:43:00PM -0400, Jonathan Kamens wrote: > The timing of when apt-listchanges gets called vs. when packages get > installed is controlled by apt, not by apt-listchanges. While it would apt doesn't hardcode calling apt-listchanges. apt-listchanges opts in to being called at a specific point with `/etc/apt/apt.conf.d/20listchanges`. Specifically the `DPkg::Pre-Install-Pkgs` setting. Other hook places exist, they do have other informations available through. In any case, as the premise for reassigning is wrong… return to sender. > certainly be possible to add an option to apt to call apt-listchanges after > rather than before the upgrade, and to omit the --confirm option when doing > so since it obviously makes no sense to ask the user for confirmation afrer > the upgrade has already happened, this change would need to be made in apt, > not in apt-listchanges. You could already now gather the info with a non-blocking hook and add an additional one after dpkg finishes which does whatever is requested here via `DPkg::Post-Invoke` hook if you so choose. That said, my `/etc/apt/listchanges.conf` contains: |[apt] |frontend=browser |browser=/etc/apt/apt-listchanges-browser |confirm=0 |which=both I have to admit that my browser is kinda special so I will not bore you with too many details, what you need here is going from 'root' to a 'normal' user (with some environment variables like DISPLAY). I think apt-listchanges even tries to do that for you if you use `sudo` to call apt (or whatever front end ends up calling listchanges), so it might just work for you or you need a bit of scripting (my solution involves a systemd user session, a user account just for browsing and sandboxing, but as this is total overkill and not a generic solution). In any case, the behaviour is that apt-listchanges will format its output as HTML, calls the browser on it (ensure that either a browser is running or double fork to the background I suppose) after which it will continue without a confirmation as requested in the bugreport. I use that for years to read the changelog entries (not just NEWS) and occasionally the linked bugs while apt/dpkg are busy doing their thing. So, I suppose, with a bit more documentation and testing this bugreport could be closed in apt-listchanges without any code changes. In any case, there is nothing I can see we as apt maintainers need to do here. If you think you (I see that you intend to adopt apt-listchanges, good luck with that & thanks for contributing to Debian in this way!) need something from apt feel free to contact us on IRC/mailinglist before reassigning bugs over as they tend to get lost in our heap – and usually, with some trickery existing facilities can be reused instead of busy-waiting for apt in stable to support whatever someone needs now… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1052058: apt: refuses to downgrade itself to a version that works on the system
On Mon, Sep 18, 2023 at 07:56:09PM -0400, Philippe Grégoire wrote: > As such, I can no longer install or remove packages since my system is > partitioned. I'd like to point out that the above link does not specifically > mention disk partitioning, but only how files are placed on disk. > > Obviously, re-partitioning the system is something I'd like to avoid at the > moment. > > Thinking about it, in the long term, due to the merge and how packagers are > expected to be able to address files (e.g. /bin/sh vs /usr/bin/sh), I don't > see any other way than re-partitioning. Re-partitioning will be done by a > future me. It is sort-of the point of /usr-merge that /usr can be another partition instead of having packaged content split over multiple subdirectories of / which could all be individual partitions, but only really work if you mount them all anyhow… (yes, /etc, /var and all that jazz. People have opinions on that, too. Lets focus on the problem we already have now instead of pilling additional ones on top). What should be the case is that /usr is a directory and e.g. /bin is a symlink to /usr/bin. That is what the apt code is trying to check in a somewhat roundabout way with inode as both /usr and /usr/bin should point to the same real directory occupying the same inode. That should be the case even if you have /usr on a different partition. Are you sure your system is properly merged – as in you haven't unmerged it with e.g. dpkg-fsys-usrunmess or prevent the merge to be executed automatically by the installation of usrmerge? In either case, it is probably better to contact a user support list to resolve your issue. > P.S. I'm uncertain why /lib isn't also merged with /usr/lib It is? The code even checks for /sbin, /bin und /lib – but that isn't all that /usr-merge entails and APT doesn't really want to be checking for everything. Just for some easy to verify truths to ensure nothing went south… like it seems to have happened on your system. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1051731: apt: [INTL:pt] Update on Portuguese translation of MANPAGE
On Sat, Sep 16, 2023 at 12:51:48PM +0200, Julian Andres Klode wrote: > Control: tag -1 moreinfo > > On Mon, Sep 11, 2023 at 09:01:54PM +0100, Américo Monteiro wrote: > > Updated Portuguese translation for apt's manpage > > Translator: Américo Monteiro > > Feel free to use it. > > Please provide evidence of peer review by the pt translator > email list, I cannot merge translations from a new third party. I think you confused "manpage" with "program" translations, as for the former Américo Monteiro is the translator for more than a decade – not really "new" by any standard. So, while peer review/interacting with debian-l10n-portuguese@l.d.o would probably not hurt, I am going ahead and merge this small update as I did for previous iterations. Thanks! Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates
On Fri, Aug 18, 2023 at 11:24:22AM +0200, Raphael Hertzog wrote: > > > As you may have noticed, the 'stable' doesn't include 'stable-updates' > > > either and that isn't new – and also part of the reason for this funny > > > regex. I was surprised then I discovered that entry the first time in > > > the release notes as we were never asked about it. > > > > Looking at the apt.conf and apt_preference manpages there is still no > > mention of the regex support, perhaps this should be documented there? > > Agreed. It would be nice to document that we can use regex here and > that it actually makes sense to do so as most Debian release are actually > composed of multiple repositories. The problem is that regex is NOT supported at the moment. It happens to work in most commands, but it e.g. doesn't in 'source'. Before we could (leaving alone the question if we should) document it as supported, we would need to check all commands and fix those which do not work with it. Nobody did in the last couple of years. So the only reasonable solution for this request so far is to document it explicitly as not supported… which helps exactly nobody. To quote myself from this very thread: | Anyway, easiest way to not have these problems is to not use the option | at all. Step back and question why you want to use the option. There are probably easier and simpler ways. Adding backports e.g. doesn't need pinning at all (it comes by default with 100). Adding unstable to stable might be a bad idea to begin with, but is certainly better dealt with a pin against unstable rather than trying to catch all your "good" "stable" repos in a regex to filter out the one bad "unstable" apple. In preferences the regex actually works and is documented, which is the deeper reason behind APT::Default-Release working with regex or not as certain commands can rely on the preferences infrastructure while a command like 'source' can currently not and hence implements it differently without support for a lot of things possible elsewhere. If you can come up with a list of use cases for that option (personally, I don't see a good one) without too much by-catch we might be able to implement a transition notice like I did for non-free-firmware. Too late, too little, but at least it would prevent future misuse. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1042089: src:golang-defaults: fails to migrate to testing for too long: triggers autopkgtest failure on armhf
On Wed, Jul 26, 2023 at 04:48:55PM +0200, Paul Gevers wrote: > [2]. Hence, I am filing this bug. The version in unstable triggers an > autopkgtest failure in vim-youcompleteme on armhf. This used to be the case for armel, too, until today, which had gccgo-13 13.1.0-9 migrate to testing – the day before it failed with 13.1.0-6. armhf seems to have followed up just now with a passing grade: https://ci.debian.net/packages/v/vim-youcompleteme/testing/armhf/ golang-defaults should hence migrate shortly *fingers crossed*. If so, as vim-youcompleteme maintainer, I am quite happy as its kinda scary to block the defaults meta package for a programming language you know nothing about with your leaf package… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1041993: is URIs supposed to be a list?
On Tue, Jul 25, 2023 at 02:27:40PM +0200, Marc Haber wrote: > Is this supposed to be a list? Yes. > What would be the semantics of multiple URIs given there? Counter question, what is the semantics of "Suites" or "Components"? Concurrent, round-robin, first answering wins? Not sure what the first means, but at least the later two make no sense for those, right? Unsurprisingly the behaviour doesn't magically change for other fields… why should it? Behaving differently depending on how you write things down would be a nightmare to document; nobody would read or even understand it! So, you can e.g. write: | deb http://ftp.de.debian.org/debian stable main | deb http://ftp.se.debian.org/debian stable main as: | Types: deb | URIs: | http://ftp.de.debian.org/debian | http://ftp.se.debian.org/debian | Suites: stable | Components: main Does it make sense? For most people, probably not – hence the man page doesn't include an example for pulling data from two different mirrors. I suppose with cdrom and http this would make a tiny bit of sense, but not everything than can be done should be done. You could use it for PPAs or the mythical Debian bikesheds, but given Signed-By would be a good idea for those it might not be as useful there either. If you want "concurrent" downloads and "fallbacks" and what not have a look at apt-transport-mirror(1). Perhaps one day an URIs alternative might exist which behaves similar to a mirror-light – but that will be a complicated sell documentation wise as one-line- and deb822-style are less interchangeable as a result. As you are basically asking for making a man page more complex by providing examples for something hardly anyone will be using (and probably misunderstand if an example is provided without explanation), I am closing with a veto as that seems not nearly important enough to clutter up the bug list with a wontfix. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1041750: apt-get changelog nvidia-driver fails with "Changelog unavailable"
On Sat, Jul 22, 2023 at 11:14:43PM -0400, Allan Wind wrote: > $ apt-get changelog nvidia-driver > Err:1 https://metadata.ftp-master.debian.org nvidia-graphics-drivers > 525.125.06-1~deb12u1 Changelog > Changelog unavailable for nvidia-graphics-drivers=525.125.06-1~deb12u1 (404 > Not Found [IP: 146.75.34.132 443]) > E: Failed to fetch > https://metadata.ftp-master.debian.org/changelogs/non-free/n/nvidia-graphics-drivers/nvidia-graphics-drivers_525.125.06-1%7edeb12u1_changelog > Changelog unavailable for nvidia-graphics-drivers=525.125.06-1~deb12u1 (404 > Not Found [IP: 146.75.34.132 443]) > > The information exist as I was able to find it via: > > https://www.debian.org/News/2023/20230722 -> > https://packages.debian.org/search?searchon=sourcenames=nvidia-graphics-drivers > -> > https://packages.debian.org/source/bullseye/nvidia-graphics-drivers -> > https://metadata.ftp-master.debian.org/changelogs//non-free-firmware/n/nvidia-graphics-drivers/nvidia-graphics-drivers_525.125.06-1~deb12u1_changelog The problem here is that the (binary) package you request is in section non-free, while the source package this boils down to is in section non-free-firmware. A similar situation could arise with main/contrib or contrib/non-free I presume, so this isn't a new problem. `pkgAcqChangelog::URI(pkgCache::VerIterator const&)` in apt-pkg/acquire-item.cc would need to be changed from using a VerFileIterator from the binary package to going 'manually' on the hunt for a (= there be many…) Sources file(s) containing the source package and from there get the Section and from that also the Release file. Alternatively, the server side could just merge the components as there can't really be different source packages with the same name in different components and the metadata hopefully doesn't have the same restrictions applied to it than the packages itself… Either way, that just as a comment as I won't be working on a fix for now as I remember people talking about completely overhauling the implementation/setup client and/or server anyhow. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1040644: [INTL:ro] Translation-revision of "apt" to Romanian
On Wed, Jul 12, 2023 at 10:24:12PM +, Remus-Gabriel Chelu wrote: > first of all, I must admit that in the translation process, I peek at > the translations made by the other Latin teams (I studied also French > in the school, and I have lived in Spain for 20 years), so at least > in part , the reported errors/"sins", are due to this. I would classify these as "mistake" at most > În miercuri 12 iulie 2023 14:41:44 (+02:00), David Kalnischkies a scris: >> On Sat, Jul 08, 2023 at 01:04:28PM +, Remus-Gabriel Chelu wrote: >> | +# Advanced Package Transfer - APT message translation catalog > > "Sinning" because of the French/Spanish team, but... a search for > "Advanced Package Transfer" or "APT message translation catalog" in the > "po/" directory will yield more surprises. > >> | +# Copyright © 2002-2023 Free Software Foundation, Inc. >> >> Are you, like, sure? > > Same as above, "sinning" because of the Spanish team, but... a search for > "Free Software Foundation, Inc" in the "po/" directory, > will "sing, bingo!" more than once. Removing things is hard, especially if it includes the word "Copyright" and as long as the "rewind" mode of my time machine is broken I am trying to focus on not adding too many new potentially future problems at least. Sounds like double-standard, but you have to start somewhere and given how old apt is and through how many hands it has passed in all those years its kind of a mess. > Regarding using the git commands, you have to admit that the "curious" > would have to do a «git clone» first, before they can use the git search/show > commands, which I think is too much of a "disturbance" for the ultimate > goal of satisfying this curiosity. Well, you can browse/search our version control system online in various places, including salsa, but I get what you mean and if you think its important I see no problem for us with it. >> | "Language-Team: Romanian \n" > > I don't know/understand what you meant here. (You picked up on what I meant, so this is just for completeness) The line is included in the first msgstr in the po file – although it includes the email address, but I suppose your mail client might have eaten that… so manually HTML encoded: | "Language-Team: Romanian debian-l10n-roman...@lists.debian.org\n" > PS2: Please help me with a clear example for the new message that appeared > in version apt 2.7.2: "Missing Signed-By in the %s entry for '%s'"; An example would be: | N: Missing Signed-By in the sources.list(5) entry for 'http://example.org/debian' So, "Signed-By" is an option mentioned in the pointed to man page and should probably not be translated (as I am not a huge fan of this message I will refrain from commenting that one further). Best regards David Kalnischkies P.S.: Attached is a refreshed ro.po file with initial file, the changes discussed here and our upstream 2.7.2 merged together. ro.po.gz Description: application/gzip signature.asc Description: PGP signature
Bug#1040644: [INTL:ro] Translation-revision of "apt" to Romanian
Hi, On Sat, Jul 08, 2023 at 01:04:28PM +, Remus-Gabriel Chelu wrote: > Please find attached the Romanian translation of the «apt» file. Thanks for the update! I have questions/comments through about the top of the file, here the diff with inline comments: | -# translation of ro.po to Romanian | -# | +# translation of APT message to Romanian | +# Mesajele în limba română pentru pachetul APT. | +# Advanced Package Transfer - APT message translation catalog While they seem borderline pointless as what else should they be, at least the third one is extremely misleading… APT doesn't stand for "Advanced Package Transfer"… it is somewhat questionable if it stands for anything at all even if various sources on the internet have their own ideas what it stands for… | +# Copyright © 2002-2023 Free Software Foundation, Inc. Are you, like, sure? | # Licensing is complex as the msgid come from several files, please see | # the individual files for licensing information. | -# | -# This file originally stated: Please keep this line as it explains the following line claiming that the file is under public domain – which in its entirety is questionable as the code the messages are extracted from is not, so at the very least the English messages are not beside that public domain is a complicated concept around the world. | # This file is put in the public domain. | # | # Sorin Batariuc , 2004, 2005, 2006. | # Eddy Petrișor , 2008. | +# Remus-Gabriel Chelu , 2023. | +# | +# Cronologia traducerii fișierului „apt”: | +# Traducerea inițială, făcută de SB, pentru versiunea apt ???, 2004. | +# Actualizare a traducerii pentru versiunea ???, făcută de SB 2005. | +# Actualizare a traducerii pentru versiunea ???, făcută de SB 2006. | +# Actualizare a traducerii pentru versiunea 1.0.5, făcută de EP noi-2008. | +# Actualizare a traducerii pentru versiunea 2.7.1, făcută de R-GC, iul-2023. | +# Actualizare a traducerii pentru versiunea Y, făcută de X, Z(luna-anul). I don't speak Romanian so I don't know, but it looks to me like you are trying to record here who translated which version and when. You can reasonably easy figure this out with the right 'git' commands as that is what version control systems are built for, so I am not sure its a good idea to keep a manual list (which someone will forget to update at some point for sure) for questionable benefit? Btw, the answer for the first ??? is 0.5.24. See https://bugs.debian.org/281458. | "Language-Team: Romanian \n" You seem (very) active on the list and not too many others around from a casual look, so that seems fine, but in an ideal world you would post a review request there first. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1038857: apt-utils: installed but aptitude claims not installed.
Control: reassign -1 debconf On Wed, Jun 21, 2023 at 07:50:33PM -0700, pe...@easthope.ca wrote: >I used aptitude to update the system. Was apt-utils part of that upgrade or was it even newly installed? You can get that info after the fact from /var/log/apt/history.log >* What exactly did you do (or not do) that was effective (or ineffective)? >Aptitude was OK but reported this. >debconf: delaying package configuration, since apt-utils is not installed The message is not from aptitude, nor from apt-utils, it is from debconf as the prefix indicates, but no worries, as that is hard to know if you don't know how they all interact. It "just" means that we can't leave the bugreport against apt-utils as it wasn't really involved. I am therefore reassigning to debconf as they might know what might have lead to this message provided you can give some further details about your situation. >* What was the outcome of this action? >Given that apt-utils is installed, puzzlement. > >* What outcome did you expect instead? >With apt-utils installed it should work as intended rather than cause >a report of absence. Note that as the message says the configuration is "delayed" as in happening in-place rather than upfront, so at least this is not dangerous and you don't miss anything, just puzzling. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1034378: Allow Percentage Formatting in apt
Hi, (sry, I seem to be either chronically out of time currently) On Fri, May 05, 2023 at 04:10:35PM -, Emir SARI wrote: > Hello,I'm attaching a patch that enables translations, Thanks – but could you perhaps create a merge request on salsa [0] rather than attaching patches to bug reports as that is easier to review and less likely to get lost. It also runs out test and all such, so it gives you and reviewers some direct visible feedback. [0] https://salsa.debian.org/apt-team/apt/-/merge_requests > and fixes an issue that creates extra spaces when the percentage sign is > prepended to the "Progress: [100%]" string, due to the fixed layout. I have only very quickly looked at the patch, so only two quick remarks: The first hunk seems wrong as our 'strprintf' 'prints to a std::string' given as first argument and doesn't return anything. Meantime, your change also uses std::printf which means it would print directly to stdout, which this code shouldn't do either. In general, I suppose the formatting currently is "Progress: [ 42%]" so "Progress: [ %42]" is your target? I think we could go with a "%d%%" string for all (four) cases (which is my other remark) and assemble the individual strings with e.g. "Progress: [%s]". The code could format a "%100" first to establish the maximum length and prepend spaces as needed for the real value. Oh, and one more thing: Comments in code meant for translators are per convention prefixed with: "TRANSLATORS: " (see existing usages) and should try a little harder to convey what a string is used for, meanwhile a "localize according to your locale settings" could be said about each and every string… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion
Hi, before I am playing bug ping-pong (as I don't think we can do much about this on the apt side), let me ask a d-i question first: On Thu, Apr 20, 2023 at 10:33:08PM +0200, Cyril Brulebois wrote: > Askar Safin (2023-04-20): > > I don't know what should really be done. I can list possible solutions: > > > > - Fix d-i. Remove /usr/lib/finish-install.d/60cleanup or replace it with > > something else > > d-i is merely exposing a bug in bash-completion, so I don't think we > should change anything there. > > > - Fix "apt-get clean". Make it not remove /var/cache/apt/*.bin Why is d-i calling 'apt-get clean' to begin with? Is it perhaps just wanting to remove /var/cache/apt/archives/*.deb ? If so, could you switch to: -o APT::Keep-Downloaded-Packages=false (well, probably in a conf file rather than on each command line). This instructs apt(-get) to remove the deb file right after it has installed them with dpkg, which might even be beneficial for space constraint installation targets. At the very least it is a much used & tested option as it is the default with apt (but not apt-get). d-i could also "just" run 'apt-cache gencaches' to create the caches; but perhaps it is intended that the caches are gone (docker people e.g. like to do that I am told, but they nuke other things as well…). > > - Fix "bash-completion". Make it work even if /var/cache/apt/*.bin are > > not present (for example, by recreating them on-the-fly) The completion script explicitly disables the recreation on-the-fly as creating the files takes a while robbing users for many seconds of their interactivity. So, we can't just "fix" the completion script as that has a(nother?) set of users complain as well. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1034790: apt: APT::Get::AutomaticRemove true + --no-remove results in failure to install: Handler silently failed
On Mon, Apr 24, 2023 at 04:11:37PM +0100, Simon McVittie wrote: > On Mon, 24 Apr 2023 at 15:41:07 +0100, Simon McVittie wrote: > > $ podman run --rm -it debian:bookworm-slim > > This is not a new problem: it's also reproducible in at least bullseye and > buster. I assume this means APT::Get::AutomaticRemove and/or --no-remove > are sufficiently rarely-used that this interaction hasn't been noticed > before. They are. Every non-default option is… The problem with those two is that they are contradicting each other and giving a preference to one or the other is hard as the code has no idea if any, all or none of them were given on the command line, via a config file (and which one at that) or via the command line but as a conf option / in a conf file… it all the same from a code pov. It is not the first time I did evil things, even to --autoremove [0], but this time around it might be best to have apt ignore an option like --autoremove (perhaps with a warning) if it encounters --no-remove set. It is kinda unlikely that users really have --no-remove in a config file as it a rather unpractical option, so that might make sense/be fine. That said, if you are scared of "important" packages being removed, you could just mark them as "Protected: yes" and have apt (and dpkg) ask for more force… Also, you might be able to slightly abuse 'apt upgrade ' after all this command does not upgrade , but upgrades the system after tagging for installation (that is the most simple form of what the commit I pointed to means with "allowing pkg modifiers for the upgrade commands" btw). Best regards David Kalnischkies [0] https://salsa.debian.org/apt-team/apt/-/commit/c89b22c285d6c4a3cb64689ff26e84af4d1477f2 signature.asc Description: PGP signature
Bug#1033675: release-notes: apt-key improves system security with 3rd party sources
). There is a lot of bad advise given about how to add 3rd party sources, but I don't think it is the release notes job to explain how to do that properly (and, as said, it varies a bit by 3rd party). As a sidenote – not a recommendation from me as I never used it myself – the package "extrepo" is supposed to help with the usecase of adding 3rd party repositories; it isn't new either but feel free to check it out. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1034378: Allow Percentage Formatting in apt
Hi, On Thu, Apr 13, 2023 at 11:49:01PM +0300, Emir SARI wrote: > The percentage formatting among different locales can vary. For instance, > Turkish uses %100 style formatting, whereas French uses 100 %. There are also > other languages that use varying styles like using non-break spaces between > the sign and the number and else. However, the percentage values displayed in > apt only uses a fixed format, such as 100%. Can you give example(s) of the messages you refer to? On the top of my head I can only think of the bottom line while packages are installed, which reads (in English) "Progress: [ 42%] …" (on a green background). That message, including the percentage value is already translatable. A few translations have this line translated so far, Turkish among them which reads as of today: msgid "Progress: [%3li%%]" msgstr "Durum: [%3li%%]" French has it translated, too, but also hasn't touched the %3li%% part. So you might want to talk it up with the respektive language teams and last active translation maintainers (see the top of the po files in the source for the contact information). My own knowledge in either language (as well as many others) is non-existent. The other place I can think of is the progress indication shown as the bottom line while files are downloaded (e.g. indexes in 'update' or debs pretty much everywhere else). These "%.0f%%" are indeed not marked for translation, but I am not sure if it is a good idea as they come without any explanation and show info pretty densely more or less to the benefit of "something is happening" rather than "here are all the details you could possibly ask for so you can refer back to this great knowledge forever". Never the less I suppose we can put in the work to make them translatable (currently the formatting is hardcoded in a few places, that would need to be fixed). On the other hand, it seems pointless labour to make the string translatable if a similar translatable string isn't used in this way, so as a compromise I suggest a deal: I will see to implement it if a language team/translator asks for it here. (translation updates are allowed in freeze, the other part would likely need to wait for trixie through as that likely doesn't sell as release- critical code change) Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1033200: apt, apt-get, aptitude and others have been failing for an extended period.
Control: merge 1033200 1033208 1033209 Hi, On Sun, Mar 19, 2023 at 11:19:23AM -0400, WILLIAM ORVILLE RICHMOND wrote: > Package: apt-get > Version: 2.2.4 > Subject: This info seems to have inadvertently been omitted from the > Debian Bug report logs The package is called "apt", a package named "apt-get" doesn't exist, so the bugs were assigned to a catch-all package – from there it got assigned now to where you probably intended to report it against in the first place… Just, please don't make every of your mails a new bugreport. You can add a message by replying to 1033...@bugs.debian.org (or just reply-all to this message here). Thanks. > When, for example, I do: > > orville@flinta:~$ sudo apt-get install lynx […] > Ign:1 http://deb.debian.org/debian bullseye/main amd64 lynx-common all > 2.9.0dev.6-3~deb11u1 > Err:1 http://deb.debian.org/debian bullseye/main amd64 lynx-common all > 2.9.0dev.6-3~deb11u1 > Connection failed [IP: 199.232.34.132 80] […] > E: Failed to fetch > http://security.debian.org/debian-security/pool/updates/main/l/lynx/lynx-common_2.9.0dev.6-3%7edeb11u1_all.deb > Connection failed [IP: 199.232.34.132 80] The IP belongs to Fastly, a big CDN, sponsoring Debian. Can you reach the IP in a browser, e.g. with "http://199.232.34.132/;? (It is normal if the page you see isn't very informative and just talks about "Fastly error: unknown domain". Not normal would be an error message from your browser about being unable to connect or some such.) > I have been considering that maybe some part of the update process, (curl > ??), has been being intercepted ... perhaps by my ISP?? ... but I don't curl is not part of the "update process". Sure, 'something' could potentially interfere with your network, but while a real attack could look the same, it is usually just some local misconfiguration and not some sinister plot by your ISP or country (if you don't happen to live in a sinister country of course). Have you e.g. recently changed something in your router configuration? Is your machine connected to the right wlan network? Sometimes, these issues turn out to be just some new neighbor with an open wlan… Or do you have a proxy configuration? Adblocker? A open hotspot near by with a captive portal? … You can change the apt sources.list to use 'https' instead of 'http' to potentially avoid some problems with external interference (although, some interference is considered good interference, so this isn't a default in Debian for now). A VPN would indeed eliminate far more of potential external interference, but for now that seems like overkill. > It has seemed to be to be unlikely that I am the only person with these > problems, however I do apologize for waiting so long, As the world isn't burning (well, it is given climate and wars, but I digress) it is actually very likely that you are the only person with these problems as we would have literal thousands of people reporting such issues, especially if they were ongoing for months, while we are even in the process of releasing a new major version of Debian and so many people interact with our servers for upgrades. In fact, between 16 and 17 March the mail reception of the BTS and a couple other things went down for a few hours only, and the outcry was huge [0]. Problems for "months" is nearly 100% proof that this problem is local to your setup. I somewhat suspect that the reason Fedora isn't effected is simple that the configuration you accidentally broke network reaching tools on Debian with hasn't reached your Fedora setup yet, so I would start with figuring out what makes your Fedora machines different from the Debian ones. Are they in a different (sub)net on your network for example? All in all, I don't really see a way to help you as I don't really see how it could be a problem originating from "apt". Especially if you have similar network problems with other tools. Best regards David Kalnischkies [0] https://lists.debian.org/debian-infrastructure-announce/2023/03/msg3.html signature.asc Description: PGP signature
Bug#1033153: Old gpg variant of apt/trusted.gpg.d buster keys not removed
Package: debian-archive-keyring Version: 2023.2 Severity: normal Tags: patch Hi, 2023.2 reinstanced the buster keys, but ships them as asc file as the rest, while in a later commit removes the cleanup of the gpg files, so that an upgrader who has skipped 2023.1 has the obsolete gpg conf files remaining. While mostly harmless it should be cleaned up properly as in the grant scheme of things most people will skip the 2023.1 release… I have push (well updated) an MR request implementing this clean up at: https://salsa.debian.org/release-team/debian-archive-keyring/-/merge_requests/3 (Although I was as of yet to lazy to login to salsa again and update the MR description as it isn't as pointless as it once was. I might have but I get the impression MRs aren't followed so I invested the time into this bugreport instead) I built+tested this both with an upgrade from 2023.1 as well as 2023.2, but only very lightly; at the very least apt is still happy and the files are gone for me as intended. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1032654: aptitude: missing message about the Debian bookworm change concerning non-free-firmware
t is so unspecific that annoying users with a warning wouldn't be right.
> I'm also surprised that, despite the default threshold in
> /usr/include/apt-pkg/error.h is WARNING, both, "apt update" and
> "apt-get update" show notices. So the apt developers changed the
> thresholds for both CLI frontends individually? Weird.
Well, imagine we would have changed them for ALL libapt users… given
that you speak about popups and annoyance levels in your own mail…
What should unattended-upgrades do with those notices? What should
a software-center-like thing do with them?
So until we have better control over messages, so that a frontend can
actually more programmatically decide which to show, which to hide and
how to display them, I decided a while ago to bundle them into a new
level and hide it away by default. Similar to how some front ends decide
to not even bother with warnings (and some not even with errors, but
that is a different story).
> least those parts which were clear enough) and agree with the apt
> developers that the message about the Debian bookworm change
> concerning non-free-firmware is only a notice, not a warning.
On a not unimportant side note: This notice (as well as my explicit
examples ftp & auth.conf earlier) is apt{,-get} specific, so even
if aptitude would show notices, it wouldn't show this one as the code
generating them is not in libapt, mostly because it can not really be
there. The update-code shared in libapt is only concerned with updating
the files, but which sources.list files are (not) involved and if and
how the caches are (re)build is an individual application decision. The
notice generation needs to know this through, so we would need a new API
for that… and if that new API is just generation messages, shouldn't it
be better at generating them. I mean, giving you a couple lengthy
strings to display as-is to the user? Shouldn't the URI be clickable?
And why isn't the package name? Oh, and the filename of the sources.list
file? Heh, how about opening it… (see the last paragraph) WAY to much
design work for something I initially didn't even want to implement in
apt to begin with.
I hope that clear this sorta misunderstanding up at least a bit.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Bug#1032631: please drop transitional package apt-transport-https from src:apt
On Fri, Mar 10, 2023 at 01:33:23PM +, Holger Levsen wrote: > On Fri, Mar 10, 2023 at 02:25:59PM +0100, Julian Andres Klode wrote: > > We have no plans to drop this package for the foreseeable future. Doing > > so breaks various bootstrapping tools and causes severe headaches we > > don't have the capacity to deal with. > > even if apt provides apt-transports-https? apt already does, longer than (trying to) dropping a-t-h even. The whole reason the package was reintroduced quickly after Julian dropped it was that tools like debootstrap were exploding, and even if he was expressing hope for the better in the commit message I have my serious doubts that has changed and as he said we aren't exactly able to fix the world… hands (more than) full with what we have now already. If you can come with prove that debootstrap (and probably other tools) can deal with virtual packages nowadays, we will be happy to oblige – and I think I know a couple other people who would be happy, too. Adding Provides: https://salsa.debian.org/apt-team/apt/-/commit/c6a428e4d17b408c2701def5daa46ca950948980 Drop a-t-h: https://salsa.debian.org/apt-team/apt/-/commit/5e770a07c8fd649340e83725f6d07b94c361e87c Reintroduce: https://salsa.debian.org/apt-team/apt/-/commit/afe3cd6ef1b157a07d05bbf70283e4f175813438 Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#716763: apt: Man page of apt-cache dont mentions regex on operations with pkg argument , except from 'search'
g the liberty to close this referenced bugreport via a CC of this message. The rest of this message should shine some light on why this might have happened back in the day and what could possible be done (nowadays). In either case, its not really a bug, "just" a communication mismatch between users and apt-* tools which can not be changed even if we wanted to (= foreshadowing a comment regarding 'apt'). Also, as a side note, be careful with your shell! It might interpret things for you as well. If all else fails btw, you can just go full regex btw as the initial message in the bugreport already said. apt (not apt-*) has those unanchored regexes disabled by default, so as it is Christmas^Wfreeze I suppose you could also workaround your problem in reportbug with a little config option: | $ apt-cache show dbus-c++ | grep -e ^Package: | wc -l | 28 | $ apt-cache show dbus-c++ -o APT::Cmd::Pattern-Only=true | N: Unable to locate package dbus-c++ | E: No packages found | $ apt-cache show vera++ -o APT::Cmd::Pattern-Only=true | Package: vera++ | Source: vera++ (1.2.1-2) | […] The option is undocumented, so we might drop it at some point, but I guess its not very likely to happen now or anytime soon if at all, so it should be good enough as a workaround until you fix the underlying problem in reportbug. > (For reportbug I think we could also solve it by making more use of > python-apt.) That is probably a good idea as, as you can see, the command line interfaces are more concerned with trying to making sense of what the user might have meant with its (incomplete) input rather than being 100% machine predictable. That apt-* are used in a lot of scripts doesn't change that, it makes it in fact worse, as changing the behaviour is impossible without breaking others. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1031026: ycmd broken on current default python3 (3.11): "cannot import name 'getargspec' from 'inspect'"
Control: reassign -1 python3-bottle On Fri, Feb 10, 2023 at 07:39:19PM +0400, Anton Shestakov wrote: > Currently in Debian testing python3 refers to python3.11, but that version has > removed getargspec function from inspect module. So when you try to run ycmd, > it errors out: > > Traceback (most recent call last): > File "/usr/bin/ycmd", line 37, in > from ycmd.hmac_plugin import HmacPlugin > File "/usr/lib/ycmd/ycmd/hmac_plugin.py", line 19, in > from bottle import request, abort, response > File "/usr/lib/python3/dist-packages/bottle.py", line 44, in > from inspect import getargspec > ImportError: cannot import name 'getargspec' from 'inspect' > (/usr/lib/python3.11/inspect.py) > > Running manually with `python3.10 /usr/bin/ycmd` shows usage information from > ycmd, meaning the command is not completely broken on python3.10. But > `python3.11 /usr/bin/ycmd` shows the error shown above, so this issue > definitely was exposed by python3.11 becoming the new default. > > > Versions of packages ycmd depends on: > ii libabsl20220623 20220623.1-1 > ii libc6 2.36-8 > ii libclang1-141:14.0.6-10+b1 > ii libgcc-s1 12.2.0-14 > ii libpython3.11 3.11.1-2 > ii libstdc++6 12.2.0-14 > ii python3 3.11.1-3 > ii python3-bottle 0.12.19-1+deb11u1 > ii python3-frozendict 1.2-3 > ii python3-future 0.18.2-6 > ii python3-jedi0.18.2-1 > ii python3-watchdog2.2.1-1 As the python trace shows the import is done inside python3-bottle, and indeed, not a single mention of getargspec in ycmd source, so reassigning there. I have to note that I can't reproduce this locally on a Debian sid machine which has already autoremoved python3.10 and is so 3.11 only. Neither can the autopkgtests of ycmd or vim-youcompleteme which would flare up in bright red if ycmd is fundamentally broken (I would hope). That might very likely be due to me/CI using python3-bottle 0.12.23-1, which if I read the code right uses getargspec only in a python2 path, so this bugreport might very well be already fixed. Not sure why you have a mixture of packages from Debian sid (e.g. libc6) and Debian stable (e.g. python3-bottle) installed. While I guess I could raise a versioned dependency on python3-bottle from ycmd to ensure you have it installed but that isn't very elegant. In an optimal world libpython3.11-minimal (which ships inspect.py) would break old versions of python3-bottle, I guess, so that this is 'fixed' for all bottle users. I will leave that up to folks who actually know python better than me through. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1030935: apt-file: patch proposal for #988105 and change its output to add release and arch
On Thu, Feb 09, 2023 at 07:54:21PM +0100, Patrice Duroux wrote:
> Will apt sooner or later provide similar functionality to apt-file?
> So that the development would become more integrated/consistent.
Maybe, maybe not. Personally, I am not much of a fan of rewriting X in
Y for (close to) no reason, but perhaps someone else will and/or a good
reason is found.
apt-file is rather close/integrated/consistent with the rest of the apt-
namespace in so far as it is e.g. directly integrated with 'update'
nowadays. Other things in "our" namespace are far more detached…
> In a first approach I tried using 'dpkg-query -W' but found 'apt list' more
> direct for purposes. How can I get also the release of the installed package:
> no
> way with 'dpkg-query -W -f '${Package} ${Release} ${Architecture}
> ${Status}\n'?
You want information which is technically not available anywhere. You
see that if you don't install some updates: No tool will have an idea
from which release/repository a version came from! It can only guess
from where you might have installed a version if it can find the same
version online somewhere (in apt the mysterious "now" release will
appears in such cases).
(While there is semi-frequently talk about recording such and more info
at installation time *somewhere* in apt/dpkg/… nothing materialized yet)
As said, I have no idea what the code does, so also no idea what it
would produce. You might get away with similar guesses or by just not
printing the information at all.
On a sidenote, dpkg somewhat makes available the Contents of installed
packages via -L (list) and -S (search), which probably doesn't work the
same way as apt-file, but perhaps it helps anyhow.
> By the way, dpkg-query(1) manpage cites 'Origin' as a possible field but it
> seems always empty on my system.
Origin is a heavily overloaded term (like most others). In dpkg it
refers to deb-origin(5) (see also dpkg-vendor(1)). In apt it can refer
to the field in a Release file (o= in pinning) or pinning by hostname
(Pin: origin). And probably other meanings I forgot^Wrepressed.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Bug#1030935: apt-file: patch proposal for #988105 and change its output to add release and arch
Hi, On Thu, Feb 09, 2023 at 03:10:39PM +0100, Patrice Duroux wrote: > Dear Maintainer, (Disclaimer: I am not an apt-file, but an apt maintainer) > The first is regarding the sub std_release that I add to match the 'apt list' You are not allowed to use 'apt' in a script. We could change its output any second breaking your ad hoc parsing without any qualms. > that gives 'unstable' even if the apt sources.list is using 'sid' and then 'apt list' for some reason prints the 'Suite' value. I suppose it really shouldn't and pick 'Release' (which is what the sources.list includes, which is either 'Suite' or 'Codename' usually). We might change that (q.e.d. previous paragraph). There is no absolute right answer here, it is a question of UI and the specific use case which you prefer. > accordingly the name of the content files. Is there a better way? (apt API? > metadata file?...) I have no idea about perl & libapt-pkg-perl, but I suppose getting a list of installed packages is such a basic task that it should be possible with it. If you really want to parse a program, dpkg would be the better choice here. Accessing the names of files (including the Content files) is a relatively new feature (like ~2 Debian releases old), so I am not sure how much if any is accessible in perl. Command line wise it would be via 'apt-get indextargets'. You will need this as a) Content files have different filenames in different repositories as they have different storage locations (Debian vs Ubuntu mostly). b) are likely compressed, but if and with what is a configuration detail. c) I have plans, but nothing concrete yet to have apt store files elsewhere and with names where your guessing wouldn't work at all. As I am not sure what apt-file does here and what your (perl) code changes, I have no comment on the patch itself and what effects output changes would have. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1030189: Let regular users know need to put non-free-firmware in sources.list
On Wed, Feb 01, 2023 at 09:32:47PM +0100, Sven Joachim wrote: > > Maybe the next time he uses apt*, somehow the system should tell him... > > Somehow, but how exactly? fwiw I intend to have apt print a notice at the end of each 'apt(-get) update' call if certain conditions are met in bookworm. My branch with details can be found here: https://salsa.debian.org/apt-team/apt/-/merge_requests/282 It is marked Draft as I mainly need to a) figure out which firmware packages from bullseye (will have been) moved in bookworm to non-free-firmware for one of my targeted scenarios and b) have a reasonably detailed entry in the release notes to link to explaining what to actually do as I really don't want to get into details in a one-line message… will be hard enough to cover all bases in a few paragraphs after all. A stub for the release-notes can be found in https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/138 although as I noted in a comment there I would prefer a more detailed §5 entry rather than linking to a rather short §4. The code isn't exactly rocket-science (although a bit lengthy) & as I am reusing already existing messages it could theoretically be backported to bullseye and pushed in a stable update so that users would see it while upgrading instead of on some run after the upgrade, but for the moment I am not planing to push for that. I might have if someone had shown any interest in the idea months ago[0]. The message is rather cryptic, but its intent is to catch unaware sid/testing users and those stable users who don't read release notes, so that is borderline okay. If the goalpost is instead moved to every user of Debian the messages should really not be that cryptic, but that would mean more work & more diff (not just by me, but e.g. translators). At this point in time it seems better to focus this energy on the release notes. Or, on discussing if gmake users are affected, too, … Best regards David Kalnischkies [0] https://lists.debian.org/debian-devel/2022/10/msg00217.html signature.asc Description: PGP signature
Bug#1030020: apt: Conditional way to automatically uninstall Protected packages due to Build-Conflicts
On Mon, Jan 30, 2023 at 12:03:14PM +0100, Guillem Jover wrote: > I checked the code and I find in apt-pkg/deb/dpkgpm.cc the > config variable pkgCacheGen::Protected being used, but I'm not sure I > understand how it is intended to be used? The code returns true for > "none" and "native" and when the "Important" flags is not-zero, but > «doc/examples/configure-index» also mentions an "all" value which > does not seem to be handled here? Shouldn't the "none" mean to return > false? pkgCacheGen::Essential is affecting the generation of the binary cache. Specifically, it tells the code to ignore the flag it parsed from the file in certain conditions and not mark the package essential in the cache – so that later apt code/runs believe the package is not marked essential at all. The code you found is preparing the command line for dpkg and that of course doesn't know what apt believes, so for certain values apt has to tell dpkg for all packages that dpkg is allowed to remove essential packages. - "all" is the default and keeps them all (aka ignores nothing). - "native" only marks :native or :all packages - "installed" only gives packages which are installed the flag - "none" ignores it for all, so no package is essential As we talk removals here we have to allow dpkg for all packages in the native/none case as we don't know if we have "forgotten" the flag for some packages. In the "all" case we haven't and in "installed" we haven't for anything which matters (= we aren't removing not installed packages after all), so those can rely on the info from the binary cache. But wait, you said pkgCacheGen::Protected… which intuitively should behave in the same way, but isn't handled in the same place essential is in apt-pkg/deb/deblistparser.cc. mh, I wrote the essential code (there, not the code you found actually) a long while ago but was not involved in the protected feature, so that could be intended in some way I don't foresee yet, but I suppose it was just forgotten. It is a rather esoteric feature after all. > If this is already supported by that option I'd request documentation > for it, or otherwise support for a similar option to control this > would be nice. Then a build-driver such as sbuild or pbuilder could > disable that option when and iff it knows it is driving the build > inside a discardable system. So, pkgCacheGen::Essential exists but isn't really documented except on a need-to-know basis and somewhere in the multiple-duplicates collection of bugs asking apt to behave a certain way with essentials. The reason is that it is hard to use: you need to provide it to the command which generates the binary cache, which is stored on disk for later commands to reuse as long as it remains valid & petty dangerous as apt will e.g. easily come to the conclusion that removing coreutils is acceptable because nothing really depends on it… While most users who demand such an option are more of the type: I want to remove this previously essential package (diff) which is now a transitional package (diffutils) but don't want to remove the old sources.list entry and I am really annoyed that apt reinstalls a package which is essential for an old release I have in my sources… those users are prime candidates for shooting themselves in the foot while demanding support as its an officially documented option. Anyway, you can get away with Build-Conflicts on Protected packages a lot easier with (partially) documented options: --allow-remove-essential -o APT::Get::Allow-Solver-Remove-Essential=true The first gets you past the error which used to be "Do as I say!" and the second is for the internal apt resolver (and relatively new¹). If another resolver is used you might need to use options specific to it (or not, if it doesn't care about the field). That isn't specific to build-dependencies either, its what you need in general while removing them (indirectly – the first is enough if you mention the package explicitly on the command line directly) in all cases. Yes, essential and protected are given the same treatment here. An equivalent just effecting protected seems not to exist. So, in summary, I think the solution to this bugreport might simple be to have the former flag also enable the later config option and perhaps mention in the documentation that this flag also effects protected. The semi-alternative would be to add also an --allow-remove-protected but I am not sure this is actually needed/a good idea. You have to be careful with either if your system is important and if your system isn't you are somewhat likely to provide both options together to apt anyhow just to be sure… Best regards David Kalnischkies ¹ 891efe3b201a104445ea723a3a5b9b434a78c364 (Wed Nov 17 2021) signature.asc Description: PGP signature
Bug#1026411: vim-youcompleteme: Breaks freshly installed vim-nox
Hi, On Tue, Dec 20, 2022 at 01:20:52AM +0800, Charles Yang wrote: > Launching vim without any arguments, it reports errors like below endlessly: > ``` > Error detected while processing CursorMoved Autocommands for > "*"..function > 25_OnCursorMovedNormalMode[1]..25_AllowedToCompleteInCurrentBuffer[1]..25_AllowedToCompleteInBuffer: > line 12: > E117: Unknown function: youcompleteme#filetypes#AllowedForFiletype > ``` > , making vim almost unusable. Mhhh. How did you enable youcompleteme in vim, via vim-addon-manager or via the (in newer vims) builtin :packadd command? If you had enabled it via vim-addon-manager in the past this is likely a duplicate of #1019188 where I wrote: | Upstream added/split out two new files which I had not recorded for | install by v-a-m, so it could indeed not be found. Me fixing the | registry entry doesn't resolve the problem completely through as you | will have to then reinstall the plugin with v-a-m (that is inherent | in its design). If you run 'vam list' it will show youcompleteme as "broken". You should be able to install it again to fix the problem. You technically have to do this after every update with every installed plugin but in practice you usually get away without it… It is one of the reasons vim-addon-manager is deprecated within Debian, so that might also be the right time for you to drop its usage. Just tell vam to remove youcompleteme in that case. You can then either load the plugin on demand with :packadd youcompleteme in vim or you can add a line like packadd! vimcompleteme to your vimrc configuration to load it always (like it was the case with v-a-m before). It should be similar for the other vim plugins you might have installed, but not all of them might have transitioned yet. Hope that helps & this is indeed that issue, otherwise I will have to dig a bit deeper what is wrong as it works here for me™. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1024457: "apt changelog" fails to display the complete changelog
Control: severity -1 important On Sat, Nov 19, 2022 at 10:42:01PM +0200, Adrian Bunk wrote: > Severity: serious Well, no. You haven't provided a reason and I fail to find an obvious one as apt's key functionality is hardly effected by a not (by default) working changelog sub-command… could Debian release with this "bug" unfixed? Certainly, given that it might/likely fails for other reasons like the online repository not actually providing changelogs. That said, severity hardly makes a difference for us anyhow as somehow assigning severity doesn't magically assign free time as well (at "best" higher values have a negative effect), so grave or wishlist doesn't really matter, but I suppose important is closer to your hope of getting that fixed before the release some way. > debhelper recently started removing older changelog entries from > binary packages, but the way to get them with apt does not work: https://salsa.debian.org/apt-team/apt/-/merge_requests/261 Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1022830: apt ignores versioned provides if non-matching version is installed via another dep
reassign -1 libruby3.1,ruby-csv retitle -1 libruby3.1 and ruby-csv are providing different things under the same name On Thu, Oct 27, 2022 at 12:32:16AM +0900, Marc Dequènes wrote: > I had a weird FTBFS in #1022340 and it looks like the resolver is just > skipping the versioned dep because another dep provides the same virtual > package. Unfortunately it does not resolve the required version and should > install the non-virtual package providing the right version (they are > co-installable). More info in the referenced BR. […] > Could you have a look please? $ apt-cache showpkg ruby-csv […] Reverse Provides: libruby3.1 3.1.2-3 (= 3.2.2) libruby3.0 3.0.4-8 (= 3.1.9) libruby2.7 2.7.4-1+deb11u1 (= 3.1.2) You are right that libruby3.0 which provides 3.1.9 is not enough to satisfy the build-dependency of redmine, but libruby3.1 is installed, too, and that certainly does satisfy ruby-csv (>= 3.2.0). It is therefore correct for apt to not install the real ruby-csv package as that dependency is already satisfied. You might or might not be able to workaround this with Build-Conflicts, but in the end libruby3.1 and ruby-csv should really agree on what they are providing at what version or not… hence reassigning to both. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1022199: apt: certificate verification fails after adding custom root certificates through ca-certificates
On Sun, Oct 23, 2022 at 11:03:19PM +0200, Julian Andres Klode wrote: > apt just calls gnutls_certificate_set_x509_system_trust() and > gnutls_set_default_priority() so this should not be our issue. Also, on a side note, I have a custom CA (without an immediate) and apt and co are happy with it. The other difference to my setup is that I place my certificate in /usr/local/share/ca-certificates/ which avoids further configuration as update-ca-certificates will pick them up directly from there (see its manpage). It might help if you can check if the chaining is part of the problem or what else might be specific to your setup. Perhaps its the algorithms used and e.g. gnutls not implementing the EC curves you used (or something like that or not at all – its just something I ran into in the past, although not with gnutls, that worked back then…). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
On Mon, Oct 10, 2022 at 08:50:49AM +0800, Paul Wise wrote: > On Sun, 2022-10-09 at 18:54 +0200, David Kalnischkies wrote: > > I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'. > > That sounds interesting and would be nice generally, however... > > > On a sidenote: What the Depends ensures which the Enhances doesn't is > > that they are upgraded in lockstep. As in, if for some reason foo (or > > foo-dbgsym) have their version appear at different points in the archive > > apt would hold back on a Depends while with Enhances this dependency > > would be broken and hence auto-remove kicks in. > > For the rolling Debian suites, the main and dbgsym archives are often > out of sync, the dbgsym packages updates sometimes appear first and > sometimes second. Keeping foo/foo-dbgsym in sync is strongly needed Oh, are they? I thought they would be better in sync. Never noticed, but I tend to have extremely luck avoiding any kind of apt problem… Anyway, that is solvable. An 'upgrade' e.g. keeps back an upgrade if that would break a Recommends. Seems reasonable to keep it back also if it would break a previously satisfied Enhances as loosing the features of a plugin due to an automatic upgrade seems super-bad. For full-upgrade we could go with a rule specifically targeted at packages from the 'debug' section with such Enhances dependencies. If you have multiple architectures of an M-A:same package installed they keep each other in check as well as long as the "old" version is still downloadable. So that shouldn't be too hard™… The downside is that both are heuristics which are solver dependent, as such aptitude likely and external solvers surely won't support that (without implementing similar solution optimisation logic). That said, this isn't really different from "miss-using" Depends for it to have it be hold-back as is not working with every solver in every situation either. For apt I am actually somewhat surprised if it does in the general case as the -dbgsym should have close to no power (as nothing depends on it), while the thing it has debug symbols for probably has things depending on it, so if it comes to upgrading foo or keeping it back it should favour upgrading foo (and hence removing foo-dbgsym) in most cases currently (full-upgrade that is, upgrade of course not). Anyway, if that is an acceptable/desirable option we should probably move any apt machinery discussion into its own bugreport and away from d-d@ and debhelper. For this thread I would say its enough to decide if using Enhances in this way is acceptable for everyone. If and how apt (and/or other tools) make then use of the data is up to them in the end. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
idea for various reasons (hence why apt likes to go on a remove spree if that is deemed more beneficial), but that would lead us too far off-topic here… So, could that be an acceptable Option c) ? Best regards David Kalnischkies ¹ this example was explicitly chosen as its possible that you want to use them independently. I don't see a lot of reasons for independent usage of e.g. asc and asc-music even if its of course possible. signature.asc Description: PGP signature
Bug#1018242: osk-sdl: Kernel modules for touchscreen input not included in initramfs on amd64 if MODUES=dep is selected
Hi, On Sun, 28 Aug 2022 00:21:25 +0100 Balint Kovacs wrote: > I have found the kernel modules necessary, it seems that hid_multitouch and > i2c_hid_acpi cover at least the Steam Deck and the Asus T100TA. Incidentally, I have the same problem with a Microsoft Surface Go with Debian 11.5 (default kernel and all), but the modules seem not enough. In =most it works without issues. (Just in case it makes a difference: Using osk-sdl via grub, not crypttab keyscript) I tried by adding the modules to /etc/initramfs-tools/modules (and of course rebuilt the initframfs afterwards). I also tried a self-compiled backport of current packaging state in salsa with no change in this regard. Happy to test more/other/different combinations, I am just at a loose as to how to get a list of modules included in these policies. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1004514: grub-common: background images don't work with luks2 encrypted root partition
reassign 945404 grub-common # package usefulness is not really affected severity 945404 minor severity 1004514 minor merge 945404 964859 1004514 thanks Hi, as I stumbled over this problem just now I thought I would at least help a bit by merging the reports about the issue (fingers crossed I got the control@ right, its a while), which I consider minor as it doesn't affect the usefulness of grub – it still boots without issue – it is just not as visually fitting as it could be. From my PoV I agree with the analyse and patch by Steve McIntyre in https://bugs.debian.org/945404#35 and have locally applied it at least until grub upstream understands luks2 and can detect this on its own. I suppose patching #803995 (Caching background image conceals original filename when updating) would make sense if we (always) cache. There is also #692244 which asks for having caching configurable. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#919652: ath10k - QCA6174 - Surface Go - missing board data - fix .bin included extracted form official .msi
Control: tags -1 + fixed-upstream On Tue, 19 Jul 2022 23:46:17 +0300 Dmitry Baryshkov wrote: > I'd suggest submitting the board files to the ath10k-firmware repo, > which will then find it's way into linux-firmware. fwiw this (or, well an update of the existing one) actually happened already at the end of 2021 [0], but Debian hasn't seen an update so far. [0] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=4d74f4dec175363fa24c95702dd86f477cef232c With that board file wlan works even through the kernel (at least on bullseye, not tested others) still complains about missing firmware: ath10k_pci :01:00.0: firmware: failed to load ath10k/pre-cal-pci-:01:00.0.bin (-2) fimeware_class: See https://wiki.debian.org/Firmware for information about missing firmware ath10k_pci :01:00.0: firmware: failed to load ath10k/cal-pci-:01:00.0.bin (-2) (followed by messages about successfully loading firmware-6.bin and board-2.bin) The internet says these files are optional, which is somewhat confirmed by having working wlan even without them, and I fail to find them – but find some references to them in Debian forums as e.g. also d-i shows its missing firmware message for those files (even if you have the firmware cd variant, which is both annoying and confusing). Not well versed in kernel code, but while [1] claims (at least for the cal file) that it is optional and should print no warning it happily still does anyhow? Or perhaps its ath10k_fetch_fw_file() doing a firmware_request_nowarn() to then go on and ERR_PTR() on its own… [2] Anyway, not really the point of this bugreport, just at the off chance someone has an idea how to proceed on this somewhat related front. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/ath10k/core.c#n1227 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/ath10k/core.c#n882 Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1019188: vim-youcompleteme makes vim show many error messages on start and while using
Hi, On Tue, Sep 06, 2022 at 10:34:46AM +0200, Emmanuel Thomé wrote: > On the other hand, enabling youcompleteme via :packadd youcompleteme > seems to work without error. Thanks for looking into it! The problem seems indeed to effect vim-addon-manager only: Upstream added/split out two new files which I had not recorded for install by v-a-m, so it could indeed not be found. Me fixing the registry entry doesn't resolve the problem completely through as you will have to then reinstall the plugin with v-a-m (that is inherent in its design). Looks like this patch would resolve it: diff --git a/debian/vim-youcompleteme.yaml b/debian/vim-youcompleteme.yaml index 57d1c6f..b00ebad 100644 --- a/debian/vim-youcompleteme.yaml +++ b/debian/vim-youcompleteme.yaml @@ -3,5 +3,7 @@ description: fast, as-you-type, fuzzy-search code completion engine basedir: /usr/share/vim-youcompleteme files: - autoload/youcompleteme.vim + - autoload/youcompleteme/finder.vim + - autoload/youcompleteme/filetypes.vim - doc/youcompleteme.txt - plugin/youcompleteme.vim On your system the file is installed as /usr/share/vim/registry/vim-youcompleteme.yaml I will see if I can come up with a little autopkgtest to ensure not breaking that too often in the future. I suggest looking into transitioning away from v-a-m through as Debian seems to slowly do this as a whole (#1015149). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1019188: vim-youcompleteme makes vim show many error messages on start and while using
Hi, On Mon, Sep 05, 2022 at 09:47:33AM +0200, Frank Scherrer wrote: > Version: 0+20220824+git7c3a88f+ds-2 > >* What led up to the situation? >An update from version 0+20220402+git3ededae+ds-3, if >snapshot.debian.org is right, there was a version in between. (Nitpick: There were two versions in between, a -4 revision of your "good" version and a -1 revision of the "bad" one, but that is easy to miss with the version number that large and unwieldy.) >* What exactly did you do (or not do) that was effective (or > ineffective)? >I started vi and tried to move around in a file after pressing return >to all the error messages. That looks indeed bad, but sadly I can't reproduce this manually nor in the automatic tests so far. :( > Here come the error messages: > Error detected while processing CursorMoved Autocommands for "*"..function > 45_OnCursorMovedNormalMode[1]..45_AllowedToCompleteInCurrentBuffer[1]..45_AllowedToCompleteInBuffer: > line 12: > E117: Unknown function: youcompleteme#filetypes#AllowedForFiletype Mhhh. Which filetype (vim tells you if you type ":set filetype?") has this buffer? Can you perhaps attach a file triggering these error for you? Perhaps its a problem with a specific filetype/syntax file (recently there was e.g. a bug in vims typescript syntax file, but you have a fixed version installed already). How are you enabling vim-youcompleteme? I recently switched the package away from vim-addon-manager, even if it should still be technically supported (and that was already done before your "good" -3) but perhaps it broke in a later version. I note that the "bad" versions added a few experimental features and with it a bit of refactoring and new files. … Now, I wanted to ask you to run 'vim -Nu NONE' (starting vim without any configuration) and then run ':packadd youcompleteme' to see if it is dependent on your local configuration, but I forgot the 'N' flag and as a result got similar errors as you got… Could it be that you run vim in vi compatible mode? (:set compatible?) Ideally this plugin should really work regardless of compatible mode or not, but I am not sure upstream agrees and will probably need some time to dig into what is going on here. Just wanting to confirm now that I am not following a red herring and this is indeed the cause of the issue (or if I found another). If you are in compatible mode I suppose it is a deliberate choice as I think it is not Debians default, but on the off chance that it is not feel free to join the nocompatible side as a possible fix/workaround. We have cookies. ;) Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1016875: RFS: freefilesync/11.23-1 [ITP] -- cross-platform file sync utility, gpl release
On Thu, Aug 11, 2022 at 11:18:36PM +0200, Fab Stz wrote: > I was also wondering if M-A:foreign was actually needed in that case. > > So the only alternative I have is either to remove the line, or set it to no. > Is there any best/prefered practice? Just remove the line, I would say. It is equivalent to setting M-A:no explicitly from a technical standpoint, but the later implies for other contributors that there is a hard/complicated reason that this package can not be marked with another M-A value currently. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1016875: RFS: freefilesync/11.23-1 [ITP] -- cross-platform file sync utility, gpl release
Hi, On Thu, Aug 11, 2022 at 03:27:14PM -0400, Boyuan Yang wrote: > * You indicated "Multi-Arch: foreign" in debian/control file. However > according to https://wiki.debian.org/MultiArch/Hints#ma-foreign , M-A: > foreign only applies to Architecture: all packages. Your package is not of > Architecture: all. To clarify, the mentioned wiki explains how the Multi-Arch hinter comes up with its suggestions. In this specific section how a package which ticks all the boxes can surely be marked M-A:foreign. Packages who do not tick (all) the boxes could be valid candidates for M-A:foreign as well, its just that an automated process like the hinter can't decide that in the general case.¹ I suppose this package could be marked M-A:foreign as it likely has no architecture-specific interfaces but that needs to be checked to be sure. I also suppose that it is not very useful to mark it as such in any case as it looks like a GUI and those tend to be leaf packages, but M-A only comes into play if other packages (build-)depend on your package. So I would recommend to refrain from setting M-A:foreign for this package until you are either REALLY SURE its the correct thing to do OR some other Debian contributor tells you they need you to set it. Best regards David Kalnischkies ¹ sed for example is M-A:foreign even though it is arch:any as the output it produces does not change regardless of you running it on amd64 or armhf. A compiler like gcc on the other hand produces output (= machine code) specific to the architecture it runs on and hence can not be marked M-A:foreign (And than an interpreter like python3 comes along and it becomes complicated. Also, this is a gross simplification). signature.asc Description: PGP signature
Bug#1016897: Temporary failure resolving 'deb.debian.org'
On Tue, Aug 09, 2022 at 04:41:44PM +0530, probal basak wrote: > We have GitHub actions setup for building/running some scripts. We don't use GitHub or actions, but a simple search on GitHub https://github.com/search?q=http%3A%2F%2Fdeb.debian.org+path%3A.github finds more than a hundred matches. This is not a recommendation for any of these projects/setups: Some of the matches look dangerous if not used with extreme caution even on the very short glance I gave the first page. And no, I don't have a best-practice/recommendation for it as I am not using it. The important part is that I doubt all these have broken CI lying around, so its something about YOUR setup/action/project/… that you haven't told us and you will have to figure out as we don't know your project. So first come up with a reliable way to reproduce your problem by stripping down your project to the bare minimum needed and share this reproducer here with us. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1012196: buglist
Hi, On Thu, Jun 16, 2022 at 05:10:41AM +, André Flechs wrote: > > For the others: Please only add them when you are sure they are resolved. > > If you are not sure or you do not have the time for them, please leave > > them untouched. > > How should I write the changelog to close unreproducible or fixed bugs? You don't. Closing a bug via the changelog is only for bugs which are resolved by this changelog entry. Ideally you have verified this yourself rather than relying on (educated) guess work. For the "fixed" one that is true with your upload I suppose? If not, but in an earlier version you would write a mail to -done@b.d.o with a Version pseudo-header and some free-form text saying something like "This bug was fixed in version 42-1 with the change hence I am closing as done. Feel free to reopen if this remained unresolved for you". The unreproducible ones you could close the same way without a Version header and some friendly free-form text saying something like "Closing as it is unreproducible (for years) and no more information could be acquired. Feel free to reopen if this still happens for you with more information so we can hopefully find and fix the issue". How friendly (or not) you want to be is your choice of course, both are just condensed examples of what I tend to do. Have a look at the developer-reference which has the entire chapter 5.8 dedicated to "Handling bugs" explaining how to deal with these and many other 'buggy situations' (SCNR). It also explains and points to further documentation about our BTS so that you will know what I mean above with pseudo-headers and -done without me repeating it here. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1012173: apt: Locking timeout for archives
Hi, (somewhat obsoleted by Julians reply, but just so I haven't only wasted my time, lets waste yours as well by sending it anyway ) On Tue, May 31, 2022 at 12:58:05PM +0200, Jouke Witteveen wrote: > In our setup, we share an archives cache directory [Dir::Cache::archives] > between multiple (virtual) machines. This turns out to be an effective > way to save bandwidth and disk space. However, each machine may lock the > archives directory and make apt unavailable for the other machines. We had I am not sure we should encourage this setup. It feels a bit brittle, especially as not every form of directory sharing even supports sharing the locks (like NFS I think), so that silently works until it doesn't. Sadly I don't really have a good alternative suggestion as e.g. the idea I am on/off playing with of constructing a partial mirror out of /var/cache/apt/archives (and /var/lib/apt/lists) so that you could us a mirror+file as a source which would have priority for the reconstructed partial file:/ mirror and otherwise fall back to the online https:// source is nice and all, but certainly not as trivial to set up and maintain as sharing /var/cache/apt/archives and pinky- promising to each machine involved to not mess up too badly as you are basically granting each of them full root access on each other. (I take it that not copying around is your goal, hence me talking about file:/ as that uses the files at the place they are rather than copying them into /var/cache/apt/archives. Otherwise more "traditional" caching solutions are likely an easier/better fit as Julian mentioned) > 3. Implement per-download locking with a timeout as requested in #478961. That isn't really gonna work as its not just the download, you also want to keep the file around until its no longer "needed", so we would need to hold onto potentially thousands of locks in a typical full-upgrade. If we just lock individual files while they are downloaded e.g. an 'apt clean' operation could remove all the ones we finished downloading already. Just like 'apt' defaults to removing deb files after installation nowadays, so that the other machine who wanted to reuse that file ends up failing to find it even through it was here a second ago… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1009797: apt: support "nodoc" build profile
> Just to add a rather unrelated argument for the nodoc support in apt. apt is For the record: I wrote nodoc and pkg.apt.nodoxygen support earlier last month and have it finally proposed earlier today in a MR request… https://salsa.debian.org/apt-team/apt/-/merge_requests/238 Another argument is actually that it helps our own CI tests: We do not build the packages so far, but we build i386 and amd64 to run tests in different setups (as root and as non-root) and building the docs twice is kinda pointless, so now we don't do this anymore while also using apts support for build-profiles to make cuts on setup costs as well. So… > Thanks, if it intrigues and inspires you, go for it, though I'd hate to > send you too deep down that rabbit hole otherwise... don't worry, I got a bit sidetracked and there could be done a lot more (as always) but sometimes I enjoy digging myself into a hole even if nobody really needs it… with three-ish (potential) "wouldn't it be nice" users this feature set might even be in the upper bracket of usefulness for things I did in these rabbit hole endeavours… ;P Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1009797: apt: support "nodoc" build profile
Hi, On Sun, Apr 17, 2022 at 06:50:19PM -0700, Vagrant Cascadian wrote: > This also allows building functional apt packages with a smaller > dependency chain, so might help with bootstrapping efforts too! Bootstrap usually doesn't care about arch:all packages, so that argument doesn't work that well here. I would even say it works against you: > I thought docbook* and xsltproc could also be excluded from the > Build-Depends, but that triggered some other build failures. They (alongside po4a) are used to build the manpages which we ship in our arch:any packages (we could go with apt-common, but while that saves mirror space, it could waste system space as you now have manpages installed for things you haven't installed… or we go with multiple apt-common packages which increases complexity and overhead… so far we haven't gone down this road as it seems not very beneficial in the end). We certainly could improve support for nodoc (upon your patch) by not building the manpages in this profile which could indeed help boot- strapping (although they never asked so far, which I am somewhat surprised now to be honest) – but it would also end up changing the contents of every package and hence spoil src:apt reproducibility in that it will be reproducible on paper, but nobody can actually use the result. > Of course, ideally building documentation reproducibly would be very > nice as well, so it would be good to eventually fix the underlying > issues in doxygen: > > > https://tests.reproducible-builds.org/debian/issues/unstable/nondeterminstic_todo_identifiers_in_documentation_generated_by_doxygen_issue.html > > https://tests.reproducible-builds.org/debian/issues/unstable/nondeterministic_ordering_in_documentation_generated_by_doxygen_issue.html It seems like hard issue(s) to solve and I am certainly not up to work on this, but there seem not too many effected, so perhaps its worthwhile to go the route of a nodoxygen (or pkg.*.nodoxygen) profile instead as it would mean less variation and e.g. a reproducible binary apt package would at least mean something as everyone has that variant installed. I would at least be happy to beat our build system into omitting just the doxygen part rather than some (currently with patch) or all (possible future) docs. Shouldn't be hard (= famous last words). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1008644: ITP: nala -- commandline frontend for the apt package manager
Hi, Disclaimer: As I am an APT developer, I am feeling obligated to note that the following comment is just that, not an endorsement nor a review. I am also not indicating interest or what not. It is just a comment. On Tue, Mar 29, 2022 at 09:35:27PM -0400, Blake Lee wrote: > This package is useful because it improves the UX of managing packages > through the command line with python3-apt. Additionally provides some (improves… tastes are very different I guess, but that is fine. It reminds me of an unfinished branch though… a well, one day.) > extra quality of life features such as a transaction history you can The README describes it as using /var/lib/nala/history.json, libapt has /var/log/apt/history.log with I suppose roughly the some content, although we don't have IDs in there and removing entries would be strange. We have no interface for it so far though as we are as usual chronically understaffed. Anyway, 'undo' in relation to Upgrades triggers my spider-senses as downgrades are in general not supported. The screenshots avoid that problem supposedly by being only about installing a bunch of new packages and eventually removing these packages again. > […] Nala improves upon the hardwork of the apt […] You don't mention it here, but the README features it first (after the UI thing): Parallel Downloads. My personal opinion on opening multiple connections to the same server for parallel downloads aside, the bigger improvement seems to be that you can use multiple different mirrors… except that all libapt client can do that assuming you configure it: apt-transport-mirror(1). (or the packages come from different sources to begin with). As your entire downloading and verification process is written by you rather than using libapt I would prefer a note here mentioning this. I am of course totally biased, but I have seen enough "apt-fast" variants doing this completely wrong while unsuspecting users were under the impression that its just some shiny frontend on top of the good old battle tested libapt implementations. (Again, see Disclaimer. This is not a security review. I also don't want to imply that you have security bugs. Heck, perhaps libapt has more. My point is entirely on: Please be upfront on rolling your own) > Nala is still in active development, but it is very usable. I've had > many people ask me about getting this into the Official Debian repos so > this is my request for that. > > I assume that I would be in need of a sponser considering I've never > uploaded anything into a Debian repository. But I did try my best to > make the debian files proper, and I personally use sbuild for building > the software. That is two different things. A request to get it into Debian is a Request For Packaging (RFP) – any user can ask and if the stars align perhaps someone finds it useful enough to also want it in Debian with the additional motivation to maintain the package within Debian and wants to claim the work for themselves. That is what an Intend to Package (ITP) is for. Writing debian/ once is easy enough, the hard part is maintaining it over time. I (well, Julian I guess, as I don't speak Python) will e.g. pester the maintainer for this package in transitions to adapt to our newer APIs. So will the Python teams. That might or might not align with upstream work. In the mean time you as the maintainer (if upstream hasn't) are supposed to interact with the security team. Your 'critical' bugfix in v0.6.0 e.g. is a bug worthy of a CVE and would need to be backported into older versions for stable and every other release supported by Debian (ideally with coordination with the other distros with embargos and such). If Upstreams solution to that problem was so far to "just upgrade to the newest version" at least one of you is in for some work (I know you are both, its just easier to realize that these are two different jobs if we pretend you are not). And last but not least: If you decide you want to be a maintainer, head over to debian-mentors and read about Requests For Sponsorship (RFS) which helps you getting your ITP package you prepared into Debian while you are still learning the ropes and hence do not have rights to upload unsupervised into Debian yourself yet. (As this is python, the python team might be interested in helping maintaining it if you apply to them. While I would be happy if you would try to interact with us from the apt team, I don't think we have the resources to help you with packaging through.) Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1007128: apt: [INTL:de] updated German po file translation
Hi, thanks for the update! As a German speaker myself, I have a comment through: On Fri, Mar 11, 2022 at 05:41:05PM +0100, Helge Kreutzmann wrote: > #: methods/gpgv.cc > #, c-format > msgid "" > "Key is stored in legacy trusted.gpg keyring (%s), see the DEPRECATION " > "section in apt-key(8) for details." > msgstr "" > "Schlüssel wird im veralteten Schlüsselbund trusted.gpg gespeichert (%s), " > "siehe den Abschnitt MISSBILLIGUNG in apt-key(8) für Details." Der Schlüssel IST in diesem Schlüsselbund gespeichert, apt hat ihn dort gefunden, deswegen erscheint diese Warnung. "Wird" klingt für mich hier stattdessen so wie also würde apt selbst aktiv einen Schlüssel dort speichern, statt in dort passiv 'gelagert' vorzufinden. Ist das ein simpler Fehler oder ist der String so für sich alleine missverständlich und wir sollten ein //TRANSLATOR: voranstellen der den Kontext etwas beleuchtet – und wenn ja Vorschläge? Mit freundlichen Grüßen David Kalnischkies signature.asc Description: PGP signature
Bug#1002605: `apt-get source calendar' downloads the wrong package
On Sat, Dec 25, 2021 at 05:43:44PM +0100, Johannes Schauer Marin Rodrigues wrote: > Quoting Stéphane Glondu (2021-12-25 13:36:48) > > `apt-get source calendar' downloads the bsdmainutils source package > > instead of calendar. I suspect this is because bsdmainutils is the > > source package of the calendar binary package. > > > > I think `apt-get source $FOO' should try to download $FOO if $FOO > > exists as a source package, and only after fallback to downloading the > > source package of $FOO if it exists only as a binary package. > > I agree and I cannot remember a single time when (in scripts or when running > apt manually) I wanted 'apt-get source' or 'apt-cache showsrc' to interpret > the > package name as a binary package and not a source package. Because of that I > have > > APT::Get::Only-Source "true"; > > in my system-wide apt config. I've never looked back. Mind reading of people I never meet is hard, but I assume the initial authors of apt wanted to avoid teaching users about source packages (and by extension also apt itself, which is still very ignorant of them even if it learned a bit about them in recent years). The idea probably was that you 'apt-get install foo' and something makes you want to check out the source code of it, because why not, right? So you do 'apt-get source foo'. In this interaction it would be surprising that I am not getting the source of the package I have installed, but somehow the source of something else?! I still remember being confused many years ago after running for the first time into the binary automake built by automake-X and automake-Y built by source automake… at least, that seems resolved nowadays. Anyway, I don't see us reversing the default search order and not dropping binary lookup altogether (what the option does) either. (or outlawing these collisions as evil – somehow I get the feeling that is what initial authors intended but failed as with many other small things). Especially source could use some love though to properly display the VCS info and in that process perhaps even display/ask about collisions. That is some longstanding wishlist though, so holding your breath might not be advisable. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1001895: Please ship also iso_week.h and co in libhowardhinnant-date-dev
Hi, On Wed, Dec 22, 2021 at 11:26:58PM +0100, Andrea Pappacoda wrote: > Those extra headers should definitely get included in the package, I > did not notice that the CMake script installs only [1] date.h :/ (Perhaps a bit overkill here, but if it is reasonably easy to do, try to build a test program as an autopkgtest. Perhaps even the testsuite. As a bonus you get faster transitions to testing.) > I'll patch this in the next revision! It will probably come after the > holidays though, as I'll busy studying / fixing my mail server / > partying. No problem – as somewhat evident by my own reply delay: A late happy festive days & an upcoming happy new year! (if applicable) I work on/use that program once in a year and that was before I reported this here, so it isn't super urgent to begin with (it is generating an ods file for a friend who records daily business statistics in it [which are then summed up by week and month] – not rocket science, but wiring 12 months by hand in Libreoffice is just too error prune/tedious). > Regarding the r-cran-tzdb package, you see my (short) discussion with > its maintainer in #998331 [2] Ah, okay. Thanks for discussing it already! (I tend to be in the "no-embeds" camp, but I see how people can disagree on that and this embed in particular isn't so bad to really object) > As for sponsoring, it would of course be nice, but in the meantime I'd > like you to ask a quick question about this package: do you think that > packaging it under libhowardhinnant-date-dev was a good idea? Because > I patched the project to install CMake config files with the > "howardhinnant-date" name instead of just "date", but its headers > still get installed to paths like "date/date.h". My reasoning for this > was to not pollute the global namespace with such a general name, but > I also wanted to not break projects correctly including date/date.h. Yeah, I think it is fine as is. "date" really would have been a bit short as a package name beside that nobody would know what the package contains as there are a gazillion things named 'date' (including the command itself…). Making a package name shorter/more generic is an easy rename usually, so if it turns out that the world expects it to have another name that is easy to do. Removing a name conflict on the other hand tends to be a huge pain for maintainers and users alike: Prior "art": node (JS and amateur radio), chromium (browser and game), firebird (browser and database – upstream renamed to firefox quickly), … So, if that can be avoided, that is a service to everyone. It is still a very generic term even in /usr/include, but I assume that at this point nobody in the C/C++ community will try to claim it and having the same name as upstream here has clear benefits while renaming would probably mean additional work/patches for every user. So that is a bridge you better think about crossing only if there is a need. ☺ Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1001895: Please ship also iso_week.h and co in libhowardhinnant-date-dev
Package: libhowardhinnant-date-dev Version: 3.0.1-2 Severity: wishlist Hi, Thanks for packaging howardhinnant-date! (and a big honor to be the first to report a bug against this package ☺) I have a local program I would like to compile against the headers shipped in Debian rather than taking care of updating it myself once in a while, but my code is using the `iso_week.h` header of this project as well, which sadly is not included in this package so far. Same for the other header-only "add ons" mentioned in the README for the date library, so it would be nice if they could be included. Not just for me, but perhaps also for packaged stuff: I don't know if e.g. `r-cran-tzdb` does use these add ons¹, but it seems to ship an embedded copy of the entire set of headers, so I presume before this copy could be removed the others would need to be included here. (Sidenote: If you need a sponsor for the upload, I might be able to help) Best regards David Kalnischkies ¹ I just used `apt-file` to look if they are perhaps in another package, I don't know the package nor the embed reason and this bug is not about working on removing this copy and/or pointing fingers per se. signature.asc Description: PGP signature
Bug#852757: apt calls malloc inside SIGWINCH handler, leading to deadlock
Hi, On Thu, Nov 25, 2021 at 07:30:45PM +0800, Zhang Boyang wrote: > It seems my last email was marked spam. It's strange that the bug tracker > has received my reply but the mailing list didn't. Please correct me if I > misunderstand the situation. Indeed, looks like your mail was dropped at some point. If you supply sufficient details listmasters might be able to tell you what exactly went wrong. (The BTS seems to assign your mails ~ -10 points which is very good, but at the same time the list mail which passed through got 0, which is not bad, but also not particular good citing e.g. "MIME_BASE64_TEXT_BOGUS(1) R_DKIM_REJECT(1)". With patches you might be better of in salsa btw.) > The patch is attached again for convenience. This patch implemented Anders's > idea. The signal handler will only set a flag. After signal handler > completed, the pselect() in pkgDPkgPM::Go() will return immediately with > errno set to EINTR. Then, progress->Pluse() is called by pkgDPkgPM::Go(), > and PackageManagerFancy::Pluse() will redraw the status bar. Not having looked at the issue itself I just gave the patch a casual glance: PackageManagerFancy is a public – hence exported – interface, so you can't change member variables or add virtual methods as that breaks the ABI. At some point we will have one I am sure, but if at all possible it could be better to investigate if that can be solved some other way. (Not exactly sure why that is public at all, given there seems to also be a factory function to be able to hide it?) Can we perhaps make it (still) easier to reproduce? apt can be told to use a different dpkg via Dir::Bin::dpkg – can we have that be a script which just spits out 'offending' lines (= is it the fd messages or the messages on stdout for example – or both) ? (Sorry for not being very specific at the moment as I am a bit starved for Debian time; will try to give that some proper thought/review ~next week) Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#999678: apt: Please list "apt search" results in decreasing order of binary package popularity
On Sun, Nov 14, 2021 at 10:02:28PM +0100, Bálint Réczey wrote: > I believe when looking for a package to install the more popular ones > have higher probability to be the right fit. Currently 'apt search' I don't think this is true. While w3m is on a downward trend for years it still easily outperforms every other browser in Debian (except firefox-esr of course): https://qa.debian.org/popcon-graph.php?packages=firefox%2Cfirefox-esr%2Ciceweasel%2Cchromium%2Cw3m%2Clynx%2Cmidori%2Ctorbrowser%2Clinks%2Clinks2%2Cluakit%2Cnetrik%2Ckonqueror%2Cdillo%2Celinks%2Cepiphany-browser_installed=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1 In the RFP bug you mentioned vim vs. emacs … you can actually argue with popcon that vim is far more popular – except for gtk people it seems: https://qa.debian.org/popcon-graph.php?packages=vim-gtk%2Cvim-gtk3%2Cemacs-gtk%2Cvim%2Cvim-nox%2Cemacs_installed=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1 And with that I come to another point: Desktop environment. For many users it is far more important to stick to an application which fits into their environment (be it due to aesthetics ala theme and such or usage/config paradigm) than how many people have installed apps from a 'competing' environment. Especially if that high number comes mostly from it being the default install. Being the default hopefully is the "best" choice, but it tends to be just the "most average for everyone" as the better choices are only for certain cases actually better. It isn't really working with "what is the best library to do X" either as due to the nature of how popcon works an old clunky library which never changes API/ABI performs way better than even the most hip and trendy alternative who fixed a trillion security bugs with API breaks. Beside that the sample is usually so small that the results could equally well be rolled by dice. So personally, I would consider this to give popcon far too much influence. It tends not to be the best metric for archive removals either. > results are sorted in alphabetical order, but a decreasing popularity > order would be more helpful, maybe even showing the percentage of > systems each binary package is installed on. It could certainly be a data point in a frontend specialist at browsing/ searching, but apt is not that frontend. It seems e.g. better to look at this from the "applications" level (aka Components) rather than from the "packages" level as a search for web browser on the packages level will always give you "bogus" results of the form "language pack for web browser foo" and stuff. Beside, firefox-esr is installed on less than 50% of the popcon participants (compared to dpkg) and that is the highest performer I mentioned. Not sure what 2.1% has vim-gtk, 2.2% vim-gtk3 installed is going to tell me usefully. And those are still rather popular packages compared to lets say the most popular strategy game (without looking, I would guess its wesnoth – but which version…). > At the moment the popularity data is not available, but I've filed > #999677 to solve that. If you agree with the proposal please share > your thoughts on the preferred database format in the RFP bug. Any data related to packages should be included in the repositories itself, popcon not really being an exception if you want to make use of that data even if many third-parties do not have comparable services. apt can be told to download additional data easily, apt-file and appstream e.g. do this. Might be best to show an existing prototype who picks the data off from a third-party repo to motivate debian archive judges^W^W^W ftpmasters to accept your dak patch (in the best case). Data format is traditionally deb822, json might be a contender, but given you will be high up the stack it doesn't really matter which parser you end up depending on. So, I think I would close this report as not going to happen (at least in apt itself), but perhaps others have a different opinion – we could then have a popularity contest to rank … (sorry, could not resist). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#998828: apt: man apt_preferences.d wrong definition of priorities
Hi, On Mon, Nov 08, 2021 at 12:17:51PM +0100, maxime.dero...@gmail.com wrote: > Records defined > using patterns in the Pin field other than "*" are treated like > specific-form records. [… vs …] > Records defined > using exactly "Package: *" are general-form, all the other are > specific-form records. Aren't that two different ways of saying the same thing? Could you give an example where the existing definition of priorities is wrong while yours is correct as per bug title? Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#675748: Where is the show command?
Hi, On Fri, Oct 22, 2021 at 02:12:52PM -0400, Kyle Lyon wrote: > I am working on it at home. Wondering how I can submit it once I have You have multiple options ranging from "just" attaching a patch here in the BTS to making a merge request on Salsa: https://salsa.debian.org/apt-team/apt (Make a fork, do your thing, commit to a branch and push that branch to your fork – the push will have an URI you can use to open a merge request). > Where is the show command located? The dumpavail function is inside of > apt-main/cmdline/aptcache.cc, so where is the show command? The dumpavail lives in /path/to/apt/cmdline/apt-cache.cc as it is available only in apt-cache. apt & apt-cache share the code for the show command (among other things), so it is in our private library in the file /path/to/apt/apt-private/private-show.cc. I am not quite sure what the semantics of dumpavail should be through. The bug asks for a restoration of a behaviour from a decade ago – so chances are for better or worse that others expect it to behave the way it does now considering the old-soon-to-be-new behaviour a bug. Who are the users of the command anyway? The bugreport has only a dselect user who likes to grep in the available file. Has the former even any users left now that it isn't really developed anymore for years and lacks support for multi-arch and co? The later at least should be equally or better served by using intended interfaces like 'apt search'. Deprecating and dropping dumpavail might be a bit too heretic, but I think before this is (intentionally) changed one way or the other someone (aka not me) should look into who are the (remaining) users and what they are expecting… the produced output reaches epic proportions already (on my system: 162 MB) and that won't be less if we add more… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#995256: aptitude: TUI loops "Can't find a source to download ..." error
On Tue, Sep 28, 2021 at 06:38:05PM +0200, Axel Beckert wrote: > > I have no idea why this happens, but originally thought it might be related > > to > > not having run 'update' as a first step. > > I'd rather imagine something the other way round: > > I wonder if there is a kind of race condition if aptitude is running > and then either on the admin on the commandline or a background job > runs "apt update". That can indeed mess up some things as the cache (which is then old) still points to file locations in the "old" files rather than what an update might have placed in there in the meantime. For a long-running process like aptitude it might actually make sense to grab the lists/lock to prevent an update process interfering – but that can technically happen to any libapt client, just that the window for e.g. apt-cache is far smaller. I don't know if that is really the root cause here through as such issues usually run into other errors (if not crashes in unsuspecting clients). Such a problem could be "easily" reproduced by starting aptitude & then modifying a Packages file in such a way that the stanza about the package you want to click on next in the interface is (re)moved. One of these days I have to try if we can make libapt hold onto the file descriptors while the cache is open, but that has all sorts of practical problems (like having hundreds of open file descriptors potentially exhausting limits, lifetime and stuff). > Thanks! There's an interesting fact visible. First let's look at that > package: > > ~ → apt-cache show texlive-fonts-recommended > Package: texlive-fonts-recommended > Version: 2021.20210921-1 > Architecture: all > > So this package in question is arch:all. > > But according to the screenshot, aptitude wants > texlive-fonts-recommended:amd64 for whatever reason — which indeed > does not exist. This is a misunderstanding. An arch:all deb file is always attributed to be of the native architecture, in your case amd64. That is because libapt makes a difference between a package(name with architecture) and a version (of a package with version number & architecture). Imagine a 'package' changing from arch:all to arch:any (or vice versa). Even through these versions have different architectures they will all be versions of the foo:amd64 package. Otherwise those transitions would require explicit user intervention (or a lot of code in package managers) as architectures would change, pins not apply anymore and all sorts of shenanigans. > I tried to fix this in zsh like this: > https://salsa.debian.org/debian/zsh/-/commit/801f5e105ad6d1f767d28c8311edd263790f419f 'all' is an invalid architecture, so while some parsers might accept it and do something roughly sensible, some others might explode and that is perfectly fine. Don't do this. Lintian might warn about this in the future. Note that the package might be 'all', but isn't M-A:foreign, so as above the package only satisfies dependencies on the native architecture. In the cross build this all package has the 'wrong' architecture, that is why it is purely virtual. Probably it was a mistake by the resolver to go down this path due to temporary unavailability of a better choice (aka the native architecture of an earlier M-A:foreign package). Currently not an avoidable mistake as the markup says its okay while it really isn't for crossbuilders… that is unrelated to this bug through (if by some miracle you are interested, look for "very foreign" aka "barbarian" architectures. libapt will allow experimenting with this concept soon, but at this stage (and hopefully forever) clients like apt and aptitude can be mostly ignorant about these topics). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#995115: /usr/bin/ruby: symbol lookup error: /lib/x86_64-linux-gnu/libruby-2.7.so.2.7: undefined symbol: rb_st_numhash
Control: reassign -1 apt-listbugs 0.1.35 On Sun, Sep 26, 2021 at 03:27:19PM +0200, xiscu wrote: > Justification: renders package unusable Which package is unusable? > [...] > 274 upgraded, 6 newly installed, 0 to remove and 0 not upgraded. > Need to get 0 B/745 MB of archives. > After this operation, 313 MB of additional disk space will be used. > Do you want to continue? [Y/n] > /usr/bin/ruby: symbol lookup error: /lib/x86_64-linux-gnu/libruby-2.7.so.2.7: > undefined symbol: rb_st_numhash > E: Sub-process /usr/bin/apt-listbugs apt returned an error code (127) > E: Failure running script /usr/bin/apt-listbugs apt The script exits unsuccessfully and as such the action is stopped. apt hence works as intended, it is "just" not intended that the scripts called do crash in such ways, but that is the bug of those scripts or their interpreters not of apt itself. > trying to deinstall apt-listbugs results on the same problem. > trying to upagrade apt (listbugs) first, results in: > > bin# apt-get install -t sid apt If you want to upgrade apt-listbugs first you will have to use that package name, not apt, apt doesn't contain apt-listbugs. That said, there is no new version of apt-listbugs at the moment, so there is nothing to upgrade to. Seems like a ruby upgrade broke it, but I don't know if it is intended breakage (= to be fixed in apt-listbugs) or unintended (= somewhere in ruby) or something in between. That is for someone to investigate who has an idea about ruby, hence reassigning down the chain. You may want to add which versions of ruby packages and apt-listbugs are involved. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#994504: Don't just say "not a real package"
On Thu, Sep 16, 2021 at 10:20:45PM +0200, Axel Beckert wrote: > Do you know of any other non-real package type than "virtual"? (Challenge accepted!) The message from apt is hardcoded, so same for all virtuals, but from a theory point of view apt "knows" about four different types: - pure virtual (= multiple providers) - single virtual (= only one provider) - mixed virtual (= a real package with that name also exists) - missing (= the name only appears in dependencies) (and of course the "normal" only-real packages) You can see that being used in 'apt-cache stats' output. The practical difference is mostly marginal and not really something we concern users with all too much. Error messages are e.g. different if the unsatisfiable dependency is a "missing" package. Trying to install a mixed package will install the real package. While a pure virtual will display an error listing the available options. A single virtual package on the other hand will be automatically picked with a notice and installed. I haven't checked, but I presume aptitude behaves similar as that is more or less a direct consequence of how libapt itself works or something people actively complain about if it isn't working that way. APTs source code has a FIXME in that place reminding us that we should display here the possible providers (like we do for install as mentioned). It isn't implemented yet through. On the other hand I highly doubt we will expose the type of virtual in any real capacity to the user. I would imagine 'missing' would just say that there is no provider, while pure & single would display a list – mixed already shows the info of the real package. I presume the grant idea behind mentioning "virtual" here in apt is that the user has another term available which might be easier to look up as not everyone will know what a "not real" package even is – they all do not exist in the physical space and are hence by definition all not real/virtual?! If that is true or not is anyone's guess. I do not consider it bloat on the apt side, but I also can't really consider it missing for aptitude… we might agree on the fact that the list of providers is missing here through. ☺ Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 03, 2021 at 02:42:29AM +, Paul Wise wrote: > httpredir.d.o was an alternative CDN-like thing that was based on HTTP > redirects to the mirror network. It had lots of problems, but now that > we have a mirror checker and zzz-dists, perhaps it could work better. > The mirror:// method in apt has probably improved since then too. If you wanted to bring back a httpredir-like¹ you are better of to combine both approaches as in: Have apt request a list of mirrors to use via mirror(+https) and have the server generate that list based on the requester as that gives you the "regional" mirrors as did httpredir while solving the major grip it had by having a list of mirrors to use, rather than one potentially non-working slightly outdated partial mirror (and the httpredir service is contacted by each client once rather than for each individual file to then be redirected elsewhere). Obviously, that approach is only workable if you are actually using libapt tools. Most debootstrap implementations couldn't really use that which might or might not be a problem for a given use case. Such a service would also have a hard time to 'redirect' you to a local mirror in your network (compared to an 'official' region one). So that isn't really what seems to be the main worry here: https prevents MitM attacks including the friendly MitM ones like the local network at home/at DebConf telling my laptop that there is an on-site mirror or not telling at all and just proxy transparently the entire network. The later seems done for in a https-world, but the former might be somewhat salvageable: We will have to get the Release² file(s) from the repo defined in the sources, but the index files and debs after that are a fairer game to get from elsewhere as they are either identical with what the defined source would have provided or a hard error. That still violates the privacy guarantees https has (assuming it does), so that would still need to be opt-in/out, but that is a one time choice per machine and could be similar in style to auto-apt-proxy. Anyway, implementation wise apt could tell $MAGIC which repo it is interested in (by Origin & Label) and would in return get a list of mirrors as apt-transport-mirror would. apt would then add the original source as least priority fallback and proceed with that list for this source. I say $MAGIC as I don't want apt to hard code the specifics of how to get the list, similar to how it is agnostic to how a proxy is currently picked up, as I could envision different implementations depending on use cases. That is different to just using apt-transport-mirror directly in the sources in so far as the provider of the list remains untrusted (beside that nobody is constantly editing their sources to adapt to the local network the machine currently resides in). Relatively quickly thought up, probably full of holes and not implemented at all in apt so far, but if someone thinks that might work feel free to report as a feature request against apt and I will see what I can do from the apt side. It at least seems slightly more workable than hoping to prevent https – which might have just as dubious a chance to succeed as https has to factually improve security in terms of apt. > Maybe http redirects to local mirrors could be feasible again, but it > would take a lot of work. fwiw: apt does not allow https to http redirects (some https repos ran into this in the past like those hosted on sourceforge until they fixed their https 'everywhere' configuration). In this regard apt is stricter than a normal webbrowser (a mirror list acquired via https can redirect to http mirrors though, but see the man pages for details). Best regards David Kalnischkies ¹ which deb.d.o sort of is just that it is nowadays done via SRV instead of an explicit HTTP redirect – and that only one mirror is in the list rather than multiple httpredir had picked one to redirect to. ² The main security benefit of https for apt is that you can't fiddle with the Release file, mostly in terms of sending an older one (in the limits of Valid-Until if used). It is also minor in size compared to the indexes and especially the debs, so caching them is not much of a concern (if a cacher was even doing it, it probably shouldn't). signature.asc Description: PGP signature
Bug#969631: can base-passwd provide the user _apt?
On Mon, Aug 30, 2021 at 11:53:59AM +0100, Colin Watson wrote: > On Mon, Aug 30, 2021 at 12:30:49PM +0200, David Kalnischkies wrote: > > So, while for some/most usecases something akin to DynamicUser would be > > enough, for others a more stable user would be preferred and then there > > are also cases were it would be beneficial if the user had the same > > UID across all systems. > > And that's exactly the bit that seems tricky to achieve here. If we > only had deal with the bits that are internal to apt (as opposed to set > up manually by sysadmins) then it wouldn't be so bad. Personally, I don't think it is too bad as there shouldn't be too many actually effected and those who are we could try to catch. We could e.g. do static for new installs in bookworm and recommend transition in NEWS (and co), have apt warn if it deals with files owned by _apt while not being UID 42 and have trixie actually perform the transition for upgrades, to then have new and upgrades being the same. apt already tries for copy:/ and file:/ if _apt can access them and if not falls back to not using it (with a warning). We don't warn on unreadable https certificates explicitly currently, but it wouldn't be a bad idea to be a bit more friendly anyhow (well, ideally we wouldn't need to, like we managed for auth.conf, but I am not sure we can massage gnutls enough for that). > > > But I guess there's no way to do something like that > > > outside of systemd, much less on systems that don't run systemd at all. > > > > The problem with systemd in this context is that apt kinda needs to be > > its own systemd --user instance as apt is not a system service, but > > a service manager of its own. I doubt the systemd ecosystem offers that > > functionality, especially considering that these parts would need to be > > platform agnostic and reasonably light given they would be involved in > > (cross)bootstrap and all the other situations apt operates in. > > To be clear, I wasn't literally proposing that apt should use systemd; I > don't think that would make sense. It was just an analogy. To be clear, I said that only to preempt the peanut gallery. ☺ Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#993287: "apt-get install" doesn't preserve autoinstall status of upgraded packages
On Mon, Aug 30, 2021 at 11:27:47AM +0300, Esa Peuha wrote: > what has happened until recently. However, since apt 2.3.3 foo will be > marked as manually installed, which seems to be an unintended change. What makes you believe apt before 2.3.3 behaved differently? I tried with 2.3.2 and 1.3 (= the first release with CMake buildsystem) and both exhibit the behaviour you describe as an unintended change… (attached is a testcase akin to what Julian described were in both blocks the second apt-mark showmanual call fails as foo is now manual) I did not implement this behaviour and it is always a bit surprising, but I assume the idea was that if you cared enough about a package to explicitly request it to be installed/upgraded you would be unhappy if apt would later on decide that it can be autoremoved. A case can also be made for that it is strange if an upgrade or not is performed should have an effect on keeping auto or not. Imagine a user who reads about 'foo' wants to use it and installs it only to find out that it was already installed as a dependency of some other thing. If that user had a fully upgraded system 'foo' would now be marked manual, but if they had not, 'foo' would now potentially still be auto in your scheme… that could be very surprising. Best regards David Kalnischkies #!/bin/sh set -e TESTDIR="$(readlink -f "$(dirname "$0")")" . "$TESTDIR/framework" setupenvironment configarchitecture 'amd64' buildsimplenativepackage 'foo' 'all' '2' 'unstable' setupaptarchive insertinstalledpackage 'foo' 'all' '1' msgmsg 'foo is upgraded from 1 to 2' testsuccess aptmark auto foo testempty aptmark showmanual foo testsuccessequal 'Reading package lists... Building dependency tree... Reading state information... The following packages will be upgraded: foo 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Inst foo [1] (2 unstable [all]) Conf foo (2 unstable [all])' apt install foo -s testsuccess apt install foo testempty aptmark showmanual foo msgmsg 'foo is unchanged' testsuccess aptmark auto foo testempty aptmark showmanual foo testsuccessequal 'Reading package lists... Building dependency tree... Reading state information... foo is already the newest version (2). foo set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.' apt install foo -s testsuccess apt install foo testempty aptmark showmanual foo signature.asc Description: PGP signature
Bug#969631: can base-passwd provide the user _apt?
On Sun, Aug 29, 2021 at 11:30:41PM +0100, Colin Watson wrote: > case) it seems mostly like the sort of user that could be anonymous > outside of the lifetime of an apt process, analogous to systemd's > DynamicUser. The _apt user started as 'nobody', but quickly people complained that they didn't want to punch holes in their firewalls for nobody. As Julian notes most cases in which _apt creates/owns files are things to fix eventually, some of which were indeed already, but that is gonna be hard work and probably not achievable in the short term. Especially if other lower hanging fruits are still in reach. We are labouring on _apt for more than seven years now after all. So, while for some/most usecases something akin to DynamicUser would be enough, for others a more stable user would be preferred and then there are also cases were it would be beneficial if the user had the same UID across all systems. > But I guess there's no way to do something like that > outside of systemd, much less on systems that don't run systemd at all. The problem with systemd in this context is that apt kinda needs to be its own systemd --user instance as apt is not a system service, but a service manager of its own. I doubt the systemd ecosystem offers that functionality, especially considering that these parts would need to be platform agnostic and reasonably light given they would be involved in (cross)bootstrap and all the other situations apt operates in. I would be happy to be wrong through as it isn't exactly my dream to make apt a decent service manager even through apt starts a lot of processes, so a lot of management could and should be done here… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#992712: apt-secure does not document how to accept new release info
Control: forcemerge 879786 -1
On Sun, Aug 22, 2021 at 12:05:07PM -0400, Joey Hess wrote:
> This could be fixed by making the apt-secure man page include,
> in its "INFORMATION CHANGES" section, a mention of
> apt-get update --allow-releaseinfo-change and/or of apt's ability to
> prompt the user in this situation.
The problem here is that apt-secure is – as it says early on – not about
apt{,-get}, but about the whole family. The message pointing to it is
equally printed for the whole family. Neither the message nor the
manpage can really say: Append this commandline flag and be done.
No such thing exists for e.g. GUIs like synaptics after all and it isn't
even yet implemented in aptitude.
And we can't really track the state of implementation in front ends
either to update each of their supposed sections with how to check some
checkboxes vs. click some buttons vs. type 'j' on the prompt vs. add
a commandline flag vs. … its sort of the job of the front ends to do
that and the apt-get manpage describes how.
We can't even really mention the config options here like in some other
cases as in this instance they can be completely overridden by the front
end. Only the default implementation actually reacts to the defaults.
Lastly, I actually envisioned that such changes would be accompanied
with release notes – the code is there to show an URI for more
information on the change, which could theoretically also describe how
to react to all this with the preferred package manager of the involved
distro/repo/whatever – but oh well, nobody ever wrote them or has set
the Release file flag for it…
I guess we could fiddle with the implementation (aka dirty hack) in the
apt and especially apt-get front end to show an apt specific message
about how you can add a command line flag. It feels like admitting
defeat, but I guess I will have to bite this bullet at some point
(again).
Note through that the N: message pointing to the manpage and any message
we could add are only shown if apt-get is connected to a terminal – aka
in interactive use. In that case you could just save at least four
keystrokes and have apt ask you interactively. ;)
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Bug#992761: apt : needs a "rollback" feature
On Mon, Aug 23, 2021 at 08:52:50AM +0200, Erwan David wrote: > After upgrading to a new version of KDE with a small bug, I would have loked > to > return back to previous version. Howeever the upgrade was ~ 400 pacakges and > that makes it complicated, getting all packages in the logs. So I thought of > the 1 feature I miss from yum in apt : the possibility, after an upgrade to > rollback to the previous versions of package list That would be a good feature > for apt Your given example is precisely the case in which a rollback will (generally) not work. Nowhere, not even in yum. First of all: Downgrades (aka going back to an older version) are not supported in Debian. Full stop. It kinda works most of the time and the lower in the stack the package is, the more likely it is actually that it will work. yum is optimistic in this regard, apt isn't. Graphical applications are far removed from "low in the stack" through. Most, if not all will create & edit files in your home directory which might be completely incompatible with previous versions. darktable reminds me of this every other big version bump actually on the first start of the new version as it will proceed to change the database then. Many others also warn while most don't and just explode if you would ever try (some games don't even have forward compat for their savegames, I highly doubt they have backward compat…). So a simple rollback of that one package wont work. What exactly do you expect to happen if ~400 packages are involved? We might get something like that some day. We introduced the history.log sort of with this in mind, but haven't added much tooling to work with it yet. But it will never work like you imagine here, as it simply can't. It might work, if you are lucky, but if not, you have likely two problems instead of one. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#992993: libapt-pkg6.0: infinite recursion in pkgDepCache::MarkPackage
On Wed, Aug 25, 2021 at 09:30:13PM -0400, Aaron M. Ucko wrote: > As of apt 2.3.8, most uses of libapt-pkg segfault; I can't even use Please at least mention an example apt call. Is e.g. apt full-upgrade -s crashing? If so (or if you find another invocation you can run in simulation or if e.g. 'apt show' or 'policy' expose the crash) see if adding -o Dir::state::status=/dev/nulland/or -o Dir::State::extended_states=/dev/null have any effect. (Don't append these on commands you run as root!) We will likely need /var/lib/dpkg/status and /var/lib/apt/extended_states from the effected system. You can sent them to me privately if you don't want to attach them (compressed) publicly to the bugreport. They contain the information which packages you have installed and which of those are marked as automatically installed – so they can be both large and considered private information. > reportbug to submit this report! The culprit appears to be infinite > recursion in pkgDepCache::MarkPackage: As an aside, the method is written as a giant recursive loop, so while "infinite" is not desired, the recursion certainly is and as such the information provided is not very enlightening. > at ../apt-pkg/depcache.cc:2406 Points at my changes in 2.3.3, especially "Mark only provides from protected versioned kernel packages", as the most likely culprit. Probably something obvious in hindsight, but at the moment I don't see it yet. Works for me (of course) and is the first report about an issue here… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#992309: apt: term.log aborts when packages have failures but installation is retried
On Tue, Aug 17, 2021 at 03:13:20AM +0200, Christoph Anton Mitterer wrote: > I've seen the following already few times, but always used apt via aptitude, > so maybe the problem is actually within that. > > What happens is the following: > - I upgrade/install/remove a number of packages. > - Amongt one/several of them there is an error during installation and one > gets a line like: > Errors were encountered while processing: > packagename1 > packagename2 > ... > - At the point, /var/log/apt/term.log ends with the ususal: > Log ended: > > - However, aptitude seems to retry once... A quick look at the code (src/generic/apt/download_install_manager.cc) suggests aptitude runs 'dpkg --configure -a' explicitly if libapt reports encountering a failure and as such completely runs outside the control of libapt and its logging (among many other things). A quick git blame isn't very conclusive on why that is done, just that it seems to be done for at least 10 years. I am not sure if its a good idea to run that always unconditionally, but then it is likely what a user runs unconditionally manually anyway, and not much different to what happens if you run things like 'apt install --fix-broken', as you either luck out or not so… So perhaps we should indeed offer a way to do this a bit more automatic for the user. I would first like to hear if the current aptitude devs have any idea why that is run and their opinion on it though. (This could be a reassign, but all they could do is removing the line in question or reassign it back to us as a feature wish, so lets skip the ping pong for now while thinking about this a bit longer) Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#916112: apt-get purge filename.deb not working like expected
Hi,
On Fri, Jul 23, 2021 at 09:44:43PM -0500, ng wrote:
> Today I ran 'sudo apt purge ./anything.deb' on a package that WAS NOT
> installed in my system. And apt's response was to install that package, as
> if I were running 'apt install'. Except that it was 'apt purge'.
> Funny.
Try: "apt remove awesome+". This will install 'awesome' for you. Just
like a "apt install awesome-" will then remove it again.
The commands "remove/install/purge/…" only provide a default mode
of operation for packages which do not have an explicit action
associated.
Now, for ./anything.deb you can consider two schools of thought:
1. "./anything.deb" clearly means I want to install that package as why
I am going to the trouble of giving an explicit deb file, if I could
just use the name and remove it that way. So this clearly is an explicit
install action regardless of the default mode. ("apt show ./anything.deb"
shows me the info about that version, too, not some candidate as usual).
2. "./anything.deb" is a substitute for the name only, I am using it in
a remove because I just installed it and shell history gives me quick
access to removing it this way. I am expecting it to respect the default
mode (and to be able to explicitly choose a mode ala "./anything.deb+";
and would a "apt purge ./anything_v1.deb" remove an installed anything
v2?).
For better or worse the implementation currently follows the first
school, which can indeed be surprising if you (by not considering what
I just mentioned with default vs. explicit action) think the second is
what is going on as that is how most other software behaves.
I do have some sympathy for both schools, so I am not really sure what
to do about this report here to be honest.
I do lean slightly towards notabug + wontfix though as (even though
highly unlikely in practice) a change of schools would be an interface
break – and it has these weird follow up questions of potentially
allowing ./anything.deb{-,+,=…} as well which makes this not so simple…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Bug#990922: apt resolves differently than apt-get: mariadb-server dist-upgrade Buster to Bullseye fails
graded. -39 upgraded, 38 newly installed, 5 to remove and 0 not upgraded. +123 upgraded, 31 newly installed, 0 to remove and 2 not upgraded. +1 upgraded, 0 newly installed, 5 to remove and 0 not upgraded. So, based on the numbers alone (and what else really matters to a machine) the second set of commands is clearly superior as they manage to upgrade the same amount of packages with less new bugs^Wpackages to install. Optimisation criteria based resolvers like aspcud will be so proud of libapts heuristic one for doing the right thing here… Your problem is that mariadb stuff is not an upgrade and it also can't be co-installed with what is already installed, so a user/resolver can pick any possible solution – not just the one solution you would prefer in which galera-4 is installed. The second set of commands instead decides to keep galera-3 and upgrade it. That makes a few other choices unavailable (like installing mariadb-5.10), but that is not important as on this specific system nothing of note depends on them anyhow (= remember: minimal chroot). That can be drastically different on other user systems and that is why it was always a bad idea to construct upgrade paths in which packages must be removed as the choice to not do it can end up being viewed as the better pick depending on what else is (not) installed on the given system. > > I have said before that the mariadb packaging style is choosing the worst > > of both worlds by being versioned and mutually exclusive which makes it > > likely to run into situations in which a(ny) resolver will pick > > Yes I agree that it is cumbersome, but this is how the mysql packaging > in Debian has been for 10+ years, and MariaDB needs to be compatible > with that, otherwise things get too complex for our users. Also, > convincing MySQL packagers and MariaDB upstream to adopt versionless > package names is hard, as everything has worked fine for the past 10 > years and it would be a rather big change in the packaging, and people > need a clear reason why to do the effort of coordinating such a > packaging scheme change with compatible packages and millions (?) of > users without causing more problem than what it solves. You know, fossil fuel worked for years and has millions of users, too. The "problem" always existed, you just didn't thought ice melting and burning fossils would be connected, so to speak. Note that I am not saying you should "adopt versionless package names". You already have (e.g. mariadb-server). You also have versioned. And you have it so that different versioned ones can not be co-installed which is offering a choice – a choice you don't want but none the less offer. If that problem is worse than your other problems, I don't know. I naively believe it could be resolved with alternatives and so on, but I don't know the situation nor do I want it to know enough to provide a solution to you on a silver plater. All I can do is spot obvious flaws from my point of view of dependency (and upgrade) problem resolution as if I look to close I could equally well become the maintainer of all of the ~60k source packages in Debian. That isn't going to work. All I am really saying is that there is no bug in apt here: Upgrade problems are by definition problems of the packages involved as even if they were a bug in apt, we could not change apt in stable to fix it. But again, the presented problem here is not a bug in apt, both choices are equally valid as far as dependencies are concerned and that is all the resolvers care about. It might be surprising that two different paths lead to different results, but given the individual constrains that is, if not expected, at least understandable in hindsight. Best regards David Kalnischkies signature.asc Description: PGP signature
