[11:34] hi guys, question for core-devs or even AA [11:34] ubuntu-minimal pulls in ubuntu-advantage-tools, [11:34] and I'm about to add a curl dependency to u-a-t [11:34] which means ubuntu-minimal would pull in curl [11:34] is that ok? [11:35] I "need" curl because we want to check the credentials the user supplied before adding the private repository that contains the packages to be installed (fips, esm) [11:43] Pwnna: hi, maybe this helps: https://help.ubuntu.com/community/btrfs#Ubuntu-specific_subvolume_layout_in_11.04_and_later [12:25] ahasenack: Pulling curl that far down the stack doesn't fill me with joy, no. [12:25] ahasenack: When I agreed (grudgingly) to add ubuntu-advantage-tools to minimal, it was because "it's just a shell script". [12:26] right [12:26] ahasenack: Why not use apt itself to test? [12:27] Add sources.list bits, run apt-get update, capture output, revert if broken, yell at user. [12:27] a bit more complicated, the "capture output" bit [12:27] versus just a one liner of curl [12:27] Yeah, but they need the apt-get update anyway. ;) [12:27] apt could fail for other reasons, and it's not like we get a nice http code output [12:28] but it was me who raised the curl dependency as an issue, so I understand your concern [12:28] see https://github.com/CanonicalLtd/ubuntu-advantage-script/pull/89 :) [12:29] ahasenack: So, the argument that "you're already pulling in apt-transport-https" ignores that you do that opprotunistically, not as a dependency. [12:29] infinity, note that we already pull libcurl-gnutls because of apt-transports-https [12:29] ackk: ^ [12:30] infinity: correct, it's installed on-demand [12:30] it's not a straight dep [12:30] and we could do the same for curl [12:31] hm, only for the enable-{esm,fips} cases? [12:31] infinity, if it wasn't "just a script" it could be python and wouldn't need the curl dep :) [12:31] ahasenack, yeah I think it should work? [12:31] that's when we need it [12:31] And python is also not in minimal, so... [12:32] infinity: is there a way to use apt-transport-https for this auth check, or is it too much apt centric? [12:32] infinity, it is? [12:32] there is /usr/lib/apt/methods/curl [12:33] Irritatingly, curl and apt-transport-https pull in different versions of libcurl3, at least on precise. But oh well. :/ [12:33] infinity: oh, precise won't be getting this [12:33] ahasenack: I mean, the way to use apt to do it is to run an update. [12:33] infinity, yeah but it's then hard to check that the reason for apt failures is credentials for that repo specifically [12:33] interesting symlink I have in artful: /usr/lib/apt/methods/curl+https -> curl [12:34] ah, that's for /usr/lib/apt/methods/curl, n/m [12:34] infinity, afaics ubuntu-minimal depends on python in precise, and on python3 in artful [12:34] ahasenack: Well, same libcurl issue on trusty. ;) [12:35] infinity: you mean libcurl3 vs libcurl3-gnutls? [12:35] ackk: Oh, hrm. Maybe I lost that argument when I wasn't paying attention to someone else committing. [12:36] ackk: You are indeed correct, though. [12:36] apt-transport-https does not pull in curl anymore in artful and newer [12:36] So, if python has the right bits there, you could also use that. [12:36] or rather, it's not needed anymore in artful [12:36] juliank: Indeed, but this is also about older releases. [12:36] in bionic it's just a transitional package [12:36] infinity, FTR u-a was initially python, then rewritten in shell :/ [12:37] Can't you use /usr/lib/apt/apt-helper download-file for whatever you're doing? [12:37] ackk: FTR, shell is absolutely the right language for what it does. Until people turn it into some swiss army beast. [12:37] Might be more useful? [12:37] infinity, which is the case already :) [12:37] juliank: Oh, that works? [12:37] juliank: hm [12:37] If it's a repo you're adding, you could just fetch the release file that way. [12:38] That would be an elegant solution, if it has useful returns. [12:38] let me check trusty [12:38] the oldest one [12:38] I'm not sure how far back that goes, though [12:38] trusty has it [12:38] we need something that works on precisetoo [12:38] *precise too [12:38] ackk: really? [12:38] esm? [12:38] ah [12:38] Right, not in precise [12:39] I thought we were not updating precise with this [12:39] bdmurray: hey hey any chance we get this in? https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1716359 [12:39] Launchpad bug 1716359 in unity-control-center (Ubuntu Xenial) "Unplugging headset with audio panel open mutes internal mic" [Undecided,Incomplete] [12:39] we can make that decision [12:39] But I mean, you could manually talk to the apt method if you're really bored. [12:39] ahasenack, I'd like to have stuff that works everywhere or we'll forget and at some point need to update precise and not be able to [12:39] Or use python-apt or something :) [12:40] python-apt is definitely not in minimal. [12:40] ackk: it's more likely that the esm idea will move forward [12:40] and in trusty, if that happens, we would have this feature (auth check) covered then [12:40] not keen on blocking a good idea (apt helper) that would help >= trusty just because precise doesn't have it [12:41] ahasenack, honestly, I would rather rewrite (again) in python and keep things working everywhere [12:41] and, accidental ping [12:42] If you want to manually talk to the method, that's easy to, they just talk an HTTP like protocol [12:42] juliank, yeah I guess I could try that [12:42] juliank: you mean /usr/lib/apt/methods/https ? [12:42] yeah [12:42] juliank, I need to launch it manually, right? [12:42] juliank: with echo | ? [12:42] Indeed [12:43] You need to write a 600 URI Acquire message to its stdin, and read the status from stdout [12:43] http://paste.ubuntu.com/26057904/ [12:43] ^ like that [12:43] The 600 block is what I wrote the rest is the method [12:43] In your case, you could just look for a failure message [12:43] I guess [12:45] The advantage of apt-helper is that it also supports proxies configured for apt and stuff [12:45] ahasenack: Oh, while we're on the topic, it's icky and gross that you embed the user:pass in the sources.list URL instead of tossing it in apt_auth.conf [12:45] infinity, is that in precise too? [12:46] infinity: that discussion started with bug https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1700611 [12:46] ackk: Should be, according to the manpage. [12:46] Launchpad bug 1700611 in ubuntu-advantage-tools (Ubuntu) "sources.list file created for ESM is world-readable, leaks subscriber token to all local users" [Undecided,Incomplete] [12:46] Was introduced in 2009 [12:46] netrc is supported since 0.7.25, at least for https [12:46] which prompted https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1701852 [12:46] Launchpad bug 1701852 in apt (Ubuntu) "(xenial+) apt-cache fails to run if a single sources.list.d entry is not readable" [Low,Fix released] [12:47] ah, the other one too [12:47] Indeed. And the fix for that is too invasive to backport to xenial and zesty [12:48] Hence having auth in auth.conf would be super awesome [12:50] The APT method protocol is documented, BTW [12:50] juliank: Of course, auth.conf (unless it's missing some docs) seems to be lacking an auth.conf.d [12:50] in method.html [12:50] infinity: hmm [12:50] that seems to be true [12:50] It would seem a natural thing to want so that sources.list.d can have matching auth.conf.d snippets. [12:51] But managing a single file on old releases isn't super difficult. [12:51] infinity, +1 [12:51] That's complicated. [12:51] We can probably add multi-file to bionic [12:51] juliank: Complicated to backport, absolutely. That was a wishlist for going forward. :) [12:52] The auth.conf is now opened before the method sandboxes. [12:52] and we just keep a FileFd to it around [12:52] (And I don't literally mean there should be some snippet-matching lookup table, just that as someone writing a tool that adds sources.list.d snippet, the natural thing to do would be to also add an auth.conf.d snippet and assume it'll be concatenated on auth.conf) [12:52] yeah [12:53] We just need to make the current FileFd a std::vector and iterate over them. [12:53] Should be doable. [12:53] Or we could get crazy and construct a new FileFd implementation that is a concatenation of other FileFds :D [12:54] Are config files not short enough that you could just load the concatenation into memory, and avoid the FileFd interface in new code? [12:55] infinity, if you apt-add-repository right now, does it use apt_auth ? [12:55] juliank: I mean, one wouldn't expect a netrc to ever be particularly large. I'd probably just read it into memory. [12:55] (But then there's all the gotchas associated with that) [12:55] ackk: add-apt-repository doesn't handle http auth at all. [12:55] (I mean, you can give it a URL with auth bits in it, but it just takes it raw, it doesn't parse it) [12:55] infinity, well I mean you can specify a deb line with basic auth [12:56] I see [12:56] Sure, we should just parse the netrc into a data structure, that would be neat. [12:56] The implementation currently just searches the file [12:56] ahasenack, I'll have a look at using the apt method when I have time [12:57] juliank: That would give micro-optimisers a heart attack. [12:57] indeed [12:58] I'd probably still parse it into a linear search struct, though. Small enough [12:58] I wonder how it behaves if I write a kitten gif to /etc/apt/auth.conf [12:58] It at least uses std::string, and no indexing, so it should be safe :D [12:58] ackk: so option 1 is to use apt-helper, [12:59] ackk: option two is to talk to the method directly, might be icky in shell [12:59] juliank, do you have a link to the helper protocol at hand? [12:59] ahasenack, we already said apt-helper is not there in precise though? [12:59] IIUC [12:59] juliank: I'm very sad to report that it didn't explode on the kitten. [12:59] apt install libapt-pkg-doc, open /usr/share/doc/libapt-pkg-doc/method.html/ [12:59] Also seems to be on http://www.fifi.org/doc/libapt-pkg-doc/method.html/ch2.html#s2.2 [12:59] whatever that is [12:59] ackk: depending on the pain, I'm willing to skip this update for precise [13:00] Just don't do the check on precise? [13:00] right, leave it as is [13:00] AFAIUI, it's just a convenient thing anyway [13:00] juliank, thanks [13:01] ok, yeah we can skip the check [13:01] juliank: and tl;dr about apt's auth.conf, can we use it without breaking apt-cache? [13:01] from trusty onwards, for exmaple? [13:01] ahasenack: That's (one of) the point(s). [13:01] auth.conf is irrelevant for the cache [13:01] ahasenack: Should be able to use it from precise onward. [13:02] even in precise [13:02] ok, will do [13:04] infinity: It's crazy what kind of useful stuff we have in apt sometimes :) [13:05] juliank: infinity: thanks for the discussion [13:05] We could also add apt-helper hashsum if somebody wants a hashsum tool [13:05] juliank: What's really crazy is that I've been using auth.conf for years, but apparently it was only documented in 1.5 (according to the manpage). Now I'm wondering how I discovered it. [13:05] infinity: You probably read the changelog or noticed when it was added? [13:05] juliank: That does sound like a thing I might do. [13:06] juliank: It's also possible that I was involved in speccing it, but I'm old and can't remember 2009. [13:07] https://wiki.ubuntu.com/LucidFoundationsAptNetrc [13:07] It even lists a Dir::Etc::netrcdir, but nobody implemented that [13:07] "add a dir.d directory (Dir::Etc::netrcdir) " [13:07] Heh. [13:08] Yeah. [13:08] add a dir.d directory (Dir::Etc::netrcdir): POSTPONED [13:08] From the blueprint. [13:08] And then mvo went to work at a university. [13:08] lol [13:09] "look into using for proxy passwords as well: POSTPONED" is actually implemented [13:13] juliank: Do you have a bug in Debian and/or Ubuntu about AutoRemove::SuggestsImportant being silly? [13:13] infinity: slangasek opened one in LP. [13:14] juliank: (I would argue that, unless explicitly set, AutoRemove::{Recommends,Suggests}Important should inherit the obvious inverse of Install-{Recommends,Suggests}) [13:14] Not the inverse. If you install recommends, they are definitely important to keep :D [13:14] juliank: You know what I meant. :P [13:15] https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1725861 [13:15] Launchpad bug 1725861 in apt (Ubuntu) "APT::AutoRemove::SuggestsImportant "false" should be the default" [High,New] [13:15] DonKult strongly disagrees with that [13:15] Yeah, I disagree with the bug title, but agree with the intent. [13:16] I want to try to find a better solution to all problems. [13:16] That one and https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1734104 [13:16] Launchpad bug 1734104 in apt (Ubuntu) "'upgrade' in bionic should by default autoremove as well" [Undecided,New] [13:17] That is, remove _new_ garbage automatically [13:17] If I uninstall foo, it should remove all unused dependencies of foo [13:17] But not of bar which I uninstalled earlier. [13:17] Couple that with a complete cleanup at release upgrades. [13:18] Eventually it should not make a difference, but it brings a higher level of safety at the moment IMO [13:19] juliank: Oh! That reminds me that I have a bug to file when I'm more awake (it's so very much nap time). [13:19] juliank: Or I can "file" it right here. [13:20] Heh, I'm totally awake - I'm actually writing my master's thesis on the left side of my screen :D [13:20] juliank: "apt upgrade" doesn't magically handle Conflicts/Replaces for package takeovers the same way that update-manager does. Given that "apt upgrade" is meant to be less broken than 'apt-get upgrade' and a bit more friendly, I'd suggest that it should. [13:21] So, apt upgrade should not remove packages. Hence conflicts are ignored. [13:21] (Though, I'd also argue that we could and should change apt-get upgrade to behave like apt upgrade, and no one will notice) [13:21] juliank: Right, update-manager also follows the "should never remove packages" rule, EXCEPT in that one case. [13:21] And conflicts/replaces do not indicate a takeover, it could also be a switch between different implementations. [13:21] Which is why we kind of want an Obsoletes keyword. [13:22] s/keyword/field/ [13:22] juliank: Conflicts/Replaces can only go one direction meaningfully or your uploaders screwed up. [13:22] (Unless a Provides is also in play, which means something different) [13:23] You don't necessarily need a provides. [13:23] For..? [13:23] P/C/R and C/R don't mean the same thing. [13:23] You could also have package foo depending on bar | baz, and bar conflict/replace baz, and baz conflict/replace bar. [13:23] Nope. [13:23] That would be a broken archive. [13:24] It's entirely possible. The P/C/R and C/R semantics are just conventions. [13:24] Sure, it's *possible*. [13:24] It would still be broken. [13:24] And I mean, lots of takeovers are also provides, conflicts, and replaces. [13:24] Lots of broken things are possible. :P [13:24] or provides, breaks, replaces. [13:25] B/R is an incorrect takeover attempt. But yes, I see people attempt it all the same. [13:25] We tend to view those fields independently of one another [13:25] Breaks / Replace is actually the recommended way [13:26] I've been considering a dh_gencontrol extention to add higher level rules like "Pseudopackage" and "Takeover" or whatever, and then it can translate to the correct bits to pass to dpkg-gencontrol. [13:26] Breaks/Replaces is how you take over files. Not packages. [13:26] Conflicts/Replaces has a very specific meaning in policy. [13:26] COnflicts should basically only ever be used bi-directionally [13:26] See https://wiki.debian.org/PackageTransition [13:27] infinity: 7.6.1 specifically says Breaks + Replaces. [13:28] juliank: 7.6.1 is file overwriting. [13:28] juliank: 7.6.2 is package removal. [13:28] juliank: 7.6.2, while poorly written, tells you that Breaks+Conflicts = takeover. [13:28] But that's with provides :) [13:28] Err. [13:28] Replaces+Conflicts. [13:29] juliank: Only with provides "if they're a virtual package". [13:29] juliank: Like I said, it's poorly-written. [13:29] juliank: And has lead to that wiki being wrong. [13:29] juliank, infinity fwiw (and I only read bits of the discussion). I think we should break apt-get upgrade in apt 2.0 maybe add a compat option or something but I think its time to reconsider that for apt-get as well (to behave like apt upgrade) [13:29] Which explains why I see people doing the wrong thing. [13:30] infinity: Wrong is a strong word. Heck if you do Breaks/Replaces with a completely empty package, dpkg would remove it itself. [13:31] Going with Conflicts+Replaces does not have any real effect compared to breaks replaces, it just imposes a stronger ordering [13:31] and the ordering is irrelevant due to the replaces. [13:32] Except that it also has semantic meaning. [13:32] And has done so for as long as I've been a DD. And longer. [13:32] Policy should probably be changed to state that for Breaks too. [13:32] From APT's perspective, there certainly is no different, and Breaks + Replaces is preferred. [13:32] But okay, if we ignore that, because people use Breaks to mean the same thing now, then fine, a uni-directional Breaks+Replaces *or* Conflicts+Replaces should be allowed for package takeovers in a non-dist-upgrade case. :P [13:34] When Breaks was implemented, the rule of thumb we always gave people was "if it should be versioned, it should be Breaks, if it should be unversioned, it should be Conflicts", and that rule stood up pretty well to scrutiny. [13:34] mvo: That's why I proposed versioned interfaces, so people can write scripts and specify APT_COMPAT=0 if they need compatibility. [13:34] juliank: +1 [13:34] And also followed the 7.6.1 and 7.6.2 takeover bits, since file overwrites should be versioned, forcing packages off should not be. [13:35] My personal opinion is that we should remove the semantics from 7.6.2, and introduce an explicit Obsoletes field. [13:35] juliank: So, I'd also be entirely fine with removing *all* the pairings. [13:35] I also like the explicit nature of obsoletes [13:36] Breaks+Replaces = Overwrites, Conflicts+Replaces = Obsoletes, P/C/R = Virtual. [13:36] infinity: Well, OK, the recommended approach is to have a transitional package anyway, as APT might screw up otherwise, so it's not like you're supposed to even do package transitions like in 7.6.2 [13:36] The fact that they confuse a small group of seasoned DDs isn't comforting. [13:37] The basic rule is: Always introduce a transitional package, and add versioned breaks/replaces/provides. [13:37] juliank: For violent ABI transitions, we never do transitional packages (intentionally). [13:37] juliank: ie: libfoo1v5 -> libfoo1. [13:37] yeah, that's a special case :D [13:37] It's the most common "total takeover" case in the archive. [13:38] By far. [13:38] And it's one I keep fixing so update-manager will upgrade. :P [13:38] Interesting [13:38] And I just noticed the other day that "apt upgrade" hates it regardless of how I write it. [13:38] Because it refuses all removals, as you say. [13:39] I don't think it's easy to make upgrade do that, though. [13:39] We special-cased that class of removals in update-manager ages ago. [13:39] It only uses a very dumb solver. [13:39] AFAIUI [13:39] update-manager's not super bright either. [13:39] The solver that handles removals is not even run [13:39] (no offense to the author) [13:39] I think [13:39] But no, I can remove a package during upgrade manually, so hmm [13:40] Not sure when that happens though [13:41] Anyhow, it's not a huge complaint for right this moment, but I feel like update-manager gets it "right" (modulo arguments about C/R versus B/R, where it only checks the former), and it would be lovely if 'apt upgrade' (and 'apt-get upgrade' when we decide to normalise) could follow suit. [13:41] Would be even better if there was one solver to rule them all, and update-manager just called into apt.doit. [13:42] Since I suspect packagekit upgrades are entirely different from apt, apt-get, and u-m. [13:42] Heh, even APT has two "solvers" :D [13:42] And I've not even looked at that. [13:42] packagekit calculates the upgrade and applies them during reboot... [13:42] or rather during boot [13:42] Unless somebody patched that out :D [13:42] Sure, I meant I haven't looked at how it calculates. [13:42] "Weird", probably [13:42] Seems like a fair bet. [13:43] I'd like to have a world where whichever silly button I press that says "upgrade", the result is the same. [13:43] But I may never get that world. [13:43] And, to be fair, I personally just use apt-get dist-upgrade. [13:44] But when I notice u-m pop up with "OMG PARTIAL UPGRADE", I go fix that for others before I ignore it for myself. :P [13:44] I strangely enough mostly use just upgrade and forget to dist-upgrade [13:45] What I never understood is why gnome-software added another package mgmt abstraction layer over packagekit [13:45] Anyhow, I think I'm going to nap. And I'll bring this up again later. You've given me some differing perspctive to chew on. [13:46] And maybe the real conversation (well, the one about control fields) needs to invole guillem and some booze. [13:46] I'm trying since 2 years or so to get the Important field standardized. [13:46] Cause I think whatever misguided reasons we had for using clever pairs to mean weird things is probably long past. [13:46] Things move slowly when you need guillem to be part of it. [13:47] I fact, if we didn't need to have backward compat with old archives, I'd be willing to argue for a future where having any of those pairs is a bug. :P [13:47] I think nthykier wanted to get rid of the pairs too [13:47] juliank: I somehow manage to work at a reasonable pace with guillem. But step one is agreeing that this is a real problem that needs to be addressed. [13:47] and have stuff just imply Replaces or something [13:48] Well, "Replaces" would disappear if you had "overwrites" and "obsoletes", since those are the two uses for replaces. [13:48] Stuff on my guillem list: Important field, Package-ID field, deltas. And I think someone else. [13:48] (ignoring virtuals) [13:48] s/someone/something/ [13:49] Ah, frontend lock is also on that list [13:49] And P/C/R could become Virtual: and you've killed the last user of Replaces. [13:49] Then Conflicts really means "these two can't coexist evar" and Breaks means "it breaks it at these versions, please do something to resolve that", and everyone's happy that they don't have extra weird meanings. [13:50] I'd just generalize apt's model. [13:50] Ironically, once you reduced that map, you could remove Breaks and just use versioned Conflicts to do the same thing internally, but I don't think anyone would appreciate that. :) [13:50] It does not care about any special pairs. [13:51] Conflicts = not unpacked at same time [13:51] Breaks = not configured at same time [13:51] Oh, right. Fair. [13:51] Replaces = can replace files from other package [13:51] Obsolete = replaces other package [13:51] I think Conflicts+Provides would still be OK [13:52] Though I don't mind Virtual or Exclusive-Provides :D [13:53] We always (these days) use Replaces with Breaks to make sure we get the ordering right (so you don't replace a file out of existence), which is why I was arguing for "Overwrites" == current Breaks/Replaces, and just ditch Replaces. [13:53] Or, one could make Replaces imply Breaks. Either works. [13:53] I think versioned Replaces should imply Breaks [13:53] * infinity nods. [13:53] There was some discussion on this, but I'm not sure if ML or IRC in #debian-dpkg [13:53] Unversioned replaces shouldn't happen except in the P/C/R or C/R cases, though. [13:54] C/R would go away with Obsolete. [13:54] So P/C/R is the only one left. [13:54] P/C/R could just be Provides/Conflicts, though [13:54] Unversioned replaces without a special pairing is very much a package bug. [13:54] from a solver and ordering standpoint, the replaces is irrelevant there. [13:55] And I wouldn't actually lose sleep over dpkg telling you that in very angry terms. [13:55] juliank: Okay, I'm going to go try to get some sleep. I'll definitely bring this up again. I think we're more or less on the same page, modulo a formal spec. [13:56] juliank: And I'm happy to help guillem see the light, when we've agreed on the shape of the bulb. [13:56] Well, gn then. [13:56] I just want to add one thing [13:56] We don't actually use replaces in apt AFAICT [13:56] Sure, we parse them. But I don't see them being used anywhere. [13:56] Well, there's no real need to do so in a frontend. [13:56] That's dpkg's problem. [13:57] For the obsoletes case [13:57] We just decide replacements solely on conflicts/breaks [13:57] Okay, that sounds like maybe a longstanding bug in either apt or policy. :) [13:57] (which was covered for years by apt being a backend to smarter frontends) [13:58] (and by nerds just not caring) [13:59] I think it slightly influences scores. [13:59] Ah no, the default score for replaces is 0 [14:00] * infinity runs away before he gets sucked back in. [14:00] :D [14:00] * juliank writes a spec if he gets bored [14:17] Hi, I am using Ubuntu 18.04. When I run firefox with firejail I get "page not found" ...Any ideas? [14:32] mk-sbuild on trusty gives me an error about 99check missing. any idea what the issue is here? [14:32] wxl: Well. I guess it cannot execute /etc/schroot/setup.d/99check, but that sounds more like /bin/sh missing. [14:33] or it's a symlnik [14:33] I mean, the list of files is not hardcoded, so 99check must exist [14:34] Hence, it's either a broken symlink or /bin/sh does not exist, I'd say [14:34] juliank: i assume you mean /bin/sh within the schroot. it does exist [14:35] re: 99check, it's a symlink to 00check which does not exist [14:35] Well, on the host. 99check should be on the host [14:35] Well, there you got your issue [14:35] Do you have schroot installed? [14:35] yeah [14:35] let me try reinstalling [14:35] I guess you might have to save config files, purge and reinstall [14:36] 00check is a conffile, so it probably saved that you removed it or something :D [14:36] weird. i can't imagine i would have removed it [14:53] juliank: that did it. weird. [14:54] andyrock: I don't feel like my question in bug 1716359 was really answered. [14:54] bug 1716359 in unity-control-center (Ubuntu Xenial) "Unplugging headset with audio panel open mutes internal mic" [Undecided,Incomplete] https://launchpad.net/bugs/1716359 [15:54] bdmurray, could you maybe try to rephrase it then? it seems they did quite some testing and think they answered it so we are in a locked situation [15:56] rbasak: on the change from apt to apt-get [15:57] rbasak: does apt-get have a stable CLI Interface - or is it just not detecting/complaining that? [16:07] cpaelzer: apt-get's CLI is generally considered stable AIUI. Too many scripts in the wild use it to make any changes to it. [16:07] ok, I was juts wondering [16:08] but yeah so it is stable-by-mass-reliance [16:08] cpaelzer: my understanding is that this is the purpose of the warning: to encourage automation to use apt-get rather than apt. [16:08] But it's interesting that you ask the question. [16:08] juliank: ^ [16:09] Maybe the message needs some adjusting? :) [16:09] cpaelzer: apt-get is too stable :D [16:09] same for apt-cache [16:10] Let's add a line to the output -> hey you broke my script [16:10] juliank: I wonder if the message should say explicitly "please use apt-get from scripts instead"? [16:11] Otherwise we might get a trend of scripts using apt. Because apt is the new apt-get. [16:11] Well. It warns you not to do that. [16:11] list is not available elsewhere, though [16:12] We need something better. [16:12] "WARNING: apt does not have a stable CLI interface. Use with caution in scripts." -> "WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Use apt-get instead." [16:13] Currently apt-* does not change at all, and all new stuff goes into apt [16:13] rbasak: But that's wrong. It might also be apt-cache, or apt-mark (eventually) [16:13] Good point. [16:14] I want you to be able to write a script, say export APT_COMPAT=0 and get a stable APT behavior [16:14] and later APT_COMPAT=1, and so on [16:15] I think we should also refactor the manual pages. We should have apt-install, apt-upgrade, and so on :) [16:15] So you can type man apt install :D [16:15] And document differences between apt-* and apt [16:16] and I guess apt list should pipe into pager [16:17] and search and show too [16:17] Then we get a default where apt defaults to latest level, warns if you do not have a terminal as stdout, but can be used in scripts if you specify an APT_COMPAT value [16:18]