[00:44] xnox: i'll sort it with powersj tmrw :) === wgrant__ is now known as wgrant === nOOb__ is now known as nOOb === nOOb is now known as LargePrime === JanC_ is now known as JanC === elky is now known as el [09:09] Hi, software-properties-gtk offers this option: When there are security updates: *[Download and install immediately]/[Display immediately] [09:09] The default is causing issues in many installations here and for many reasons... For example, it's trying to access some Ubuntu repository via ipv6, and it hangs due to ISP or Ubuntu mirror issues, leaving apt locked even with the net problem gets resolved, with no visible indication at all, completely blocking the user from using apt, software centers etc. [09:09] I'd like to file a bug report to make a case in favour of switching the default to [Display immediately]. My question is, should I file this in Debian or in Ubuntu? (or it's a lost case anyway because it was already discussed somewhere?) [09:12] alkisg: "I want to change the default because there's a bug" isn't a reason to change the default. [09:13] alkisg: The correct answer here is to determine why it's hanging. [09:13] infinity, I did mention one possible cause [09:13] And the solution there is to fix the ISP and apt resuming after failures [09:13] We might be able to fix apt, but not the ISP [09:13] alkisg: We can still fail gracefully if there's a network issue. [09:14] The solution isn't "turn off everyone's updates becuase some people have crap networks". [09:14] Of course not. I'm only proposing going back to the default of 1 year ago [09:14] The default changed for a reason. [09:14] Not to turn off updates, but to immediately prompt, as it was so far [09:14] Right, and I'm giving a reason for the opposite [09:15] That apt isn't ready for that [09:15] When the apt codebase matures enough, I would completely agree... [09:15] Please file apt bugs for the behaviour you're seeing? [09:15] The apt codebase is plenty mature. [09:15] What you're seeing is called a "bug". [09:15] Another example. When I log in, I want to see the unattended upgrades progress [09:16] Whose bug is it that I can't see it? Apt or unattended upgrades? [09:16] That sounds more like a feature request than a bug. [09:16] I'm not even sure what you mean by "see its progress". [09:16] Apt downloading and installing security updates... I can't see or stop it [09:16] Nope. It's unattended. [09:17] That's more or less the meaning of that adjective. [09:18] OK anyway I could make my case here (it's against unattended upgrades, not against apt), but I think it'll be best if I list all possible issues in a bug report, [09:18] would that be against debian, or against ubuntu? [09:18] Who is the policy maker there? [09:19] Your request to be able to have some window into what's going on is an upstream feature request (and one likely to be denied, I'd expect, since that's entirely not the point of the package -- if you want to see and control your updates in progress, you don't want unattended-upgrades) [09:19] The request to change the default option is an Ubuntu request, as it's a policy request, but I can flat out tell you that will be denied. [09:19] The bug about apt (or perhaps a frontend) hanging on for dear life when the network sucks is an upstream bug, but you can file it in both places if you want. [09:20] I want to be able to use apt and not have it blocked with no visible indication in a default ubuntu install; I don't think I'm being unreasonable. [09:20] "not have it blocked with no visible indication"? [09:21] When you try to use apt while it's locked, it tells you pretty conclusively that it's locked. [09:21] If that lock is being held by something that should have exited, that's a bug, yes. Please file it. [09:21] But there's no hidden "apt silently fails" behaviour here. [09:22] Suppose I have a laptop. And on some particular boot I'm using some form of connection that costs per GB. Shouldn't I be able to pause the unattended updates at that point? [09:23] (Btw, is there a "proper" way to stop unattended upgrades when apt fails and hangs forever? I'm using pkill currently, as apt-daily stop doesn't stop it) [09:23] By disabling the automatic update option? Yes. [09:24] Giving users a kill button to murder apt mid-upgrade is asking them to shoot themselves in the foot, hard. [09:24] Friendly interfaces don't tend to encourage users to break things. [09:25] An example that there are at least some persons sharing my opinion, is windows implementation of unattended updates, which does give an icon and one such option to block/postpone them [09:25] Windows doesn't let you stop an update halfway through, which is what you asked for. [09:25] HCI is a big topic, and there are multiple views on interface design... [09:26] It lets you postpone installation, which isn't the same as postponing the download, so doesn't much relate to your connnection scenario. [09:26] I see the icon, I click it, it brings up the options, it shows a bar "downloading", and I can stop it [09:26] If unattended-upgrades was able to do that, I wouldn't have any usage issues [09:27] Ahh, maybe mine downloads too quickly to ever see that bit. :P [09:27] :D [09:28] Yes, it's plausible one could write a nice little UI widget for the downloading part of unattended-upgrades. Pretty big feature request, as it currently has no GUI bits at all, but doable. [09:28] But it very much needs to be sure it's only interrupting the download, as interrupting the next part of an apt run is disastrous. [09:29] I fully agree that the "pause/stop/postpone" button should only be enabled when apt downloads and not when apt installs [09:29] And it's apt downloading that is causing most of the issues [09:29] Not apt installing... [09:29] Sure. Like I said, big feature request, but feel free to file it. [09:29] And some form of `service unattended-upgrades stop` that would stop when apt downloads [09:30] And not when it installs [09:30] Might be able to tie it into something that already has GUI bits, like update-notifier. [09:30] So that I would be able to use it in server installs too [09:30] You'll probably find less sympathy about the issue for servers. [09:31] It's not a "common" use-case for servers to randomly swap between metered and unmetered connections. [09:31] But, YMMV, I won't stop you from filing wishlist bugs. [09:31] E.g. I boot a server, try to run `apt dist-upgrade` and leave, but I have to wait for 10 minutes for unattended-upgrades to run before I can run my own apt command [09:31] More importantly though, you should lay some blame and file some bugs about the hung processes. That's much more important. [09:32] infinity, thanks for all the input, so I should be filing ubuntu bugs, not debian bugs, right? [09:34] alkisg: File Debian bugs for code issues, Ubuntu bugs for policy issues, if you want to make sure the right people are seeing them. [09:34] alkisg: "apt hangs when the network sucks" isn't a policy issue. [09:35] Gotcha. Thanks again. :) [09:47] tyhicks: hi there, did ext4 encryption with fscrypt make it in time for 17.10, or will it have to wait for 18.04? [09:48] tyhicks: asking because it was brought up on this (false) kernel bug where i participated (https://bugzilla.kernel.org/show_bug.cgi?id=197045) where ted tso suggested i "stop using ecryptfs, switch to ext4 encryption" :) [09:48] bugzilla.kernel.org bug 197045 in ext4 "renameat2 rename_noreplace" [Normal,Resolved: invalid] [12:10] fabbione: please could you do the SRU verification for the valgrind upload? [12:10] doko: i am totally lost on those new processes, how do I do that? [12:12] fabbione: read the instructions ;p [12:16] doko: i'll try. those machines are hooked up on a CI pipeline. it's a pain to do manual stuff [12:16] doko: not today tho. [12:17] fabbione: ok, just test the uploaded binaries [12:19] doko: ok, testing now. this meeting is too boring anyway [12:23] doko: tested, but i don't know the Lp mumbojumbo paperwork to validate the SRU. that you can do :P [12:46] hi everyone [12:46] who's responsible for patches.ubuntu.com? [12:47] at least one packages there diffs against a wrong Debian package version (not currently part of any release) [12:47] and I guess that also is the reason ubuntudiff.debian.net and deriv.debian.net do the same thing [12:48] doko: tested also on i386. it's all good Sir of the toolchains [12:51] andrewsh: Examples are more helpful than abstract statements. [12:52] andrewsh: But you might also be misunderstanding what patches.ubuntu.com is meant to represent. It's not showing the Ubuntu delta to "current Debian", as that can often be enormous, depending on upstream version skew, it's showing the delta to the base version that package was forked from. [12:53] andrewsh: Which may, indeed, be a version no longer published anywhere except snapshot.debian.net. [12:53] andrewsh: Because that 3-line delta is far more interesting than wading through 3MB of goop. [13:14] infinity: wpa [13:15] https://patches.ubuntu.com/w/wpa/ [13:15] the patch here is from some random version not even in oldstable [13:16] and its not useful at all, precisely because of "3MB of goop" in it [13:16] not a couple of lines of diff [13:24] is it possible to retarget it to 2:2.4-something Debian ships? [13:24] andrewsh: That would be because Ubuntu doesn't have an epoch and Debian does. [13:24] I mean, the best thing would be to ask Marc to rebase Ubuntu version to the Debian one [13:24] but it would be very helpful if the diff was useful [13:25] mdeslaur: ^ [13:25] mdeslaur: Any plans to adopt the Debian epoch in a future wpa merge? [13:26] andrewsh, infinity: sure, next merge will have it [13:26] andrewsh: Short answer though, is no, it's not trivial to make a computer guess what was obvious to a human there. [13:27] so there isn't a way to override the automatic guess, is that correct? [13:28] Nope, but mdeslaur rebasing with the epoch will solve this particular issue. [13:30] Arguably, we shouldn't have tried to produce a delta at all, since I can't fathom how it even decided to pick something as a common base when there wasn't one. [13:30] So, I'm down with saying that it's a bug that there was a patch. :) [13:31] Producing a better patch runs into deminishing returns of teaching a very generic system to be specifically clever in the face of oddball things that rarely happen. [13:35] I think even a diff against the latest package for the same upstream version would be better than no diff at all [14:20] tsimonq2: again a new debhelper in unstable [14:24] estan: hi - the kernel bits have been in place for a while but the userspace project didn't make it into 17.10 [14:30] tsimonq2: If you have a debhelper merge already prepped, please point me to it, but don't ask anyone to sponsor it for you, I need to do dpkg and debhelper in the same publisher cycle (or in a bootstrap archive) to avoid the dep/breaks loop. [14:30] tsimonq2: (And I need to sleep before that happens) [14:59] infinity, I can upload them [15:01] oops, just wait for tsimonq2, I don't know where doko has dpkg [15:01] we can do a silo upload === Eleventh_Doctor is now known as Pharaoh_Atem [15:33] tyhicks: alright. do you think they will for 18.04? [15:35] estan: the userspace package will certainly be in the archive - I'm not sure if it'll be officially supported the way that eCryptfs has been in the past [15:36] estan: rolling out a new way to do user data encryption just before the LTS is risky === mnepton is now known as mneptok [17:01] slangasek: i know you're quite busy, so consider this asynchronous and not urgent resolve immediately. We ship debsign and gpg2 in the git-ubuntu snap so that we can sign uploads after building them (if --sign is passed). However, since we are shipping gpg2 and the host might be xenial with gpg1, there is a mismatch of configs (and gpg2 needs a gpg-agent running from gpg2) and we really don't want to [17:02] modify anything in the user's ~/.gnupg if we can avoid it. What do you recommend we do? I'm trying to consider the various combos, xenial host, artful host, etc. Should we be installing and invoking gpg1 ? Will that work with a gpg2 as gpg setup like in artful? [17:07] tyhicks: yes, understandable. thanks for the info. [17:11] doko, infinity: ack, but I won't have access to my merge for the next 5 hours... if you don't want to wait, feel free to steal, but I would like to steal back next time ;) [17:14] I didn't set myself away by accident, and I can't scroll on mobile, so I will grep for other pings later [17:26] bdmurray: re: https://code.launchpad.net/~james-page/merge-o-matic/ubuntu-opnestack/+merge/332297 looks merged, does it also need to be deployed somehow? [17:33] powersj: I'm pretty sure I did that bit too [17:34] not seeing anything at https://merges.ubuntu.com/ for openstack [17:38] I see it on the server, digging [17:40] powersj: sorted it was a missing symlink [17:41] bdmurray: thanks! for future reference should that have been in the merge proposal? [17:44] powersj: No that folder doesn't exist in the code. [17:44] ok :) [17:44] thanks again [18:09] Laney: did you see my question from yesterday? === JanC_ is now known as JanC [19:15] hi, can I get sponsorship for #1725110, an SRU request for syncing with Debian testing? [19:15] LP #1725110 [19:15] Launchpad bug 1725110 in config-package-dev (Ubuntu Artful) "config-package-dev 5.2 broke transforms" [Undecided,Confirmed] https://launchpad.net/bugs/1725110 [19:15] (or for backporting the patch, but if you sync with Debian testing, you get the patch, autopkgtests, and no other functional changes) [19:29] rbasak, arges I see you both are on the SRU team rotation for today, and there's an item roaksoax would like to be pushed to -proposed - https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1711760 (https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=resolvconf). Would either of you handle this request? [19:29] Launchpad bug 1711760 in resolvconf (Ubuntu Xenial) "[2.3] resolv.conf is not set (during commissioning or testing)" [Medium,Confirmed] [19:42] elbrus: don't think so? [19:44] elbrus: wait, something about a britney commit - did I forget to reply? [20:07] Laney: I didn't notice a reply, yes, about britney [20:08] question was: Laney: can you confirm that https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=fe627aa was indeed only to catch NEW packages that FTBFS? [20:10] elbrus: IIRC it's for packages that aren't in testing [20:11] Laney: thanks, that means I have to check the code (if I am doing the right thing) [20:12] I think it was something like an FTBFSed package with no binaries anywhere that was getting tests triggered [20:12] in https://github.com/Debian/britney2/tree/autopkgtest [20:12] which doesn't usually work out so well [20:12] * elbrus is preparing Debian to also do autopkgtest processing in britney [20:13] ya, happy to see this work progressing, cool stuff! [20:14] just a heads up, I would love to have the Debian britney be more in sync with Ubuntu [20:14] nacc: I'm going to refer that question to xnox, who has more context on the state of play with gnupg compatibility across releases. Especially where private keys are concerned, there are differences in the .gnupg directory layout between old and new, so you definitely need to be careful here [20:14] but I am no release manager... [20:15] so I try to keep things working for the Ubuntu setup while implementing it to the desires of the Debian RT [20:15] hope you appreciate that as well [20:15] otherwise I can drop some logic [20:26] Laney: by the way, all comments on my code in that branch are welcome [20:31] slangasek: thank you [20:31] xnox: let me know if you need more context [20:33] slangasek: and completely agree re: private keys, that's what I'm trying to determine. It does look like once you do the upgrade and if gpg2 does any modifications to the private keys, they are not visible to gpg1. However, we don't actually expose gpg2 to the user as an application (although as classic, then can snap run --shell and then find the binary in the snap and run it if they chose to). [20:34] nacc: so, copying ~/.gnupg into private space, setting GNUPGHOME to point to the copy, and discarding it, on each relevant invocation of git ubuntu, would be possible [20:34] nacc: is this used for signing tags? [20:35] ah, no, for signing builds [20:35] so [20:35] slangasek: yeah that's a good idea [20:35] why would I want git ubuntu to do my build? [20:35] slangasek: right, just siging the builds [20:35] *signing the builds [20:35] slangasek: because we can get the orig tarballs from pristine-tar for you (or from LP) [20:35] slangasek: and we can use a LXD cotainer to do the build in [20:35] slangasek: it's just a wrapper for someone who doesn't want to setup sbuild [20:35] ok, the first bit is interesting to me, the second is less interesting [20:36] origtargz can get be the tarball. :3 [20:36] could we not just invoke the system gpg? [20:36] instead of bundling [20:36] slangasek: hrm, maybe i can do that with the debsign -p argument [20:36] nacc: well, or even just invoking the system debsign :) [20:36] slangasek: right, but our goal is to not require the user to install deps [20:36] shrug [20:36] slangasek: in that, they shouldn't really need to :) [20:37] slangasek: yeah, i understand not your concern :) [20:37] or i wish it was easier for my snap to depend on debs [20:37] I don't think it's a goal that people run git-ubuntu in an environment they haven't already configured for Ubuntu development [20:37] slangasek: not for experienced developers, no. But for a drive-by contributor, per rbasak, I think it is [20:37] nacc: I think the other way around is more important: having debs depends on snaps [20:37] DEBEMAIL, DEBFULLNAME, etc.; there's setup involved [20:38] and I disagree that git-ubuntu should try to bite all of this off in one go before we even have adoption of the tool [20:38] slangasek: and no one has to use `git ubuntu build` [20:39] Unit193: didn't know about that command, thanks! [20:39] right, but re-synthesizing the tarballs from git without requiring a separate download is one of the killer features for me, so I *do* want that; I just also want it to integrate with my underlying dev environment instead of bundling [20:39] (bundling incompatibly, that is) [20:39] * tsimonq2 disagrees that development tools should hard depend on snaps, I don't have snapd installed on my system and I don't think I ever will unless forced [20:39] nacc: It's a very nice version of "just get me the tar!" [20:39] slangasek: yes, that will be exposed as `git ubuntu export-orig`, i thinkn [20:39] slangasek: which parallels gbp [20:40] slangasek: as i agree, that on its own is very useful :) [20:40] slangasek: so you could just use clone, export-orig and do whatever you do now basically (I think) [20:41] so if you don't have debsign on the system, you don't have devscripts installed. If you don't have devscripts installed, you don't have dch. [20:41] QED git-ubuntu w/o devscripts is not useful [20:41] slangasek: right, which is why we have devscripts in the snap [20:41] slangasek: but i see what you are saying [20:42] oh dear God no [20:42] there is *no* dependency system currently [20:42] slangasek: we don't expose any of devscripts to the user [20:42] (as binaries) [20:42] This is sounding more and more like a "docker to fasttrack dev env setup", which I didn't think snap was made for. [20:43] slangasek: if you would really like me to pare back to only shipping tooling that will just mostly not work in the general case, I can do that :) but I'd like that to be discussed with rbasak [20:45] jbicha: you might be right, but that wouldn't solve my issues [20:46] nacc: You made slangasek fall over. [20:46] Unit193: :) [20:47] As far as packages that depend on snaps, that seems very unideal. [20:47] ragequit, maybe? :) [20:47] nacc: like it might be nice if Firefox would be a snap, I think we've wanted that for a while, but how do you upgrade users to it? [20:47] jbicha: oh i know [20:47] Please oh please can we package it as a deb already? [20:47] (git ubuntu) [20:47] tsimonq2: it's not easy [20:48] tsimonq2: because of versioned dependencies [20:48] tsimonq2: we don't want the build to be different on xenial and artful when building for xenial, e.g. [20:48] (or the import, more importantly) [20:49] nacc: Why are the dependencies versioned? [20:49] tsimonq2: i mean we need specific versions [20:49] tsimonq2: because bugs exist. [20:49] Oh [20:49] nacc: Where's the code? :P [20:50] https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer/+ref/master [20:50] tsimonq2: --^ [20:50] tsimonq2: probably the biggest one is gbp [20:50] tsimonq2: we have talked about doing a bunch of backports [20:50] tsimonq2: but it's not a priority right now [20:51] nacc: Is code doing those backports and then prototype deb packaging welcome? [20:51] tsimonq2: yep [20:52] tsimonq2: and we'll hopefully have some tests from rbasak that can be dep8'd [20:52] we do have some unit tests already, in the code [20:52] and a very simple integration test (taht's slow) that tries to clone something, build it, and reimport it (without pushing it) [20:52] Excellent. [20:53] nacc: I just think it's *extremely* ironic that in order to use this set of tooling meant to develop *debs* you need to install a *snap*... [20:53] Maybe that's just me though. [20:53] tsimonq2: i think it was the fastest way for us to get from A to B on every distro at the same time [20:53] No. [20:54] nacc: Except just like every other development tool we use (I think), am I wrong to expect people to use either Debian, Ubuntu, or a derivative? [20:54] nacc: I don't personally care if there's a snap, what's killing me is that there's no deb. [20:55] tsimonq2: dunno, you don't have to with the way the snap is written :) [20:55] tsimonq2: right, but having both means twice as much maintenance burden [20:55] currenntly owned by me, basically :) [20:55] tsimonq2: the other thing that will be hard with the deb is python compatibility [20:55] for older releases [20:55] nacc: But I thought the maintenance burden with snaps was "supposed to be" less? [20:55] tsimonq2: right it's low for the snap [20:55] nacc: Oh, I'm not worried about that. [20:56] tsimonq2: but if you add a deb, then i'm presumably going to own that too [20:56] tsimonq2: in 3 releases [20:56] (and it's presumably going to need to be in main) [20:56] tsimonq2: the snap lets me move a lot of faster than debs ever could [20:57] nacc: Why would it need to be in main? :) [20:57] tsimonq2: i'm not trying to wage political war on the topic, i have hated getting the snap to work, tbh. But now that it does, it's really useful to have. [20:57] tsimonq2: presumably it'd be a 'supported' thing if it ever becomse the primary development tool [20:58] tsimonq2: perhaps not, I don't know [20:59] nacc: And my thing is that I don't like snaps. I don't want snapd installed because I have major performance concerns about it. If git ubuntu ever becomes the primary development tool, it should be available in the packaging format we're trying to build it on... [20:59] nacc: Yes there's fast turnaround time, but that could also be because nobody invested the time to make deb building automatic as well. [20:59] (for this particular case) [21:00] tsimonq2: building the deb doesn't change at least 7 day turnnaround time [21:00] tsimonq2: ulness you mean a PPA [21:00] tsimonq2: i think i disagree with you because git-ubuntu is meta to the packaging format it generates [21:01] tsimonq2: so it doesn't matter that it's not a deb, that's a philosophical thing to get over (or not) [21:02] wouldn't an LXC/LXD build bundle (of standard .deb packages) for the fixed-version build tooling be a better way to integrate with regular dev workflow? [21:02] TJ-: that's essentially what the snap is [21:02] TJ-: except we don't expose the individual commands [21:03] levelset: I'm not trying to solve or replace everyone's tools [21:03] nacc: I get that it might be an extra turnaround time (that I'm willing to invest, by the way, I'm not giving *you* things to do) but you'll probably get a more *interested* audience. If you want to develop deb packages, you're likely running either Ubuntu or Debian. [21:04] my theory is that experienced developers need nothing more than `git ubuntu {clone, export-orig, push}` where the latter two don't yet exist [21:04] drive-by developers want `git ubuntu {clone, build, build-source, submit}` and git-cherry-pick so they can just get a upstream change, let us convert it to a quilt patch and get it to a developer than can sponsor it [21:04] there are two very distinct audiences [21:06] And? In order to build it to verify it works, you need pbuilder or sbuild. Having that in a snap doesn't really sound feasible... [21:06] tsimonq2: no, you don't. [21:06] nacc: Or something like that. [21:06] tsimonq2: we use the host's lxd to spawn a container and do the build there. We don't ship lxd (it's our only external dependency) [21:08] nacc: But (correct me if I'm wrong) LXD isn't the most efficient way to do that. [21:08] tsimonq2: it's pretty fast, tbh [21:08] tsimonq2: i don't know about 'most efficient' or not, but I also don't care about that (yet) [21:08] nacc: Regardless, my point is that it should be a deb, we could talk about builders all day long :) [21:09] nacc: I'm willing to put that work in if it will be accepted. [21:09] tsimonq2: I think we just disagree about "should" :) [21:09] tsimonq2: yep, I would take it [21:09] tsimonq2: as long as the deb's results always match the snaps [21:09] snap's [21:09] if there is a chance of a deb's import being different, it can't go in the archive [21:09] that's relatively important [21:10] nacc: Which, with proper testing (both manual and automated), should be trivial, as long as the initial work is done. [21:10] tsimonq2: *with* backports enabled, possibly [21:10] tsimonq2: which the archive does't, afaik [21:10] nacc: Possibly, or the tools could just adapt given which tools are available to it. [21:11] tsimonq2: adapt how? we assert hash stability, idempotency and reproducibility [21:11] tsimonq2: if the deb won't do that, i really can't encourage its use [21:12] nacc: I'll have to look more into the code, but are the features that you are using from underlying tools brand new? [21:12] tsimonq2: the gbp ones are relatively new (component tarball support, we don't yet use export-orig, but we might rather than spinning our own) [21:12] tsimonq2: i'd need to check on the others for you [21:13] tsimonq2: the other point about all of this is, if you aren't going to use git-ubuntu for whatever reason, you can just use git [21:13] tsimonq2: and do your normal stuff and dput like usual [21:14] nacc: True. I'll have to think on it more and look into the tooling, but I'm thinking this might be possible. [21:14] tsimonq2: cool [21:15] nacc: Also, think about it, are people more likely to Just Use Git or install snapd then snap install git-ubuntu-or-something and THEN use the tools they've never used before and learn new syntax? [21:15] tsimonq2: snapd is installed by default [21:15] iirc [21:16] Since I can't dput, I could adapt the bzr workflow for merge proposals (even how nasty it was. Do changes, clone the bzr repo, rsync -avhP --delete-after --exclude *.bzr ./package-2.4.1/ ./package/ debcommit and push) I personally like gbp+dput, though. [21:16] nacc: Not on all flavors. ;) [21:16] tsimonq2: Installed by default, yes. Only Lubuntu doesn't, but that's because recommends are off and that tends to break stuff anyway™ [21:16] tsimonq2: :) [21:17] tsimonq2: there are significant gotchas to using git directly, btw [21:17] reverse-depends -r artful snapd [21:18] Unit193: all desktop flavors do include snapd [21:18] jbicha: thanks, I hadn't looked at that yet [21:18] jbicha: You're pinging the wrong one. :) [21:19] tsimonq2: I think, to be completely honest, a drive-by contributor will do what they are told [21:19] tsimonq2: right now, they're told to use bzr (or that may be fixed now) [21:21] tsimonq2: also, use the tool and see what you think first. Maybe you'll like it, maybe you'll hate it, I don't know. We have reasonable reasons, IMO, for doing things the way we have, and I'm responsive on bugs when they get filed. I'm not sure we can replace (and like I said, we don't really intend to) every workflow. But we don't want to break anyone's. [21:21] nacc: depending on lxd is interesting since Debian still doesn't have lxd :( [21:21] jbicha: it's not a hard dependency [21:21] jbicha: in that it's flag-controlled [21:21] jbicha: also, lxd is a snap :) [21:22] Can't it use lxc? [21:23] nacc: I personally fixed the packaging guide to *not* use Bazaar. [21:23] tsimonq2: yeah, that's what I was recalling :) [21:23] tsimonq2: but think about how lonng that sat there [21:23] Unit193: not currently [21:23] nacc: Well now it's better. :P [21:23] Unit193: i suppose it could be taught, what we need in the lxc/lxd is not much [21:24] Unit193: i just personally never use lxc, and lxd is readily at hand [21:24] Unit193: would just need some code in gitubuntu/build.py [21:25] nacc: It's the reverse for me. :> [21:25] Unit193: :) [21:26] Unit193: feel free to file a bug, i think i can get that integrated without too much effort [21:26] Unit193: we basically are assumign you already have lxd setup on the host (we use the host binary), same would hold true for lxc [21:27] nacc: why don't you use the lxd snap? [21:27] jbicha: it wasn't available when i started adding lxd support [21:27] jbicha: i think the plann is to migrate to lxd and its interface, yeah [21:28] jbicha: but also, i was trying to avoid forcing current lxd-as-deb users to migrate to the lxd-as-snap (although perhaps they can both be isntalled at the same time? not sure) [21:29] I expect that would be insanely confusing [21:29] But again, I think so far out of everything I've tried, sbuild with /dev/shm is the fastest :) [21:30] I personally recommend that to anyone that I'm mentoring and they use it with little to no problems. [21:30] sarnold: :) [21:34] Unit193: as to your earlier point about docker-esque. Sort of accurate. As a snap, albeit classic, I did't want to have to wrap every call to every thing not in my code base with try/except with a useful error message and didn't want to pull every dep into our source. So our snap image is large and carries tools that most developers already have installed. As I said, we don't expose those as [21:34] applications in the snap, although they are exeuctable if you knonw the voodoo [21:35] tsimonq2: right, and I'm not standing in the way of you recommending that, or doing that yourself [21:36] tsimonq2: if you want, i'll put a blurb in the code / manpage saying "tsimonq2 says this is shite performance, don't use it if you care about that" :) [21:36] nacc: Go ahead XD [21:37] Everyone likes their own methods, just like I use pbuilder with eatmydata. [21:37] Unit193: agreed [21:37] \o/ [21:38] each subcommand is fairly independent of the other. So you can use just clone if you want, and do all your work with git and other tools (you might need to adjust the pristine-tar branches if you use that, but in general you're not going to be pushinng the pristine-tar data) [21:43] slangasek, nacc - if current .gnupg is keyring based (gpg1) either gpg1 or gpg2 can manipulate it; if gpg2 is used on the kerying based .gnupg directory, it is converted to keybox format (gpg2) and gpg2 will from then on ignore the keyring based keys that are still left in the .gnupg folder. [21:44] sladen, nacc - it is quite wrong for git-ubuntu to ship either gpg1 or gpg2, and it is wrong for it to touch .gnupg dir outside of the snap directly, because you don't know what's there, and you might not even be able to use any keys from there because one is using GPG keys on a smartcard / yubikey (quite common, given that yubikeys were given out for free at one of the last UDS) [21:44] unping sladen [21:45] xnox: ok, so it's best for me to just invoke the host gpg, got it [21:46] (and by me, i mean debsign) [21:46] xnox: thank you [21:46] nacc, by default, ubuntu desktop runs gpg agent (default is gnome-keyring, but can be kwallet, gpg-agent, etc) and you simply should be talking to the agent / invoking host gpg yeah. [21:47] xnox: the yubikeys that were given out where HOTP-only (not gpg capable). But yes, sensible people use smart cards :) [21:47] nacc, ideally yeah, debsign from the host. [21:47] tumbleweed, darn, i thought it was version 4 later. maybe it was just a canonical only sprint post-uds. [21:47] probably [21:47] xnox: right [21:49] i've been having key material on smartcards (yubikey) after Laney exported my private key to stdout at one of the sprints.... [21:49] :P [21:50] what a pal :) [21:51] heh [21:56] hah [22:04] juliank: can you add bionic to python-apt? thanks [22:05] Oh, yeah [22:05] But afterwards we should really get rid of this stuff [22:05] :D [22:05] It's just copy and sed these days [22:06] use distro-info-data ? [22:07] Well, we should probably move the additional data there [22:08] And Cdrom should be CD-ROM I guess [22:10] * tsimonq2 subtley pokes infinity to update the vim syntax highlighting for vim [22:11] Wow, that's redundant, I mean Bionic. :P [22:11] it's more of a metaphorical Cdrom anyway I guess! [22:14] jbicha: uploaded [22:19] 👍 [22:34] tsimonq2: oh also, we're goign to be relying on git-worktree being present, which, at least, isn't there on trusty [22:35] nacc: I don't personally care about trusty :) [22:35] tsimonq2: just was an fyi, there is probably a dependency on git and git fixes that I'm not explicitly testing for [22:36] nacc: Ok === giraffe is now known as Guest20101 [23:33] damnit, almost got there first [23:34] Could likelu punt ubuntucraze, dax. [23:34] (dear developer folks: someone with too much free time is currently mad at freenode. there may be some turbulance in IRC-land for a bit) [23:37] $~a ? [23:38] Unit193, dax: #ubuntu-desktop [23:38] Thanks. [23:39] Unit193, thank you [23:39] my push notifications to phone just went nuts =( [23:39] sarnold: Not identified. [23:39] Unit193: aha :) thanks <3 [23:39] Sure thing! [23:40] Unit193, #ubuntu-kernel [23:40] Jeez. [23:40] but not #upstart, because nobody cares..... [23:40] * xnox :`( [23:41] can we preemptively protect #ubuntu-discuss, if it hasn't been already? [23:42] Unit193, #canonical-sysadmin [23:42] Beat me to it [23:42] dax: can you help with #canonical-sysadmin as well? [23:42]