[00:01] <cjwatson> infinity: acceptx() was pretty cute
[00:05] <cjwatson> infinity: Oh, and sendfilev() was awesome for benchmarks.
[00:06] <cjwatson> (or, charitably, for static file serving)
[00:10] <mwhudson> oh hooray python3-defaults-3.5.3 source has a .bzr directory in it
[00:10] <mwhudson> wait i uploaded that
[00:11] <Unit193> mwhudson: G'luck on DM!
[00:11] <mwhudson> ah the newest version i didn't upload also has it
[00:12] <mwhudson> (i was sure i didn't do anything bzr related in my uploads...)
[00:14] <mwhudson> slangasek: quick review on http://paste.ubuntu.com/24852968/ ?
[00:16] <slangasek> mwhudson: if it builds, then sure? :)
[00:16] <mwhudson> hah
[00:16] <slangasek> mwhudson: the reference to python3.6-minimal makes me sad
[00:16] <mwhudson> i should do some testing before i rebuild 3000 packages against it i guess
[00:19] <mwhudson> slangasek: yeah i don't understand what that's doing there
[00:21] <slangasek> mwhudson: the -minimal split as a whole never achieved its intended purpose and is now just an inconvenience in the archive... references to it from other packages are particularly heinous
[00:21] <mwhudson> slangasek: i see
[00:22] <cjwatson> references to it from python3-defaults seem a bit less heinous than from elsewhere, seeing as it has a python3-minimal itself
[00:22] <cjwatson> though I don't know what it's doing in Build-Depends
[00:23] <cjwatson> some kind of bootstrapping hack given the :any ?
[00:23] <mwhudson> slangasek: have lunch appt in 8 minutes going to see how much pycxx i can understand in that time :)
[00:23] <slangasek> yeah, possibly
[00:23] <cjwatson> that would be a "don't remove -minimal without doing careful cross-build tests" flag for me
[00:24] <slangasek> right, if anything I would promote it to python3.6:any instead
[00:24] <cjwatson> yeah but I wonder if that complicates bootstrapping due to non-cross-installable dependencies or something
[00:24] <slangasek> could be
[00:25] <slangasek> anyway, I'm certainly not advocating that it must be changed as part of the transition
=== JanC_ is now known as JanC
[00:37] <slangasek> mwhudson: pycxx, this autopkgtest is hateful and clearly could never have worked anywhere; shameful
[00:37] <slangasek> s/shameful/SAD/
[00:41] <slangasek> mwhudson: one-line change to add cxx_exceptions.cxx to setup_makefile.py, alongside cxx_extensions.py; must rebuild and install since the autopkgtest (properly) tests the installed package; and now I'm afk, feel free to turn this comment into a patch or something
[00:43] <sarnold> diff --hand-waving-on-irc  :)
[01:00] <mwhudson> slangasek: ok
[01:00] <mwhudson> good thing i had lunch instead of coming to the same conclusions
[01:00] <sarnold> you really can't go wrong with lunch
[01:01] <mwhudson> tis true
[01:03] <gsilvapt> Apologies for the long delay, nacc and infinity. I'll be testing this soon (need some more reboots)
[01:25] <gsilvapt> infinity and nacc: Regarding the command you suggested, it says fuseblk.
[01:25] <gsilvapt> Meaning I'm toasted for this...
[01:50] <sarnold> gsilvapt: what the heck kind of filesystem -is- that?
[01:50] <Unit193> fuse?
[01:51] <sarnold> yeah not many fuse backends seem like they'd be up to package builds
[01:55] <tarpman> sarnold: guessing it's ntfs via ntfs-3g
[01:57] <sarnold> *shudder*
[01:58] <Unit193> fat32 better?
[01:58] <sarnold> *shudder*
[03:11] <blahdeblah> Is this sarnold trigger word bingo?  Let me try.
[03:12] <blahdeblah> NFS
[03:12] <sarnold> number field sieve? sounds like fun!
[03:12] <blahdeblah> drat - foiled again!
[04:32] <blahdeblah> Some launchpad server upgrades under way; expect some minor delays on builds and diffs
=== zyga is now known as zyga-ubuntu
[09:10] <ginggs> jamespage: ceph build failure with --no-parallel https://launchpadlibrarian.net/323860925/buildlog_ubuntu-artful-armhf.ceph_12.0.3-0ubuntu1~ubuntu17.10.1+ppa12_BUILDING.txt.gz
[09:45] <jamespage> ginggs: yep that's the one
[09:45] <jamespage> any ideas on cause?
=== rumble is now known as grumble
[10:10] <ginggs> jamespage: no, sorry
[10:12] <cpaelzer> doko: Hi,does python3-ldb-dev ring a bell on bug 1614936 ?
[10:12] <ubottu> bug 1614936 in ldb (Ubuntu) "package python3-ldb-dev (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/x86_64-linux-gnu/pkgconfig/pyldb-util.pc', which is also in package python-ldb-dev 2:1.1.24-1ubuntu3" [Low,Confirmed] https://launchpad.net/bugs/1614936
[10:13] <cpaelzer> doko: I hoped you might be able to help clarifying the right approach, so I subscribed
[10:13] <cpaelzer> you
[10:22] <jamespage> ginggs: figured out the other i386 issue (ish)
[10:22] <jamespage> https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1697908
[10:22] <ubottu> Launchpad bug 1697908 in gcc-6 (Ubuntu) "i386 compilation hang with rocksdb (via ceph)" [Undecided,New]
[10:22] <jamespage> have a patch series to try with
[10:26] <rbasak> nacc: \o/
[10:31] <jamespage> how do I persuade proposed migration to look at autopkgtest results for reverse-depend packages in proposed as well?
[10:32] <jamespage> I have a stack of autopkgtest fixes in proposed, but py modules are testing against the release pocket
[10:34] <rbalint> jamespage: i have a script for generating links for autopkgtests with additional dependencies
[10:35] <rbalint> jamespage: let me push it somewhere
[10:35] <jamespage> rbalint: great - thanks!
[10:36] <Laney> umm
[10:36] <Laney> If a package breaks another one, that sounds like Breaks to me
[10:42] <rbalint> jamespage: https://git.launchpad.net/~rbalint/+git/autopkgtest-retry
[10:42] <rbalint> jamespage: it needs editing and parsing the yaml in python is slow
[10:46] <rbalint> Laney: in theory, yes, but in practice adding Breaks for every other package which happens to be broken is unmanagable
[10:53] <Laney> If you add extra triggers into autopkgtest runs, you risk causing a package to migrate without the thing you added a trigger on, which would end up breaking real users.
[11:03] <rbalint> Laney: what is then the proposed way of getting two (n) packages migrated which pass autopkgtest together only?
[11:04] <Laney> rbalint: As you would with a normal package upgrade - you add the right relationships to ensure that users can only have working combinations of packages installed
[11:05] <Laney> If you're seeing failures that are fixed by adding extra triggers then autopkgtest is pointing you to a bug
[11:05] <rbalint> Laney: will the Breaks trigger autopkgtest with the right version from proposed?
[11:06] <Laney> The triggers translate into pins
[11:06] <Laney> So yes
[11:07] <Laney> It's an option to use the workaround that you're suggesting if you decide that it's not a realistic bug, but I think it should be considered after thinking about fixing the packages.
[11:11] <rbalint> Laney: i assumed that if i add an extra trigger the original package will migrate only together with the triggering version
[11:12] <rbalint> Laney: at least this would make more sense to me than asking for temporary deltas with Breaks
[11:23] <Laney> why is it temporary?
[11:23] <Laney> And no, because you're filing those requests outside of britney.
[11:30] <rbalint> Laney: not all Breaks are recorded between packages and keeping the ones which surfaced only for the short period of -proposed migration may not be really useful
[11:31] <Laney> rbalint: The fact that a combination of packages doesn't work together doesn't change just because the situation is in release instead of proposed.
[11:33] <rbalint> Laney: i agree
[11:35] <rbalint> rbalint: if you pick all versions of all packages ever been in zesty (release) during the development for zesty and test every combination of them with autopkgtest which are co-installable considering Breaks Conflicts etc rules would those tests pass?
[11:35] <rbalint> Laney: ^
[11:36] <Laney> I'm not getting into a discussion about an absurd situation
[11:36] <Laney> You understand what I'm saying, and I have to go work on codec installation now, so see you later
[13:30] <jamespage> rbalint: ta
[14:10] <psusi> so what the heck does dpkg mean when it says a package is in a very bad inconsistent state?  been seeing a lot of bug reports lately about upgrades throwing this error on grub.
=== koza is now known as koza|away
[14:56] <bdmurray> xnox: I added some info to that systemd bug 1621396
[14:56] <ubottu> bug 1621396 in systemd (Ubuntu Yakkety) "systemd-resolved crashed with SIGSEGV in dns_packet_is_reply_for()" [Low,Confirmed] https://launchpad.net/bugs/1621396
[14:59] <xnox> bdmurray, and the russian text says that systemd-resolved was modified since the error occured.
[15:00] <xnox> thus crash; upgrade; then report.
[15:00] <xnox> bdmurray, thanks a lot. because i raised an eyebrow at that crash report
[15:02] <bdmurray> xnox: No problem.
[15:05] <bdmurray> xnox: Its possible apport should do something better / different here.
[15:41] <bdmurray> xnox: I reported bug 1697959 about the report containing "fake" information.
[15:41] <ubottu> bug 1697959 in apport (Ubuntu) "late package version collection can cause confusion" [Undecided,New] https://launchpad.net/bugs/1697959
[15:43] <pitti> bdmurray: back then, ev was pretty adamant about "I want all sorts of broken bug reports on errors.u.c.", apport has specific code to ingore UnreportableReason: for errors.u.c.
[15:43] <pitti> perhaps it's time to reconsider :)
[15:44] <bdmurray> pitti: I recall those discussions from when we were in London.
[15:56] <kyrofa> Hey rbasak, can we get snapcraft into proposed for x y and z?
[16:28] <kyrofa> bdmurray, click is now in proposed. Can you help me get snapcraft there as well?
[16:33] <bdmurray> kyrofa: Could you check with arges or rbasak first since its their SRU day?
[16:35] <kyrofa> arges isn't here, I pinged rbasak over 30 minutes ago
[16:43] <bdmurray> kyrofa: okay, I'll have a look in about an hour
[16:44] <kyrofa> bdmurray, I appreciate it, thank you
[16:51] <slangasek> smb: why is your network device so broken? :)
[16:52] <smb> slangasek, It would be both for me KVM and Xen. But I am just updating to the latest ISO. Maybe it is just that which was broken. :)
[16:52] <slangasek> ok
[16:53] <slangasek> though, you were already on the latest version of systemd
[16:54] <smb> Yeah, just want to be sure it really still happens. If not, then meh
[16:54] <slangasek> smb: do you have radvd running somewhere such that you *should* be getting public IPv6?
[16:54] <smb> slangasek, no radvd (no ipv6 for my home network). One thing I want to change at some point but never get to
[17:01] <rbasak> kyrofa: sorry, I'm nominally EOD at 1800 UTC+1, and it would have been too big a chunk of review to do last thing for me anyway. I've been deep inside the certbot SRU today.
[17:01] <rbasak> bdmurray: thank you for looking
[17:03]  * rbasak wonders why snapcraft isn't a classic snap
[17:03] <kyrofa> rbasak, it is
[17:04] <kyrofa> But it's not stable yet, still in beta
[17:04] <rbasak> So why the need for SRUs?
[17:04] <rbasak> I see.
[17:04] <kyrofa> And there's no real established pattern for transitioning deb users to snaps
[17:04] <kyrofa> Don't want to leave them in a lurch
[17:05] <rbasak> I did wonder about that. snapcraft sounds like the perfect candidate to lead the way on that :)
[17:05] <nacc> heh
[17:05] <nacc> show us the way, kyrofa! :)
[17:07] <kyrofa> Ha! Well, once it's actually stable and well-tested, I'm sure we'll chat about it
[17:10] <cjwatson> And LP builders don't yet support installing snaps, so would have problems installing snapcraft
[17:12] <smb> slangasek, Bah, so fwiw I am still broken ... or rather my installation(s)
[17:13] <cjwatson> It'd also make our development setups depend on snapd in lxd, which would perhaps be excessively exciting
[17:14] <slangasek> smb: right, so maybe this needs some poking around in the kernel state of the device to understand why networkd isn't considering it 'configured'
[17:15] <smb> slangasek, possibly. would be nice if it was not just me though. even more so as I am not around the rest of the week
[17:17] <slangasek> smb: what does 'ip link' look like on this box?
[17:18] <smb> slangasek, http://paste.ubuntu.com/24857940/ (after timing out and then working normally except for the failed service)
[17:20] <kyrofa> cjwatson, excellent points indeed
[17:21] <slangasek> smb: ok, nothing looks abnormal there to me
[17:21] <kyrofa> And the simple fact that snaps don't run everywhere that debs do. You wouldn't be able to use snapcraft on travis anymore either
[19:28] <tsimonq2> Hmmmm... can I use syncpackage with PPAs?
[19:28] <slangasek> yes
[19:29] <slangasek> if you're syncing /from/ a ppa /to/ the main archive, you must not do a binary sync
[19:29] <tsimonq2> I'm looking to sync from Debian to a PPA
[19:29] <slangasek> (I don't recall of LP itself has a way of enforcing this as a security policy)
[19:29] <slangasek> yeah, that's doable
[19:29]  * tsimonq2 isn't seeing it in the manpage...
[19:30] <slangasek> oh. you probably can't use the syncpackage command, sorry - you can do it with copy-package from ubuntu-archive-tools
[19:30] <tsimonq2> Ah ok
[19:41] <tsimonq2> slangasek: I can't figure out how to use this with Debian... hint?
[19:46] <infinity> tsimonq2: copy-package --from=debian --from-suite=sid --to=ppa:adconrad/ubuntu/ppa --to-suite=artful hello
[19:46] <infinity> tsimonq2: Adjust to taste.
[19:49] <tsimonq2> infinity: gracias.
=== ChanServ changed the topic of #ubuntu-devel to: Canonical datacentre firewall maintenance 23:59 - 00:00 UTC | Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
=== ChanServ changed the topic of #ubuntu-devel to: Canonical datacentre firewall maintenance 23:00 - 23:59 UTC | Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: