[00:45] <snkcld> when i run "sbuild -A -d xenial-amd64 bluez_5.37-0ubuntu8.dsc", i am getting an error at "renaming `/etc/apt/trusted.gpg' to `/etc/apt/trusted.gpg~' failed: Invalid argument", i tried stracing (following forks) but i can not seem to find the error... any clue why this is happening? the fact that its related to a file rename makes me think it might be a
[00:45] <snkcld> filesystem issue (im on btrfs), but im able to create files with a ~ just fine
[00:49] <nacc> snkcld: i wonder if /etc/apt/trusted.gpg maybe doesn't exist for some reason?
[00:50] <snkcld> on the it seems to exist on the host and in the chroot
[00:51] <nacc> snkcld: yeah, i meant in the schroot; ok
[00:53] <nacc> snkcld: sbuild-update --keygen is mentioned at https://wiki.ubuntu.com/SimpleSbuild
[00:54] <snkcld> ok let me run through those steps once more
[00:54] <nacc> snkcld: sure
[00:55] <nacc> pitti: if you're around, had a samba question for you (re: MR: #293440 and LP: #1604630)
[00:55] <ubottu> Launchpad bug 1604630 in samba (Ubuntu) "16.04 SAMBA missing winbind packages during install" [Undecided,New] https://launchpad.net/bugs/1604630
[00:56] <jbicha> pitti: or whoever, why does oslo-sphinx's 'Testsuite: autopkgtest-pkg-python' fail with 'SKIP no tests in this package'
[00:56] <jbicha> it also says autopkgtest: build not needed and doesn't look like it even installs the oslo-sphinx binaries
[00:59] <snkcld> nacc: same thing
[01:00] <nacc> snkcld: strange ...
[01:00] <snkcld> i entered the chroot, and was able to install e.g. vim just fine
[01:00] <snkcld> but that wouldnt invoke gpg anyway
[01:01] <snkcld> any idea what command might be running, which is invoking gpg, to have it rename trusted.gpg?
[01:02] <snkcld> OH, i think i am onto something: "mv: cannot move '/etc/apt/trusted.gpg' to a subdirectory of itself, '/etc/apt/trusted.gpg~'"
[01:03] <snkcld> it seems that trusted.gpg~ is seen as... a directory?
[01:03] <snkcld> though its a file, when i look at it
[01:06] <snkcld> eh, that may have actually been me invoking "mv" incorrectly, ignore that
[01:27] <snkcld> nacc: do you happen to be using btrfs or not?
[01:28] <snkcld> i noticed this, too, btw: "This does not work if /tmp is mounted under btrfs due to incompatibilities with aufs"
[01:28] <snkcld> fwiw: /tmp does not seem to be mounted as tmpfs
[06:01] <pitti> nacc: I have no clue about samba I'm afraid
[08:13] <jamespage> pitti, hey - would you have a little time to help me figure out why I managed to bloat out the ceph packages with debug symbols with my last upload?
[08:13] <jamespage> https://launchpad.net/ubuntu/+source/ceph/10.2.2-0ubuntu3/+build/10487267
[08:13] <jamespage> I thought that dropping the dh_strip overrides and the -dbg packages would be sufficient to kick in the builds based stripping
[08:13] <jamespage> but evidently not
[08:21] <infinity> dh_strip_nondeterminism <-- Did dh_strip get renamed in a recent debhelper?
[08:21] <infinity> pitti: ^
[08:22] <infinity> Oh, no, that's different entirely.
[08:22] <infinity> jamespage: dh_strip doesn't seem to get called in your build at all now...
[08:22]  * infinity scratches his head.
[08:23] <jamespage> infinity, I do have an override_dh_strip in .PHONY still
[08:23] <infinity> jamespage: That could be it
[08:23] <jamespage> that's my suspicision - but with a 4 hour build turnaround atm I'd like to have a high confidence that's all good
[08:25] <infinity> jamespage: http://paste.ubuntu.com/20154493/
[08:26] <jamespage> infinity, ta
[08:27] <infinity> jamespage: Store --no-act away somewhere for future use.  Very handy. :P
[08:27] <jamespage> infinity, great tip - thanks
[08:28]  * jamespage ties a load of builder up for a bit
[08:32] <pitti> jdstrand, tyhicks: I'm trying to update /etc/apparmor.d/abstractions/dbus-session-strict for the dbus peer address /run/user/<uid>/dbus (which replaced the abstract @/tmp/dbus* thing)
[08:32] <pitti> jdstrand, tyhicks: however, I keep getting "unix rule: invalid value for addr='/run/user/*/bus'" errors
[08:32] <pitti> with peer=(addr="/run/user/*/bus"),
[08:33] <pitti> I also tried with changing * to 1000, or with /run/user/**, nothing works
[08:34] <pitti> and the manpage doesn't say how to specify path based sockets; halp?
[08:34] <pitti> infinity: yes, dh_strip_nondeterminism is for reproducible builds, replacing time stamps etc.
[08:35] <infinity> pitti: Yeah, I realized after reading the manpage. :P
[08:37] <infinity> pitti: Also, peer=(addr="@/run/user/[0-9]*/bus"), ?
[08:38] <pitti> but @ is wrong
[08:38] <pitti> it's not an abstract socket, it's a path
[08:38] <infinity> Oh.
[08:39] <infinity> pitti: Does the dmesg audit have anything interesting to say?
[08:39] <pitti> [  159.822302] audit: type=1400 audit(1469003934.773:28): apparmor="DENIED" operation="connect" profile="/usr/lib/telepathy/mission-control-5" name="/run/user/1000/bus" pid=2862 comm="mission-control" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
[08:39] <pitti> pretty much what you'd expect
[08:40] <pitti> oh
[08:40] <pitti> maybe we need to give separate permissions for the file
[08:43] <pitti> that wouldn't fix the syntax issue, but explain why it still doesn't work with completely dropping peer=
[08:44] <pitti> I added   /run/user/*/dbus rw,
[08:44] <pitti> and recache/restart, no change
=== robert_ancell_ is now known as robert_ancell
[09:27] <LocutusOfBorg> hi, can anybody please have a look at ben?
[09:27] <LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/transitions/html/html/ocaml.html
[09:27] <LocutusOfBorg> Clicking on "transitions" brings to file://index.html
[09:27] <LocutusOfBorg> probably missing a ../
[09:28] <LocutusOfBorg> looks like the issue is fixable here? http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/ben/view/head:/frontends/ben_monitor.ml
[09:29] <LocutusOfBorg> Laney, ^^ :)
[09:47] <LocutusOfBorg> hi jbicha, do you plan to have a look at libpqxx sadness?
[09:47] <LocutusOfBorg> I would like to avoid having a delta from debian that is an epoch bump
=== rcj` is now known as rcj
[10:49] <hrw> hello
[10:50] <hrw> anyone with grub2 knowledge?
[10:50] <hrw> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1603083
[10:50] <ubottu> Launchpad bug 1603083 in grub2 (Ubuntu) "please provide a standalone grub image" [Undecided,New]
[11:00] <hrw> added test image, renamed bug
[11:11] <infinity> hrw: What's the usecase for a standalone image?  We provide an image for netboot.
[11:12] <hrw> infinity: cirros image (minimal one for openstack) needs grub-efi binary to be bootable on aarch64, x86-64/efi platforms
[11:13] <hrw> infinity: initially I used centos grub-efi binaries but smoser (cirros maintainer) prefers to use ubuntu one
[11:13] <hrw> I renamed bug in meantime: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1603083
[11:13] <ubottu> Launchpad bug 1603083 in grub2 (Ubuntu) "standalone grub image does not see GPT partitions" [Undecided,New]
[11:28] <hrw> infinity: ideas?
[11:28] <infinity> hrw: Not currently, it was just a drive-by question.  I don't have the time today to think much about it.
[11:28] <hrw> infinity: ok
[11:31] <jamespage> infinity, yeah small debs and ddeb's - https://launchpad.net/ubuntu/+source/ceph/10.2.2-0ubuntu4/+build/10492159
[11:32] <jamespage> thanks for your help
[11:32] <infinity> jamespage: NP.
[11:45] <hrw> hm. looks like I found solution ;D
[11:45] <hrw> have to test
=== hikiko is now known as hikiko|ln
[12:16] <hrw> does ubuntu images contain /.disk/info file?
[12:17] <hrw> long time since I used ubuntu
[12:25] <hrw> nevermind
=== _salem is now known as salem_
=== hikiko|ln is now known as hikiko
=== ivoks is now known as mirka_
=== mirka_ is now known as ivoks
=== King_InuYasha is now known as Son_Goku
[14:30] <nacc> pitti: ok :)
[14:33] <smoser> tjaalton, i just filed https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1604819
[14:33] <ubottu> Launchpad bug 1604819 in xorg-server (Ubuntu) "intel driver (intel_drv) not loaded" [Undecided,Confirmed]
[14:33] <smoser> latest xorg-xserver ends up with me using vesa driver.
[14:35] <tjaalton> smoser: read my comment, it's not using vesa but modesetting which is the new default
[14:36] <tjaalton> fbev/vesa are lower on the list of fallback drivers
[14:36] <tjaalton> *fbdev
[14:37] <smoser> was just reading your changelog entries, and yeah figured it was related to those.
[14:37] <tjaalton> the real bug is the flickering screen, which is likely a kernel bug that -intel hid away
[14:38] <smoser> possibly, yeah.
[14:39] <tjaalton> you can try with newer kernel mainline builds first, and add results there. then use the xorg.conf until there's something else to try
[14:39] <tjaalton> intel will look into all these from now on
[14:39] <tjaalton> got their word on that :)
[14:40] <smoser> so how to add that xorg.conf ?
[14:40] <tjaalton> read the comment :)
[14:40] <smoser>  /usr/share/doc/xserver-xorg-video-intel/xorg.conf just has the single Section
[14:40] <tjaalton> and it's enough
[14:40] <smoser> thats all thats necessary ? (been probably 5 happy years since i've looked at an xorg.conf)
[14:55] <tjaalton> smoser: thanks for testing 4.7-rc7, mind give 4.6 a spin?-)
[14:55] <tjaalton> *giving
[14:56] <smoser> shoot
[14:56] <smoser> i was just going to tell you thank you for your help and that i was going on my way :)
[14:56] <tjaalton> hehe
[14:56] <smoser> tell me what to try and i will
[14:56] <tjaalton> mainline build of 4.6.x
[14:57] <smoser> 	v4.6.3-yakkety/ seems latest
[14:57] <smoser> right?
[14:57] <tjaalton> yep
[14:57] <smoser> ok. will try
[14:57] <smoser> you should probably re-title that bug to somethign that is remotely close
[14:57] <smoser> :)
[14:57] <tjaalton> I did
[14:58] <tjaalton> back to what it was
[14:58] <smoser> ok.
[15:01] <tjaalton> leave a note on the bug if 4.6 works, I'm signing off now
[15:14] <nacc> bdmurray: so 7 of the php7.0 sru 'errors' are these debconf issues I don't have a lead on (and don't seem to be related to the package necessarily): https://errors.ubuntu.com/problem/e4de08d8bf5a70d8b04970d2a3823529b7a56706 (and similar)
[15:15] <nacc> mdeslaur: --^ as well
[15:15] <nacc> bdmurray: mdeslaur: i'm looking through the other ones
[15:21] <mdeslaur> hrm, yeah, I don't think that's related to the actual package. I see those types of errors from time to time, but I've never looked at what was causing those.
[15:22] <mdeslaur> bdmurray: do you have any idea what causes those? ^
[15:22] <mdeslaur> is it when someone cancels an install half-way though?
[15:22] <bdmurray> mdeslaur: Nope, I've no idea.
[15:22] <mdeslaur> bdmurray: you've seen them too, right?
[15:23] <mdeslaur> launchpad is full of them
[15:23] <bdmurray> mdeslaur: yes, I've seen them for lots of different packages
[15:24] <nacc> yeah, it's very strange; it does seem like a broken pipe (that line in the perl file)
[15:25] <rbasak> I wondered if it was some nuance of how maintainer scripts are supposed to speak to debconf, such as the need for db_stop or something like that.
[15:25] <nacc> rbasak: yeah, i was putting it on my list to dig, but given that it's kind of everywhere, i think it's not something we introduced (and there have been bugs like that for the php7.0 already in xenial)
[15:26] <bdmurray> nacc: I've starting the phasing of php7.0 again
[15:26] <rbasak> nacc: sure
[15:26] <nacc> bdmurray: thanks!
[15:27] <nacc> bdmurray: i'll keep triaging the reports and reproducing those that seem like they might be real -- a few have all error reporting disabled, so the logs aren't helpful :)
[15:34] <jdstrand> pitti: /run/user/<uid>/dbus looks like a named unix socket and therfore should used a file rule instead of a unix rule. eg: owner /run/user/[0-9]*/dbus rw,
[15:35] <pitti> jdstrand: right, I tried that; does that completely replace the unix (connect ...) rule then?
[15:35] <pitti> we need to allow both for a while
[15:35] <pitti> jdstrand: because restricting connection to peer=(addr="@/tmp/dbus-*"), excludes the named socket apparently
[15:36] <jdstrand> pitti: it would for the session bus if the session bus is now using a named socket, yes. but upstream would use both
[15:36] <pitti> jdstrand: I added "/run/user/[0-9]*/dbus rw," and that didn't seem to help
[15:36] <jdstrand> pitti: the unix rule is for an abstract socket and a completely different rule, so yes, you need the file rule I gave. a system that only uses a named socket would not need the unix rule
[15:37] <jdstrand> pitti: with /run/user/[0-9]*/dbus rw, what is the denial?
[15:37] <nacc> rbasak: fyi, i'm verifying all the bacula bugs are already fixed (by pushing to debian and upstream) in 16.10, will update them accordingly
[15:37] <pitti> jdstrand: ok, good to know; I'll try again in a few mins
[15:38] <jdstrand> pitti: s/but upstream would use both/but upstream apparmor would specify both for cross-distro support and transition/
[15:40] <jdstrand> pitti: note that there might be other services that use libdbus that might create an abstract socket that matches @/tmp/dbus-* that would fail without the unix rule. ibus was one (but I patches im-config in yakkety for that), but there might be others (though I don't think in main). it should be obvious from the denial though
[15:41] <pitti> jdstrand: right, I wasn't meaning to remove the abstract one, just to *also* allow the path based one
[15:41] <pitti> jdstrand: so that things work with dbus-user-session and without
[15:41] <jdstrand> sounds great
[15:41]  * jdstrand nods
[15:42] <nacc> rbasak: also, did you see my debug of the mysql-server vs. bacula install path?
[15:42] <jdstrand> pitti: note I see in backscroll the path is /run/user/1000/bus
[15:42] <nacc> rbasak: i think, in retrospect, it's not a bug, just a quirk of the way bacula and dbconfig work
[15:42] <jdstrand> pitti: your rule is /run/user/[0-9]*/dbus
[15:42] <jdstrand> ie, dbus vs bus
[15:42] <pitti> jdstrand: argh, how silly; thanks!
[15:42] <jdstrand> np
[15:42] <pitti> (that was Adam's rule, but I might have done the same)
[15:47] <infinity> bus, dbus, whatever. ;)
[15:47] <seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1604872
[15:47] <ubottu> Launchpad bug 1604872 in apparmor (Ubuntu) "dbus abstraction not compatible with dbus-user-session" [Undecided,New]
[15:47] <pitti> jdstrand: I feel so silly now, thanks :)
[15:47] <pitti> works fine
[15:48] <pitti> jdstrand: I'll attach to seb128's bug
[15:49] <jdstrand> thanks
[15:51] <pitti> jdstrand: is there an upstream git you want a PR for?
[15:51] <infinity> pitti: I apologize deeply for infecting you with my thinko. ;)
[15:52] <pitti> infinity: I already screwed it up before, so no worries :)
[15:52] <infinity> pitti: Oh, then I take it back.  No apology for you.
[15:52] <jdstrand> pitti: a patch to the https://lists.ubuntu.com/mailman/listinfo/apparmor is the normal way. otherwise you can add an upstream apparmor task and the patch to the bug
[15:53] <pitti> jdstrand: thanks, I'll do that then, as I'm not subscribed
[15:56] <pitti> jdstrand: done
[16:01] <rbasak> nacc: that's OK then I guess. As long as we're no worse than Debian.
[16:02] <nacc> rbasak: ack
[16:42] <mhall119> infinity: there's an email from the CC to the DMB list that is waiting on moderation, can you let it through?
[16:43] <mhall119> seb128: willcooke: ^^ same thing for the ubuntu-desktop ML
[16:43] <infinity> mhall119: Not sure I have the DMB list password.
[16:44] <mhall119> infinity: it's owned by the TB according to mailman, so anybody from that team should be able to approve it
[16:44] <infinity> mhall119: That's not how mailman moderation works...
[16:45] <mhall119> it's just a reminder that the biannual checkin with the CC is tomorrow at 1700 UTC in #ubuntu-meeting
[16:45] <mhall119> if you can't approve it, can you send a reminder yourself?
[16:45] <infinity> Oh.  I thought we already had one of those.
[16:45] <infinity> Or maybe that was to the TB.
[16:45] <mhall119> infinity: you have one very cycle :)
[16:46] <infinity> mhall119: We got a mail to the dmb list today.
[16:46] <infinity> From: Svetlana Belkin <belkinsa@ubuntu.com>
[16:46] <infinity> Subject: Re: Check-In With Community Council
[16:47] <infinity> mhall119: So, I tihnk we're good.
[16:47] <mhall119> ah, someone let it through then, thanks :)
[16:47] <willcooke> mhall119, done
[16:47] <mhall119> thanks willcooke
=== cmagina is now known as cmagina_lunch
[17:13] <mterry> bdmurray, per bug 1275083, unity-api-team seems better than unity-api-bugs it seems, for the package-subscribers script
[17:13] <ubottu> bug 1275083 in ubuntuone-credentials (Ubuntu) "[MIR] ubuntuone-credentials" [Undecided,New] https://launchpad.net/bugs/1275083
[17:19] <bdmurray> mterry: thanks, I've commented on the bug.
[17:21] <mterry> bdmurray, thanks!
[18:15] <semiosis> hi again.  any movement on my vagrant issue?  bug 1565985
[18:15] <ubottu> bug 1565985 in cloud-images "vagrant vb ubuntu/xenial64 cannot mount synced folders" [Undecided,In progress] https://launchpad.net/bugs/1565985
[18:15] <semiosis> https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305
[18:15] <semiosis> thanks in advance
[18:20] <dobey> anyone know how to make sbuild build unsigned packages? my search-fu is apparently not working so great
[18:21] <dobey> as in, i want it to build unsigned binaries
[18:31] <semiosis> dobey: pbuilder?
[18:32] <dobey> semiosis: no, i need to use sbuild. just looking for a way to make it build unsigned, to avoid extra hassle of needing to generate and secure keys
[18:33] <dobey> (ie, i'm trying to fix something that runs sbuild in clouds to not build signed packages)
[18:34] <dobey> also, sbuild-update --keygen doesn't seem to want to generate keys for me
[18:36] <tumbleweed> dobey: sbuild shouldn't be caring about signatures on packages
[18:37] <tumbleweed> it does need to sign its internal archive, though
[18:38] <dobey> tumbleweed: sign its internal archive?
[18:38] <dobey> tumbleweed: why does it need this and to sign it?
[18:39] <slangasek> because apt refuses unsigned archives by default, and sbuild needs to support building packages against other packages that it has built and subsequently published internally
[18:42] <dobey> ok. can i make sbuild not use the internal archive stuff then? these are throw-away CI builds in jenkins
[18:44] <tumbleweed> I think you should figure out the problem with sbuild-update --keygen
[18:44] <dobey> i guess not because the dummy package it creates is in that archive :-/
[18:45] <nacc> slangasek: germinate question for you; how serious is it for the seeds to refer to nonexistent packages in your mind? I recently (with pitti's help) fixed an issue in the samba-server task where a non-existent (but necessary functionality-providing) pacakge was listed (smbpass-winbind -> libpam-winbind migration). Looking through
[18:45] <dobey> tumbleweed: well, that's not the core issue i was trying to solve
[18:45] <nacc> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.xenial/_germinate_output, I do see it mentions "nknown samba-server package: libpam-smbpass". I also see that for several other packages (including some from server-ship).
[18:46] <sarnold> dobey: since packages themslves aren't signed, I'm not sure where sbuild fits in to this; they only get "signed" when they get moved into a repository, no?
[18:46] <dobey> ie, distributed management of infrastructure is a lot more annoying/difficult when you have private keys to keep private
[18:47] <slangasek> nacc: it is an issue that the seed owners should take seriously, because it leads to problems like the one described here where functionality goes missing from the seed due to an unnoticed package rename
[18:47] <tumbleweed> dobey: why do you have to keep them private?
[18:47] <nacc> slangasek: ack, thanks!
[18:48] <slangasek> nacc: if you look carefully, you will certainly find that server is not alone in terms of stale seed contents :/
[18:48] <dobey> tumbleweed: well, i guess this specific instance it might be ok if the private keys are in a vcs, since they're only for internal sbuild thing
[18:48] <nacc> slangasek: yeah, that's why i was sort of asking the relative priority :) I will at least try to get server cleaned up
[18:49] <dobey> sarnold: i think we got past that point already :)
[18:49] <sarnold> dobey: okay :) hehe
[18:50] <sarnold> dobey: are you already using a tool to manage the internal repo?
[18:50] <dobey> sarnold: no, i'm not trying to manage an internal repo. just trying to make managing a jenkins instance which uses sbuild to build things for testing MPs, a bit easier
[18:51] <sarnold> dobey: the security team has scripts around apt-ftparchive, and by default we leave our internal repos unsigned, so if you haven't selected one already, apt-ftparchive may work alright
[18:52] <dobey> sarnold: this is the internal repo which sbuild uses for itself, so i guess that wouldn't help here
[18:55] <sarnold> dobey: alright, if I've understood .. in the schroot you're using, change the apt.sources lines from "deb ..." to "deb [trusted=yes] ..."
[18:56] <sarnold> (and deb-src too)
[18:56] <slangasek> sarnold: that's all pretty deep fiddling with the sbuild setup.  The better answer is just to either put your private creds in the VCS, or let sbuild create them as part of the setup job, and not care
[18:56] <dobey> sarnold: i don't have shell access to those. the jenkins jobs currently won't even let me create the chroots, without the keys
[18:57] <slangasek> fwiw if we really are talking about signed packages rather than signed changes, that's just an option to dpkg-buildpackage: -uc -us
[18:59] <jbicha> LocutusOfBorg: for libpqxx-dev, I'm hoping we can ignore the epoch once bug 1588570 is taken care of
[18:59] <ubottu> bug 1588570 in libpqxx3 (Ubuntu) "please remove libpqxx3 from the archive" [Wishlist,New] https://launchpad.net/bugs/1588570
[18:59] <dobey> slangasek: no, i'm talking about the sbuild keys. i just didn't understand exactly what they were used for when i originally asked how to not use them
[18:59] <slangasek> ok
[19:00] <LocutusOfBorg> jbicha, not sure but I hope so
[19:00] <LocutusOfBorg> :)
[19:02] <dobey> so probably the best solution here would be to just let sbuild generate its keys during setup
[19:11] <cjwatson> dobey: I've been meaning to make sbuild use [trusted=yes] instead of the local key thing, but there are compatibility issues when building for old releases
[19:26] <dobey> ah, entropy is an issue :-/
[19:51] <infinity> cjwatson: trusted=yes showed up in trusty, right?  So when precise EOLs, we can go to town!
[19:51] <infinity> (Which is coming up)
[19:54] <cjwatson> I think I was still thinking of doing some kind of cheap version detection, but something like that.
[19:54] <infinity> cjwatson: Well, -d is passed through pretty much everything, you can just strstr for precise and be done with it.
[19:55] <infinity> cjwatson: Assuming anything !precise and !wheezy (or whatever Debian releases don't support it) are fine, and screw people with weird distros.
[19:55] <infinity> Close enough, anyway.
[19:56] <cjwatson> Could also just do a version comparison on apt.
[20:02] <nacc> rbasak: ok, i've submitted a sru debdiff for bacula
[20:03] <dobey> cjwatson: having trust=yes would be awesome, indeed
[20:04] <dobey> hrmm, how does one delete an sbuild schroot which somehow still has resources in use?
[20:04] <dobey> ie /proc /sys /dev/shm and /dev/pts
[20:05] <dobey> somehow the suggested rm -rf for deleting a schroot on the wiki page, seems like a bad idea
[20:06] <nacc> well, those are all virtual filesystems, right? meaning the /proc in /var/lib/schroot/chroots/ is empty
[20:06] <dobey> are they not bind mounts? and either way, wouldn't they need to be unmounted first?
[20:08] <nacc> dobey: i don't htink they are bind mounts (at least not /proc or /sys, but i might be wrong)
[20:08] <nacc> https://wiki.ubuntu.com/SimpleSbuild#Deleting_a_schroot
[20:08] <nacc> dobey: --^ you mean those stanzas?
[20:08] <dobey> yes
[20:09] <nacc> dobey: to be clear /var/lib/schroot/chroots/* is the 'source' chroot (I think); sessions is where a running sbuild/schroot would be
[20:10] <dobey> 19:59:16 rm: cannot remove '/var/lib/schroot/chroots/vivid+overlay-amd64/dev/pts': Device or resource busy
[20:11] <dobey> well, i just want to know how to get rid of it, on a remote vm in a cloud that i don't have direct shell access to
[20:12] <nacc> dobey: oh with overlays, it might need to be not running?
[20:15] <cjwatson> dobey: schroot -ec <session id>  usually WFM
[20:16] <nacc> right, that should end the running session; which won't necessarily delete the underlying chroot (aiui). But maybe overlays are different?
[20:16] <dobey> i don't know that there is an active session
[20:17] <nacc> dobey: are you able to lsof that file (I think that's the command) and see what is using it?
[20:22] <dobey> oh, ffs, trusty umount doesn't have -R option apparently :-/
[20:34] <dobey> ok, some fancy mount|grep schroot|... magic and i managed to get everything unmounted, so hopefully this will all do the right thing now
[20:44] <dobey> 20:43:13 cp: '/etc/localtime' and '/var/lib/schroot/chroots/xenial+overlay-i386/etc/localtime' are the same file
[20:44] <dobey> any idea why that would happen?
[20:44] <infinity> Yup.
[20:45] <slangasek> dobey: because you should install the SRU version of ubuntu-dev-tools, 0.155ubuntu2
[20:47] <infinity> (Or the yakkety version)
[20:48] <dobey> 20:48:11 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[20:48] <dobey> hrmm
[20:49] <infinity> dpkg -l ubuntu-dev-tools ?
[20:49] <dobey> slangasek: oh, it's not an SRU on trusty?
[20:49] <infinity> Oh, no.  Only yakkety and xenial.
[20:49] <infinity> People use trusty?
[20:49] <slangasek> this bug affects trusty?
[20:49] <infinity> Probably.
[20:50] <slangasek> I assumed it was a regression in the released version of mk-sbuild in xenial, didn't look further
[20:50] <infinity> The bug was in new userspace, thus new chroots.
[20:50] <infinity> I believe.
[20:50] <dobey> hrmm
[20:50] <infinity> Well, "bug".
[20:50] <slangasek> if it's a behavior change in debootstrap, then yes, mk-sbuild in trusty might need help
[20:50] <dobey>  0.153ubuntu1updates (universe)2016-07-03
[20:50] <infinity> As in, those files changed type, and thus couldn't be copied over anymore.
[20:50] <dobey> err, paste from lp sucks
[20:50] <infinity> Went from file to link, I think.
[20:50] <infinity> Or something.
[20:50] <infinity> I dunno.
[20:51] <infinity> *hand wavy*
[20:51] <infinity> But yes, probably needs fixing in trusty and precise too.
[20:51] <dobey> so it looks like 0.153ubuntu1 is installed
[20:51] <slangasek> infinity: oh, you're right.  I had assumed this was always the case, but now I realize it's an assume-/usr-is-present-ism
[20:51] <slangasek> so yes, mk-sbuild in trusty should also get an SRU
[20:51] <slangasek> somebody who runs trusty can drive that ;)
[20:52]  * infinity stares at dobey.
[20:52] <dobey> i'm just trying to put out this firebomb :(
[20:54] <dobey> i guess these clouds are all still 14.04 at least until 16.04.1 (and then until IS gets time to upgrade things)
[20:54] <slangasek> it's a one-liner patch to mk-sbuild, fwiw
[20:55] <dobey> mk-sbuild is just a text script right?
[20:55] <slangasek> yes
[20:56] <slangasek> you can probably cowboy patch it in your setup script, if that's what you're thinking
[21:01] <dobey> indeed
[21:03] <dobey> oh bugger, my entering-commands-in-a-web-form-to-run-on-a-remote-system-fu is not as strong as i'd thought
[22:34] <mwhudson> sooner or later i'm going to have to figure out how to make 'chdist apt' work
[22:43] <nacc> mwhudson: was about to cobble something together, but yakkety's version has the support :)
[22:43] <nacc> 2.16.6 added it
[22:43] <mwhudson> nacc: oh cool
[22:43] <mwhudson> will the world catch on fire if i install the yakkety version on xenial, i wonder...
[22:43] <nacc> mwhudson: i'm pretty sure (in quick testing) that apt also accepts APT_CONFIG as the env variable, so it's just a matter of adding apt as a command option
[22:44] <mwhudson> yeah, i'm assuming it's not hard
[22:44] <nacc> i think itmight be literally adding:
[22:44] <nacc>     when ('apt') {
[22:44] <nacc>         aptcmd('apt', @ARGV);
[22:44] <nacc>     }
[22:44] <nacc> to the parser