Re: 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
Re: Firmware GR result - what happens next?
should be very light on (rev-)dependencies and demands upon them. We are potentially burning one component name forever, but I suppose we can live with that. The question is if we should do that through as it would be libapt- specific magic. I suppose as we are only talking about sources.list I guess we can do whatever as after all, that file is libapt-specific as well, but: Alice as an upgrader has non-free in its sources.list and gets non-free-firmware implicitly as a service from apt. Bob installs Debian on a fresh system and gets non-free-firmware in its sources.list as a service from d-i. Cecile is an upgrader, too, but she has non-free in her sources.list only for the firmware, so she would happily switch out non-free for non-free-firmware, if only she would know. All of them go online, read stuff potentially decades old about Debian, firmware and non-free. Their software center GUIs talk about four components now (do they?) they can enable (or not) in these funny little dialogs… As much as I would like apts sources.list to be apt-specific, I fear a bunch of things read and even write it, which potentially need to implement apt's magic as well to make sense to the user. Alice and Cecile will be confused if e.g. the GUI says they don't have non-free-firmware enabled, but they are getting packages from it… That is not to say no, I just want to highlight that other places would need some work as well and it could be confusing if we miss some – but then, what change isn't confusing. (That apt does things this way is due to historic grow. I entertain some changes which if they would exist would make similar split-offs work better, but those I would classify as requiring enormous patches. Absolutely not going to happen soon, if at all) > 1. Document it in the release notes and let users handle it. This means > lots of users won't get security updates for firmware (which are mostly > only issued for x86 CPU microcode), since lots of folks won't read the > release notes. This also means lots of support requests when users > can't find the firmware package they wanted. 'apt update' still has the code which detected Debian sources accessed via ftp, which told users that ftp will be shut down and points to a press release about it. [0] I didn't implement something similar for the security change as I somehow got the memo way too late and it would have been harder given in that case I would have no data to go by, but that is water under the bridge by now. We could do something similar to ftp here, detecting non-free but not non-free-firmware for a Debian source and point users to a press release explaining what this is all about (not the release notes, as e.g. sid users would somewhat rightly not expect to need to look there for information). That is somewhat trivial to do, we might even be able to convince the stable managers to allow backport this, so a bullseye user running 'apt update' while upgrading to bookworm would see that message already or otherwise be bugged about it IF they later interact with apt (which isn't a guarantee. So ideally other front ends would talk about this, too). That would be entirely Debian specific and hard-coded in apt (and in other front ends) though. I am not an enormous fan of producing an index of all repositories wanting to opt-in within apt source code. So moving that to an external hook might be better from a backport sense (as I suppose in the lifetime of stable, repositories will adapt. Not all prepare for stable while we do but against the finished product). I don't really want to rank either of the mentioned options as either could work, they all have their benefits and drawbacks and most importantly: while I am happy to impose work upon myself, I don't want to decide what others should work on. I also have a bad track-record of judging what is acceptable to bother users with… If I completely ignore the work aspect, for me personally I would favour 3 as it has the hint of introducing the concept of a hierarchy in components which might come in handy later if we want to split off other sections in other components as well. But as said, either works and I would be willing to support them from the apt side of things at least. With one exception: I rank any option even remotely considering a postinst failure well below NOTA as that is a horrible user experience. isa-support is a hack, not a role model. It is barely acceptable only because it effects only a tiny fraction of our user base so far. And even for those, I would like apt to help not installing broken packages (but that is another topic). So, who is gonna take the blame for deciding this for everyone? Best regards David Kalnischkies [0] https://salsa.debian.org/apt-team/apt/-/blob/main/apt-private/private-update.cc#L88-106 signature.asc Description: PGP signature
Bug#886473: apt-setup lacks a dependency on gnupg
On Mon, May 21, 2018 at 04:07:42PM +0200, Philipp Kern wrote:
> I think in the latter two cases it's necessary to name the key fragments
> .asc or .gpg depending on the content, correct? Right now we do not have
> this distinction, so we'd need to somehow detect which one it is. Worst
> case using grep for the ASCII armored preamble. Neither sources.list(5)
> nor apt-secure(8) describe what the contract for /etc/apt/trusted.gpg.d
> or other fragments actually is.
apt-key(8) has some scattered hints.
Beware of the keybox format which apt does not support. apt-key checks
the first byte of a (supposed to be) binary file and if its unexpected
skips with a warning (see is_supported_keyring). You could potentially
use a similar logic. It also includes code to convert asc to gpg format.
Both was suggested/vetted by the gpg maintainer(s).
If I could be wishing for something, I would go with ASCII armored files
(as that avoids problems with binary conffiles, keybox and other vanity
formats, …) and Signed-By in sources rather than /etc/apt/trusted.gpg.d.
If I had a djinni instead it would be something more along the lines of
the various alternatives which are proposed every so often, but never
actually materialize.
> We also use fetch-url from debian-installer-utils at the moment, which
> discards the source file name. I suppose we could use something like
> ${url%%://*} to strip the protocol (which fetch-url already does) and
> then use basename somehow to figure out the name, but I feel that this
> would be a little surprising.
We haven't figured out a sensible scheme for file naming either which
was one more reason to not try to make 'apt-key add' work without gpg.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Re: Bug#879591: apt: warns about main/debian-installer/i18n/Translation-en
he files might be empty (and hence allowed to be missing from the Release file, which apt supports e.g. for Packages files if the arch is mentioned in Architectures. Debian doesn't make use of this yet through and I don't know how other tools might react if it would). So we can't really go with a logic of "if any file from this component can be downloaded" as that set might very well be empty. We also can't look if the Release file contains any file for this component as we don't really know what is the component in the filepath: "main/debian-installer/some/file" might be from the component "main", "main/debian-installer" or "main/debian-installer/some". As said, I am not sure. In the end reassigning to ftpmaster might be the best option, but I am open for other opinions. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#851774: [pkg-gnupg-maint] Bug#851774: Stop using apt-key add to add keys in generators/60local
On Sun, Feb 05, 2017 at 12:23:19AM -0500, Daniel Kahn Gillmor wrote: > On Sat 2017-02-04 19:48:54 -0500, Cyril Brulebois wrote: > > [ dkg wrote: ] > >> Regardless of the choice of filesystem location (fragment directory or > >> elsewhere), gpgv does want to see the curated keyrings it depends on > >> in binary format, so on to the next bit: > > > > I'm a bit confused here: apt-get update (in a sid chroot, not attempted > > in d-i) is fine with an armor key in the fragment directory; are you > > saying that using the Signed-by option for sources.list would mean > > having to have a (curated) keyring, and an non-armored version, hence > > the need for the transformation you're suggesting below? > > Sorry, i guess it's possible that apt is doing something fancier that i > don't know about, then. > > gpgv on its own expects the --keyring files it encounters to be either a > sequence of raw OpenPGP packets that together form a series of OpenPGP > certificates (a.k.a. "a keyring") or GnuPG's "keybox" format. AFAIK, > gpgv does not accept ascii-armored files for its --keyring argument. > > maybe the apt folks can weight in on what's going on with armored > fragments? If it's converting them before handing them off to gpgv, > maybe you can just count on it to convert the files that aren't in the > fragment directory as well? apt >= 1.4 uses basically the awk snippet (it is slightly more complex to deal with two or more armor keys in one file, but that is implemented more for our testcases than a real external requirement) [see apt-key for implementation details]. Note that you can NOT use files in keybox format in exchange as apt merges all keyrings into a big one with 'cat' to avoid both a dependency on gnupg and to avoid running into limits on the amount of keyring files (gpg has a limit of 40 keyring files in a single invocation – and there is always the looming threat of having that be 1 one day…). So, as long as you make it so that an armored file has the extension 'asc' and binary (OpenPGP packet) file has 'gpg' apt will do the right thing with them in the fragment directory just as well as in Signed-By [in stretch, but Signed-By is a new-in-stretch feature, too]. > > Remember we're talking about adding extra repositories with custom d-i > > configuration, so I'm fine with people having broken stuff because they > > pasted a whole mail… > > agreed, we can expect these folks to get the details right. For the same reason I wouldn't worry too much about people using *.asc files with binary format contents and vice versa to be honest. Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Backports installed without prompt if not in base suite: bug or feature ?
On Sun, Dec 20, 2015 at 10:27:41PM +0900, Charles Plessy wrote:
> Le Mon, Dec 14, 2015 at 11:16:24PM +0900, Charles Plessy a écrit :
> > The current behaviour of the backports suite is deeply rooted in how APT
> > works.
> > Following the "install" command for a package, APT will look at the versions
> > present in its cache and their priorities ("pin values"), and following the
> > rules explained the apt_preferences manpage, will either install one of
> > these
> > versions or do nothing. In that sense, there is actually no difference
> > between
> > "installing" a package and "upgrading" a package. For backport packages
It is dense and simplified, but at least not wrong, so fine by me.
> > without a counterpart in the base suite, the backports versions are
> > valid candidtes and will be installed without warning. This is true
> > as well for packages in the "experimental" suite.
You never get a "warning" if a package is taken from a 'non-base suite'
(lacking the definition of what would be the 'base suite' as that is an
idea which only exists in the head of people and is nowhere codified,
beside that if we really explore this idea each package has its own base
suite it should be coming from which quickly leads us to define a way of
specifying a way of expressing preferences for possible sources…).
stable main, stable non-free, experimental and backports are all
perfectly fine sources which can all include a package and distribute
versions of this package. Preferences define how apt picks a version
among the potentially many options as its candidate – which is set by
the user ultimatively, but the maintainers of a source can provide
a default value if they so choose.
It is a natural consequence that – lacking better options – apt will
pick a candidate coming from a 'non-base suite' even if that is as low
in preferences as experimental is by default.
The closest thing to a warning you get at the moment is a notice if apt
picks a *different* candidate version based on your request e.g. if you
do "apt install foo/experimental" it will say it gets foo from
experimental (and maybe bar as well, which foo has a strong versioned
dependency on). If you do "apt install foo -t experimental" on the other
hand nothing tells you if foo (or bar) is installed from experimental
before you press 'y'.
> > David wrote that he would like to implement a pattern system inspired from
I think I wrote 'we'. The team is very small, but it is still big enough
to reasonably deny my use of "pluralis majestatis" for 'us'. ;)
> > aptitude, and utilise this to configure and display package listings in a
> > way
> > that gives a chance to the user to cancel the installation of a backports
> > package when this installation happens only because there is no version
> > available in the base suite.
That is a very negative summary. As I tried to explain in my last mail
I believe users can have very different views on how to rate a presented
solution – and I believe apt should make it (more) easy to rate
a solution by displaying more information. Personally, I doubt it will
significantly increase the amount of cancelations, but it helps letting
the user feel in control which is always a good thing (beside that it
helps educating users and presets the right expectation value).
In your previous mail you raised the question of which other frontends,
which potentially ranges from none to all depending on what you expect
to be told by your frontend. That is why we have so many.
> I would like to report the fruit of our discussion to the debian-cloud
> mailing
Frankly, I haven't seen much of a discussion – just a question being
raised and me trying to answer it from my personal POV. If my POV is now
elevated via a summary to "fuits of a discussion", I think 'we' have to
rethink the "pluralis majestatis" thing… but maybe I have just missed
all the good parts of the discussion as I am not subscribed to -boot or
-backports. I am just responding to calls to deity(@). ;)
The best "fruits" for me in this thread were actually the private
replies I got, which I haven't answered as I don't really know what to
say, but still are very grateful for as even after all things said in
public I actually ended up labeling this experience as good, which
I hadn't even considered a potential outcome initially.
So, thanks a lot!
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Re: Backports installed without prompt if not in base suite: bug or feature ?
On Tue, Dec 01, 2015 at 05:00:47PM +0100, Rhonda D'Vine wrote: > * David Kalnischkies <da...@kalnischkies.de> [2015-11-30 22:22:08 CET]: > > In other words: If you have experimental sources on your stable system, > > packages new in experimental will be automatically installed, too, if > > requested without any force needed (it won't be upgraded through as > > installed is pinned 100 which is higher than 1). Everything else would > > be against how pinning works – and its like that for 17 years now, so it > > can't be all bad – aka: feature. > > I really consider the reasoning of "it always has been that way" kinda > disturbing, frankly spoken. It has been used in very bad areas over the > history of human development, please don't use it. That's not really an > argument. All what I was trying to say is that the apt_preferences behaviour I explaining in this mail isn't a new invention, but exists since the beginning of apt in this way as a core design principle (in my eye), using the "it can't be all bad" as a reference to the fact that apt is still used while a lot of things with different designs fell out of favour because decisions in opensource aren't made by big white guys with power to have you killed if you look in the wrong direction, but by users who simply either use it or not. I wasn't advocating $very-bad-area because humanity did that for centuries and, frankly spoken, I am quite shocked its even suggested I would be – not only because that offends me, but it also suggests the work needed to stop $very-bad-area is even only remotely comparable to changing a piece of software – after all a single person can replace all of apt completely in a few days (q.e.d.: cupt) without fearing any negative consequences (beside users actually using it perhaps). (yes, I wrote that section last as reading what I had to respond to alone made me super angry already and I didn't want to paint the whole mail in this emotion) > > I don't think this is wrong, given that you have this source enabled > > you want that package installed, so not offering this solution would be > > a disservice. Pretty much the same thing as with non-free. > > And with my backports hat on I consider the comparison of backports > with non-free quite disrespectful, too ... I am sorry. I was using non-free (as it was established in the context already) as a means to broaden the view. Not in the "backport or non-free, its all the same crap" sense, but in the "I see little difference in the need to tell the user that a package comes from backports compared to that it comes from non-free given that both aren't the default source". An earlier draft was talking about experimental, various third-party repositories, future bikesheds and what have you, but I cut that out too reduce length and so ended up using only backports and non-free as the probably most relatable examples on opposite sites of the sources spectrum… As it is now obvious to me I cut so much, that its actually easy to get the wrong idea… so, again, I am sorry, it wasn't meant that way. > > Personally, I am in the "enable backports by default" camp as > > I believe that most people who issue a "apt install foo" want foo > > installed and do not care enough about stable vs. backports to say > > 'no' to the solution even IF they would know at the right moment > > that foo comes from backports (same for non-free) > > Again - please do *not* compare backports with non-free. And that you > consider people not to care is a fair bit disturbing. The objection to > putting backports into the default install should be reason enough for > you that there are people who *do* care and you shouldn't disregard > their opinion with a statement of people don't care anyway. I was saying "personally", I mentioned camp implying that there is (at least) another, words like "believe" and "most" aren't really very definitiv words and further down the line I even explicitly acknowledged the status quo as different and that I can agree with it even through I have a different opinion. I don't think that qualifies as disregarding opinions and don't caring, but I will assume that you only said that as you were expecting me to be like it after reading my previous statements (incorrectly, by my own fault). The whole paragraph was meant as full disclosure to avoid the inherent "display problem" of coming from a certain view point (aka source), but no indication of this (and yes, this is a "pun"). So, with that said, lets try again: I don't think its a good idea to change the behaviour I described explicitly in the last mail as plenty of users (including me) and tools actually depend on and like this behaviour. It is so natural that even the
Re: Backports installed without prompt if not in base suite: bug or feature ?
(see the other mail for more on this topic and also hopefully as a clearup of what was meant initially; just picking some semi-unique element here) On Tue, Dec 01, 2015 at 03:39:25PM +0100, Philip Hands wrote: > David Kalnischkies <da...@kalnischkies.de> writes: > > Personally, I am in the "enable backports by default" camp as I believe > > that most people who issue a "apt install foo" want foo installed and do > > not care enough about stable vs. backports to say 'no' to the solution > > even IF they would know at the right moment that foo comes from > > backports (same for non-free) > > I'd say that non-free is very different from backports in this context. > > One might enable non-free solely to get a wifi driver, and want nothing > else from it. One might disagree with the Debian position on GFDL and > want all the GNU documentation, while wanting nothing non-free. Which is exactly how some use backports: only wanting a very specific package, not the whole zoo. Its also how the majority of sources a user can have are supposed to operate as pretty much only "Debian my current release main" can be considered a catch all while all the rest was likely added to get this or that package only. > Such users are going to want updates to any of those packages, but > they're not going to want to get another single non-free package unless > they explicitly ask for it (with -t non-free or foo/non-free) The solution for those users is pinning packages from their undesired source to -1 (or lower, which translates exactly to "this is never a candidate") and pin specific packages (those which they have installed from there) to 100 (or slightly higher). That is cumbersome to work with, but it works. Its also a surefire way of running into miles long error messages you have to be a wizard for to decrypt. > Assuming we can make non-free behave in this way (so that upgrades are > automatic, but new installations are only by request), then it seems > possible that some people would also appreciate that feature in > backports. I already described that this is impossible with preferences alone and you can read all about it in the manpage for it: apt_preferences (Reading it carefully you will realize that this something most people describe as "upgrade" doesn't exist, but is just an happy accident of how pin values are chosen as by the time a new version is online nobody knows anymore where the old version came from…) I guess we could come up with some hardcoded logic in apt, but that wouldn't work for everything else be it aptitude, packagekit or whatever people use nowadays to install stuff and I don't see why backport or non-free would be special snowflakes here given that many users have many sources they only want very specific packages from. I further guess that we could hardcode a logic in libapt similar to the one described above with -1 and 100 pins, but that breaks tools which are supposed to flip to less preferred sources if needed like experimental buildds for example (see next), gives you the "perks" mentioned above and would be an all around stranger in an already complicated topic code and documentation wise. > If nothing else, having it as a configuration option that we can enable > by default would allow the d-i team to enable backports with confidence > knowing that this would not result in any surprised users. This imagined user isn't surprised that she gets a solution offered which includes packages from a less preferred source – aptitude does this all the time and was therefore also used to resolve dependencies on experimental buildds (now its apt with an external solver which has the same properties). In fact, we have plenty of bugreports detailing that users are surprised that apt is /NOT/ taking a package from a less desireable source. The external solver protocol for APT (EDSP) has an option to free a resolver from even more preferences concerns as I fought hard to not have it as the default… Your imagined user is surprised that she isn't told about such things before hand in a simple way (you can look for yourself with show or policy, or look at the download process, but that isn't simple and the later a bit late). That is a display problem, which as said, we are slowly but steadily working on in apt. Solving this with an option (our solution to everything) or just not enabling it by default isn't a solution: A user will just disable the option or enable the repository and will still be surprised by this. Even if you call the option I::want::apt::to::surprise::me=true. (People are repeatly told that recommends shouldn't be disabled, still way too many people do it and complain loudly if something breaks as that is a one time action with gets you into trouble only many months later if at all – and broken recommends are actually displayed…) Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Backports installed without prompt if not in base suite: bug or feature ?
On Mon, Nov 30, 2015 at 06:11:10PM +0100, Cyril Brulebois wrote: > Charles Plessy <ple...@debian.org> (2015-11-30): > > However, there is an exception: when a package is in the backports suite but > > not in the base suite, it will be installed by "apt install foo" without the > > need to select the backports suite. For this reason, jessie-backports has > > not > > been added to the default sources.list in new installations. > > (<https://bugs.debian.org/764982>) […] > Teaching apt to ask explicitly in such a case would make the problem go > away as far as I'm concerned, and I'd be happy to have stable-backports > enabled through apt-setup. I'm therefore adding apt developers to the > loop to get their opinion (and debian-boot@). APT is installing packages based on the pin value. NotAutomatic and ButAutomaticUpgrades do effect only upgrades in practice as they switch the default value of 500 (or 990 if its the default release) to 1 or 100 respectively. All of these choices are > 0 and hence valid candidates, it is just that if a package is in your preferred release (here stable) this package has the highest pin and therefore you need an explicit request to change the candidate to lesser pinned sources. In other words: If you have experimental sources on your stable system, packages new in experimental will be automatically installed, too, if requested without any force needed (it won't be upgraded through as installed is pinned 100 which is higher than 1). Everything else would be against how pinning works – and its like that for 17 years now, so it can't be all bad – aka: feature. I don't think this is wrong, given that you have this source enabled and you want that package installed, so not offering this solution would be a disservice. Pretty much the same thing as with non-free. The problem is "just" that you aren't told all details which could influence your decision of accepting or denying the solution in a very visible way upfront with apt (aptitude cui is better in this regard I guess). I have longterm plans to change this and the code slowly moves in this diection, but to make that fly there is a bunch of stuff still to do. A bigger part is on our next-up list: Merging back (the better parts of) aptitudes pattern system. With that in place I envision being able to configure package listings as well as configure the display of matching packages in listings which would – assuming we could agree on some for most people sensible defaults which isn't going to be trivial – solve this eventually… So, then does that happen? Lets say it this way: Roughly six years ago I joined the apt team with this very simple idea… rapid development of features is a bit harder than I would like if the team is cronically understaffed. Personally, I am in the "enable backports by default" camp as I believe that most people who issue a "apt install foo" want foo installed and do not care enough about stable vs. backports to say 'no' to the solution even IF they would know at the right moment that foo comes from backports (same for non-free) – but I can perfectly understand that some want to hold that off until everyone actually has the information at the right moment. [That is not to say that the treatment by a user doesn't change if she knows – I prefer potentially buggy open firmware over closed one for example and given the choice of cake via backports or no cake, I will opt for backports accepting less service than stable, but if apt would hide this choice behind an error I would just get the impression that the system is making this needlessly difficult – after all, far more dangerous solutions like removing the entire desktop environment is purposed without additional loop to jump through, too] Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?
On Sat, Nov 28, 2015 at 12:30:52AM +0100, Cyril Brulebois wrote: > Now if I log out of the schroot session, remove my user 'kibi' from the > cdrom group and re-enter a schroot session, I'm now getting a failure on > the next group: > | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ make -C build > build_netboot-gtk USE_UDEBS_FROM=sid > | make: Entering directory '/home/kibi/debian-installer/installer/build' > | Using generated sources.list.udeb: > |deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/ > localudebs/ > |deb http://localhost/debian sid main/debian-installer > | make[2]: 'sources.list.udeb' is up to date. > | Reading package lists... Done > | E: Method gave invalid 400 URI Failure message: Could not switch group, > user _apt is still in group 25 > | E: Method gave invalid 400 URI Failure message: Could not switch group, > user _apt is still in group 25 > | E: Method copy has died unexpectedly! > | E: Sub-process copy returned an error code (112) > | > | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ getent group floppy > | floppy:x:25:kibi > | > | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ groups > | kibi floppy audio dip video plugdev sbuild kvm libvirt > > Iterating again, I'm now failing because of the audio group… Mhh. apt is run as root (as we don't reach this codepath with uid != 0), but it has all the groups of kibi and a setgroups is silently ignored… wtf… The code is if someone wants to look: https://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/fileutl.cc#n2264 I will go to bed now, maybe I have an epiphany tomorrow. (or manage to reproduce this for a start) > While I've been experimenting with adding/removing myself from the said > groups, I'm noticed this a few times, without being able to figure out > what exactly causes this… > | W: No sandbox user '_apt' on the system, can not drop privileges > > In which case, going back to apt.git and "sudo debi -u" to reinstall all > packages I've built seems to fix the issue. As mentioned briefly schroot copies users & groups from your host system, so if your host system has no _apt user, the _apt user in your schroot will "disappear" next time it is copied over. Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?
On Fri, Nov 27, 2015 at 09:08:35PM +0100, Cyril Brulebois wrote:
> | E: Method gave invalid 400 URI Failure message: Could not get new groups -
> getgroups (22: Invalid argument)
> | E: Method copy has died unexpectedly!
> | E: Sub-process copy returned an error code (112)
So, getgroups gets called there to verify that we really lost all groups
(beside the one _apt is in: nogroup). A few lines above we set the list
of (supplementary) groups containing only this group, then we switch uid
and gid (the later isn't enough for group switching aka we would be
still in root without the setgroups before).
So, us calling getgroups should really only return one group. Getting an
EINVAL suggests we get more than one… that is probably bad, but I have
a slight glimmer of hope that its just two times the same group – even
if that makes no sense… anyway, I can't reproduce this at the moment, so
it would be nice if someone could try the attached patch which could at
least tell us in which groups we remain (or it just works if we really
see duplicated groups here). Everything is possible I guess.
Given that schroot is involved mentioning if your host has an _apt user
or not might also help. As I learned today schroot is copying users and
groups into the schroot which makes all of this kinda strange… (#565613)
[two years of testing and you are still surprised on release…]
btw: To not block anyone: You can use the config option
Debug::NoDropPrivs to true to disable privilege dropping for the moment.
Best regards
David Kalnischkies
diff --git a/apt-pkg/contrib/fileutl.cc b/apt-pkg/contrib/fileutl.cc
index 46de634..f754b31 100644
--- a/apt-pkg/contrib/fileutl.cc
+++ b/apt-pkg/contrib/fileutl.cc
@@ -2322,12 +2322,17 @@ bool DropPrivileges() /*{{{*/
return _error->Errno("seteuid", "Failed to seteuid");
#endif
- // Verify that the user has only a single group, and the correct one
- gid_t groups[1];
- if (getgroups(1, groups) != 1)
- return _error->Errno("getgroups", "Could not get new groups");
- if (groups[0] != pw->pw_gid)
- return _error->Error("Could not switch group");
+ // Verify that the user isn't still in any supplementary groups
+ long const ngroups_max = sysconf(_SC_NGROUPS_MAX);
+ std::unique_ptr<gid_t[]> gidlist(new gid_t[ngroups_max]);
+ if (unlikely(gidlist == NULL))
+ return _error->Error("Allocation of a list of size %lu for getgroups failed", ngroups_max);
+ ssize_t gidlist_nr;
+ if ((gidlist_nr = getgroups(ngroups_max, gidlist.get())) < 0)
+ return _error->Errno("getgroups", "Could not get new groups (%lu)", ngroups_max);
+ for (ssize_t i = 0; i < gidlist_nr; ++i)
+ if (gidlist[i] != pw->pw_gid)
+ return _error->Error("Could not switch group, user %s is still in group %d", toUser.c_str(), gidlist[i]);
// Verify that gid, egid, uid, and euid changed
if (getgid() != pw->pw_gid)
signature.asc
Description: PGP signature
Bug#764587: installation-reports: After successful installation from usb stick the stick is not recognised on reboot.
On Tue, Nov 25, 2014 at 03:40:06PM +, Steve McIntyre wrote: Apt guys, how much effort would it be to add an extra package source (derived from cdrom), called apt-usb or similar? The apt-cdrom code is practically unmaintained, so if anyone is really interested in any improvements in that area: Now (modulo jessie, so maybe in a few weeks instead) would be a good time to get active… That said: Where available apt-cdrom is using udev to figure out mountpoints. Currently, it is looking for CDROMs only, but setting APT::cdrom::CdromOnly to false should tell it to look for any mountpoints which are removable instead. I further see some code using .disk/ with a comment starting with if we are on a writable medium (like a usb-stick) so I presume this could already work, but I have never tried.¹ This says nothing about systems where udev isn't available (for various reasons) of course and as said, it is practically unmaintained, so at least I am not flipping any default value in code I only touch for one reason: d-i breaks because I have changed something unrelated. The best approach might be to move apt-cdrom to apt-transport-cdrom (it is currently a bit entangled with other code, but removing this is not the worst idea anyhow) and finding maintainer(s) for it. These can probably come up with a way better name than cdrom as well. All I can come up with is removable which has a slightly different meaning for me if its attached to code. ;) (As usual, if you are said volunteer feel free to contact me (or better yet deity@) and we will do what we can to help you out; I just want to make cristal clear that we don't have the resources to do it ourselves). Best regards David Kalnischkies ¹ well, we have a testcase which works with cdrom sources which obviously doesn't need to burn and mount a test cd, so I am pretty sure that the using part works. I am just not too sure about udev, mounting, multidisks, interaction with d-i (and others) and similar details… signature.asc Description: Digital signature
Re: Bug#765458: apt: broken cdrom support, breaking installation from weekly ISO images
Hi,
On Wed, Oct 15, 2014 at 11:47:44AM +0200, Cyril Brulebois wrote:
[ X-D-Cc: debian-boot@, please keep it in the loop when replying. ]
[Done, although I don't see the header… (bad mutt, bad).]
we received several bug reports about weekly installation images being
unable to find a kernel package to install on the freshly debootstrapped
system. I've been able to replicate this issue with apt 1.9.0.2. Various
Is the apt-get update call from which you have included the output
a recent addition or was it 'always' there?
I am asking as 'apt-cdrom add' actually does the work of copying the
indexes to disk, which (should) mean that 'apt-get update' is a no-op,
making the call useless if cdroms are really the only possible source in
that stage.
That 'update' isn't really supposed to be called here is reinforced by
the ugly warnings/errors you showcase and which existed since ever. Our
only testcase covering apt-cdrom also doesn't include such a call…
Why that is the case, I have no idea, as I would expect at least some
people to have multiple sources, including cdrom, which would call for
an update, so that should really work without being scary (= assuming
warnings from apt are regarded as scary…).
The irony is that the suspected bad-boy 80174528 actually fixes this
longstanding problem as the regression was that apt exited nonzero, not
that it printed warnings (so much for scary).
The problematic commit is b0f4b486 (and therefore not a regression in
a security fix – everyone rejoice): While fine by itself, merged with
the suspected bad-boy we still have no warnings and a successful exit,
but our helpful list-cleanup kicks in removing files from the lists/
directory which seem to be orphaned given that it is looking e.g. for
a Packages.gz file and not for Packages as the part fixing up the
filename is skipped if a cdrom source is encountered.
The attached patch should merge both in a better working way, at least
that is what the testcase is promising me – which I have extended a bit
to cover a bit more ground, too. Nothing near proper testing though, so
someone giving it a proper testspin would be nice, but if that is too
hard I guess Michael could just upload it and let the world test it for
us (now that he doesn't have to fear another security upload). ;)
Best regards
David Kalnischkies
commit 5afcfe2a51a9e47e95023b99bcab065d1975e950
Author: David Kalnischkies da...@kalnischkies.de
Date: Wed Oct 15 15:56:53 2014 +0200
don't cleanup cdrom files in apt-get update
Regression from merging 801745284905e7962aa77a9f37a6b4e7fcdc19d0 and
b0f4b486e6850c5f98520ccf19da71d0ed748ae4. While fine by itself, merged
the part fixing the filename is skipped if a cdrom source is
encountered, so that our list-cleanup removes what seems to be orphaned
files.
Closes: 765458
diff --git a/apt-pkg/acquire-item.cc b/apt-pkg/acquire-item.cc
index 2401364..253cbda 100644
--- a/apt-pkg/acquire-item.cc
+++ b/apt-pkg/acquire-item.cc
@@ -1144,16 +1144,12 @@ void pkgAcqIndex::Done(string Message,unsigned long long Size,string Hash,
else
Local = true;
- // do not reverify cdrom sources as apt-cdrom may rewrite the Packages
- // file when its doing the indexcopy
- if (RealURI.substr(0,6) == cdrom:
- StringToBool(LookupTag(Message,IMS-Hit),false) == true)
- return;
-
// The files timestamp matches, for non-local URLs reverify the local
// file, for local file, uncompress again to ensure the hashsum is still
// matching the Release file
- if (!Local StringToBool(LookupTag(Message,IMS-Hit),false) == true)
+ bool const IsCDROM = RealURI.substr(0,6) == cdrom:;
+ if ((Local == false || IsCDROM == true)
+ StringToBool(LookupTag(Message,IMS-Hit),false) == true)
{
// set destfile to the final destfile
if(_config-FindB(Acquire::GzipIndexes,false) == false)
@@ -1162,7 +1158,10 @@ void pkgAcqIndex::Done(string Message,unsigned long long Size,string Hash,
DestFile += URItoFileName(RealURI);
}
- ReverifyAfterIMS(FileName);
+ // do not reverify cdrom sources as apt-cdrom may rewrite the Packages
+ // file when its doing the indexcopy
+ if (IsCDROM == false)
+ ReverifyAfterIMS(FileName);
return;
}
string decompProg;
diff --git a/test/integration/test-apt-cdrom b/test/integration/test-apt-cdrom
index 8d8fdf1..44eccb7 100755
--- a/test/integration/test-apt-cdrom
+++ b/test/integration/test-apt-cdrom
@@ -66,22 +66,51 @@ CD_LABEL=$(echo $ident | grep ^Stored label: | head -n1 | sed s/^[^:]*: //
testequal CD::${CD_ID} \${CD_LABEL}\;
CD::${CD_ID}::Label \${CD_LABEL}\; cat rootdir/var/lib/apt/cdroms.list
-testequal 'Reading package lists...
+testcdromusage() {
+ touch rootdir/var/lib/apt/extended_states
+
+ testequal 'Reading package lists...
Building dependency tree...
+Reading state information...
The following NEW packages will be installed:
testing
0 upgraded, 1 newly
Re: Activating t-p-u by default (was: Re: For those who care about their packages in Debian)
2010/8/26 Carsten Hey cars...@debian.org: * David Kalnischkies [2010-08-26 17:43 +0200]: Long story short: If you want to get updates from an archive only if you pushed a version previously from it: 100 = pin 500. Wouldn't adding a new field to Release files similar to 'Not-Automatic' but pin to 101 instead of 1 if this new field is set to yes an option for apt/Squeeze+1? This has been reported in #186767. Well, yes and no. Technical more or less no problem, but… As far as i understand t-p-u i don't understand why the default should be 500. If i am adding it (or let a piece of software add it for me) i guess i want these packages on my system: proposed-updates at least suggests for me, that they will be soon in testing anyway, just, that they are tested now before they enter real testing in an overlay archive. If i don't want to participate in this testing, i should remove the archive from my sources. If i just want to grab some versions from it, t-p-u doesn't get much testing in general as you must care for this specific package enough to get a new version for it: So new iceweasels are maybe tested a bit, but packages like tzdata will not get any testing through t-p-u… The problem with this is also, which is why i don't think it would be suitable for backports, is that these archives mixing minor only-bugfix releases and new groundbreaking upstream releases… E.g.: I maybe want to get bugfix releases for iceweasel through backports automatically, but what i don't want is an automatic 3.6 - 4.0 upgrade, but such pinning i need to define by hand anyway. Regarding the bug: What do you do if two non-debian archives provide such a package -- and, do they fight against each other now that they can by changing their DefaultPriority? The cleaner way for the user would it be to declare: I don't want to get this package from this archive ever and i care only for these packages from this archive, ignore the rest. You can say that with -1 and Co, but it is a bit harder than needed… So, again in short: I don't see a reason backports shouldn't be pinned to 1 by default and t-p-u by default not pinned at all to get the default 500 pin… Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikbzjm8cb9fgg_vtki2h8xjk-7_fpv-e9pmm...@mail.gmail.com
Re: Activating t-p-u by default (was: Re: For those who care about their packages in Debian)
2010/8/26 Paul Wise p...@debian.org: AFAIK to achieve that you need pinning priorities 500 and 1000. A pin-value = 100 is enough in this scenario. 500 would have maybe even the wrong effect, as repositories which are not from the default-release - if set at all - get 500 per default (expect if the Releasefile says Non-Automatic: yes, then it is pin 1). So setting t-p-u too 500 would give it always a preference in case no default-release (which gets pin 990) is set. Example: Package: apt Pin: release t-p-u Pin-Priority: 600 apt: Installed: 0.8.0 Candidate: 0.8.1 Version table: 0.9.0 0 500 http://ftp.de.debian.org/debian/ testing/main i386 Packages 0.8.1 0 600 http://ftp.de.debian.org/debian/ t-p-u/main i386 Packages *** 0.8.0 0 100 /var/lib/dpkg/status Note that the candidate is t-p-u apt 0.8.1 and not testing apt 0.9.0 … In case APT::Default-Release (-t option) is set to testing the candidate will be 0.9.0 as testing will have a pinning of 990 instead of 500… but in this case 0.8.1 would be never a candidate as long as in testing is still apt 0.8.0 as 990 600 and if you manually use 0.8.1 from t-p-u apt will wait with an upgrade until this one or newer is in proper testing… So, to let that actually work a user should not have a default-release… Long story short: If you want to get updates from an archive only if you pushed a version previously from it: 100 = pin 500. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinoy2_9zczxmktndqe3xve2jx5-gbziybjbc...@mail.gmail.com
