[04:24]  * mwhudson bangs head on desk
[04:25] <mwhudson> has something changed in binutils recently (or possibly not recently) wrt preferring to emit dt_runpath over dt_rpath
[07:03] <pitti> bdmurray: it certainly used to work; I can't imagine that crashing /usr/bin/yes leaves a > 1 MB core file behind now??
[07:09] <infinity> pitti: It was rewritten in Go.
[07:10] <pitti> I'm sure a complex program like yes can benefit greatly from that
[07:10] <infinity> pitti: It's also now a symlink to /usr/bin/maybe
[07:42] <seb128> good morning desktopers
[07:51] <tsimonq2> But what if I'm a serverer *and* a desktoper? :P
[07:52]  * tsimonq2 obviously needs more sleep and exits left
[07:53] <pitti> bonjour seb128 !
[08:02] <seb128> hey pitti! wie gehts?
[08:08] <LocutusOfBorg> pitti, <3
[08:13] <pitti> seb128: gut, danke! greetings from Karlsruhe, we have a hackfest this week
[08:15] <seb128> pitti, ah, nice, greetings toward Karlsruhe then :-)
[09:45] <cpaelzer> hmm - on package versioning the ~ is nice to stay below something, but what is the trick to stay above in any case?
[09:45] <cpaelzer> the version has to start numeric
[09:46] <pitti> cpaelzer: how do you mean exactly?
[09:46] <cpaelzer> so starting with 99- seems ugly but does the trick for quite a while
[09:46] <cpaelzer> I wonder if there is a better thing
[09:46] <cpaelzer> pitti: I think about creating some daily builds of packages
[09:46] <cpaelzer> in a ppa
[09:47] <cpaelzer> but I'd like them to be fully automated and preferred to whatever is current if the ppa is enabled
[09:47] <rbasak> I don't force a "stay above" in my PPA versioning. If the archive carries the same version, it's fine for the archive to "win" IMHO.
[09:47] <cpaelzer> manually modifying versions is against the automation thought
[09:47] <cpaelzer> but 99-* is so ugly
[09:47] <rbasak> You could use an epoch I suppose.
[09:48] <cpaelzer> uh yeah
[09:48] <cpaelzer> that was the <numb>: starter right?
[09:48] <rbasak> Yeah. Normally we avoid those, but that's in the archive. In a PPA, you're basically asking for exactly what they do - a bump beyond anything else.
[09:48] <cpaelzer> yep
[09:49] <cpaelzer> ok thanks that will do for sure
[09:49] <cpaelzer> but maybe there is an even better way
[09:49] <rbasak> The issue is that you'll need user intervention to go back to the archive version, but I think you're asking for that exactly.
[09:49] <rbasak> Apt pinning might be another option maybe?
[09:49] <cpaelzer> can I somehow ignore my changelog and generate the version from source?
[09:49] <rbasak> You can ask apt to score the PPA higher even for a lower version I think.
[09:50] <xnox> is debconf broken in zesty? https://launchpadlibrarian.net/324836850/DpkgTerminalLog.txt
[09:50] <xnox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1699360
[09:50] <xnox> or is it systemd?
[09:50] <cpaelzer> xnox: known bugs (plenty of)
[09:50] <cpaelzer> wait there is one to dup to
[09:50] <cpaelzer> oh that might already be it
[09:51] <cpaelzer> xnox: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1679435 ?
[09:51] <cpaelzer> yet it is supposed to be fixed now
[09:52] <cpaelzer> there is also an older incarnation https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/442941
[09:53] <jbicha> xnox: gnome-software/zesty got stuck in phased-updates so there are several bugs that still affect people that were fixed 2 months ago :(
[09:54] <xnox> jbicha, yeah, it looks like installation is done via aptdaemon with passthrough.
[09:56] <xnox> I guess https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1688721 ?!
[10:01] <cpaelzer> pitti: rbasak: even after the epoch I need a number again :-/
[10:01] <cpaelzer> I thought I could get away with something like 2:daily-201706270956-054914f
[10:02] <cpaelzer> I can insert a random number, but is there a way to even insert a real number generated fomr e.g. the source?
[10:02] <cpaelzer> note: in LP recipe
[10:06] <rbasak> cpaelzer: I'm not sure I follow. What does your recipe say right now?
[10:09] <cpaelzer> rbasak: # git-build-recipe format 0.4 deb-version 2:daily-{time}-{git-commit}
[10:09] <cpaelzer> which would have given me ahead of archive (due to epoch) but clearly daily on time+commit hash
[10:10] <cpaelzer> but it wants a numeric after the colon
[10:10] <cpaelzer> I might go with 2:0
[10:10] <cpaelzer> that way it surely is below any other 2: if one ever exists
[10:10] <rbasak> Yeah
[10:10] <cpaelzer> but what I meant before is if the build recipes could do ynthing like the following
[10:10] <rbasak> Or 0~ or 0~~ - depends on how far you want to go :-)
[10:11] <cpaelzer> # git-build-recipe format 0.4 deb-version 2:$(get from VERSIONS file)-daily-{time}-{git-commit}
[10:13] <cpaelzer> this doesn't hold anything that seems to solve this for me https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Version_numbers_and_substitution_variables
[10:14] <rbasak> I still don't really follow why you need this.
[10:15] <cpaelzer> if I want to build a daily ppa from an upstream that changes versions but I don't want to touch the debian/changelog that is merged into the build as part of the LP recipe
[10:15] <rbasak> I see
[10:16] <cpaelzer> if upstream goes version 3->4, then I can't find a way in the recipe to pick that up - which is why I chose to "stay ahead for sure"
[10:17] <rbasak> Perhaps a feature request for git-build-recipe is in order? Though I don't know about the status of executing arbitrary code on Launchpad.
[10:17] <rbasak> (for the build recipe stage; obviously the build itself is rather arbitrary code by definition)
[10:18]  * cpaelzer doesn't like "executing arbitrary code on Launchpad"
[10:24] <rbasak> It'd have to be arbitrary though - how else could you make "parse from VERSIONS file" work generically?
[10:24] <cpaelzer> rbasak: allow only a sed string or smth like it
[10:25] <cpaelzer>   {localver <FILE> <sedstring>}
[10:25] <rbasak> sed can't be trusted
[10:26] <rbasak> 'r /etc/shadow' etc
[10:26] <cpaelzer> grml
[10:26] <cpaelzer> true
[10:27] <cpaelzer> a chrooted sed or something like it maybe?
[10:28] <rbasak> This is probably why it doesn't support what you want already :)
[11:05] <jbicha> juliank: hi, LP: #1697120 is annoying :)
[11:29] <cpaelzer> rbasak: about random code on LP - the build of the recipe runs dpkg-source -i -I --before-build => dh clean => override_dh_clean can run any code
[11:29] <cpaelzer> although it is in fakeroot
[11:29] <cpaelzer> just as I'd have suggested for the version generator code
[11:30] <cpaelzer> so one could say "if it is safe enough for A it is safe enough for B as well" and a feature request bug would not be too bad
[11:36] <jbicha> cpaelzer: this thread feels like questionable advice to me, so let me add one more idea for you: override_dh_gencontrol
[11:36] <jbicha> dh_gencontrol -- -v
[11:37] <jbicha> I've only ever used that to change an epoch, but if you don't care about the source package version, it might work…
[11:47] <juliank> jbicha: Well, see what Niels wrote in the bug.
[11:52] <cpaelzer> thanks jbicha, reading into that as an option
[12:42] <cpaelzer> to locally debug germinate before a change to the seeds how much deeper than "germinate -d artful -d artful-updates -S file:///home/paelzer/work/seeds/ -s ubuntu.artful" can I go?
[12:43] <cpaelzer> currently I miss rdepends in the generated Dirs/Files
[12:43] <cpaelzer> but it is not run with --no-rdepends
[14:12] <cpaelzer> jbicha: thanks a lot - qemu_2.9.50-daily-20170627140413 via dh_gencontrol - just how it should be
[14:49] <rbasak> jbicha, cpaelzer: ah. Interesting approach, thanks.
[15:07] <zyga> jjohansen: hey
[15:07] <zyga> jjohansen: are you around?
[15:11] <bdmurray> xnox: What in bug 1699360 leads you to believe gnome-software as the frontend in use?
[15:13] <xnox> bdmurray, discussions here earlier in Europe morning time; the journal logs that aptdaemon invoked the install, with passthrough frontend.
[15:13] <xnox> bdmurray, i'm not sure if it is software-updater or gnome-software, but i've been advised that the unphased gnome-software in zesty only may be the culprit.
[15:13] <xnox> this bug is on zesty.
[15:14] <jbicha> bdmurray: do you want to phase gnome-software/zesty or should we just wait for the next SRU (already in -proposed) at this point?
[15:16] <bdmurray> xnox: I'm just trying to understand what indicates that it is gnome-software so more bugs related to that gnome-software bug can be found. I don't doubt that it could be gnome-software. Its just not obvious from the logs that it is.
[15:20] <xnox> bdmurray, it would be nice to document in aptdaemon /who/ started a given transaction, but i do not think we currently log that.
[15:21] <xnox> maybe that is logged somewhere, but i don't know where.
[15:21] <xnox> the dpkg frontend and the aptdaemon mentions strongly indicate a desktopy / gui update.
[15:24] <bdmurray> xnox: I think I've found a way to determine which frontend it is although its not great. The JournalErrors will contain a PyGIWarning when its gnome-software and maybe an update-notifier.desktop error when its update-manager.
[15:26] <xnox> bdmurray, >_< lovely =) so we gonna go by gtk vomit =)
[15:26] <xnox> as good as anything
[15:26] <bdmurray> Well I think something (apport?) should be fixed so we know which frontend it is for sure.
[15:46] <jjohansen> zyga: just getting in
[15:46] <jjohansen> what can I do for you?
[15:48] <zyga> jjohansen: hey, I found a bug in apparmor, I'm just preparing a program to reproduce it
[15:48] <zyga> jjohansen: I wanted to share what I have so far
[15:48] <zyga> jjohansen: and ask what you think
[15:48] <jjohansen> zyga: the issue from yesterday, with pivot_root?
[15:49] <zyga> jjohansen: I think so
[15:49] <zyga> open("/proc/1/ns/mnt", O_RDONLY|O_CLOEXEC) = 6
[15:49] <zyga> setns(6, CLONE_NEWNS)                   = 0
[15:49] <zyga> chdir("/")                              = 0
[15:49] <zyga> umount2("/run/snapd/ns/snapd-hacker-toolbelt.mnt", UMOUNT_NOFOLLOW) = -1 EACCES (Permission denied)
[15:49] <zyga> write(2, "cannot unmount preserved mount n"..., 85cannot unmount preserved mount namespace file /run/snapd/ns/snapd-hacker-toolbelt.mnt) = 85
[15:49] <zyga> write(2, ": Permission denied\n", 20: Permission denied
[15:49] <jjohansen> correct
[15:49] <zyga> [46499.130927] audit: type=1400 audit(1498576919.074:225): apparmor="DENIED" operation="umount" profile="/usr/lib/snapd/snap-confine" name="/" pid=19511 comm="snap-confine"
[15:49] <zyga> jjohansen: does that look plausible
[15:50] <jjohansen> correct
[15:50] <zyga> jjohansen: my gut feeling is that after jumping out of the namespace something is not updated
[15:50] <jjohansen> it is however correct
[15:50] <zyga> yes/
[15:50] <zyga> ?
[15:50] <jjohansen> switching namespaces will cause the files opened within the namespace to disconnect
[15:51] <zyga> jjohansen: hold on, this is not using any files opened from the namespace anymore
[15:51] <jjohansen> mount namespaces can't even be thought of as parent child
[15:51] <zyga> jjohansen: umount uses just the path
[15:52] <zyga> jjohansen: and for sure, umount was not using / but another thing, so how did / show up without any other error (like disconnected path)
[15:52] <bdmurray> jbicha: I think we really want the version of gnome-software in -proposed. I don't think the unphased one in -updates gets us much.
[15:53] <jbicha> bdmurray: it allows installing 3rd party deb's !
[15:53] <zyga> jjohansen: can you explain how you see it?
[15:54] <jbicha> it's almost moot now since maybe the new one will start phasing later this week anyway
[15:54] <jbicha> bdmurray: sorry I didn't ping you sooner about it
[15:54] <bdmurray> jbicha: Which bug / crash is it fixing? I don't see the new one as being verified.
[15:54] <jjohansen> zyga: mounts are try too, what does /run/snapd/ns/snapd-hacker-toolbelt.mnt look like? is there a bind mount involved, is there a component that steps through nsfs
[15:54] <jbicha> LP: #1672424
[15:55] <zyga> jjohansen: /run/snapd/ns/snapd-hacker-toolbelt.mnt is a bind-mounted mount namespace of a process
[15:55] <jjohansen> zyga: can you give me a stat of each component of the path?
[15:55] <jbicha> the new one has not been verified yet, robert_ancell is sprinting this week
[15:55] <zyga> jjohansen: from my regular mount namespace? yes
[15:55] <zyga> jjohansen: the file itself is nsfs, everything else is / /run (tmpfs) ... all until the .mnt file which is nsfs
[15:56]  * zyga goes to stat it
[15:56] <jjohansen> zyga: okay, that explains it
[15:56] <zyga> http://pastebin.ubuntu.com/24964030/
[15:56] <jbicha> the gnome-software SRUs look simple enough to verify so I'm going to take a look
[15:56] <zyga> let me know if you want stat -f as well
[15:57] <jjohansen> nsfs, exists in its own special kern mount, that is detached from the system
[15:57] <jjohansen> apparmor doesn't handle that well atm
[15:57] <zyga> aha
[15:57] <zyga> so it is a bug in some way?
[15:57] <jjohansen> I have some wip to address this
[15:57] <zyga> (stat -f: http://pastebin.ubuntu.com/24964032/)
[15:58] <jjohansen> zyga: bug sure, or feature still in dev
[15:58] <zyga> jjohansen: interestingly it works if you don't setns at all
[15:58] <zyga> jjohansen: because we unmount them all the time
[15:58] <zyga> jjohansen: I was thinking about unmounting it from a helper forked process that doesn't transition at all
[15:59] <zyga> jjohansen: to work around it for now
[15:59] <zyga> jjohansen: do you think that is sensible?
[16:00] <jjohansen> possibly, it certainly seems to be the way to avoid the issue until a fix lands
[16:00] <zyga> jjohansen: do you have a reference to the bug?
[16:00] <zyga> jjohansen: or your way to describe it accurately
[16:01]  * zyga is still unsure if it is setns done twice or the fact that pivot_root was used on the namespace that is being "jumped" out of
[16:06] <jjohansen> zyga: there is no bug that I know of, feel free to open one. It is an issue I am aware of, there is a bug that mentions the nsfs issue I will have to dig for that, it comes out of lxc reports but I lost the all my open tabs in a browser crash, the double pivot_root/setns is a separate thing and I know there is nothing for it
[16:07] <zyga> jjohansen: ok, is that something that you are planning to fix soon? is it still unknown in some regard or just not implemented but well understood?
[16:09] <jjohansen> zyga: the don't know that I would say all the issues around setns, and pivot_root are well know but I have been working on a patchset for upstream RFC that adds some new hooks that help us so that the LSM will get the information we actually need to be able to properly deal with them
[16:10] <jjohansen> so yes, actively being worked on, I am hoping to land something for 4.14
[16:10] <zyga> jjohansen: is there anything we should be aware of that may affect snapd? we use setns and pivot_root for fundamental snap operations
[16:11] <jjohansen> note: landing something for 4.14 would mean we should be able to put it into 17.10
[16:11] <zyga> jjohansen: I'm somewhat worried as this affects all the snaps, all the way back to 14.04
[16:12] <jjohansen> zyga: heck yes, it certainly does
[16:12] <jjohansen> the LSM can't do anything about setns, we only see its affects post it happening
[16:13] <jjohansen> zyga: we will have to be careful and do some abi detection, if we do it correctly we should be able to emulate old behavior and not break things
[16:14] <jjohansen> I will make sure you get patches in advance
[16:15] <zyga> jjohansen: I'm still unsure about what is broken exactly but I worry that the issue may affect regular (existing) operations in snapd
[16:15] <zyga> jjohansen: I only noticed the issue when trying to implement a new issue
[16:16] <zyga> jjohansen: apart from getting the fix merged in 17.10, do you think we could get a fix in 16.04 kernels earlier?
[16:17] <zyga> s/a new issue/a new feature/
[16:20] <jjohansen> zyga: yes, I am going to backport/SRU everything that lands upstream, the goal is to get rid of all (most) ubuntu sauce patches, making it easier for the kt to also support, and pull fixes from upstream
[16:29] <zyga> jjohansen: understood
[16:29] <zyga> jjohansen: we're kind of tired after a very unhappy day but I'll file a bug as soon as I can (tomorrow) and try to make a program that reproduces the issue, just to understand it better
[16:29] <zyga> (hopefully without attaching all of snap-conifne)
[16:33] <jjohansen> zyga: understood, and sorry
[16:35] <zyga> jjohansen: no worries, thank you!
[21:12] <doko> infinity: please could you have a look at the glibc autopkg test failures triggered by binutils?
[21:17] <infinity> doko: Looking.
[21:18] <infinity> doko: On all arches.  Looks like a real regression.  Fun.
[21:18] <infinity> {standard input}: Assembler messages:
[21:18] <infinity> {standard input}: Error: `loc1@GLIBC_2.2' can't be versioned to common symbol 'loc1'
[21:18] <infinity> {standard input}: Error: `loc2@GLIBC_2.2' can't be versioned to common symbol 'loc2'
[21:18] <infinity> {standard input}: Error: `locs@GLIBC_2.2' can't be versioned to common symbol 'locs'
[21:18]  * infinity will look into that.
[21:18] <doko> right, maybe look first if it's already addressed upstream
[21:19] <infinity> Indeed.
[21:19] <infinity> 388b4f1a02f3a801965028bbfcd48d905638b797
[21:19] <infinity> Will pick that up and commit to Debian too for you.
[21:19] <doko> ta
[21:30] <mwhudson> doko: did you see my mail about the gcc-cross packages in the python rebuild ppa?
[21:31] <doko> mwhudson: I did, and I thought I sent a reply: please ignore it
[21:31] <mwhudson> doko: oh yes you did send a reply, i hadn't got to that part of my email yet
[21:31] <mwhudson> doko: thanks
[21:38] <zyga> slangasek, infinity: hey, did you get my message about testing initrd a few days ago?
[21:40] <slangasek> zyga: hi, I did - sorry, thought I had replied here on IRC.  I think it's a good idea and I have added it to my backlog^W open browser tabs for further consideration
[21:41] <zyga> slangasek: thanks I must have lost the response
[21:41] <zyga> slangasek: let me know when would be a good time to have a chat about what should be the next step
[21:41] <zyga> slangasek: and if you have any views on the approach taken
[21:42] <slangasek> zyga: any urgency attached to this?
[21:43] <zyga> slangasek: no, none
[22:00] <infinity> zyga: I looked at it, and had some emotions, but didn't have the time to turn those emotions into English opinions.
[22:12] <zyga> infinity: positive or negative emotions?
[22:35] <infinity> zyga: Yes.
[22:51] <mwhudson> hooray you can't install python-argcomplete and python3-argcomplete at the same time?
[22:52] <mwhudson> hm no
[22:53] <sarnold> I can't see any reason why the two would conflict based solely on the apt-cache show output and apt-file show output
[22:53] <sarnold> I could understand that maybe you get to use only one of them at a time..
[23:11] <mwhudson> i get
[23:11] <mwhudson> Unpacking python3-argcomplete (1.7.0-0.1ubuntu1) ...
[23:11] <mwhudson> dpkg: error processing archive /tmp/apt-dpkg-install-Xce9pu/60-python3-argcomplete_1.7.0-0.1ubuntu1_all.deb (--unpack):
[23:11] <mwhudson>  trying to overwrite '/usr/bin/python-argcomplete-tcsh', which is also in package python-argcomplete 1.7.0-0.1ubuntu1
[23:11] <mwhudson> in a build lot where other very strange things are happening
[23:12] <mwhudson> also python-argcomplete itself ftbfs in a-p in really odd ways
[23:12] <sarnold> eww.
[23:12] <mwhudson> https://launchpadlibrarian.net/325814526/buildlog_ubuntu-artful-amd64.python-cement_2.10.0-1_BUILDING.txt.gz
[23:12] <mwhudson> https://launchpadlibrarian.net/318923342/buildlog_ubuntu-artful-amd64.python-argcomplete_1.8.1-1_BUILDING.txt.gz