[00:40] <slangasek> sbeattie: should I go ahead and fire off no-change rebuilds for those, then?
[00:42] <slangasek> sbeattie: (let's suppose "yes" and do it)
[00:51] <hallyn> wgrant: cool, closer than i thought :)  thanks!  i can't wait.  i'm always on crappy links so pulling 300 mb just to push it is painful :)
[00:51] <slangasek> sbeattie: (done)
[00:52] <slangasek> sbeattie: (except for bglibs which somehow generated a broken .changes file, BRILLIANT)
[00:53] <sarnold> slangasek: bglibs looks "special"<EMAIL_ADDRESS>[00:53] <slangasek> yes, yes it is
[00:54] <slangasek> maybe build-depending on that one is a good reason to remove a package instead of fixing it
[00:56] <sarnold> it might be, it looks unloved for a while https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544056
[04:00] <lfaraone> infinity: belated thanks :)
[04:01] <infinity> lfaraone: I don't know what I did, but you're welcome.
[04:05] <infinity> pitti: Wow.  Why is systemd so effin' noisy about timers?
[04:05] <infinity> pitti: None of that belongs in my ringbuffer.
[04:10] <lfaraone> Hmm. Why do we still build .imgs for the server install CD, but not the desktop install CD?
[04:10] <lfaraone> I feel, if anything, those should be swapped.
[04:10] <infinity> lfaraone: server.img is a symlink to server.iso. :P
[04:11] <infinity> It was a specific request to do so, it's not an extra image (despite the confusion)
[04:11] <lfaraone> infinity: hm, ok. do we build actual images for anything?
[04:11] <infinity> lfaraone: Define "images".
[04:11] <infinity> They're all images.
[04:11] <lfaraone> infinity: well, anything for which https://help.ubuntu.com/community/Installation/FromImgFiles is helpful. I think no :P
[04:13] <infinity> lfaraone: Seems that all those docs (including the ISO doc that links to) are pretty out of date.  Whee.
[04:14] <infinity> lfaraone: To be clear, the ISOs we produce are all bootable, and can thus be written raw to a USB key via dd.
[04:14] <infinity> lfaraone: So, all the docs seem to be many years crusty on that score.
[04:14] <lfaraone> infinity: Figured. I was planning on rewriting it a bit, and include some steps about how to verify the SHA256SUM.gpg, since it took me a bit of effort to find out the right invocation myself.
[04:46] <sbeattie> slangasek: yeah, in order to get it to be accepted in the ppa, I had to add 'Sections: libs' to the source section of the control file.
[05:36] <cpaelzer> good morning
[06:16] <ricotz> doko, hi :), https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/6377511/+listing-archive-extra
[06:17] <pitti> infinity: timers> err, what? some details please? "ringbuffer" sounds like "dmesg", but there are no timer messages after booting
[06:17] <pitti> Good morning
[06:18] <pitti> infinity: I suppose some pile up over time when e. g. the apt timer has run a few times?
[06:37] <infinity> pitti: Yeah, I have a ton of apt timer messages.
[06:38] <infinity> pitti: I see zero reason to spam kmsg with that.
[06:39] <pitti> infinity: can you please file a bug? the apt timer only runs every ~ 12 hours, so for sure there shouldn't be messages more often than that (unless there are other timers)
[06:39] <pitti> and they are supposed to go to the journal, not to dmesg
[06:40] <infinity> pitti: Sure, it's not often (though it adds up), but that's not really the point.  If we had a ton of timers all doing that, it would be ridiculous.
[06:40] <infinity> pitti: Filing a bug.
[06:41] <pitti> "systemctl list-timers" shows that the apt-daily timer ran 25 mins ago and systemd-tmpfiles-clean.timer 10 mins ago, still nothing in dmesg
[06:41] <pitti> so, can't reproduce yet I'm afraid; let's see what your messages actually are
[06:42] <infinity> pitti: It's the random adjust.  Sec.
[06:42] <pitti> Apr 29 08:15:39 donald systemd[1]: apt-daily.timer: Adding 4h 5min 11.531683s random time.
[06:42] <pitti> (in the journal indeed, but not in dmesg)
[06:42] <infinity> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1576536
[06:43] <infinity> pitti: I have a ton in dmesg.
[06:43] <pitti> infinity: ubuntu-bug please
[06:43] <pitti> infinity: can you please do apport-collect then?
[06:43] <pitti> (release, arch, JournalErrors.txt, etc.)
[06:44] <infinity> pitti: apport-collecting.  Apparently, python-apport isn't installed by default anymore.
[06:44] <pitti> kernel's command line etc.
[06:44] <pitti> infinity: right, that fell victim to "py 3 only on the iso" some releases ago
[06:45] <pitti> infinity: unfortunatley python3-launchpadlib still falls over too often, so apport-collect has to use py2 for now
[06:45] <infinity> pitti: Oh.  So why doesn't apport-collect use python3-apport? :P
[06:45] <infinity> Ahh.
[06:45] <infinity> pitti: apport-collected.
[06:47] <pitti> infinity: thanks; need to ponder that for a bit, I see nothing unusual on the log target or errors
[06:50] <infinity> pitti: I suppose I could just blame mvo for pointlessly switching away from cron. :P
[06:50] <pitti> infinity: I think his point was to smear out the time when the trigger hits, with the random delay
[06:51] <infinity> pitti: Quite, yes, which the cronjob also does. :)
[06:51] <infinity> (though not as well, admittedly)
[06:51] <mvo> infinity: *cough* pointless *cough*
[06:51] <pitti> I remember that mvo discussed this, but I forgot why the cron job wasn't sufficient any more
[06:51] <mvo> infinity: you need to embrace this new tech, its awesome !
[06:51] <pitti> mvo: oh, guten Morgen
[06:51] <infinity> mvo: Can't make me.
[06:52] <infinity> mvo: (And it does feel a bit pointless when you still have the compat cronjob for non-systemd systems)
[06:52] <infinity> mvo: Anyhow, systemd being a big jerk to my logs isn't your fault. :)
[06:53] <mvo> infinity: the big one is that we need more randomness for the start of the job and systemd gives it to us cheaply. with cron the ranodm delay delays other jobs. sure, we could have done it differently without systemd but it saves some extra work
[06:53] <mvo> infinity: :P
[06:54] <mvo> infinity: I won't disagree that the systemd timers seems to be not quite the same level as good old cron yet
[06:54] <mvo> pitti: hey, guten morgen!
[06:55] <infinity> mvo: Forking the delayed job in the background would let cron carry on, wouldn't it?
[06:55] <infinity> mvo: (I agree that holding up cron for your delay is awful)
[06:56] <Unit193> barry: FWIW, updated merge: https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/6377589/+listing-archive-extra
[06:58] <mvo> infinity: yeah, it could be done without systemd timers of course
[07:10] <dholbach> pitti, I don't know why summit is ignoring you, but maybe you can rename https://blueprints.launchpad.net/ubuntu/+spec/desktop-y-replace-upstart to convergence-1605-replace-upstart - just to see if that helps?
[07:11] <pitti> dholbach: oh, we don't do the -series any more, just the -UOSdate? that's a bit strange
[07:12] <pitti> dholbach: renamed
[07:19] <dholbach> pitti, I have no idea
[07:19] <dholbach> pitti, and mhall119 who's our local summit expert is on holidays
[07:20] <dholbach> I just noticed that it hadn't been imported
[07:20] <pitti> dholbach: so, let's try with convergence-y first, and if that still doesn't work, I'll rename it further to convergence-1605 ?
[07:21] <pitti> how long do we need to wait until the next import run?
[07:21] <dholbach> I have no idea
[07:21] <dholbach> I'll watch the situation and let you know
[07:27] <sbeattie> doko: looks like slang asek took care of the packages I mentioned earlier. Two additional packages needing rebuild are dpkg and python2.7.
[07:37] <LocutusOfBorg> hi pitti can you please retry json-c autopkgtest against u1db in proposed? 13.10-6ubuntu1 or 13.10-6.2 is fine either way
[07:37] <LocutusOfBorg> it was a bad autopkgtest I fixed yesterday
[07:37] <LocutusOfBorg> AFAIK this will make the json-c transition look better :)
[07:39] <sarnold> LocutusOfBorg: hmm, this thing says "13.10-6" http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#json-c
[07:40] <LocutusOfBorg> yes, it is the -release version
[07:40] <LocutusOfBorg> now proposed has 13.10-6ubuntu1 and upcoming 13.10-6.2 (dinstalling right now)
[07:40] <LocutusOfBorg> both are fine
[07:41] <LocutusOfBorg> oops my upload was called 13.10-6.1ubuntu1
[07:41] <LocutusOfBorg> but I sync'd the same change half an hour ago
[07:48] <elbrus> autopkgtesting; anybody here that knows how to get a package installed before the package to test?
[07:49]  * elbrus tries to test cacti, but that depends on a mysql-server | mariabd-server (but cacti doesn't (need to) depend on it
[07:49] <elbrus> )
[07:50] <jtaylor> add it to the Depends in the tests/control?
[07:50] <elbrus> jtaylor: it get's installed AFTER cacti (instead of before)
[07:51] <elbrus> see: https://ci.debian.net/data/packages/unstable/amd64/c/cacti/20160428_043001.autopkgtest.log.gz
[07:51] <elbrus> or to be more precise: setup after cacti setup
[07:51] <jtaylor> urg, maybe add needs-root and install it yourself
[07:53] <elbrus> jtaylor: is that allowed (e.g. do you have network/repository available)?
[07:54] <pitti> LocutusOfBorg: running: http://autopkgtest.ubuntu.com/running.shtml#pkg-u1db
[07:54] <elbrus> so then you wouldn't need anything in Depends in tests/control
[07:54] <pitti> LocutusOfBorg: the armhf one will still take a bit, I'll probably just hint it in
[07:54] <pitti> (once the other arches succeed)
[07:55] <jtaylor> if its not allowed the infrastructure should just ignore it
[07:55] <pitti> elbrus: if cacti doesn't depend on mysql, then apt will randomly pick an order in which to configure them
[07:56] <pitti> elbrus: so if cacti's postinst tries to configure mysql, it shuold get at least a recommends: mysql then, to force configuration order in apt?
[07:56] <pitti> elbrus: I mean, this is an actual problem, not just a test artifact
[07:57] <elbrus> pitti: but it depends on the client and theserver is normally remote
[07:57] <LocutusOfBorg> thanks
[07:57] <elbrus> so no recommends
[07:58] <pitti> elbrus: then I guess the postinst needs to gracefully handle mysql not being available?
[07:58] <LocutusOfBorg> if I understand correctly, once the autopkgtestsuite is green I can see what is missing on update_output, right?
[07:58] <pitti> LocutusOfBorg: right
[07:58] <LocutusOfBorg> because with no transition tracker I have difficulties in looking at what is wrong
[07:58] <LocutusOfBorg> thanks
[07:58] <elbrus> pitti: that is the case: dbconfig-common: cacti configure: noninteractive fail.
[07:58] <elbrus> dbconfig-common: cacti configure: ignoring errors from here forwards
[07:58] <pitti> LocutusOfBorg: we can add transition trackers
[07:58] <LocutusOfBorg> pitti, I think just two or three packages are wrong, and just for some archs
[07:59] <pitti> dpkg: error processing package cacti (--configure):
[07:59] <LocutusOfBorg> not needed I gues
[07:59] <pitti>  subprocess installed post-installation script returned error exit status 1
[07:59] <pitti> not enough then apparently :)
[07:59] <LocutusOfBorg> I fixed all the packages, the failures are related to boost and or fPIC stuff
[07:59] <LocutusOfBorg> BTW whill anybody fix virtualbox/amd64 at the end? I'm not really sure about the fPIC stuff
[08:00] <LocutusOfBorg> s/whill/will ENOCOFFEE
[08:20] <tjaalton> doko: there seems to be an issue with openjdk-6-jre, which depends on tzdata-java which then is uninstallable. could jre drop the dependency on tzdata-java?
[08:20] <tjaalton> this on enial
[08:20] <tjaalton> +x
[08:21] <seb128> doko, did you ask about gtk+ yesterday because you want 3.20? because we don't plan to update to that version yet (and maybe not this cycle because it might be too much work to fix theme and apps then)
[08:22] <elbrus> pitti: granted, I made a mistake in my postinst in the latest cacti package for the noninteractive case, but that still leaves the package non-functional...
[08:24] <elbrus> pitti: do you know it the order in the tests/control Depends field matters?
[08:25] <pitti> elbrus: that's up to apt (it more or less gets tossed to apt as it is)
[08:25] <pitti> elbrus: so, it could be
[08:25] <pitti> elbrus: but still, this is a real bug, easier to just fix it than trying to hide it in the test control?
[08:25] <elbrus> hmm, will try in my next upload than (albeit not robust I guess)
[08:26] <pitti> elbrus: yeah, I don't think you can rely on the order there
[08:26] <darkxst> seb128, hmm really? we need gtk+ 3.20 this cycle
[08:26] <elbrus> pitti: I will fix the real but, but mysql-server should NOT be recommends or Depends as it is on a remote server (or at least allowed)
[08:26] <seb128> darkxst, you are welcome to work on the update, just need the themes and apps to be fixed before landing
[08:26] <pitti> elbrus: yeah, understood; I meant the bug in the postinst that it fails if mysql isn't available
[08:26] <elbrus> pitti: sure, will fix that
[08:28] <darkxst> seb128, which apps? most all of the GNOME ones are already fixed
[08:28] <darkxst> I am not really familiar with the ubuntu theme though
[08:29] <seb128> doko, darkxst, https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1576576 in any case
[08:29] <seb128> so nobody updates it by mistake :p
[08:29] <seb128> darkxst, dunno, I didn't look at it at all, there was a blogpost on planet GNOME saying that gnumeric looks buggy, there are probably others
[08:29] <seb128> darkxst, I expect the big part of the work to be to update the unity themes
[08:29] <seb128> those are being and not maintained for years
[08:30] <seb128> and we don't have anyone knowing theming well and/or available to work on that
[08:30] <andrewsh> hmm
[08:31] <andrewsh> every time I plug a USB smartcard reader, something (gnome-software?) triggers org.freedesktop.packagekit.trigger-offline-update
[08:31] <andrewsh> can that be disabled?
[08:31] <darkxst> seb128, firefox is a bit glitchy but imagine upstream will fix that
[08:32] <seb128> andrewsh, our packagekit version doesn't support that I think so it shouldn't do anything?
[08:32] <darkxst> seb128, its going to be hard to stage on a ppa
[08:32] <seb128> darkxst, why?
[08:32] <andrewsh> seb128: well, I get a notification "updates available"
[08:32] <darkxst> I mean are we meant to go through every single gtk3 app in the archives
[08:32] <seb128> andrewsh, that has nothing to do with trigger-offline-update though
[08:33] <seb128> darkxst, no, just what is installed by default on the flavors I would expect
[08:33] <andrewsh> seb128: possibly, yet gnome-software itself is being triggered
[08:33] <seb128> unity/GNOME/xfce
[08:33] <andrewsh> can *that* be disabled?
[08:33] <seb128> andrewsh, no
[08:33] <seb128> knowing about updates is a feature
[08:33] <seb128> though it should be fixed to not overnotify
[08:34] <seb128> like it should do it once a day max
[08:34] <andrewsh> well, I have everything I wanted to update updated really
[08:34] <seb128> you have updates you decided to not apply?
[08:34] <andrewsh> well, yes, libfreetype6
[08:34] <andrewsh> it breaks my fonts
[08:35] <andrewsh> so I have re-applied the patch upstream didn't like
[08:35] <seb128> andrewsh, anyway, please open a bug about gnome-software about it notifying you on card reader events, that's buggy
[08:35] <andrewsh> from journalctl -f it seems it's triggered on any USB plug/unplug event
[08:35] <andrewsh> that sounds useful for some situations, but not in this case
[08:36] <seb128> we need to make it less spammy for sure
[08:36] <seb128> but disabling it totally is not the solution
[08:36] <andrewsh> one more question: something re-sets the keyboard layout to English on login (I have a custom layout), what can that be?
[08:37] <andrewsh> I'd happily debug and write a patch for that myself, I don't know where to look
[08:37] <andrewsh> whole Unity stuff looks a bit opaque to me
[08:38] <seb128> andrewsh, the unity-settings-daemon keyboard plugin most likely
[08:38] <andrewsh> full disclaimer: I have the default layout (I haven't configured anything in Unity), but run setxkbmap after login
[08:38] <darkxst> seb128, we don't have the manpower to deal with 3 entire flavours
[08:38] <andrewsh> and after that runs something resets it back
[08:38] <darkxst> seb128, but without the gtk+ update, there is little point us even releasing a 16.10
[08:38] <andrewsh> so if I run it manually it persists, but not if it's done from .xsessionrc or autostarts
[08:39] <seb128> andrewsh, you can try to "gsettings set org.gnome.settings-daemon.plugins.keyboard active false" and see if it workarounds it for you
[08:40] <andrewsh> thanks, let's see
[08:40] <seb128> darkxst, yeah, I'm sorry
[08:40] <seb128> unsure what to do
[08:40] <seb128> but we can just update and say "screw unity and other non GNOME flavors"
[08:40] <seb128> can't
[08:41] <seb128> well maybe it's going to be fine and not that much
[08:41] <seb128> but I've a feeling fixing themes isn't going to be trivial
[08:41] <andrewsh> definitely not
[08:41]  * andrewsh has an experience
[08:41] <andrewsh> I ported Clearlooks-Phénix two times
[08:41] <andrewsh> not willing to anymore
[08:42] <darkxst> seb128, well xfce doesnt use gtk3 themes i didnt think, but unity themes will be plenty of work
[08:46] <darkxst> seb128, there is no one left on the -desktop team, that understands the unity themes?
[08:47] <seb128> not since larsu left
[08:47] <seb128> also we don't have much resources to spend on that atm
[08:47] <darkxst> damn
[08:47] <seb128> the LTS is more important than the new updates
[08:47] <Unit193> darkxst: Xfce doesn't entirely use GTK3, but it does use it and of course the themes have to support it.
[08:50] <darkxst> seb128, atm the moment yes, but we have 1000's of users screaming at us if there in no update in 16.10
[08:50] <darkxst> s/we/we will/
[08:50] <seb128> :-/
[08:50] <darkxst> we already get enough complaints at being one cycle behind, but I don't mind that myself
[08:51] <darkxst> well really 5 months behind
[08:53] <seb128> darkxst, did you try to log into an unity session with gtk 3.20 just to see how buggy the theme looks like?
[08:54] <darkxst> seb128, no, because I know it will be buggy
[08:54] <darkxst> what I do know is exactly how much effort is required to port unity to css nodes
[08:55] <darkxst> s/do/don't/
[08:55] <seb128> right, same here, I've no clue about css and how different the new gtk stuff is
[08:55] <darkxst> and I wouldn't expect it to land in a broken state
[08:55] <seb128> but I've a feeling it's not going to be trivial
[08:56] <darkxst> but guess I was hoping someone would work on it
[08:56] <seb128> we could maybe try to bounty/contract the work if we know of somebody who would be interested...
[08:57] <seb128> I don't have any name in mind of whoever could be interested though
[08:58] <darkxst> seb128, I only know one themer, and I can't remember how to spell his name!
[08:59] <darkxst> though he maintains a few gtk themes
[09:02] <seb128> darkxst, the name even spelt wrong can be useful :-)
[09:02] <darkxst> seb128, https://launchpad.net/~satyajit-happy
[09:02] <tjaalton> huh, xenial has openjdk-6 binaries but no source
[09:02] <seb128> willcooke, ^
[09:03] <seb128> darkxst, in any case we are trying to find a solution, but I expect the new gtk isn't going to be ready to land any time soon
[09:03] <darkxst> he is the author of the very popular numix theme
[09:03] <willcooke> I'll reach out to him and see if he could help
[09:04] <seb128> thanks
[09:04] <darkxst> seb128, soon is not a requirement, just this cycle (with enough time to land everything else!)
[09:04] <seb128> right, I prefer to mention it early so we can try to find help to work on this
[09:04] <seb128> because otherwise it's likely it's not going to happen
[09:09] <darkxst> seb128, yes it needs a solution ;)
[09:11] <Odd_Bloke> I'm looking at a xenial server installation, and it has backports enabled.  However, that line is commented out when it is added in live-build/auto/build (line 139).  What uncommented it?
[09:14] <darkxst> willcooke, he (Satyajit) was involved with the Ubuntu GNOME teams for a while, but moved onto other project
[09:16] <tjaalton> doko: nevermind, mirror being out of date
[09:17] <willcooke> darkxst, thx.
[09:18] <darkxst> anyway I just sat down from a 5hr drive home, discussing gtk+ can wait!
[09:19] <willcooke> :)
[09:25] <morphis> jibel, davmor2: can we land https://requests.ci-train.ubuntu.com/#/ticket/1256 ? failed automated sign off seems to be due to a runtime problem
[09:30] <davmor2> morphis: that is a job for Mirv maybe or sil I don't think we touch it past testing it
[09:31] <morphis> ok
[09:31] <morphis> Mirv: ^^
[09:40] <Mirv> morphis: done
[09:44] <morphis> Mirv: awesome!
[09:50] <LocutusOfBorg> can anybody please kill this with FIRE? https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu22/+build/9658082
[09:50] <LocutusOfBorg> ginggs, ^^^
[09:50] <LocutusOfBorg> ok, somebody did it, thanks
[09:52] <happyaron> it's still building
[09:52] <happyaron>  [BUILDING] Currently building on z13-018   Build score:4010 (What's this?)   Started 1 minute ago
[09:52] <LocutusOfBorg> it was cancelling, and ginggs retried it while posting here :)
[09:52] <LocutusOfBorg> yep
[09:52] <LocutusOfBorg> ta
[09:55] <LocutusOfBorg> upstart, why you so sad?
[09:57] <darkxst> LocutusOfBorg, because it always gets accused of being a Canonical NIH systemd init, even though it came first :p
[09:58] <LocutusOfBorg> it doesn't explain why the combination upstart/s390x is so sad
[09:59] <LocutusOfBorg> darkxst, did you manage to stop seeding xorg-legacy package from the gnome flavour? it would be nice to do it for yakkety
[09:59] <darkxst> LocutusOfBorg, I can't seed virtualbox-dkms its in multiverse
[09:59] <darkxst> LocutusOfBorg, code doesnt have feelings anyway!
[10:00] <LocutusOfBorg> there is the kernel module in src:linux!
[10:00] <LocutusOfBorg> you can use that
[10:00] <darkxst> LocutusOfBorg, has it been updated?
[10:01] <LocutusOfBorg> in -proposed
[10:01] <LocutusOfBorg>  4.4.0-22.38
[10:01] <darkxst> LocutusOfBorg, ok, remind me when it lands, and I will test and update seeds for yak
[10:01] <LocutusOfBorg> ta
[10:02] <LocutusOfBorg> you might already do some testing with the -proposed one, just to be sure ;)
[10:05] <darkxst> LocutusOfBorg, not tonight, I just drove home 5 hrs through heavy rain ;(
[10:10] <LocutusOfBorg> Hi, question probably for -release, but I'll ask here anyway. what should be done to remove src:libpng from yakkety?
[10:11] <LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/transitions/html/libpng.html
[10:11] <LocutusOfBorg> can we "demote" something in -proposed and remove it from release until stuff gets fixed?
[10:11] <LocutusOfBorg> e.g. polybori needs an rm of armhf
[10:11] <darkxst> LocutusOfBorg, that is a massive transition
[10:11] <LocutusOfBorg> s/a massive/a finished massive/
[10:13] <darkxst> how can it be finished if there is still broken stuff? anyway if broken stuff is in universe and unmaintained -release team can demote
[10:13] <LocutusOfBorg> pcl is going to be fixed with vtk6 transition, polybory needs a single binary removed, gst-plugins-good0.10 why you still there? k3d I might fix but it is boost- related
[10:13] <LocutusOfBorg> darkxst, finished because the broken stuff is "who cares" and broken in debian anyway
[10:15]  * darkxst has been off in the mountains, mostly offline for the last week, but that seems like a good enough reason
[10:15] <LocutusOfBorg> I would prever removing 10 packages or demoting instead of having two libpng implementations, specially for stuff that isn't also part of stretch
[10:15] <LocutusOfBorg> maybe I'll fix two or three packages and then request it
[10:19] <darkxst> LocutusOfBorg, have the packages been removed from debian?
[10:19] <LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822318
[10:20] <LocutusOfBorg> gonna be
[10:20] <cjwatson> we shouldn't remove libpng until it stops having rdeps
[10:20] <LocutusOfBorg> fixing the fixable and then remove what is remaining
[10:21] <darkxst> cjwatson, no, removing the rdeps I think is what LocutusOfBorg is talking about, thats fair game if they are gone from debian
[10:21] <darkxst> libpng will disappear by itself when ready I assume
[10:22] <LocutusOfBorg> yes indeed, we are doing this on debian
[10:22] <cjwatson> sure, but maybe LocutusOfBorg needs to check rdeps before asking questions like "gst-plugins-good0.10 why you still there"
[10:22] <LocutusOfBorg> but many of the blockers are armel and hurd
[10:22] <LocutusOfBorg> so ubuntu should be easier
[10:22] <cjwatson> I mean "reverse-depends src:gst-plugins-good0.10" answers that question immediately
[10:22] <LocutusOfBorg> oh... I wasn't aware of reverse-deps
[10:23] <cjwatson> LocutusOfBorg: I've removed polybori/armhf
[10:24] <cjwatson> and while we can demote stuff to -proposed, I'd rather not do that for stuff with rdeps, it gets complicated
[10:24] <LocutusOfBorg> ok, but reverse-dependencies of gst-plugins-good0.10 are out of debian testing and unstable
[10:24] <LocutusOfBorg> the only one is plasma-mediacenter where it is a recommend
[10:25] <LocutusOfBorg> what to do in this case? btw thanks for polybori
[10:25] <cjwatson> IIRC there was a bug about farstream, it wasn't entirely trivial
[10:25] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/telepathy-qt5/+bug/1538772
[10:27] <LocutusOfBorg> seems it is going to disappear from that bug
[10:27] <LocutusOfBorg> wonderful
[10:27] <cjwatson> doko: mind if I merge ffmpeg?
[10:27] <cjwatson> that would clear out mplayer from that transition tracker, I think
[10:27] <LocutusOfBorg> thanks cjwatson for doing it!
[10:27] <LocutusOfBorg> cjwatson, yes
[10:28] <LocutusOfBorg> I was wondering to do it, but thanks
[10:28]  * LocutusOfBorg is fixing boost stuff
[10:29] <TJ-> anyone know what package/process writes /etc/initramfs-tools/conf.d/resume  originally?
[10:29] <cjwatson> TJ-: base-installer / ubiquity
[10:30] <TJ-> cjwatson: Ahhh! I've been trying to figure out what wrote an incorrect UUID that doesn't exist there!
[10:30] <TJ-> cjwatson: is that file totally manually administered then? no tools to do it?
[10:31] <cjwatson> TJ-: correct afaik
[10:31] <TJ-> cjwatson: OK... I'm not going mad then :D Been searching all the .postinst and initramfs-tools hooks trying to figure out what wrote it :)
[10:32] <LocutusOfBorg> btw xcftools on s390x <-- is that important? I don't have stuff/machines to fix that testsuite failure
[10:32] <LocutusOfBorg> cjwatson, if you want to remove it :p
[10:33] <cjwatson> not particularly with zero investigation
[10:34] <LocutusOfBorg> -- 10x10+27+27 RGB-alpha Normal AE=AE
[10:34] <LocutusOfBorg> +- 10x10+27+27 RGB-alpha Normal Æ=AE
[10:34] <LocutusOfBorg> seems something locale-related
[10:34] <cjwatson> probably related to recent change to C.UTF-8
[10:35] <cjwatson> so should be fixed as that's not intrinsically s390xish
[10:35] <cjwatson> it just happens that s390x has a newer buildd base system than the others so probably a slight difference in behaviour there
[10:36] <LocutusOfBorg> sigh, I don't know how to fix UTF stuff :(
[11:16] <andrewsh> lool: you haven't forwarded LP: #1290069 ;)
[11:21] <lool> andrewsh: I did actually! https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758728
[11:21] <andrewsh> actually you have, yes :)
[11:21] <andrewsh> lool: I haven't checked the BTS, I just saw the patch not applied in Debian :)
[11:22] <andrewsh> it's probably the time for an NMU
[11:24] <andrewsh> lool: where does /etc/ld.so.conf.d/fakeroot-<multiarch-triplet>.conf file comes from?
[11:24] <andrewsh> I can't find any mention of it in the package
[11:26] <lool> andrewsh:         echo /usr/lib/$(DEB_HOST_MULTIARCH)/libfakeroot > debian/libfakeroot/etc/ld.so.conf.d/fakeroot-$(DEB_HOST_MULTIARCH).conf
[11:26] <lool> andrewsh: in rules
[11:26] <andrewsh> hmm
[11:26] <andrewsh> somehow I missed that
[11:28] <andrewsh> I'm basically trying to fix #636192 in pseudo
[11:50] <doko> cjwatson, not at all
[11:51] <doko> tjaalton, xenial doesn't have openjdk-6 anymore ...
[11:52] <tjaalton> doko: yeah, and I noticed that dropping i386 from my mirror was a bad idea, apt stopped using it at all
[11:53] <tjaalton> so the package lists on this machine were over a month old and still showed it
[11:55] <doko> sbeattie, slangasek: dpkg and python2.7 uploaded
[11:59] <doko> ginggs, postgis test failures on s390x and arm64, qgis build failures on ppc64el and powerpc
[12:04] <ginggs> doko: thanks, will take a look
[12:10] <ginggs> LocutusOfBorg: the qgis ftbfs is also in Debian, bug #822477
[12:11] <ginggs> err, Debian bug #822477
[12:11] <ginggs> yes
[12:18] <LocutusOfBorg> ack
[12:20] <LocutusOfBorg> ginggs, https://github.com/qgis/QGIS/commit/fc6559aa053317cda8ced657c3013a0d4c6549e9
[12:20] <LocutusOfBorg> we got a patch
[12:46] <stokachu> im getting an error regarding E: openstack: init.d-script-not-included-in-package etc/init.d/openstack, even though im only packaging a openstack.service systemd file
[12:46] <stokachu> what am i missing?
[12:47] <stokachu> i set dh $@ --with systemd also
[12:52] <LocutusOfBorg> xnox, k3d FTBFS because of missing boost_system link, but a quick look seems to make me wonder about a bug in boost itself
[12:52] <LocutusOfBorg> because it doesn't use directly system boost library
[12:52] <barry> Unit193: any chance you can file a bug+patch over in debian?  it'd be nice now that we're resync'd not to continue to carry an ubuntu delta
[13:07] <LocutusOfBorg> cjwatson, can I ask you to remove insighttookit from Ubuntu? vmtk on powerpc needs probably a removal, we removed every arch except amd64 and i386 for debian
[13:10] <cjwatson> LocutusOfBorg: not now sorry, on leave this afternoon
[13:10] <cjwatson> LocutusOfBorg: find another victim please :)
[13:11] <pitti> LocutusOfBorg: insighttoolkit has built fine on all arches in the current version
[13:11] <LocutusOfBorg> pitti, this doesn't mean it shouldn't be killed with fire :)
[13:12] <LocutusOfBorg> we are switching to insighttoolkit4 available since years
[13:12] <pitti> same for vmtk
[13:12] <LocutusOfBorg> also vtk->vtk6
[13:12] <LocutusOfBorg> yes, but insighttookit has issues that can't be backported from itk4
[13:12] <seb128> dholbach, https://blueprints.launchpad.net/sprints/uos-1605 seems pretty empty, am I looking at the wrong place?
[13:13] <LocutusOfBorg> it needs to go, even if itk4 only builds in two archs (because upstream stopped supporting everything else)
[13:13] <LocutusOfBorg> so, I'll probably ask some powerpc removal (if nobody fixes insighttoolkit4 there)
[13:13] <pitti> LocutusOfBorg: ah, it was just removed from sid, but https://tracker.debian.org/pkg/insighttoolkit didn't catch up with that yet?
[13:13] <dholbach> seb128, a lot of people decided to just create meetings in summit instead
[13:13] <cjwatson> oh if it was only just removed then you don't need to ask
[13:13] <pitti> LocutusOfBorg: so that should turn up in process-removals
[13:13] <dholbach> seb128, for the sessions where they felt they don't need a blueprint
[13:14] <cjwatson> process-removals will catch up with it at some point
[13:14] <dholbach> seb128, http://summit.ubuntu.com/uos-1605/create_meeting/
[13:14] <LocutusOfBorg> really? that is a nice feature!
[13:14] <cjwatson> file a bug if you want vmtk/powerpc removed
[13:14] <seb128> dholbach, k, is submit having them all or is there unscheduled ones?
[13:14] <LocutusOfBorg> cjwatson, I'll file one probably when also vtk gets removed
[13:14] <cjwatson> process-removals is only semi-automatic (i.e. somebody has to run it and think about its output) but it deals with a lot of this stuff
[13:14] <pitti> dholbach: so https://blueprints.launchpad.net/ubuntu/+spec/convergence-y-replace-upstart still doesn't appear on the summit page; expected, or does it need to be renamed furhter?
[13:14] <LocutusOfBorg> lets wait some more time, I guess it is too early
[13:15] <LocutusOfBorg> I can provide some more stuff to remove in a single shot
[13:15] <cjwatson> if stuff is removed from Debian then there's no need to ask unless it's for some reason especially urgent or if it doesn't seem to be removed from Ubuntu within a week or two
[13:15] <LocutusOfBorg> urgency for me is now+4 months :)
[13:16] <cjwatson> which probably means that either (a) AAs are slacking and not dealing with removals or (b) there's something like rdeps holding it in
[13:22] <dholbach> pitti, ah no, it's there - I just need to put it on the schedule
[13:22] <pitti> dholbach: awesome, thanks; can you make it not Tuesday, so that I've got some time to prepare on the sprint?
[13:22] <dholbach> yep
[13:22] <pitti> I also have some meetings on Tue
[13:22] <pitti> cheers
[13:23]  * pitti hugs dholbach
[13:23] <dholbach> put it on for Wed
[13:23] <pitti> splendid, that's 11:00 in Austin
[13:23] <pitti> seb128: ^ but that's already 20:00 CEST, is that still ok for you?
[13:23] <pitti> sorry, no, it's 13:00 in Austin
[13:24] <pitti> time zones are hard
[13:25] <seb128> pitti, does it still make it 20CEST? or +2 to 22 as well?
[13:25] <pitti> seb128: no, it's 18:00 UTC
[13:25] <pitti> seb128: earlier is fine for me, if you want it earlier
[13:25] <seb128> one hour earlier would be better
[13:25] <pitti> although Wed is already pretty full on http://summit.ubuntu.com/uos-1605/track/convergence/
[13:25] <seb128> I've tennis on wed evening
[13:26] <seb128> well I guess I can skip for once
[13:26] <pitti> nah
[13:26] <pitti> dholbach: how much beer does it cost us to move it to Thu morning?
[13:26] <pitti> seb128: le sport est très important :-)
[13:26] <seb128> :-)
[13:26] <smoser> pitti, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1575572
[13:27] <pitti> smoser: o/
[13:27] <smoser> does your intended fix support proper systemd jobs ?
[13:27] <pitti> smoser: working on it
[13:27] <smoser> that wasnt clear to me.
[13:27] <pitti> smoser: it's not really related to init.d vs. units
[13:27] <smoser> right.
[13:27] <pitti> smoser: init.d scripts get "converted" to units by a generator, so on that level they all look the same
[13:27] <smoser> ok.
[13:27] <pitti> smoser: i. e. in short: "yes"
[13:28] <pitti> smoser: well-spotted bogus runlevel failure check, I'm just committing the fix for that
[13:29] <dholbach> pitti, done
[13:29] <smoser> that script is kind of scary
[13:29] <pitti> dholbach: double-hug
[13:29] <dholbach> :-)
[13:29] <pitti> smoser: amen :(
[13:30] <smoser> i'm sort of afraid to *fix* the check for failure
[13:30] <pitti> smoser: one can feel the 15 years of ad-hoc development :/
[13:31] <pitti> smoser: that part will get short-circuited under systemd anyway, I tested it under sysvinit; still need to test it under upstart
[13:32] <pitti> smoser: but it shoudln't actually have much net effect: even though *that* test failed, the remainder of the code would just run with RL=unknown, which would make it bail out with 102 as well in verifyrclink()
[13:33] <pitti> oh, actually not
[13:33] <pitti> it just bails on bad symlinks, not on nonexisting ones
[13:33] <pitti> smoser: anyway, I think I won't SRU that fix, that's just for unstable/yakkety
[13:34] <smoser> ok.
[13:34] <smoser> thank you pitti
[13:34] <pitti> smoser: the one important for SRU is to provide a proper runlevel under systemd while it's not booted yet
[13:34] <pitti> smoser: unless you object
[13:34] <smoser> so cloud-init wills til have issues starting services that have and expect dependencies.
[13:34] <pitti> smoser: but as you say, I'd rather not change this more than necessary, it's scary
[13:34] <smoser> wills till == will still
[13:35] <pitti> right; I tried to explain in the bug, that's a bit subtle
[13:35] <smoser> yeah.
[13:35] <smoser> that still sucks. but for now this is a good fix.
[13:35] <pitti> it's not actually that different from sysvinit
[13:35] <smoser> right.
[13:36] <pitti> i. e. starting a service with invoke-rc.d under sysvinit had no concept of dependencies in the first place
[13:36] <smoser> see my last comment there, this issue can be exposed without cloud-init very easily.
[13:36] <pitti> smoser: indeed, I ran into it myself a week or two ago
[13:36] <smoser> :)
[13:37] <pitti> smoser: so, I don't think the dependency thing is a very big deal, but I wanted to note it for completenless
[13:37] <pitti> smoser: maybe we can haul the whole thing until after the boot has done
[13:37] <pitti> smoser: but that sounds like a discussion for next week, and it desperately needs beer involved
[13:37] <smoser> yeah.
[13:38] <pitti> s/has done/has finished/, argh grammar, TGIF
[13:38] <smoser> what is neat is that you get to run stuff "after" boot without being part of boot
[13:38] <smoser> becauase if you're part of boot, then you are screwed.
[13:38] <smoser> which seems kind of broken
[13:38] <pitti> smoser: "you get" -> "you want it to"? or "there is some trick to do it"?
[13:39] <smoser> you get -> you have to
[13:39] <pitti> smoser: my trick was to spawn a shell script in the background in runcommand
[13:39] <pitti> and in that script, wait until the sysetm is booted
[13:39] <pitti> which was a cheap 10-second hack, if we want to provide this in cloud-init, we'd do that with a bit more style of course
[13:39] <smoser> yeah. how elegant :)
[13:40] <pitti> like, we'd just start (non-blocking) cloud-init-blah during boot, so that it runs after the boot sequence
[13:40] <pitti> anyway, let's fix this thing first
[13:41] <smoser> i'm gonna remove the cloud-init task from this
[13:41] <smoser> i'll open anotehr bug for "fully support package installation in systemd"
[13:44] <pitti> smoser: yep, seems fair
[13:45] <smoser> done. https://bugs.launchpad.net/cloud-init/+bug/1576692
[14:08] <doko> pitti, please let gcc-6 migrate, not yet used for builds
[14:10] <pitti> doko: hintifiziert
[14:11] <doko> gstreamer0.10 gone \o/
[14:12] <pitti> yay
[14:12] <pitti> just about two weeks too late :)
[14:12] <ogra_> just in time for 16.06 ;)
[14:15] <doko> pitti, I only see now https://bugs.launchpad.net/ubuntu/+source/telepathy-qt/+bug/1538772 ...
[14:15] <doko> both the telepathy-qt and telepathy-qt5 packages were somehow unmaintained in Ubuntu, so I took the Debian one
[14:17] <pitti> doko: yeah, that seems fine; the remaining delta in xenial was
[14:17] <pitti>   * debian/control: Change libssl1.0.2 build dependency to libssl-dev (in
[14:17] <pitti>     Ubuntnu the library is called libssl1.0.0).
[14:19] <doko> ginggs, the pcl ftbfs is now a boost related one
[14:20] <doko> ahh, crap, wrong changelog entries for the gdal transition ...
[14:23] <ginggs> doko: i thought so too, but pcl and yade both build on boost1.60 and vtk6 built in xenial
[14:23] <seb128> doko, pitti, isn't telepathy-qt5 used by ubuntu-touch?
[14:24] <doko> seb128, doesn't have a touch version number
[14:24] <seb128> right, they use packages from the archive
[14:24] <seb128> they don't fork everything
[14:25] <doko> I would call a separate source a fork
[14:25] <seb128> I don't understand what you mean
[14:25] <seb128> they don't use a separate source
[14:25] <seb128> you delete it from the main archive it seems?
[14:28] <doko> ugh,
[14:28] <doko>   * Renaming source package until upstream supports building both Qt4 and Qt5
[14:28] <doko>     versions from the same source (and with Qt5 final)
[14:29] <doko> so looks like I need to re-add these to the telepathy-qt package :-/
[14:29] <doko> next week
[14:30] <seb128> doko, yes please
[14:35] <siretart> mvo: I've uploaded apt-btrfs-snapshot, but it FTBFS on the launchpad builders: https://launchpad.net/ubuntu/+source/apt-btrfs-snapshot/3.5/+build/9658733 - I also cannot reproduce that failure in my yakkety lxd machine, it builds just fine there.
[14:35] <siretart> mvo: do you have cycles to look at it? if not, I'm inclined to disable the test
[14:35] <mvo> siretart: ok, I have a look
[14:36] <mvo> siretart: silly question, did you commit the changes anywhere? I am fine merging them via debdiff, just double checking
[14:37] <siretart> mvo: yes, I've uploaded it to lp:~siretart/apt-btrfs-snapshot/yakkety, and proposed that branch for merging into lp:apt-btrfs-snapshot/trunk, you should have received an email requesting a code-review
[14:38] <mvo> siretart: \o/ thank you
[14:40] <doko> seb128, there are no patches left
[14:40] <seb128> doko, ok, good then, thanks for checking :-)
[14:41] <doko> seb128, well, but then we did had to keep it for xenial ... and gst0.10 :-/
[14:46] <pitti> doko: glibc FTBFS in yakkety on amd64<EMAIL_ADDRESS>[14:46] <pitti> doko: "__stack_chk_fail_local' isn't defined" sounds weird -- did that change in the new gcc-5?
[14:47] <pitti> I guess I can ignore that for the new libselinux
[14:55] <pitti> smoser: I have a fix now, followed up to the bug
[15:00] <doko> pitti, please re-run with the currently rebuilding gcc-5, as apw noted, it had issues turning off pie
[15:00] <pitti> doko: I see, thanks
[16:29] <doko> Laney, update-output-helper needs an update, no .bz2 files anymore
[16:30] <pitti> LocutusOfBorg: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt has json-c FYI
[16:31] <LocutusOfBorg> thanks!
[16:31] <LocutusOfBorg> we have a tracker now
[16:31] <LocutusOfBorg> and doko just fixed the ben file
[16:31] <LocutusOfBorg> so I'll wait
[16:31] <pitti> ah, cool
[16:38] <infinity> LocutusOfBorg: I fixed it a little harder (to match Debian's), but maybe that wasn't necessary.
[16:39]  * infinity shrugs.
[16:39] <LocutusOfBorg> who knows? :)
[16:39] <pitti> tedg, Laney: can one of you please pull https://code.launchpad.net/~pitti/indicator-session/dep-fix into lp:indicator-session? the branch can't be pushed by core-dev (can you please fix that too?)
[16:40] <pitti> (already uploaded)
[16:41] <infinity> pitti: Did something Provides: systemd-services in xenial?  I'm assuming yes, or that would have been completely broken.
[16:41] <pitti> infinity: yes, C:/R:/P:
[16:41] <pitti> but I dropped that now that the LTS is out of the door
[16:41] <infinity> Ah-ha.
[16:42] <pitti> we've been dragging that along for 3 cycles or so
[16:42] <tedg> pitti: Sure, I'll review it and we can get it into the train?
[16:42] <pitti> tedg: it's already uploaded to yakkety
[16:42] <tedg> Yeah, we'll try to keep the vivid phone overlay and everything in sync.
[16:42] <pitti> I just usually push the tag and release commit after dput succeeds (a habit)
[16:43] <infinity> tedg: No need to be in sync for this, it can just go out the next time someone pushes something else on top.
[16:43] <pitti> tedg: this commit isn't relevant for vivid, so it's not urgent at all to land that in vivid (it can be dragged along with the next overlay landing though)
[16:43] <tedg> Yup
[16:43] <pitti> thanks
[16:45] <pitti> haha
[16:45] <pitti> https://code.launchpad.net/~seb128/indicator-session/correct-systemd-depends/+merge/285454
[16:45] <pitti> sorry seb128
[16:45] <pitti> apparently that didn't land for two months :/
[16:45] <pitti> but it's equivalent, so commit whichever you prefer :)
[16:49]  * pitti waves a good weekend to everyone, time to pack; see some of you next week in Austin!
[16:49] <infinity> pitti: See you soon!
[16:49] <LocutusOfBorg> have a nice trip
[17:20] <Unit193> balkamos: FWIW, I did poke jelmer a couple times, he's aware of the MP and even remarked rwilber commented on it (months ago.)
[17:37] <slangasek> cjwatson: hi, do you have any thoughts on bug #1576353?
[18:02] <Michal_> Hello, I installed ubuntu 16.04 and then I want install armhf in ubuntu sdk with error. Is it any bug?
[18:06] <nacc> bzoltan_: --^ ?
[18:06] <nacc> Michal_: what was the error?
[18:06] <smoser> infinity, https://bugs.launchpad.net/ubuntu/+source/sbuild/+bug/1566590
[18:06] <bzoltan_> Michal_: yes, and I have a fix for you :)
[18:07] <smoser> you made that change there. which is causing some of my unit tests to fail as any invocation of bash in my wily sbuild environment spews complaints about C.UTF-8
[18:07] <smoser> how do i fix that ?
[18:07] <bzoltan_> Michal_:  Two fixes actually... the simplest is to install ubuntu-sdk-api-15.04-armhf package and profit
[18:12] <Michal_> So you mean install via terminal?
[18:12] <Michal_> ANd will function maintance?
[18:19] <bzoltan_> Michal_: yes, sudo apt-get install ubuntu-sdk-api-15.04-armhf
[18:19] <bzoltan_> Michal_:  it will produce a brand new and not broken click chroot for you what should work
[18:20] <bzoltan_> Michal_:  please ping me if it does not
[18:26] <Michal_> Thanks, I let you know if any trouble.
[18:36] <smoser> anyone else who my have seen this. i dont know how, but i had a libc-bin at version 2.22-0ubuntu1 in my schroot. which does not appear to have existed anywhere. must have gone into proposed at some point i guess.
[18:36] <smoser> vbug 1497473 shows even related errors to it. i guess my schroot just got it and then i was stuck.
[18:59] <infinity> smoser: Fixed by making your chroot libc6/libc-bin consistent, I'm guessing?
[18:59] <smoser> i just re-created the schroot
[18:59] <smoser> so that thign got into -proposed i guess?
[19:00] <infinity> smoser: It was briefly in wily-proposed, yes, though odd that you upgraded only half of it.
[19:00] <infinity> smoser: Since libc6 and libc-bin really try to be in sync.
[19:00]  * infinity shrugs.
[19:00] <smoser> oh. i dsidnt look at libc, i dont knwo the version of it.
[19:01] <smoser> i'm sure an upgrade just happened via a nightly schroot-update
[19:01] <infinity> smoser: Oh, there was another bug in libc in that version (which was why it was pulled from proposed).
[19:01] <infinity> smoser: So, yeah.  It was probably in sync.
[19:01] <infinity> smoser: FWIW, my updates of source: chroots *don't* use post-release pockets for this (and other reasons).
[19:01] <infinity> smoser: My base chroots are release-only.
[19:02] <infinity> smoser: Anyhow, glad it was just the buggy libc from yesteryear and I don't have to panic. :)
[19:02] <smoser> yeah.
[19:06] <smoser> how would i debug why ${python3:Depends} is not doing what i think it should
[19:06] <smoser> specifically in curtin
[19:07] <smoser> i dont seem to get any of the python dependencies that are used
[19:08] <smoser> they're defined in build depends. simple ones like python3-yaml and it does 'import yaml' but the python3-curtin does not pick up a python3-yaml dependency
[19:10] <slangasek> smoser: I don't believe that python3:Depends handles modules, only the interpreter dependencies; but barry would know
[19:11] <smoser> https://wiki.debian.org/Python/LibraryStyleGuide sure acts like it should
[19:12] <slangasek> smoser: "dh_python2 and dh_python3 will correctly fill in the installation dependencies (via ${python:Depends} and ${python3:Depends} respectively" - I think that's just badly communicated
[19:17] <infinity> I think it's meant to yank deps from setup.py/requirements.txt or some such.
[19:20] <slangasek> infinity: not that I've ever heard of.
[19:21] <smoser> well, its reading it from somewhere.
[19:22] <smoser> look at cloud-init. in depends i list only python3-requests (due to the versioned depends)
[19:22] <smoser> and it picks up may more
[19:22] <slangasek> fancy
[19:23] <slangasek> smoser: are you using pybuild in curtin?
[19:23] <slangasek> you are not
[19:24] <slangasek> and you are in cloud-init
[19:24] <slangasek> smoser: so this is bound to be pybuild-provided fanciness
[19:24] <smoser> ah. buildsystem pybuild
[19:24] <smoser> hm.
[19:29] <hallyn> ok so build-deps for main pkgs can now be in universe - that includes packages with tools (say dtrace), not just library packages?  long as the tool is not required on install?
[19:31] <infinity> hallyn: Yes.  Really, it's just for tools.
[19:31] <infinity> hallyn: Since biuld-depending on a tool doesn't imply a runtime dep.  Build-depending on libfoo-dev will result in a runtime dep of libfoo if you actually use it, so it would have to be in main.
[19:33] <hallyn> thanks
[19:34] <slangasek> infinity: which means we're also now one change away from being able to have debconf in sync, too ;)
[19:34] <infinity> slangasek: I saw that, yeah.
[19:35] <infinity> slangasek: Colin did have to do a zero-hour fix to germinate and source CD building because of this, too.  Fun times.
[19:36] <infinity> slangasek: (Added an option to ignore seed follo-build-dep prefs, and then used it in source CD gen, so source CDs are GPL compliant)
[19:36] <slangasek> ah :)
[19:36] <infinity> Which started with a "hey, why are the source CDs so small this time?"
[19:36] <infinity> And some head-scratching. :P
[19:40] <nacc> so, i just noticed that http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/view/head:/samba-server referes to a package that doesn't exist (libpam-smbpass)
[19:40] <nacc> is there a good way to fix that, given xenial has been published?
[19:40] <nacc> i'm also not clear on the impact of that
[19:40] <infinity> nacc: The impact is 0.
[19:40] <nacc> infinity: ok :)
[19:40] <infinity> nacc: germinate skips packages that don't exist in the archive.
[19:40] <slangasek> nacc: we can update the seed, feel free to send an MP and be sure to also push to ubuntu.yakkety at the same time; but what infinity says
[19:40] <infinity> (Still worth cleaning up the cruft, but it doesn't hurt anything to be there)
[19:41] <nacc> and i think the replacement, libpam-winbind, is getting installed by default, but i guess it's coming in via deps
[19:41] <nacc> infinity: slangasek: ack, thanks!
[19:41] <infinity> I don't see anything pulling in libpam-winbind.
[19:41] <barry> slangasek, smoser what's the question? :)
[19:41] <infinity> ie: it's not in any tasks.
[19:41] <infinity> And has no rdeps.
[19:41] <nacc> infinity: hrm, i did a `apt-get install samba-server^` and it got installed, let me see if i can figure out why
[19:42] <nacc> infinity: oh "suggested", i just misread the output
[19:42] <smoser> well, i expected dh_python to fill in  ${python:Depends} with any thing that was used in my Build-Depends line
[19:42] <nacc> so samba-server may be not fully functional (or at least equivalent to trusty) in xenial?
[19:42] <smoser> and it seems it does at least to some affect if you use pybuild
[19:43] <infinity> nacc: libpam-winbind is for client auth, it shouldn't affect functionality of the machine as a samba server.
[19:44] <infinity> nacc: But that was true of the previous pam module too.  So not sure why it was in the task.
[19:44] <nacc> infinity: yeah, i just meant to match what was there before
[19:44] <barry> smoser: no, it won't fill in ${python:Depends} from Build-Depends
[19:44] <infinity> nacc: I don't think there's a reasonable upgrade path anyway, so it's a bit "meh" either way.
[19:44] <smoser> barry, well it does *something*
[19:44] <smoser> what does it do ?
[19:45] <smoser> (in cloud-init it definitely expands that to include some additional things)
[19:45] <slangasek> doko, apw: I caught sight of discussion of dkms in yakkety but didn't grok what the problem was; what needs to happen to un-break http://autopkgtest.ubuntu.com/packages/f/flashcache/yakkety/amd64/ ?
[19:45] <nacc> infinity: yeah, reading the description, it seems like libpam shouldn't be necessary at all and the server guide section for it doesn't actually mention it, so i think we should just remove it
[19:46] <barry> smoser: it attempts to decipher run-time dependencies from setup.py/requirements.txt and translate them into debian package names
[19:46] <nacc> infinity: ack, maybe i should ask you to update the samba serverguid section :) there's a lot of references to libpam-smbpass and i'm not finding a good guide anywhere for getting a corresponding setup to libpam-smbpass
[19:46] <slangasek> infinity, nacc: samba is happier when its users are real unix users rather than some internal virtual representation; and users are happier when their password is their password instead of having one for Unix things and one for fileshares; I believe this was the argument for the pam module being in, so that password changes DTRT
[19:47] <infinity> slangasek: Does pam_winbind DTRT locally out of the box?
[19:47] <infinity> For some value of TRT.
[19:47] <slangasek> the only difference between libpam-smbpass and libpam-winbind is that libpam-smbpass would munge the password database files on disk directly, and libpam-winbind talks to the winbind service over socket
[19:47] <slangasek> infinity: I haven't checked lately, but it /should/...
[19:48] <nacc> ok, so i'd be safe to replace smbpass with winbind in the documentation and seed (given that there are no configuration steps for libpam-smbpass either)
[19:48] <infinity> Ahh, then perhaps it indeed has a place in the task.
[19:48] <nacc> we'd be "as broken" as it is now, at least :)
[19:48] <nacc> (the documentation)
[19:49] <infinity> Note that the lack of seeding means it's in universe currently.
[19:49] <infinity> And you won't be magically fixing that in xenial until there's an SRU that we can move around.
[19:49] <slangasek> same source though, so no practical impact on security support
[19:51] <smoser> barry, and it only does that with pybuild. right ?
[19:51] <nacc> ok, so if i understood the above correctly, i'll 1) update xenial and yakkety samba-server to libpam-winbind 2) file an SRU for MIR of libpam-winbind? 3) update the serverguide documentation references to libpam-winbind
[19:51] <smoser> and if i add --buildsystem=pybuild then my tests fail right now when they try to access some files that are not installed
[19:51] <barry> smoser: well, dh_python2 and dh_python3.  i know it's kind of confusing, but it's really those two that manage ${python:Depends} and ${python3:Depends}, not pybuild
[19:52] <barry> smoser: all three have manpages which should provide some help
[19:52] <smoser> well, curint uses dh_python2 and dh_python3. but not --build-system=pybuild
[19:52] <smoser> and it as a requirements.txt and setup.py
[19:52] <smoser> but i dont get any thing in dependencies.
[19:53] <barry> hmm
[19:53] <barry> smoser: you might try to add an override_dh_python2 and pass in --verbose
[19:53] <barry> (similarly for 3)
[19:53] <barry> e.g.
[19:53] <slangasek> nacc: libpam-winbind is built from samba source; no MIR required / meaningful
[19:53] <barry> override_dh_python3:
[19:53] <barry>     dh_python3 --verbose
[19:54] <nacc> slangasek: ah right
[19:54] <hallyn> smb: around?
[19:54] <infinity> nacc: No MIR required, but we can't republish the release pocket, so for libpam-winbind to move to main, it needs to be in updates, that's all.
[19:54] <barry> i think if it used pybuild and you `export PYBUILD_VERBOSE=1` it would do that automatically, but as you say, it's not using pybuild
[19:54] <infinity> nacc: Until that happens, the seed change won't do anything, because germinate won't find the package.
[19:55] <infinity> (But feel free to update the seed first)
[19:55] <nacc> infinity: right, maybe i'm being dense or friday, but does that just mean until we do an update to the package?
[19:55] <barry> smoser: another thing to remember is that python package names (as you'd find in setup.py) are not the same as debian package names
[19:55] <infinity> nacc: And none of this will work from the server ISO until .1, because the server ISO has its own idea of tasks, based on the packages in the /pool/ on the ISO.
[19:56] <barry> smoser: often they can be guessed (e.g. prepend python3-) and i think dh_python{2,3} have a set of overrides, but sometimes they won't be guessable
[19:56] <smoser> yeah.
[19:56] <smoser> i had previously thought it did something more complex
[19:57] <smoser> and looked at the imports and saw they came from installed packagse
[19:57] <smoser> and got the package names
[19:57] <barry> nope, nothing so fancy ;)
[20:01] <nacc> slangasek: infinity: thank you both, as usual!
[20:15] <smoser> barry, so.. --requires=requirements.txt
[20:15] <smoser> (default is requires.txt). not sure how it wrks in cloud-init
[20:15] <barry> smoser: does that work?
[20:16] <smoser>  Depends: curl | wget, curtin-common (= 0.1.0~bzr380-0ubuntu1), util-linux (>= 2.20.1-1ubuntu3), python3-oauthlib, python3-pbr, python3-urllib3, python3-yaml, python3:any (>= 3.3.2-2~)
[20:16] <smoser> yeah.
[20:16] <barry> cool
[20:17] <smoser> and it must get it in cloud-init because it has a install_requires argument to setuptools.setup
[20:18] <barry> smoser: almost certainly.  dh_py invokes the egg build command and then digs it out of there
[20:20] <infinity> smoser: That util-linux dep looks obsolete, while you're in there. :P
[20:20] <smoser> infinity, as in dont need to specify it becauase its essential ?
[20:21] <infinity> smoser: Right, only need to if you need a version, and that version is precise's.
[20:52] <pitti> PSA: I have to rebuild http://autopkgtest.ubuntu.com (this only affects the web presentation, not the test machinery and proposed-migration)
[20:54] <pitti> this will take several hours, I hope not too many people need it on Friday evening/Saturday, sorry about that
[21:05] <slangasek> pitti: well, there goes my afternoon's entertainment!
[21:23] <hallyn> is there a way to ask getent for only the groupnumber, or do i have to cut/awk the output?
[21:23] <hallyn> well cut is in coreutils so i guess no biggie
[21:58] <LocutusOfBorg> upstart, you take two minutes to build
[21:58] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu22/+build/9658082
[21:59] <LocutusOfBorg> why 12 hours without doing anything
[21:59] <LocutusOfBorg> and not being killed?
[21:59] <LocutusOfBorg> cjwatson, ^^^ I would like to have a log, but seems impossible
[21:59] <sarnold> and also: why do we still have it in yak?
[22:00] <Unit193> sarnold: User sessions, indicators seem to use it somehow.
[22:03] <slangasek> yes, your client user session is still upstart; as well as your phone's init
[22:04] <Unit193> I don't have a phone running Ubuntu. :3
[22:08] <ogra_> Definitely something you should fix ;)
[22:08] <slangasek> LocutusOfBorg: this might be what you're after. http://paste.ubuntu.com/16136680/
[22:09] <LocutusOfBorg> thanks :(
[22:10] <slangasek> mmm not the only failing test, though; I guess I'll rerun to grab a full log in a minute
[22:11] <LocutusOfBorg> I'm not sure I want to fix upstart, and wasting time on it
[22:11] <slangasek> also, I'm not opposed to dropping the upstart binaries on s390x to unblock that transition
[22:11] <LocutusOfBorg> slangasek, ^^ that one <3
[22:12] <LocutusOfBorg> if it is used only for phone... who cares about s390x?
[22:12] <slangasek> so... that's interesting.  there are definitely test failures, but the build succeeded.
[22:12] <LocutusOfBorg> the problem might be that s390x has an updated toolchain, so it might become an issue also on other architectures
[22:12] <LocutusOfBorg> oh...
[22:13] <slangasek> LocutusOfBorg: it's not only phone.  it's also Ubuntu desktop, which is also irrelevant for s390x; and xfce4-indicator-plugin for some reason
[22:13] <slangasek> no, the toolchain isn't updated separately on different archs
[22:13] <Unit193> slangasek: So the indicators start, it emits the signal.
[22:14] <LocutusOfBorg> slangasek, this is something mentioned here some hours ago
[22:15] <slangasek> there is a new gcc-5 in yakkety-proposed, but it's present on all archs, as shown in e.g. this successful log. https://launchpadlibrarian.net/257148409/buildlog_ubuntu-yakkety-amd64.upstart_1.13.2-0ubuntu23_BUILDING.txt.gz
[22:17] <LocutusOfBorg> slangasek, http://irclogs.ubuntu.com/2016/04/29/%23ubuntu-devel.txt
[22:17] <LocutusOfBorg> 10:34
[22:18] <LocutusOfBorg> newer "buildd base system"
[22:18] <LocutusOfBorg> bad me, but the result should be the same right?
[22:19] <slangasek> I certainly wouldn't expect any of these test failures to be utf8 related, no
[22:19] <Unit193> LocutusOfBorg: You can link to it directly, just s/.txt/.html#t10:34/
[22:20] <LocutusOfBorg> slangasek, I don't know what has been updated in buildd system, so it might be related to updates, even if not utf8 related
[22:21]  * LocutusOfBorg is wild guessing, because he feels blind about this
[22:22] <slangasek> well, the aforementioned test failure is actually caused by me trying to run the build as root and is not related to the failure on the buildd
[22:22] <slangasek> trying a better reproducer now
[22:33] <cyphermox> cjwatson: mind if I merge ndisc6?
[22:35]  * LocutusOfBorg accoring to backlog he is AFK
[22:36] <cyphermox> LocutusOfBorg: I kind of expected it because of the time; he will answer when he's back
[23:13] <slangasek> LocutusOfBorg: ok, these are the test failures I get when testing right. http://paste.ubuntu.com/16137229/