Bug#1077074: apt invalid signature
Am Thu, Jul 25, 2024 at 09:24:58PM GMT, schrieb mh: > Err:3 http://dellopti:3142/deb.debian.org/debian unstable InRelease > At least one invalid signature was encountered. Are you using apt-cacher-ng (or an other proxy) perhaps? I don't use it myself, but I see somewhat frequent complains about it shipping broken InRelease files and not recovering from it. Other people are quick to reply that they never had that problem ever and I never got to see the broken files so far… but what Julian said. > -- apt-config dump -- […] > Dir::Etc:3 [end of mail] Have you accidentally truncated the output/mail? Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1076678: apt: as of the recent apt redo, progress bars on screen-on-urxvt in en_US.UTF-8 uses wrong characters
Am Sun, Jul 21, 2024 at 11:02:18PM GMT, schrieb cl...@jhcloos.com: > it may occurr under any UTF-8 locale, but I only ever use en_US.UTF-8 > and more recently C.UTF-8, but I’ve not switched everything over yet. You failed to mention what these "wrong characters" are… perhaps with a copy or a screenshot. If APT runs with an UTF-8 codeset it now uses utf8 block characters, if it isn't it falls back to the "old" style of using #. The code is here: https://salsa.debian.org/apt-team/apt/-/blob/main/apt-pkg/install-progress.cc?ref_type=heads#L346-367 The block characters are btw: ▏ ▎ ▍ ▌ ▋ ▊ ▉ █ as in: those chars including & following "U+2588 FULL BLOCK" So, honestly, I don't see much opportunity for apt to be wrong here and would guess its either your transit layers messing up or your chosen font not supporting these characters; but I am happy to be proven wrong given utf8 isn't my expertise. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1075975: apt: [INTL:pl] Polish translation for apt (program)
Am Mon, Jul 08, 2024 at 09:13:05PM GMT, schrieb Michał Kułach: > We discussed[1] it briefly on the debian-l10n-polish list & I'm the last > translator (which is rather shameful, as it's the first update in 12 > years…). Thanks for maintaining apt/pl.po for 12 consecutive years now! It happens to be that I was the committer back than, too. Lets hope we all make it another 12 years for a repeat of that achievement – optionally with a slightly higher update rate in between. I note that there is a FIXME (not from us) left in the file: | # FIXME: Skoordynować tłumaczenie DEPRECATION z apt-key(8) | #: 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 "" | "Klucz jest przechowywany w przestarzałym zbiorze kluczy trusted.gpg (%s), " | "więcej informacji w rozdziale DEPRECATION w podręczniku apt-key(8)." (I don't speak polish, so I have no idea what that might mean.) I am happy to commit as-is if this needs more work/time, is a simple reminder/note or whatever, but I wanted to ask first. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1075819: apt list --upgradable does not reflect snapshot state
Am Fri, Jul 05, 2024 at 07:05:28PM GMT, schrieb Noah Meyerhans: > apt does not appear to to be able to list upgradable packages when they come > from a snapshot. I have never used this new snapshot feature, but I have the feeling what is missing here is "just" the support in the command line parsing (as that is a bit convoluted… entirely by my fault). > root@c6220891b564:/# apt -S 2024-06-30T00:05:09Z list --upgradable > Error: Command line option 'S' [from -S] is not understood in combination > with the other options. Does it work (show mawk?) with: apt -o APT::Snapshot=2024-06-30T00:05:09Z list --upgradable ? (-S/--snapshot are just cmdline sugar for this option) I don't think it should "work" without the option set – and I have to note that your config includes the option (with another timestamp). Best regards David Kalnischkies P.S.: Congrats! This is the first open bug number 1000 against apt. signature.asc Description: PGP signature
Bug#896834: /usr/bin/apt-key: also unstable with gpgv 2.2.43-{6,7} ...
On Wed, Jun 19, 2024 at 09:59:52AM +0200, Pti Zoom wrote: > when upgraded unstable gpgv to 2.2.43-{6,7} ! Red herring, as you don't seem to be using gpgv. > ii gpgv2.2.43-7 > ii gpgv-from-sq [gpgv] 0.9.0-1 If I am informed correctly the later diverts the former, so you are "secretly" using sq instead. apt 2.9.5 had a commit related to better support of this setup, but I haven't tried it myself, nor do we have any tests for this, and hence I don't know the objective qualification for better – after all, the world burning slightly slower is arguably better as well, even if its is still burning. #1073272 against it seems to suggest that it got kinda worse instead, but at least there is a promise of it working with a future 0.10. So, perhaps 'apt remove gpgv-from-sq' might "resolve" your problem. You might still want to figure out how that package got installed and perhaps report a bug against what brought it in as my understand was that this is not supposed to happen™, so some dependencies might be off. (for the avoidance of doubt: I have no opinion on sq as I haven't looked nor tried it yet, but I am not a gigantic fan of apt left not working, even in unstable, so I might have negative prejudices now) Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1073591: apt-get install failed with error "Could not create temporary file for ..._Packages - mkstemp (36: File name too long)"
On Tue, Jun 18, 2024 at 11:21:06AM +0800, Changqing Li wrote: > When I run "apt-get install with a long path", the following error is > reported: > "Could not create temporary file for ...long_path..._Packages - mkstemp (36: > File name too long)" Shouldn't that already be a problem with 'update'? Or are you talking about 'apt install /very/very/long/path/…' (or a --with-source variant)? > How about fix with the following patch? […] > Truncate it when it is longer than 240 (leave some spaces for > ".Packages" and "._Release" suffix) Imagine as source: deb http://example.org/very/very/long/path foo main deb http://example.org/very/very/long/path bar main that would roughly translate to e.g.: example.org_very_very_long_path_dists_foo_main_binary-amd64_Packages example.org_very_very_long_path_dists_foo_main_binary-i386_Packages example.org_very_very_long_path_dists_bar_main_binary-amd64_Packages example.org_very_very_long_path_dists_bar_main_binary-i386_Packages So, you can't just arbitrarily cut from the end as that potentially maps multiple URIs to the same filename (and while I am not sure if that method is UTF-8 safe, truncating is definitively not). The suffix part in your description is also misleading. The "suffixes" you mention tend to be already part of the URI (and hence the filename), so you would cut them. "Suffixes" that might be attached tend to be on the short side like if a file is compressed (although nobody said that a compression algorithm needs to use e.g. 'xz', it could also be 'xtremely_zmall'. The longer ones like .diff/Index (or the individual patches) tend to use this method (and would again be subject to truncating) if I remember right (haven't checked). Julian entertained the idea of storing files by hash in lists/ – that would at least limit the problem to files we don't have hashes for, as in the (In|)Release(.gpg|) file(s) – and of course every repo we don't have hashes for. For these we could go with a (directory)index file that tells us about the mapping. Such an index might even be better than our current guessing what files could exist and checking for their existence in many compression formats, but that would probably amount to a micro-micro optimisation… Anyway, drawback is of course that changing filenames means everything that access the files directly is broken. We told everyone who wanted to listen that they can use 'apt-get indextargets' to access filenames, but I doubt everyone wanted to and some might even have "good" reason like not doing shell (heck, I do sometimes. Our tests do. …) On a sidenote, NAME_MAX seems as constant as PATH_MAX, as in on some filesystems it is larger (or potentially smaller), but [surprisingly] more in effect than PATH_MAX. In any case, no magic numbers please. Oh, and congratulations! I suppose that problem exists since the beginning (1997) and I haven't seen it being mentioned while I am around (~15 years), so that makes this some very old and esoteric problem. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1072489: apt: what does this recommendation mean? (curl | lynx .. fonts-lato \n | wget)
Hi, On Sun, Jun 02, 2024 at 08:08:35PM +0200, наб wrote: > apt build-dep just asked me this in a sid chroot: mmhhh. I think build-dep did not show recommends/suggest in the past, so that might be a regression in that sense already. The reading order for the "new" column view is according to its name: 111 477 22 55 888 3666 9 while the "old" wall-of-text has: 111 22 3 4 55 666 77 888 9 So: > Suggested packages: > autoconf-archive cargo-doc gettext-doc libssl-doc | > fortran95-compiler apparmor libmail-box-perl libjs-mathjax > gnu-standards python3libasprintf-dev libtool-doc gcj-jdk > less riruby-kramdown-parser-gfm > autoconf-doc dh-makelibgettextpo-dev gfortran m4-doc > www-browser ruby-dev bundler gfortan | fortran95-compiler > Recommended packages: > curl| lynx imagemagick netpbm libarchive-cpio-perl > libldap-common publicsuffix libltdl-devzip > fonts-lato > | wget ghostscript libpaper1psutils javascript-common libgpm2 > libsasl2-modules libmail-sendmail-perl ruby-rouge rust-llvm curl | wget | lynx > But what's the recommendations? I think the alternatives group might be better of written together and then the individual columns separated with ~4 spaces like in the future-suggested "oldname => newname" case. The individual columns could get quiet big given package names can be long, but that is a problem for the column display anyhow. Anyway, I will leave it up to Julian what to do about this as this new stuff is his baby. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1071219: apt: debListParser fails to parse arch lists with extraneous whitespace: terminate called after throwing an instance of 'std::length_error'
(This mail is only related to the quoted sidenote question) On Thu, May 16, 2024 at 02:11:41PM +0200, Andreas Beckmann wrote: > not sure if it is allowed to inject spaces between '!' and arch as in > ..." ppc64 ! mips64el ! s390x "... No, debian-policy §7.1 says "Exclamation marks may be prepended to each of the names." and said right before that "[…] names […] separated by whitespace". dpkg agrees on this: | LANG=C dpkg-checkbuilddeps -d 'foobar [! amd64]' /dev/null | dpkg-checkbuilddeps: error: '!' is not a legal architecture in list '! amd64' It does have interesting behaviour on another whitespace-related case which is forbidden by policy via "The brackets enclose a non-empty list": | LANG=C dpkg-checkbuilddeps -d 'foobar []' /dev/null | dpkg-checkbuilddeps: warning: can't parse dependency foobar [] | dpkg-checkbuilddeps: error: cannot parse Build-Depends/Build-Depends-Arch/Build-Depends-Indep field vs | LANG=C dpkg-checkbuilddeps -d 'foobar [ ]' /dev/null && echo 'OK' | OK (but undefined behaviour on bad input isn't too bad) As a sidenote, as you haven't started with a '!' that string is a policy violation due to "(It is not permitted for some names to be prepended with exclamation marks while others aren’t.)". dpkg and APT both parse such strings and do what might be meant by it through. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1070959: /usr/lib/riscv64-linux-gnu/libapt-pkg.so.6.0.0: apt: riscv64: sun20i-d1: http(s): unhandled signal 4 code 0x1 in libapt-pkg.so.6.0.0
Hi, On Sun, May 12, 2024 at 12:13:11AM +0200, scpcom wrote: > When I run apt-get update on Allwinner D1 Nezha hardware I get the following > errors: > > [ 1610.448999] http[1575]: unhandled signal 4 code 0x1 at 0x003fa43ee5f8 > in libapt-pkg.so.6.0.0[3fa4326000+19c000] > [ 1610.459512] CPU: 0 PID: 1575 Comm: http Not tainted 6.6.29+sun20i #sun20i > [ 1610.466313] Hardware name: Allwinner D1 Nezha (DT) > [ 1610.471109] epc : 003fa43ee5f8 ra : 003fa43ee5f8 sp : > 003fc95c63d0 > [ 1610.478337] gp : 002ae3eca800 tp : 003fa35a0780 t0 : > 000a > [ 1610.485563] t1 : b8fa9f1e0b81022a t2 : 0064 s0 : > 002ae95abe00 > [ 1610.492789] s1 : a0 : 002ae95a5f80 a1 : > > [ 1610.500014] a2 : 002ae9565020 a3 : a4 : > 0001 > [ 1610.507239] a5 : 0001 a6 : 002ae95a1590 a7 : > 144ef8bcb0a5ab57 > [ 1610.514465] s2 : 003fa3df9618 s3 : 002ae3eca0a0 s4 : > > [ 1610.521691] s5 : 002ae959bda0 s6 : 002ae3eca0a0 s7 : > 003fc95c6d48 > [ 1610.528917] s8 : 003fc95c6d58 s9 : 003fc95c6690 s10: > 002ae9582730 > [ 1610.536144] s11: 003fa44ffd18 t3 : 003fa3d167cc t4 : > 003a > [ 1610.543371] t5 : 0001 t6 : 005c > [ 1610.548688] status: 00024020 badaddr: 833f cause: > 0002 > [ 1610.563819] https[1574]: unhandled signal 4 code 0x1 at 0x003fa5b155f8 > in libapt-pkg.so.6.0.0[3fa5a4d000+19c000] > [ 1610.574420] CPU: 0 PID: 1574 Comm: https Not tainted 6.6.29+sun20i #sun20i > [ 1610.581307] Hardware name: Allwinner D1 Nezha (DT) > [ 1610.586102] epc : 003fa5b155f8 ra : 003fa5b155f8 sp : > 003fd7b3b3c0 > [ 1610.593329] gp : 002ac54c6800 tp : 003fa4cc6780 t0 : > 000a > [ 1610.600554] t1 : b8fa9f1e0b81022a t2 : 0064 s0 : > 002ad80d4e40 > [ 1610.607780] s1 : a0 : 002ad80cefc0 a1 : > > [ 1610.615006] a2 : 002ad808e018 a3 : a4 : > 0001 > [ 1610.622233] a5 : 0001 a6 : 002ad80d2bc0 a7 : > 6fd82bd679d27ec2 > [ 1610.629458] s2 : 003fa5796618 s3 : 002ac54c60a0 s4 : > > [ 1610.636686] s5 : 002ad80d5540 s6 : 002ac54c60a0 s7 : > 003fd7b3bd38 > [ 1610.643912] s8 : 003fd7b3bd48 s9 : 003fd7b3b680 s10: > 002ad80ab730 > [ 1610.651138] s11: 003fa5c26d18 t3 : 003fa56b37cc t4 : > 003a > [ 1610.658363] t5 : 0001 t6 : 005c > [ 1610.663680] status: 00024020 badaddr: 833f cause: > 0002 > > The problem seems to exists since mid 2023. > On Ubuntu 23.04 there is no error. > I got the error on Ubuntu 23.10, 24.04 and latest Debian unstable. > The error only shows up on the real hardware and not inside a chroot > (qemu-user-static riscv64 image on amd64 hardware). > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > I build apt 2.9.2 from sources on Ubuntu 23.04 and installed the resulting > libapt-pkg6.0t64 deb on Debian unstable which temporairly solved the problem. > > It looks like a toolchain issue and apt may not be the only affected packge > (I have seen the same "unhandled signal 4 code 0x1" on libvte) This does indeed sound like a toolchain issue given different versions behave differently and unrelated (to apt) things have the same issue, so I am "soft-reassigning" this to riscv64 porters in the hope they will know where to assign and deal with this as libapt seems not a good place for that as I have quite literally no idea about riscv64… Installing -dbgsym packages and getting a corefile might be helpful. I note that you haven't provided much detail on your apt setup, but given the crash says `http` (and `https`) it might be helpful to get a simpler reproducer than "ran some apt command": Do you have the same problem with e.g.: /usr/lib/apt/apt-helper download-file 'http://example.org/' /tmp/example.html -o Debug::Acquire::http=1 or can you reproduce it with another URI? One from `apt update --print-uris` perhaps? If you can, it is possible to talk to `/usr/lib/apt/methods/http` directly on stdin to might have an easier time debugging this. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#839546: apt upgrade wants to install packages that apt autoremove will remove
On Mon, May 13, 2024 at 04:19:53PM +1200, Olly Betts wrote: > On Sat, Oct 01, 2016 at 11:15:28PM +0300, Sami Liedes wrote: > > apt upgrade lists some packages as new packages that will be > > installed, but at the same time lists those packages as "automatically > > installed and no longer required". > [...] > > Note that all of the NEW packages that will be installed are also in > > the autoremoveable list (contrary to what apt says, those packages are > > not yet installed). > > I'm seeing what appears to be the same problem, so this bug still seems > to be present: Possible, although its hard to say as the reason is hard to pin point from the provided output alone. As an example, the just released 2.9.3 actually includes a fix which has the same output – but I doubt its the same issue as I couldn't spot an offending Recommends so far: https://salsa.debian.org/apt-team/apt/-/commit/e099ee946000797f4c03b8c5075ce7ebba193337 I don't see too much that screams at me, although that all of them are t64 might be related to Provides shenanigans. As hinted in the commit message, its sadly not as easy as just not installing them all if they are new, so this code is a bunch of rarely fully engaged guess work. > If there's stuff I can usefully prod to help debug what's causing this > please let me know. It would help if you could share `/var/lib/dpkg/status` and `/var/lib/apt/extended_states` – both together resemble your exact system state, so if you don't want to share them publicly, you could sent them to me privately. Ideally you also run `apt upgrade -s -o dir::log::solver=/tmp/solver.edsp.xz` and keep the resulting /tmp/solver.edsp.xz file for now. This one includes the two former files as well as info about all packages available to you at this moment in case this is repository state dependent which it might be… but its a big file even compressed and a bit unwieldy to deal with in autoremove-debugging, so I hope not. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#990451: apt: the --no-all-versions option not working as documented
On Thu, May 02, 2024 at 12:40:30PM +0200, Manny wrote: > Note that “-o APT::Cache::AllNames=false” is used in vain (it has no > effect but at least it does not interfere either). The work of I think you meant All*Versions*, not Names. The later is documented to effect `pkgnames` only. In some way, AllVersions is documented to effect `show`, but much less specific by "full records" – a record is what show displays and policy doesn't, but yeah, not really discoverable. > It would be nice if I could also get a total size on any files to be > fetched. My knee-jerk thought would be to filter on all packages that > are not sourced from file:/local/filesystem, run apt-cache on that > subset to get full URLs, then do something like: > > apt-cache show "$pkg" | awk '/^Size/{print $2}' > > Anyway, the low-effort fix would be to at least update the man page to > state the narrow availability of --no-all-versions. Though it would be > useful if it worked for policy. > > In light of my use case, you could also say it’s already hacking > territory that apt-cache was needed at all. In principle, aptitude’s > installer output of how much data will be fetched should give a > breakdown of data volume to be fetched from each source location, > perhaps when run in a verbose mode. fwiw: I don't know about aptitude and if you think it should get some feature I suppose you should report it there, but for apt(-get) I have to note that both display "download size" as the size of all *.deb files to be downloaded from non-local (that mostly means non-file:/) sources… They do this mostly to check if the free disk space is large enough to hold the debs to download (while file:/ are used from there they are), but that is close at least to your knee-jerk thought. Not sure about the later "each source location"… that can turn out to be a lot of details for not that much gain: a typical Debian stable has 'normal', 'updates' and 'security'. You could add 'proposed' and e.g. 'backports' and a random set of 3rd parties like the typical Ubuntu user with seemingly 42+ PPAs added. That is 3+X counters useless even to you as you were just interested in the data coming from your local mirror vs. others. And that would assume that all mirrors are complete and available, no retries, no fallbacks, no redirects. Best regards David Kalnischkies signature.asc Description: PGP signature
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