[00:08] <doko> jtaylor, any idea about https://launchpad.net/ubuntu/+source/python-scipy/0.16.1-1build2/+build/8871562 ?
[01:06]  * mwhudson sighs
[01:06] <mwhudson> INFO: pkgstripfiles: waiting for lock (libgolang-github-pborman-uuid1-dbgsym) ...
[01:06] <mwhudson> ^ what does this mean?
[01:07] <mwhudson> oh wait, this is what doko was complaining about
[01:10] <doko> mwhudson, please wait until pkgbinarymangler is published, then cancel and give back the builds
[01:10] <mwhudson> doko: this is local, but ok
[01:11] <mwhudson> ah seems it is published
[01:11] <doko> https://bugs.launchpad.net/bugs/1535949
[01:11] <ubottu> Launchpad bug 1535949 in debhelper (Ubuntu) "handling of -dbgsym packages breaks pkgbinarymangler" [High,Confirmed]
[01:11] <mwhudson> distro development feels like juggling a sack of cats sometimes
[01:12] <sarnold> hehe
[01:15] <mwhudson> doko: new pkgbinarymangler seems to fix it indeed, thanks
[01:22] <doko> ahh, no, this looks worse, packages can not be uploaded
[01:23] <doko> pitti, https://bugs.launchpad.net/bugs/1535949
[01:23] <ubottu> Launchpad bug 1535949 in debhelper (Ubuntu) "handling of -dbgsym packages breaks pkgbinarymangler" [Critical,Confirmed]
[01:38] <mwhudson> waaiittt a minute
[01:38] <mwhudson> does sbuild not override PATH?
[01:50] <doko> pitti, slangasek: 1535949 still needs to get resolved. however I'm afk now. cancelled all looping builds
[02:00] <doko> cancelled all affected builds. please give all cancelled builds back once the issue is fixed
[02:05] <mapreri> I just got a reject from a archive@u.c for an upload I did to debian and got synced:
[02:05] <mapreri> sigil-dbgsym_0.9.2+dfsg+dfsg-2_powerpc.deb: control file lists name as 'sigil-dbgsym', which isn't in changes file.
[02:06] <mapreri> uh, just had the same failure for ppc64el and armhf now
[02:06] <sarnold> mapreri: I think you get to ignore that https://bugs.launchpad.net/bugs/1535949
[02:06] <ubottu> Launchpad bug 1535949 in debhelper (Ubuntu) "handling of -dbgsym packages breaks pkgbinarymangler" [Critical,Confirmed]
[02:06] <mapreri> oh, I received that mail too, but didn't read it (subscribed to dh bugs through debian's pts
[02:09] <mapreri> ok, thank you.  guess somebody else will take care of fixing dh and retry all the affected uploads (or the build)
[06:26] <pitti> Good monring
[06:28] <pitti> doko: we still have the previous patch to disable dbgsyms, and I didn't notice any in my local sbuild, but I'll look; argh
[06:39] <pitti> slangasek: FYI, I figured out the "apt pinning compatible apt-get source" to also work for linux now, so audit and friends went in
[06:42] <cpaelzer> good morning
[07:06] <pitti> doko: fixed debhelper uploaded
[08:02] <pitti> doko: and all 70 "failed to upload" builds retried
[08:23] <LocutusOfBorg> pitti, <3
[08:25] <LocutusOfBorg> BTW while I'm highlighting you, you retried libquazip test against marble-proposed, but it didn't start for s390x
[08:25] <LocutusOfBorg> so the migration is still stuck I think
[08:27] <pitti> LocutusOfBorg: yep, it's on my radar; s390x has some trouble ATM, I'm working on a fix to at least see the error message, and will then do a mass-retry
[08:31] <LocutusOfBorg> thanks, double thanks
[08:35] <cpaelzer> pitti: LocutusOfBorg: all of what I saw so far with s390x was packaging and stuff which you guys are way++ more experienced - but if it every seems to come down to s390 instructions or other real close-to-HW issues let me know
[08:36] <cpaelzer> same is true if the dasd/eckd disk design ever troubles you
[08:36] <ginggs> morning all! There are now only a handful of ubuntu-specific packages still using python-support LP: #1535318 . Most of them haven't been touched in several years.  Do we want to fix them or remove them?  pitti: system-config-date has your name on it :)
[08:36] <ubottu> Launchpad bug 1535318 in system-config-date (Ubuntu) "deprecation of python-support" [Undecided,New] https://launchpad.net/bugs/1535318
[08:37] <pitti> ginggs: indeed Debian dropped pysupport recently, so we absolutely shoudl fix it
[08:37] <pitti> ginggs: having a tracking bug for the remaining Ubuntu ones would be really useful indeed
[08:37] <pitti> ah, that :)
[08:37] <pitti> quite a few more than I expected
[08:37] <pitti> but I think a lot of them should be in Debian too, and thus either be merges or removals
[08:38] <pitti> Depends: python, python-support (>= 0.90.0), python-gtk2, python-gnome2, gksu
[08:38] <pitti> ginggs: that really smells like a remova ;)
[08:38] <ginggs> pitti: no, only the ones I have linked to debian bugs are in debian
[08:45] <pitti> ginggs: e. g. python-cogent is only blocked on the arm64 FTBFS (https://launchpad.net/ubuntu/+source/python-cogent/1.5.3-10/+build/8774183) which is again blocked on some blast FTBFS
[08:45] <pitti> tricky
[08:46] <ginggs> yeah, ncbi-tools6, arm64 built fine in Debian
[08:47] <ginggs> but in ubuntu we get a gcc internal compiler error
[08:48] <ginggs> is removing the old arm64 binaries for ncbi-tools6 and python-cogent an option?
[08:49] <LocutusOfBorg> mapreri, ^^^^
[08:51] <pitti> ginggs: it has a bunch of reverse dependencies, so we need to find out which and remove them all
[09:18] <ginggs> pitti: yeah, i do see them with 'reverse-depends'.  do we have an equivalent for 'dak rm' in ubuntu?
[09:18] <pitti> ginggs: if that auto-removes reverse depends, then no
[09:19] <ginggs> it can tell you what will be removed
[09:20] <pitti> stgraber: can I override /usr/share/lxc/config/ubuntu.common.conf in /etc/ somewhere?
[09:21] <pitti> stgraber: I edit it on the LXC autopkgtest instances, but every dist-upgrade that includes lxc resets it
[09:29] <pitti> stgraber: oh, I suppose I could at least use /usr/share/lxc/config/common.conf.d/README
[09:29] <pitti> well, without the README obviously
[10:32] <alkisg> mitya57: hi, have you ever considered making an ubuntu flavor with gnome-flashback as the default session? I think edubuntu will have its last release ever in 16.04, so an ubuntu-flashback flavor would fill a big gap there...
[10:38] <highvoltage> alkisg: out of curiousity, what would suck a flavour use for file browser, viewing images, login manager, etc?
[10:38] <highvoltage> *such
[10:39] <alkisg> highvoltage: the gap I'm thinking is "as much close to ubuntu as possible, but for clients without 3d/compositing abilities"
[10:39] <alkisg> So I would like it if it used whatever ubuntu uses (which afaik gnome-flashback already does)
[10:41] <highvoltage> wouldn't ubuntu-mate fit that use case well?
[10:42] <Laney> doko: file conflict in libxapian-1.3-5 update
[10:42] <alkisg> ubuntu-mate is basically an older gnome which is now maintained by a few students, I'm not sure it's a better choice than upstream gnome + ubuntu + a thin layer (=flashback, menus etc)
[10:43] <Laney> doko: bug #1536093
[10:43] <ubottu> bug 1536093 in xapian1.3-core (Ubuntu) "package libxapian-1.3-5 (not installed) failed to install/upgrade: trying to overwrite '/usr/share/xapian-core/stopwords/dutch.list', which is also in package libxapian-1.3-4 1.3.3-0ubuntu2" [Undecided,Confirmed] https://launchpad.net/bugs/1536093
[10:43] <highvoltage> alkisg: gnome-flashback is also not upstream gnome (despite the name)
[10:44] <alkisg> highvoltage: yes, but it's a thin layer, it is something maintainable by a couple of devs, unlike ubuntu-mate which as years go by and gnome2 gets extremely out of date, will require many more devs...
=== _salem is now known as salem_
=== alkisg is now known as alkisg_away
=== cpaelzer is now known as cpaelzer_afk
[11:47] <mapreri> LocutusOfBorg: what particular line are you highlighting to me?
=== jincreator is now known as jincreator_
[11:54] <LocutusOfBorg> mapreri,
[11:54] <LocutusOfBorg> [09:36:34] <ubottu> Launchpad bug 1535318 in system-config-date (Ubuntu) "deprecation of python-support" [Undecided,New] https://launchpad.net/bugs/1535318
[11:54] <ubottu> Launchpad bug 1535318 in sadms (Ubuntu) "deprecation of python-support" [Undecided,New]
[11:54] <LocutusOfBorg> I know you like to kill python-support with fire, don't you? :P
=== cpaelzer_afk is now known as cpaelzer
=== salem_ is now known as _salem
[12:06] <mapreri> LocutusOfBorg: packages in ubuntu-only are so outdated and without love in every possible way...  (looking at the dh_python2 transition tracker in ubuntu)
[12:07] <mapreri> I think for now I'll not be involved in getting rid of pysupport from ubuntu
[12:10] <mapreri> ... and then you notice packages with Maintainer: a DD in a ubuntu-only package, and wonder how that can happen :|
[12:11] <rbasak> There are plenty of packages in Debian that are rotting too.
[12:11] <rbasak> Popular packages end up in sync.
=== _salem is now known as salem_
=== _salem is now known as salem_
[12:46] <stgraber> pitti: right, common.conf.d is most likely the way to go for you
[12:49] <pitti> stgraber: still seems strange to put them into /usr, but I can work with that; certainly much better than changing the deb-shipped file :)
=== pat_ is now known as Guest33510
=== salem_ is now known as _salem
=== _salem is now known as salem_
[13:42] <tjaalton> are upgrades from lts + lts-backport-stack supported to next lts only?
[13:44] <rbasak> tjaalton: if you're not aware of the page, https://wiki.ubuntu.com/Kernel/LTSEnablementStack might have an answer.
[13:45] <tjaalton> I am aware, and point 12. mentions something about "issues", but no clear wording about "don't do that"
[13:47] <tjaalton> someone upgraded from 14.04.3 to vivid and things broke, no surprises there
[13:47] <rbasak> AH
[13:47] <rbasak> Yes, I think that's a serious issue. I had a similar use case explode on me. I filed a bug about it.
[13:47]  * rbasak looks
[13:47] <tjaalton> the page probably should have a command for reverting back to stock trusty packages
[13:48] <rbasak> bug 1252843
[13:48] <ubottu> bug 1252843 in update-manager (Ubuntu) "Permits upgrade from an LTS system on an HWE stack to a broken system" [High,Triaged] https://launchpad.net/bugs/1252843
[13:49] <rbasak> My use case was to initially install 12.04.(something), and then eventually decide to roll up to 13.10 or something because I needed some newer package. And the install exploded.
[13:49] <rbasak> s/install/upgrade/
[13:50] <tjaalton> looks like it's still an issue
=== Zic_ is now known as Zic
=== beisner- is now known as beisner
=== ]reed[ is now known as [reed]
=== mapreri_ is now known as mapreri
=== ChrisTownsend1 is now known as ChrisTownsend
[14:35] <xnox> doko, btrfs-tools has ice on arm64 in ubuntu =( https://launchpadlibrarian.net/234669123/buildlog_ubuntu-xenial-arm64.btrfs-tools_4.4-1_BUILDING.txt.gz
[14:35] <xnox> doko, the build-log looks like it has a clean gcc dump too.
[14:35] <doko> looking
[14:49] <doko> xnox, work around is to build with -O2 instead of -Os
[14:54] <xnox> doko, =(
[14:54] <xnox> doko, is it a known bug?
[15:01] <slangasek> pitti: nice!
[15:10] <doko> xnox, https://bugs.linaro.org/show_bug.cgi?id=2001
[15:11] <ubottu> bugs.linaro.org bug 2001 in General "[5 Regression] ICE in final_scan_insn, at final.c:3020 on aarch64-linux-gnu" [Major,Unconfirmed]
=== enrico___ is now known as enrico
[15:14] <doko> barry, tumbleweed, jtaylor: http://people.canonical.com/~ubuntu-archive/transitions/html/python3.5-only.html   a few packages left
[15:16] <xnox> doko, tah.
[15:17] <ginggs_> doko, pitti: looks like that arm64 bug is the same in ncbi-tools6? https://launchpad.net/ubuntu/+source/ncbi-tools6/6.1.20120620-10  "pseed3.c: In function 'seedEngineCore':
[15:17] <ginggs_> pseed3.c:631:1: error: could not split insn"
[15:17] <jtaylor> doko: scipy will get a new upstream soon, I may check the failure then
[15:17] <jtaylor> doko: though I'll be only partially available in the next 10 days, so if someone else wants to fix it go ahead
[15:18] <barry> doko: cool.  we're still sprinting for the next 2 days
[15:26] <sergiusens> hi there pitti, I'm trying to use adt with lxd and getting http://paste.ubuntu.com/14582679/ is there anything obvious I'm missing?
[15:27] <pitti> sergiusens: nothign obvious, I think
[15:27] <pitti> sergiusens: if you do "lxc launch images:ubuntu/xenial/amd64 x1", wait a bit (boot should take < 5 s), and "lxc exec x1 bash"
[15:27] <pitti> sergiusens: I suppose it fails to boot, can you check journalctl?
[15:28] <jtaylor> is there a docker update planned for xenial? given the issues we have in trusty and the next version 1.10 will have large changes in its internal layout I think it would be best to have it as new as possible (or not at all)
[15:28] <sergiusens> pitti, launching works just fine
[15:28] <sergiusens> I've been using lxd for a bit now for playing with random things
[15:29] <sergiusens> and to confirm, lxc exec for bash worked just fine
[15:31] <pitti> sergiusens: and "runlevel" says something like "5 N"?
[15:32] <sergiusens> pitti, ah, it indeed says unknown
[15:32] <pitti> sergiusens: so something went wrong with booting the container
[15:33] <pitti> sergiusens: checkig "runlevel" is the least common denominator that I found for handling arbitary testbeds
[15:33] <sergiusens> pitti, there are a couple of failing services
[15:33] <pitti> sergiusens: what does "systemctl status" say? degraded, or still booting?
[15:34] <sergiusens> pitti, 'starting'
[15:34] <sergiusens> pitti, 3 units failed, which is the amount of failures I saw when running systemctl
[15:35] <sergiusens> if it is of any worth http://paste.ubuntu.com/14582730/
[15:36] <pitti> sergiusens: yeah, I get that too, that's just unpriv container limitations
[15:37] <pitti> sergiusens: so for me I get "State: degraded" (which is "booted, but some failed units"), and runlevel "N 5"
[15:37] <pitti> and the same three failed units
[15:37] <pitti> sergiusens: can you pastebin "journalctl"?
[15:38] <sergiusens> pitti, http://paste.ubuntu.com/14582749/
[15:39] <sergiusens> pitti, oh, now I recall bridging the containers to my network card, not sure it should affect booting, but it will affect adt :-)
[15:43] <pitti> sergiusens: it doesn't care much about networking as long as your tests don't; but of course that will blow up if you run --apt-upgrade or install test deps
[15:44] <sergiusens> pitti, yeah, I will certainly hit that
[15:44] <pitti> networking.service: Start operation timed out. Terminating.
[15:44] <pitti> Failed to start Raise network interfaces.
[15:44] <pitti> sergiusens: so, that
[15:44] <pitti> sergiusens: and previously the unit was still starting, until it hit the timeout
[15:44] <pitti> so it didn't yet appear in --failed
[15:46] <sergiusens> pitti, great, I'll look into this later, thanks for all the pointers!
[15:52] <Laney> doko: https://launchpadlibrarian.net/234703765/xapian1.3-core_1.3.4-0ubuntu3_1.3.4-0ubuntu4.diff.gz should be libxapian-1.3-4
[15:53] <doko> ohh crap
=== dannf` is now known as dannf
=== rickspencer3_ is now known as rickspencer3
=== alkisg_away is now known as alkisg
=== cpaelzer_ is now known as cpaelzer_afk
[17:41] <RAOF> cjwatson: I seem to recall at some point you making the buildd chroot tarballs available over lpapi. Is that me confabulating, or is this possible? (This is cf: jenkaaaaaaas).
[17:46] <pitti> RAOF: serach for "chroot_url" on https://launchpad.net/+apidoc/1.0.html
[17:46] <RAOF> pitti: Maha! Thanks!
[17:46] <RAOF> Also, thanks for the apidoc link :)
[17:47] <pitti> "http://launchpadlibrarian.net/222053869/chroot-ubuntu-xenial-amd64.tar.bz2"
[17:47] <pitti> $ wget -q -O- https://api.launchpad.net/1.0/ubuntu/xenial/amd64/chroot_url
[17:47] <pitti> RAOF: ^ imagine these two lines swapped around :)
[17:47] <pitti> RAOF: (-: ɐᴉlɐɹʇsn∀ ɹoɟ ɹǝpɹo ʇɥƃᴉɹ ǝɥʇ uᴉ ǝɹɐ ʎǝɥʇ 'ʎllɐnʇɔɐ
[17:47] <RAOF> :)
[17:50] <sergiusens> xnox, hey, btw, when should my upload rights become effective?
[17:53] <RAOF> Well, that's sad. I don't think I can slurp a vivid-overlay chroot out of that :)
[17:54] <xnox> sergiusens, i dunno =) i don't think i've acted upon doing so, yet.
[17:54] <cjwatson> RAOF: That's just the same as the vivid chroot.
[17:55] <xnox> sergiusens, i will not get around to do it today, sorry. added a todo for tomorrow.
[17:56] <RAOF> cjwatson: ...of course it is. HAH!
[17:56] <sergiusens> xnox, ah, I was just wondering what the time lines were; no worries
[17:56]  * RAOF knew that. Or would have, had he thought about it for any extended period of time.
[17:56] <Laney> xnox: you can't do PPU anyway, need to ask TB person for that
[17:56] <xnox> Laney, right that's i thought.
[17:57] <xnox> and all of them expired, unless stgraber was back-doored in
[17:57] <Laney> https://launchpad.net/~techboard/+members lies
[17:58] <stgraber> TB terms have been extended a bit so we have time to deal with elections
[18:02] <caribou> xnox: while you're at it, might think of changing my access as well :-)
[18:02] <caribou> or whoever can
=== lifeless_ is now known as lifeless
=== xnox_ is now known as xnox
=== DrKranz is now known as DktrKranz
=== funkyHat_ is now known as funkyHat
=== dasjoe_ is now known as dasjoe
=== pfsmorigo is now known as Guest2202
=== fginther` is now known as fginther
=== cpaelzer_afk is now known as cpaelzer_
=== ochosi_ is now known as ochosi
=== mbarnett` is now known as mbarnett
=== nopf_ is now known as nopf
=== salem_ is now known as _salem
[22:33] <mightyiam> Yo, I'm on 16.04 and some package doesn't upgrade
[22:33] <mightyiam> python3-xapian1.3 is partially installed
[22:34] <mightyiam> Some dependency issue
[22:35] <mightyiam> http://i.imgur.com/ONip6pN.png
[22:37] <mightyiam> But libxapian-1.3-5 is marked for installation
[22:39] <sarnold> mightyiam: file a bug against the xapian1.3-core source package with ubuntu-bug xapian1.3-core -- include the copy-and-paste output inlcyuding the file-overwrite attempt and the killed paste command