[01:06] <nacc> tjaalton: in 16.04, libgles1-mesa is present but not installable because it depends on an old libglapi-mesa. I think that's because the xenial-updates version of mesa dropped libgles1 altogether? Should there be a dummy binary package to make libgles1-mesa not be broken? Or something to resolve that? User in #ubuntu is hitting it
[01:15] <nacc> tjaalton: i guess this is all from the 16.04.3 update for mesa?
[02:35] <Unit193> cyphermox: In regards to LP 1636666, http://lkml.iu.edu/hypermail/linux/kernel/1708.0/03653.html suggests git move from pcre1 to pcre2. " As the"
[02:35] <ubottu> Launchpad bug 1636666 in pcre2 (Ubuntu) "[MIR] pcre2" [Undecided,Incomplete] https://launchpad.net/bugs/1636666
[02:35] <Unit193> upstream PCRE maintainer has abandoned v1 maintenance for all but
[02:36] <Unit193> the most critical bug fixes, use of v2 is recommended.
[02:37] <jbicha> Unit193: for artful, we probably want to build 'git' with pcre3 (which confusingly is older than pcre2)
[02:39] <jbicha> git is only the 2nd main package to want to use pcre2
[02:39] <jbicha> https://people.canonical.com/~ubuntu-archive/transitions/html/pcre2-main.html
[02:40] <Unit193> http://repo.or.cz/git/debian.git/commit/89a26f94004eb5bf76b012f64394cec0bc508d68
[02:40] <Unit193> jbicha: Personally, I'd rather get vte2.91 out of main, but meh.
[02:43] <jbicha> Unit193: do you prefer xterm or what??
[02:43] <Unit193> Nope.
[02:44] <jbicha> no terminal?
[02:45] <Unit193> xfce4-terminal, which is in universe, and dropping vte2 to universe would allow it to build against pcre2.
[02:51] <jbicha> ok
[02:54] <jbicha> Debian's pcre2 is a pain to do security updates for, the only patch system it uses is dgit
[02:55] <Unit193> Esh..
[02:58] <jbicha> https://browse.dgit.debian.org/pcre2.git/
[03:01] <Unit193> Wow, that looks fun, but tbh I haven't looked into dgit really at all.
[03:03] <Unit193> (Still would be very nice if vte2 wasn't in main. :/ )
[04:58] <tjaalton> nacc: i'd like to know what depends on it, as nothing in the archive does
[05:35] <tjaalton> I wonder what might cause some package builds fail on sbuild when tests are enabled, while they build fine on a ppa.. reproduced with a debian host too
[05:36] <tjaalton> tried on stock xenial/debian and OOTB mk-sbuild
[08:48] <Unit193> lutostag: G'morning.
[08:48] <Unit193> Erm, LocutusOfBorg.
[08:50]  * LocutusOfBorg waves
[08:51] <Unit193> I have nothing specific to bother you with this morning. \o/
[08:58] <LocutusOfBorg> :)
[09:28] <cpaelzer> LocutusOfBorg: sorry for the wall of text in the qemu armhf bug you opened
[09:28] <cpaelzer> LocutusOfBorg: but it seems debugging went on and on and I couldn't decide which info to drop
[09:29]  * cpaelzer is providing replacement-bothering of LocutusOfBorg for Unit193 :-)
[09:52] <LocutusOfBorg> cpaelzer, thanks, I answered and I'll give another try
[10:12] <Unit193> cpaelzer: Oh btw, does that mean I can poke you for things, then? ;)
[10:42] <cpaelzer> Unit193: you can always poke as long as I can always ignore :-)
[10:43] <Unit193> Meh, got enough of that one, thanks though.
[10:44] <cpaelzer> don't get that wrong, honestly feel free to poke if you have something I can help
[10:45] <cpaelzer> LocutusOfBorg: I think for now you'd want to get the if armhf then test || true back
[10:54] <acheronuk> mitya57 LocutusOfBorg et al. http://paste.ubuntu.com/25269337/ seems to fix the FTBFS in QtwebEngine 5.7.1 that slangasek was trying to sort for his rebuild against libevent-2.1-6. Have you any objections to me uploading that while we wait for Qt 5.9?
[10:56] <mitya57> acheronuk, no objections from me
[10:58] <acheronuk> mitya57: thanks. could not see a problem, but had to ask so not to step on toes
[12:51] <sary> Salutations!
[12:51] <sary> please #see https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1709306
[12:51] <ubottu> Launchpad bug 1709306 in grub-installer (Ubuntu) "Xubuntu installer with usb in UEFI BIOS mode ubiquity GRUB Installer crashed with "grub-efi-amd64-signed" package." [Undecided,New]
[12:51] <sary> and
[12:51] <sary> https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1629348
[12:51] <ubottu> Launchpad bug 1629348 in grub-installer (Ubuntu) "installer crash (grub2) during installation in UEFI mode" [Critical,Invalid]
[12:52] <sary> additional informations i should add to the bug report
[12:52] <sary> .. before leaving the live-session!
[12:53] <sary> I don't have all day , and i need to fix this broken system..
[12:56] <sary> I hope that am in the proper channel.
[12:59] <sary> O' boy when you search the web with "ubuntu bugs launchpad xubuntu 17.04" ...
[13:01] <sary> anway , i was point it to address this to cyphermox.
[13:41] <LocutusOfBorg> jbicha, eta for gnome-settings-daemon in Debian? xmonad is uploaded
[13:42] <LocutusOfBorg> lol uploaded now
[13:42] <LocutusOfBorg> I had a cached page
[13:54] <Unit193> LocutusOfBorg: Somehow got sucked into looking at dput, seems to mostly match except manpages. >_<
[13:57] <cyphermox> sary: got your links
[13:59] <cyphermox> sary: is that an upgrade or a new install? it looks like if you're doing partitioning, you're missing an EFI partition (which the installer creates for you if you used guided partitioning)
[14:00] <sary> cyphermox: thanks, am in the live session trying to install in legacy mode .. well now the installtion is done. i've ran apport-collect but there was nothing to collect.
[14:01] <sary> well it started as a new install , then tried to reinstall ..
[14:01] <cyphermox> are you trying to do "Something else" to choose your partitions yourself?
[14:01] <sary> nope.
[14:03] <sary> anyhing you'd like me to collect to attach to the bug report! cyphermox
[14:04] <cyphermox> maybe 'sudo fdisk -l' and 'archdetect' from the live session, but it's not going to help all that much
[14:05] <cyphermox> looks like your CD didn't boot in "legacy mode"
[14:05] <cyphermox> or USB
[14:06] <sary> well it did now the installtion is done whilst bootin within legacy mode.
[14:06] <cyphermox> ok..
[14:06] <cyphermox> you didn't run into that crash this time?
[14:06] <sary> correct.
[14:07] <cyphermox> did you do anything different to boot the live session? because there isn't much else that deals this
[14:08] <sary> maybe a few shutdowns , ive wanted to tty resetting the BIOS , but i couldn't find that option.
[14:17] <sary> cyphermox: thanks for the love and support.. i shall reboot now!
[15:12] <nacc> tjaalton: possibly nothing in the archive, but, it would appear, the verison of the intel updater for 16.04 seems to depend on libgles1 still -- and it's still a package that exists and is now uninstallable, which seems like something we should avoid
[16:09] <tdaitx> https://packages.ubuntu.com/ still defaults to yakkety, shouldn't it default to zesty now?
[16:09] <nacc> tdaitx: yeah, i think someone was going to file a bug
[16:14] <tdaitx> nacc, tks, haven't found one open about that, so I did it. LP: #1709378
[16:14] <ubottu> Launchpad bug 1709378 in pkg-website "packages.u.c defaults to yakkety, should default to zesty instead" [Undecided,New] https://launchpad.net/bugs/1709378
[16:14] <nacc> tdaitx: thanks
[16:21] <nacc> slangasek: fyi, django-compat needs an upstream update for python-django to migrate (django-compat 1.0.13 only supports up to 1.10 and 1.0.14 supports up to 1.11 which is the version in a-p). Do you want me to do the uupdate?
[16:37] <slangasek> nacc: yes please! :)
[16:37] <nacc> slangasek: will do, thanks
[16:41] <doko> coreycb: https://launchpadlibrarian.net/332460548/buildlog_ubuntu-artful-amd64.skimage_0.13.0-0ubuntu3_BUILDING.txt.gz
[16:42] <doko> please could you address these sphinx related issues? I think syncing sphinx ahead of time from experimental is a bad idea anyway ...
[16:43] <coreycb> doko: yeah i agree, i think i made a mistake there
[16:43] <coreycb> doko: can we reject it at this point?
[16:44] <doko> not my call. you should address this with the releae team
[16:44] <coreycb> doko: i will
[16:44] <slangasek> this was a sync from experimental? yeah we can totally nuke that from orbit
[16:48] <slangasek> coreycb, doko: sphinx/1.6.3-1 nuked from -proposed
[16:48] <doko> ta
[16:48] <coreycb> slangasek: thank you
[16:48] <ilmaisin> slashd: hello, i read your message to the cups bug
[16:50] <slangasek> coreycb: for your awareness, the ongoing perl transition is a bit of a mess, and updating packages deep in the stack is likely to make more work for the team right now as we try to shepherd that transition through; it's a good idea to avoid syncs from experimental for the next little whie
[16:50] <slangasek> while
[16:50] <ilmaisin> slashd: do you still have the vm you used for the experiment? what will happen if you run "apt upgrade" now?
[16:52] <coreycb> slangasek: ok will do
[16:53] <slangasek> coreycb: and also, in general, uploading new versions of packages that are currently in -proposed, and are candidates, will slow down getting them into artful
[16:55] <coreycb> slangasek: do you mean packages that are stuck in proposed?
[16:55] <coreycb> and uploading new versions on top of them?
[16:56] <nacc> coreycb: i think slangasek means the ones that are not stuck, but those that are valid candidates and would migrate if a new upload wasn't placed on top?
[16:56] <slangasek> coreycb: packages currently listed as 'Valid candidate' on http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html but have not migrated
[17:00] <coreycb> nacc: slangasek: i see what you're saying.  it'll be hard for me to wait on proposed migrations at least for now, with final release of pike at end of august.
[17:00] <coreycb> for openstack packages, that is
[17:00] <slangasek> coreycb: yeah, but the reality is, any uploads now of the related packages will only make it slower
[17:02] <nacc> coreycb: yeah, i can understand that -- you're just caught between your deadline and a maze of other transitions :)
[17:04] <coreycb> slangasek: nacc: yeah, well and we do  still get ahead from an openstack pov even if pkgs are stuck in proposed because they get backported to the cloud archive from proposed where we do most of our initial testing.
[17:05] <coreycb> but duly noted, thank you
[17:05] <slangasek> coreycb: you backport from -proposed? ugh :)
[17:05] <slangasek> which means your incentivized to upload it to devel even if it's not migratable
[17:05] <coreycb> slangasek: well, it goes to a staging ppa, then once that checks out it goes to the proposed pocket of the cloud archive, then to updates later
[17:06] <coreycb> slangasek: but yes we're incentivized to do that
[17:06] <slangasek> if all goes well this will be sorted in a couple more days
[17:20] <tsimonq2> Could I please get a review of https://bugs.launchpad.net/ubuntu/zesty/+source/indicator-sound-gtk2/+bug/1708619 from someone on the SRU Team? Lubuntu would like the fix and it's sitting in the Zesty Unapproved queue (I got it sponsored).
[17:20] <ubottu> Launchpad bug 1708619 in indicator-sound-gtk2 (Ubuntu Zesty) "[SRU] sound settings does nothing - sound menu of the indicator applet" [Undecided,In progress]
=== Sir_Gallantmon is now known as Son_Goku
[17:56] <nacc> slangasek: uploaded (django-compat 1.0.14), fyi\
[17:58] <slangasek> nacc: great, thankS!
[17:59] <nacc> slangasek: np
[18:38] <rbasak> Am I right in thinking I can skip the orig tarball in an SRU upload if the orig tarball already exists in the development release?
[19:42] <nacc> rbasak: um, i *think* dput will reject it -- but I'm trying to recall, let me see in my e-mails
[19:44] <nacc> rbasak: i'm not sure, not finding it in my own e-mails. I have this vague recollection I had to include the orig tarball for the php7.0 MREs. I guess I will be able to tell you shortly :)
=== Sir_Gallantmon is now known as Son_Goku
[19:46] <rbasak> nacc: I'll just -sa to be sure then. Thanks!
=== Sir_Gallantmon is now known as Son_Goku
[20:30] <nacc> slangasek: django-compat migrated, i'll retrigger the python-django tests
[22:10] <nacc> slangasek: alright, looks like they all pass, once the update_excuses picks up the new results, python-django should migrate now
[22:24] <slangasek> nacc: migrated. fancy!
[22:25] <nacc> slangasek: nice -- it was on my todo to see if we had to add code, as when i last checked django-compat upstream hadn't yet updated. So it was just good timing :0
[23:03] <nacc> xnox: i spent some time looking at the test, and smoser is out for a while. I don't see a trivial way to run more tests in the nested guests (currently only files are pulled out). So I think the correct short-term fix is to remove that test that can't succeed with the new systemd unit.
[23:29] <nacc> mdeslaur: i sent you a couple MPs to review (and gave instructions to obtain the equivalent debdiff) for php7.0
[23:33] <mdeslaur> nacc: thanks! will take a look first thing tomorrow
[23:40] <nacc> mdeslaur: np, let me know if you have any questions