[00:22] <Trevinho> RAOF: hey
[00:22] <Trevinho> RAOF: could you please review the unity7 xenial SRU that is in queue?
[00:22] <RAOF> Trevinho: Sure!
[00:22] <Trevinho> RAOF: related silo is https://requests.ci-train.ubuntu.com/#/ticket/1843
[00:22] <Trevinho> RAOF: thanks a lot
[00:23]  * RAOF dislikes reviewing SRU syncs. :(
[00:24] <Trevinho> Eh, i'm sorry about that... We should really have some scripts which produces debdiff for these
[00:24] <RAOF> Yeah, I could totally improve some of the scripts in ubuntu-archive-tools to do this.
[00:24] <RAOF> Not your fault!
[00:24] <Trevinho> RAOF: what would be the best way for helping SRU team in that? debdiffs attached to bugs, or what else?
[00:25] <Trevinho> eh, I know.. I've heard about some difficulties about that, but I'm not much into that work to understand what's missing :-)
[00:25] <RAOF> Trevinho: Make sru-review in lp:ubuntu-archive-tools handle syncs.
[00:25] <cjwatson> It's really an LP bug, but quite a hard one to fix.
[00:26] <cjwatson> (https://bugs.launchpad.net/launchpad/+bug/851562, specifically)
[00:26] <ubottu> Launchpad bug 851562 in Launchpad itself "Diffs not available for syncs on +queue page like for regular uploads" [High,Triaged]
[00:26] <RAOF> It would not be *that* hard to make sru-review DTRT; it'd just need to follow the sync link, then hope that the PPA has the regular stuff.
[00:27] <RAOF> Trevinho: Presumably you need bamf, compiz, and unity all done at once?
[00:27] <Trevinho> RAOF: yeah... I mean, there are no interdependencies... So you can actually land these in the order you want
[00:27] <RAOF> Trevinho: Cool.
[00:29] <Trevinho> RAOF: I see there's a from_ppa option in the review script, is that helpful?
[00:29] <RAOF> Actually just checking that out :)
[00:31] <RAOF> No dice, but --no-diff is helpful.
[00:31] <RAOF> Heh. https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/913880 is clearly not fix-released in xenial :)
[00:31] <ubottu> Launchpad bug 913880 in compiz (Ubuntu) "mouse scroll down over sound indicator while expo is active selects previous desktop" [Low,Fix released]
[00:34]  * RAOF wishes PPAs built their debdiff against -updates
[00:39] <Trevinho> ah, that's annoying...
[00:39] <Trevinho> using options -p ci-train-ppa-service/landing-085 didn't give me anything though, but maybe it's just something else
[00:39] <Trevinho> anyway... if there's any problem, let me know... time for bed now :-)
[00:42] <RAOF> Trevinho: Do any of your bugs have xenial tasks? :)
[00:45] <Trevinho> RAOF: no.... Cause I'm not an Ubuntu driver and I can't add these without confirmation it seems 😢
[00:46] <RAOF> Trevinho: You can nominate them, at least. But I'm happy to do so while processing, too. Just for future reference :)
[00:54] <RAOF> Wow. That unity upload is all that and a bag of potato chips.
[01:43] <RAOF> Trevinho: (For when you wake up) Is https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1616031 actually fixed in the uploaded unity and/or Yakkety?
[01:43] <ubottu> Launchpad bug 1616031 in unity (Ubuntu) "Problems with restoring window size/position after half-maximizing" [Medium,Triaged]
[01:49] <RAOF> Trevinho: Also, a *lot* of those bugs are pretty borderline SRUs.
[01:52] <RAOF> Trevinho: Accepted the bamf and compiz SRUs, as they're good and correct.
[01:54] <RAOF> Trevinho: Once you've checked that bug 1616031 is actually fixed in yakkety and the package, unity can (with some reservations) go through.
[01:54] <ubottu> bug 1616031 in unity (Ubuntu) "Problems with restoring window size/position after half-maximizing" [Medium,Triaged] https://launchpad.net/bugs/1616031
[05:09] <pitti> RAOF: urgh, seriously? that should take a few minutes, not a day..
[05:09] <RAOF> IPv6 snafu, it seems.
[05:14] <RAOF> Each package tried to resolve over IPv6 with a 1min timeout, failed, then tried again for the next package.
[05:14] <RAOF> pitti: Anyway, ping!
[05:15] <pitti> RAOF: aye!
[05:16] <pitti> RAOF: "yakkety" → "unstable" in changelog, s'il te plaît
[05:16] <RAOF> Ahem.
=== King_InuYasha is now known as Son_Goku
[05:20] <RAOF> pitti: Done.
[05:29] <pitti> RAOF: and built/uploaded
[05:46] <cpaelzer> good morning
[06:35] <RAOF> Oh, kfreebsd. Hush.
[06:36] <pitti> RAOF: heh, --fail-missing FTW: )
[06:37] <RAOF> touch debian/not-installed.linux; echo "/lib/udev/..." > debian/not-installed
[06:37] <pitti> RAOF: oh, is debian/not-installed a thing? I wasn't aware of that
[06:37] <RAOF> New in compat 9, I think?
[06:37] <pitti> RAOF: I usually use some -X*.rules fu (conditionalized)
[06:39] <RAOF> I think I'll go the not-installed route.
[06:42] <RAOF> Aaargh. Git! When I push I want to push the signed tags, damnit.
[07:16] <RAOF> pitti: I can't seem to push to colord git anymore, but the permissions on the repository seem fine? I was hoping to have another go at building on kfreebsd/hurd :/
[07:17] <pitti> RAOF: uh, what happened since this morning? you still pushed the changed debian/changelog release target?
[07:17] <RAOF> Yes! I don't know. I went to push 1.3.3-2 (that should build on kfreebsd/hurd, hopefully), and git is complaining about insufficient permissions on ./objects
[07:30] <pitti> RAOF: some chmod -R on git.debian.org?
[07:42] <RAOF> pitti: Everything seems to be 775, owned by mpitt:scm_collab-maint
[07:42] <pitti> RAOF: uh, did I set up the colord.git? I don't remember that at all
[07:44] <RAOF> pitti: Would you be able to pull from github.com:raof/colord.git ?
[07:44] <pitti> RAOF: sure
[07:45] <pitti> RAOF: there are a few files owned by raof-guest:raof-guest which should probably have group scm_collab-maint, but that shouldn't stop pushing for you..
[07:46] <pitti> RAOF: oh, I do see a few files which are 444
[07:47] <pitti> RAOF: perhaps do try a chgrp -R scm_collab-maint and chmod -R ug+w ?
[07:48] <pitti> I just did that, but I cannot change the raof-owned ones
[07:49] <RAOF> Nope
[07:49] <pitti> RAOF: hmm, then I guess moving the whole colord.git/ dir away and re-creating/pushing it? I'm out of ideas
[07:50] <RAOF> Oh, hello!
[07:51] <RAOF> There are 3 files in objects/; two owned by mpitt:mpitt one by biebl:biebl.
[07:52] <RAOF> Are you able to remove those final ones?
[07:52] <pitti> RAOF: done
[07:52] <pitti> RAOF: (pulled/building from github in the meantime)
[07:53] <RAOF> And collab-maint/colord.git is now updated.
[07:55] <pitti> RAOF: pulling works indeed, thanks
[08:00] <pitti> RAOF: -2 uplaoded
[08:01] <pitti> (which is better than uploading, obviously!)
[08:01] <RAOF> It's more ladder-like.
[08:21] <Trevinho> RAOF: so... We used to be pretty flexible in unty SRUs to keep the delta with trunk to the minimum
[08:21] <Trevinho> So... Yes, there are bigger changes, but still all fixes
[08:22] <Trevinho> RAOF: as for that bug, I thought I removed it from the changelog, didn't I?
[08:22] <Trevinho> Since it wasn't fixed here
[09:47] <Laney> what's this "Stale file handle" business that's going on with sbuild?
[09:47] <Laney> anyone else seen that?
[09:55] <pitti> Laney: oh, you got it too? xnox and me too
[09:56] <pitti> I tried to apt-get clean/-f etc. in src:sid, but didn't help, so I just rebuilt it from scratch (easier than wasting time)
[09:56] <Laney> pitti: first saw it yesterday and though it was some freak occurrence, but now I get it on other schroots too
[09:56] <pitti> I only got it in my sid schroot; either because it was sid, or becasue that was my only schroot that used an overlay (the others are tarballs)
[09:56] <xnox> Laney, pitti - you shall not use overlayfs and dpkg
[09:57] <xnox> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1620525 our bug
[09:57] <ubottu> Launchpad bug 1620525 in linux (Ubuntu Yakkety) "sbuild with overlayfs fails in yakkety" [Critical,New]
[09:57] <pitti> it has worked for many years, but since all my others are tarballs I just use a tarball too now
[09:57] <xnox> debian bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836211
[09:57] <ubottu> Debian bug 836211 in dpkg "dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link" [Normal,Open]
[09:57] <pitti> and live with the 2 s unpack time
[09:57] <xnox> pitti, use older kernel?
[09:58] <Laney> xnox: do you know what changed?
[09:58] <xnox> or newer....
=== JanC_ is now known as JanC
[09:58] <Laney> this has always been the case on overlayfs hasn't it?
[09:58] <xnox> Laney, something rather fixed in overlayfs. Re-creating chroots with new enough apt pre-installed should work too, because then the subdir move is not needed.
[09:59] <Laney> I get it on loads of random stuff
[09:59] <Laney> Updating certificates in /etc/ssl/certs...
[09:59] <Laney> mv: cannot move '/tmp/ca-certificates.crt.tmp.OgRoXw' to 'ca-certificates.crt': Stale file handle
[09:59] <xnox> excellante.
[09:59] <xnox> i bet all the live images are busted too
=== hikiko is now known as hikiko|ln
=== hikiko|ln is now known as hikiko
[11:36] <tjaalton> looks like a xenial server of mine has had an unattended-upgrade in limbo since june
[11:37] <seb128> tjaalton, like a stucked job? any error?
[11:38] <tjaalton> yeah kernel install stuck
[11:38] <tjaalton> nothing in dpkg.log
[11:38] <seb128> urg
[11:39] <seb128> do you know where it's stucked?
[11:39] <tjaalton> grub-mount
[11:39] <seb128> I guess that's worth at least a bug report
[11:39] <tjaalton> then again this has zfs-on-root
[11:40] <seb128> oh...
[11:40] <tjaalton> eldon# LANG=C grub-mount /dev/sda1 /var/lib/os-prober/mount
[11:40] <tjaalton> error: unknown filesystem.
[11:40] <tjaalton> guess that's it
[11:41] <seb128> well, it should handle the case better
[11:41] <tjaalton> I'll file it against os-prober
[11:42] <seb128> thanks
=== pavlushka is now known as Guest70016
[11:49] <tjaalton> hmm or grub2 actually
=== _salem is now known as salem_
[12:43] <pitti> juliank: there is no way to get a .dsc or diff for the synced apt 1.2.14 in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=apt
[12:44] <juliank> pitti: Why?
[12:44] <juliank> I just ran syncpackage for it :/
[12:44] <pitti> juliank: this makes it extremely hard to review for SRU; normal uploads are a lot simpler
[12:44] <pitti> juliank: this might also explain why nobody reviewed it yet
[12:45] <Mirv> I seem to have many problems with "Finished" builds not really finishing like https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-1916/+build/10713715 (this is retry number two)
[12:45] <pitti> oh, I can get it from here: https://launchpad.net/debian/+source/apt/1.2.14
[12:45] <juliank> pitti: Yeah
[12:45] <Mirv> maybe it's a test failure in content-hub though showing off as unkilled thread
[12:45] <pitti> but this takes creativity (no click-through path), downloading two packages, running debdiff, etc.
[12:46] <brendand> this feels like a dumb question, but i want to be able to ssh to the autopkgtest host from the testbed, without being prompted for a password - what are my options?
[12:46] <pitti> brendand: scp your host's key to ~/.ssh/authorized_keys once?
[12:47] <juliank> pitti: Right. I can upload (the next release) 1.2.15 as a .dsc for the next upload. infinity sort of wanted that to be in a PPA and then synced from the PPA, but if it's easier to look at, I can just re-upload the .dsc from the PPA then.
[12:49] <pitti> juliank: got a diff now; I'm ok with accepting into -proposed, but for verifying (for -updates) I'd like to see an actual test plan such as testing a dist-upgrade with that apt, to see how it performs in big scenarios which the test suite doesn't cover
[12:49] <brendand> pitti, i still get prompted for the password... maybe something i need to change in the hosts ssh configuration?
[12:50] <pitti> brendand: no, this is determined by the guest, and this generally allows key-based auth (I do that often)
[12:50] <pitti> brendand: maybe you forgot to say ubuntu@ ?
[12:50] <pitti> brendand: the scp itself (for copying id_rsa.pub) will ask for the password of course, but after that it should work
[12:51] <brendand> pitti, no i definitely did do that
[12:52] <brendand> pitti, ah i think i know a way. i can set up the access in the base image
[12:52] <pitti> brendand: please run ssh with -vv to see what it doesn't like about your key
[12:52] <juliank> pitti: There were no changes at all to the installation code in 1.2.14 since 1.2.12(~ubuntu16.04.1) - don't you have some automated update testing tools in some QA thing somewhere?
[12:53] <pitti> brendand: if this is lxc, lxd, or qemu, you can also funnel it in through the side channels like lxc-attach or ttyS1
[12:53] <pitti> juliank: we have the autopkgtests, but AFAIK no automatic upgrade tests against -proposed
[12:53] <pitti> we used to have some, or still have -- if so, running those is fine of course
=== herb_ is now known as herb
[12:56] <xnox> cjwatson, gimock fails to spawn things that are supposed to be executed in the subprocess as far as I can figure out. There is no stdin/stdout and the pipe that should unpickle things raised EOF. Who is the current maintainer of click/gimock?
[12:56] <xnox> it's probably something changed in gi and/or python.
[12:56] <cjwatson> xnox: already fixed in a silo awaiting QA approval
[12:56] <xnox> ah excellent!
[12:56] <cjwatson> https://requests.ci-train.ubuntu.com/#/ticket/1878
[12:57] <cjwatson> xnox: (but I think it's waiting until after OTA13 - that's still in adequate time for yakkety so I'm not worrying about it too much)
[12:57] <juliank> pitti: In the worst case, starting with a 16.04 image, install apt 1.2.14 and then upgrading to updates+proposed should be a good test
[12:57] <cjwatson> xnox: there were quite a few little details wrong, I had a "fun" bit of weekend work sorting it all out
[12:59] <juliank> 1.2.15 is going to be awful, I have queued 46 cherry-picked commits so far: https://github.com/Debian/apt/compare/1.2.14...julian-klode:1.2.y - one changes the cache format in order to fix a buffer overflow, and another one changes the main MarkRequired() algorithm to allow kernels to be autoremoved again in the presence of (zfs) virtual deps
[13:00] <xnox> cjwatson, /o\ ok. So i'll grab that ppa, and retest that things don't regress with new python-debian / gpg -> because those trigger click tests. If all is good, I'll ask Laney to skiptest click on those packages.
[13:01] <xnox> because gnupg2 transition is possibly stuck with click failure now.
[13:01] <xnox> or possibly partially release above silo into yakkety only?
[13:01] <juliank> Oddly enough, I did not reserve any space in the cache version, so both 1.3 and 1.2.15 have 10.6. That works now as they are the same format, but I should invent a better way to allow for independent changes in multiple branches of apt
[13:03] <pitti> xnox: oh, I just force-badtest'ed the current click version as I thought it got broken by some apparmor thing, not the new gnupg2?
[13:13] <xnox> pitti, no it's broken all by itself. the gnupg2 impact is unknown. It does use debsigs-verify thing, which uses gpgv, which should be fine.... but i want to test that.
[13:15] <kgunn> flexiondotorg: ping
[13:21] <cjwatson> xnox: I don't really want to think about doing a partial release, no idea how bileto would cope
[13:21] <cjwatson> (hopefully it would be fine, but I don't know)
[13:58] <Laney> xnox: are you winning?
[13:59] <xnox> Laney, i am working on making more win
[14:00] <Laney> k
[14:00] <xnox> trying to fix parcimonie on our infra, it passes locally...
[14:00] <Laney> well done for taking it on
[14:02] <Laney> xnox: can provide you with access to a machine if you want
[14:02] <xnox> nah it's all good. i create citrain thingy and it gives me access to our infra for adt
[14:02] <Laney> you can operate it interactively then
[14:02] <Laney> but ok
[14:04] <doko_> tvoss: any update on unity-scopes-api and thumbnailer?
[14:13] <Laney> xnox: reproduces for me with an adt-buildvm-ubuntu-cloud thingy btw
=== tyhicks` is now known as tyhicks
[14:15] <xnox> Laney, i use lxc locally.
[14:15] <Laney> well you also couldn't reproduce it
[14:16] <Laney> just saying :)
[14:16] <xnox> right. it's building in bileto, and should fix things there ( i did a blind patch ) in the mean time porting buildroot
=== zigo is now known as Guest39147
[14:39] <Laney> ahh
=== zigo_ is now known as zigo
[15:25] <Laney> xnox: add-apt-repository doesn't work out of the box due to dirmngr not getting installed
[15:25] <xnox> muahaaaaaa
[15:26]  * xnox ponders why it needs dirmngr all of the sudden....
[15:27]  * Laney knows nothing
[16:08] <doko_> Laney: please could you just attach the D file that triggers the issue? #1620681
[16:09] <Laney> if you want
[16:09] <doko_> ta
[16:19] <doko_> Laney: I want the command line too ;p
[16:20] <Laney> I doubt you can build those things alone
[17:00] <bdmurray> pitti: the ubuntu-release-upgrader package tests started failing recently and I wonder if its related to the server change - http://autopkgtest.ubuntu.com/packages/ubuntu-release-upgrader
[17:03] <bdmurray> pitti: the same failure happens if changelogs.ubuntu.com is not accessible when running test_dist_upgrade_fetcher_core.py
[17:12] <Laney> doko_: got a reasonably minimal reproducer now
=== JanC is now known as Guest18007
=== JanC_ is now known as JanC
[19:07] <pitti> bdmurray: which server change? was changelogs.u.c. changed recently and the test needs updating?
[19:10] <bdmurray> pitti: I mean the autopkg test server
[19:13] <pitti> bdmurray: I'm not aware of any change there; IS changed the firewall the other day, but the proxy should still behave as it used to
[19:28] <bdmurray> pitti: is there anyway to test the firewall manually?
[19:29] <pitti> bdmurray: sure, I can run things in a scalingstack instance
[19:30] <pitti> bdmurray: indeed wget -O- http://changelogs.ubuntu.com/last_check.txt hangs now
[19:30] <pitti> it seems our proxy stopped allowing changelogs.u.c.
[19:32]  * pitti adds it to $no_proxy
[19:33] <bdmurray> pitti: thanks
[19:34] <bdmurray> pitti: also, the link back to the package here is broken http://autopkgtest.ubuntu.com/packages/u/ubuntu-release-upgrader/trusty/amd64
[19:41] <pitti> bdmurray: I rolled out the proxy config update, so a retry ought to work now
[19:44] <pitti> bdmurray: link fixed, thanks for pointing out
[19:58] <nacc> smoser: thanks for the importer bugs and MRs, I'll try and get to them this week!
[19:59] <smoser> nacc, cool. thanks.
=== chiluk_ is now known as chiluk
[20:25] <jbicha> sakrecoer: where did you get numix-blue from?
[20:29] <jbicha> numix-blue should really be a separate source package (I can't tell what version it claims to be or where it came from or who wrote it)
[20:49] <krytarik> jbicha: We are planning to get it in via Debian - but it was too late for this release.
[20:52] <jbicha> krytarik: ok, I understand UI freeze
[20:56] <Unit193> LocutusOfBorg: ...Feel like sponsoring something super simple to Debian?
[20:58] <flexiondotorg> kgunn, Hi
[20:59] <kgunn> flexiondotorg hey :)
[20:59] <flexiondotorg> I was busy at work today so not on IRC.
[20:59] <flexiondotorg> But, evening now :-)
[20:59] <flexiondotorg> kgunn, How you doing?
[20:59] <kgunn> good, you? i wanted to pick your brain, as mine got fuzzy, but I was wondering about those gpu drivers...
[21:00] <flexiondotorg> OK
[21:00] <kgunn> i couldn't recall were those closed source? or are those in some way realted to the freedesktop project here
[21:00] <kgunn> https://github.com/anholt/mesa/wiki/VC4
[21:01] <flexiondotorg> Those are the drivers.
[21:01] <LocutusOfBorg> Unit193, yes
[21:04] <LocutusOfBorg> but I guess you will have to send a mail :)
[21:05] <Unit193> LocutusOfBorg: Git or dch?
[21:07] <kgunn> flexiondotorg awesome, so do you know the story on those? e.g. is that a broadcom supported project?
[21:09] <flexiondotorg> kgunn, My understanding is Eric used to work for ARM (maybe Broadcom) but is now in the employee of the Raspberry Pi Foundation working specifically on those drivers.
[21:09] <kgunn> flexiondotorg ah, that's great...
[21:09] <kgunn> flexiondotorg and our guys recently enabled gallium as part of the archive build...
[21:09] <kgunn> so these should "just be there"
[21:10] <flexiondotorg> Yes.
[21:10] <flexiondotorg> They are in the 4.4 Ubuntu Kernel. At least a version of them.
[21:10] <flexiondotorg> And the corresponding mesa and xserver pieces.
[21:11] <flexiondotorg> In 16.04.
[21:11] <kgunn> flexiondotorg cool, better story than i thot
[21:11] <kgunn> time to get a pi3 i gues
[21:11] <flexiondotorg> But I'm using the Raspberry Pi Foundation kernel on those demos I showed you.
[21:12] <flexiondotorg> The Ubuntu kernel needs some more Pi 3 hardware enablement.
[21:12] <flexiondotorg> Last time I checked.
[21:13] <kgunn> flexiondotorg missing gpu firmware? or kernel modules for things?
[21:13] <flexiondotorg> https://github.com/gohai/vc4-buildbot
[21:14] <flexiondotorg> I think missing device tree for VC4.
[21:14] <LocutusOfBorg> Unit193, I prefer mentors
[21:14] <flexiondotorg> And firmware for wifi (I think).
[21:15] <Unit193> LocutusOfBorg: Oh dang, I was going to link you to https://sigma.unit193.net/source/inxi_2.3.1-1.dsc or ssh://git.debian.org/git/collab-maint/inxi.git :3
[21:15] <Unit193> I can do that too.
[21:15] <flexiondotorg> kgunn, Eric was at Intel previously.
[21:15] <kgunn> thanks flexiondotorg
[21:15] <kgunn> will help a discussion i'm having tomorrow
[21:16] <flexiondotorg> Great. I'd love to see for Pi 2/3 is the Ubuntu raspi2 kernel.
[21:16] <flexiondotorg> There are several million of those devices out there now.
[21:16] <LocutusOfBorg> Unit193, .
[21:16] <flexiondotorg> So worth targeting.
[21:20] <Unit193> LocutusOfBorg: Oh wow, thanks.  Had just uploaded to mentors!
[21:22] <LocutusOfBorg> oops, sorry
[21:23] <Unit193> Nono, totally fine.  Thanks. :)
[21:23] <LocutusOfBorg> :)
[21:32] <doko_> jamespage: I filed rt#95411 for the porter box updates :-/
[23:37] <Unit193> nacc: Oh, never said because you were offline.  Congrats!
[23:37] <nacc> Unit193: thanks!
[23:37] <sarnold> oh!
[23:37] <sarnold> nacc: congratulations :)
[23:37] <nacc> sarnold: thanks!