[09:44] <doko> libguestfs doesn't seem to be recognizing gobject anymore
[09:46] <doko> LocutusOfBorg: ^^^
[09:50] <jibel> could someone restart update-manager tests triggered by ubuntu-release-upgrader on armhf ?
[09:55] <Laney> done
[10:16] <jibel> thx
[10:48] <doko> jamespage, coreycb: could you have a look at the failing murano autopkg tests on ppc64el and s390x? blocking several python packages
[12:38] <coreycb> doko: yes and thanks for the poke
[12:40] <seb128> could somebody from the SRU team look at indicator-printers in the artful queue?
[12:41] <seb128> it fixes one of the most reported issue on e.u.c in 17.10 and is waiting in the queue since 10-23
[12:43] <seb128> if you would also be useful to understand why we don't manage to get important and trivial fixes like that in in a timelined fashion if somebody from the SRU team has an explanation, we got a stack of other updates more complex uploaded later and accepted earlier
[12:46] <seb128> bdmurray, ^ hey, maybe you can have a look/have an idea why we have a such delay and what we could change to avoid that in the futur?
[12:58] <bigon> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1713457 << cyphermox xnox: hello, an idea about this bug?
[12:58] <bigon> I'm seeing that on a coleague laptop and it's breaking his VPN (vpnc) dns resolution
[12:59] <doko> coreycb: the other one blocking bzr is the python-testtools merge/sync
[12:59] <coreycb> doko: ok i'll take a look at that too
[13:01] <doko> ta
[13:10] <xnox> tsimonq2, is there a transition tracker for v5 -> '' transition of e.g. cairomm? and the rest too i guess?
[13:10] <xnox> as currently -dev packages are not installable.... https://launchpadlibrarian.net/345610614/buildlog_ubuntu-bionic-amd64.glom_1.30.4-0ubuntu11_BUILDING.txt.gz
[13:11] <tsimonq2> xnox: No but there probably should be
[13:12] <xnox> tsimonq2, i'll try to make one for cairomm
[13:12] <xnox> tsimonq2, did you drop v5 suffixes from other packages too, that I should track?
[13:13] <xnox> tsimonq2, http://paste.ubuntu.com/25953982/
[13:13] <tsimonq2> xnox: Not remembering which off the top of my head but yes
[13:14] <xnox> this is similar to the libjsoncpp tracker
[13:15] <tsimonq2> I've had few Bionic uploads in November, shouldn't be hard to find ;)
[13:15] <tsimonq2> xnox: Sure
[13:16] <xnox> tsimonq2, i'll wait for the output generated for this one; rebuild these; and then look at what proposed migration tells me ;-)
[13:16] <tsimonq2> xnox: My personal goal is to see which packages I can transition off of v5 before 18.04 so we don't have to keep transitional packages for the next 2 years...
[13:17] <tsimonq2> (meaning, before release)
[13:23] <xnox> tsimonq2, if you are migrating off v5 package names, it is wrong to keep providing them.
[13:23] <xnox> tsimonq2, plus it is not installable as you intend them to be.....
[13:24] <xnox> see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[13:24] <xnox> which lists a bunch of things that are not installable, which i will rebuild for.
[13:25] <tsimonq2> xnox: Oh, right. The alternative is to not Provide and adjust all rdeps?
[13:25] <xnox> tsimonq2, just replaces+conflicts is what you want. but not provides.
[13:26] <tsimonq2> xnox: Alright. Thanks
[13:26] <xnox> tsimonq2, also the shlibs looks wrong, as you should probably generate >= 1.12.2-1ubuntu1
[13:26] <xnox> tsimonq2, such that old v5-less does satisfy the new depends.
[13:26] <xnox> tsimonq2, such that old v5-less does NOT satisfy the new depends.
[13:28] <tsimonq2> xnox: ack, is it correctable at this point?
[13:29] <xnox> tsimonq2, yes, better do that before we rebuild all the things as per the transition tracker =)
[13:33] <tsimonq2> xnox: Sure, I won't be home for ~ 8 hours and will need a sponsor anyways, feel free to JFDI.
[13:34] <xnox> ok
[13:37] <xnox> juliank, surely if the passed argument contains '_' it means that it is a file, not a valid package name, and *only* local filesystem resolution should work. As if it is a './' path.
[13:38] <juliank> xnox: hmm, I'm not sure we'd want to go down that route and assume that _ can't be in a package name (even though that's valid for debs in theory)
[13:38] <xnox> juliank, debian policy prohibits _ in the package names...
[13:38] <juliank> It does
[13:39] <xnox> juliank, hence .changes .deb _files_ use it.
[13:39] <juliank> But (1) It also forbids upper case characters, and packages are using it (2) we might want other backends allowing it
[13:39] <xnox> juliank, hence *.deb which expands to foo_1_all.deb is a ./foo_1_all.deb, and never a metadata pkg specification.
[13:40] <xnox> juliank, what is a backend in this context?
[13:40] <juliank> Like rpm support
[13:41] <juliank> But well, "valid package name" could be made specific
[13:41] <xnox> juliank, rpm will not end in .deb thus ends in .deb and is _. I do hope you do not allow extensionless files to be installed....
[13:41] <juliank> I don't know, I did not write it :)
[13:41] <xnox> juliank, rpm will not end in .deb thus ends in .deb and has _. I do hope you do not allow extensionless files to be installed....
[13:41] <xnox> lolz
[13:41] <juliank> But we probably should
[13:41] <juliank> Like .ddeb
[13:41] <juliank> Or .udeb
[13:42] <juliank> Or future extensions :)
[13:42] <xnox> juliank, apt should not allow installing .udeb
[13:42]  * xnox is strict
[13:43]  * xnox wonders if we actually use apt to build d-i
[13:46] <cjwatson> xnox: we do, with a whole pile of options
[13:47] <cjwatson> build/util/get-packages
[13:47] <cjwatson> xnox: though only to download udebs, not to install them
[13:48] <cjwatson> I'm not aware of any situation where we use apt to install udebs, nor any where it would be sensible to do so
[13:48] <xnox> ack. thanks!
[13:48]  * xnox is anti easy access to self-harm
[14:14] <jbicha> xnox: I don't think we want to do that cairomm transition unless Debian also does it, see https://irclogs.ubuntu.com/2017/11/11/%23ubuntu-devel.html
[14:15] <jbicha> it's one thing to change the library name to drop an Ubuntu delta, it's another thing to *introduce* a delta
[14:16] <xnox> jbicha, opened block-proposed bug about it https://bugs.launchpad.net/ubuntu/+source/cairomm/+bug/1731929
[14:17] <jbicha> the same with all of the other ones that Simon started without talking to Debian, I see at least 'afflib'
[14:19] <jbicha> adplug, assimp, boolstuff
[14:20] <jbicha> and bulletml
[14:26] <jbicha> xnox: so I'm intending to try to find an Archive Admin later to delete those uncoordinated transitions from -proposed
[14:27] <xnox> jbicha, i guess https://bugs.launchpad.net/ubuntu/+source/cairomm/+bug/1731929 should be retitled RM and subscribe ubuntu-archive?
[14:28] <xnox> apw, are you delete happy? rm cairomm from bionic-proposed because it is toast
[15:03] <tsimonq2> jbicha: I'll file Debian bugs for all those packages then
[15:05] <tsimonq2> I already did a QA upload for one of the packages
[15:16] <tsimonq2> jbicha: Some of those packages have already migrated it seems, I'll give Debian those deltas too
[15:18] <michael-vb> Hello all.  I have a question regarding X.Org and Wayland sessions.  I know that when the NVIDIA driver is in use an X.Org session is forced.  Can anyone tell me what the mechanism is?  I work on the VirtualBox guest drivers and it would make sense for us too.
[15:18] <coreycb> doko: jamespage: i've uploaded a new murano to bionic and submitted the patch upstream to https://review.openstack.org/#/c/519369/
[16:04] <bdmurray> seb128: There isn't a way to evaluate whether an SRU item is "important and trivial" just by looking at the queue. If one is important please ping an SRU team member.
[16:06] <jibel> bdmurray, ubuntu-release-upgrader migrated and upgrades to bionic are green. I'll add more upgrade scenarios this week and next.
[16:07] <bdmurray> jibel: Great thanks! I appreciate it.
[16:18] <seb128> bdmurray, right, still shouldn't the queue mostly be processed by oldest items first? do you have any clue why that one isn't getting reviewed?
[16:20] <bdmurray> seb128: Yes. No, not really - maybe because its a sync and those are harder to review?
[16:20] <seb128> bdmurray, that's one thing I was wondering about ... you didn't do a review shift and skept over it for some reason?
[16:21] <seb128> I wonder if Lukas or others did
[16:21] <bdmurray> seb128: I have not looked at the particular upload but could now.
[16:22] <seb128> bdmurray, that would be nice, thanks
[16:22] <seb128> bdmurray, sorry for the stack of questions, I'm just trying to figure out what isn't working so we can maybe fix it, asking individuals to nag the SRU team members works but is a workaround at best
[16:23] <bdmurray> seb128: If its really an "important" SRU pinging is still a good idea.
[16:24] <seb128> bdmurray, right, well that one is not that important in sense it's not a security or data lost or can't-use-your-desktop type of bug, just a frequently reported crash which means apport noise for users etc
[16:24] <seb128> bdmurray, thanks for looking!
[16:26] <bdmurray> andyrock: The test case in bug 1703046 is rather weak. It'd be fine to say this is the errors bucket at errors.u.c and watch for the new version not appearing in it.
[16:27] <bdmurray> seb128: Is it fixed in Bionic?
[16:28] <andyrock> bdmurray: do you want me to update the bug description
[16:28] <andyrock> for what I know that's not been merged in trunk
[16:28] <bdmurray> Is there an outstanding merge proposal?
[16:30] <andyrock> https://code.launchpad.net/~azzar1/indicator-printers/fix-1703046/+merge/332554
[16:30] <andyrock> bdmurray: ^^^
[16:32] <bdmurray> Hmm, I'd feel better if that were closer to being fixed in bionic.
[16:32] <andyrock> it just need to get merged
[16:32] <andyrock> seb128: ^^^
[16:39] <coreycb> doko: jamespage: i've uploaded python-testtools 2.3.0 to bionic. that should unblock bzr.
[17:01] <seb128> bdmurray, andyrock, k, we can merge/land that tomorrow, it was uploaded before bionic was open so usually it would have been a pocket copy but since review was delayed we need an upload
[17:01] <bdmurray> seb128: Ah, given the timing I'll accept it provided the description is sorted out.
[17:15] <tjaalton> should artful be able to resize partitions on an nvme ssd?
[17:21] <ricotz> tjaalton, sounds like a weird question ;)
[17:21] <tjaalton> ricotz: why?
[17:21] <tjaalton> I've installed 16.04 on it, but can't install 17.10 next to it
[17:21] <ricotz> are those things actually related?
[17:22] <tjaalton> seem to be
[17:22] <ricotz> I mean hardware <-> filesystem/partitions
[17:22] <tjaalton> never had issues with "normal" ssd's
[17:22] <tjaalton> sata disks
[17:23] <ricotz> I have one here, how do you test this?
[17:23] <ricotz> without actually doing it ;)
[17:24] <tjaalton> boot the installer, see if it offers you an option to install another version by resizing partitions/filesystems
[17:24] <tjaalton> the disk needs to be fully allocated of course
[17:24] <ricotz> how is the current layout of yours?
[17:25] <tjaalton> first partition is for EFI, then is the os, and rest for swap
[17:25] <ricotz> I could imagine a used swap partition prevent it
[17:27] <tjaalton> ok, I'll try after deleting it
[17:29] <ricotz> e.g. on my running system, gparted seems to be happy and provides the required options here
[17:29] <tjaalton> what options?
[17:30] <tjaalton> on the installer?
[17:30] <ricotz> not the installer, just confirmed that this is not prevented on purpose
[17:33] <tjaalton> after deleting the swap-partition it allows install on it (of course) but not resizing the other partition
[17:33] <ricotz> hmm, I see
[17:33] <jbicha> slangasek: could you look into removing cairomm, adplug, afflib, assimp, and bulletml from bionic-proposed? we can wait for Debian to do those transitions
[17:37] <slangasek> tsimonq2: ^^ why are you changing library binary package names to incompatibly *revert* a rename that was done in Debian?
[17:39] <slangasek> (also grrr, who accepted these through NEW)
[17:42] <powersj> cyphermox: seems with bionic ISOs I'm getting asked about keyboad-configuration again as it is marked high, is this expected?
[17:43] <slangasek> jbicha: assimp and bulletml appear to have migrated; do you want to upload a revert or get tsimonq2 to do so?
[17:44] <jbicha> thanks, he can fix those 2
[17:46] <tsimonq2> slangasek: Right, apologies. I'll upload reverted packages when I get home in <= 2.5 hours
[17:46] <slangasek> tsimonq2: thanks
[17:47] <slangasek> tsimonq2: have you and jbicha already discussed this, and do you understand why these changes were wrong?
[17:48] <tsimonq2> slangasek: We briefly discussed this, and yes, I now understand why this is wrong to do in Ubuntu and not Debian.
[17:49] <tsimonq2> slangasek: One thing though, I did spot packages which the revert was only done in Ubuntu and Debian doesn't have v5 packages at all. In that case, is it alright to do the revert?
[17:50] <tsimonq2> slangasek: (and if in that case it *isn't* OK, why not?)
[17:51] <slangasek> tsimonq2: if the current state is that Ubuntu has a different name for the binary package (with v5) than Debian does, and the Debian history shows the bug was closed as "no transition required", it's appropriate to revert in Ubuntu and add a transitional Provides: as a delta, yes
[17:51] <seb128> bdmurray, thanks
[17:51] <tsimonq2> slangasek: Alright, thanks.
[17:52] <seb128> andyrock, can you please update the indicator-printers SRU description according to the feedback from Brian?
[17:56] <tjaalton> ricotz: gparted does let me resize the partition, just not the installer
[18:00] <andyrock> seb128: tomorrow if that s fine
[18:01] <ricotz> tjaalton, maybe the installer isn't comfortable with it with a specific partition layout, but I assume yours is GPT
[18:01] <tjaalton> should be
[18:02] <ricotz> of course this is also tied to the filesystem afaik some can't be shrinked
[18:03] <tjaalton> ext4
[18:09] <cyphermox> powersj: not that I know of, but what are you getting prompted for exactly? console-setup hasn't changed recently
[18:13] <powersj> cyphermox: https://imgur.com/a/WAP9J
[18:13] <powersj> sorry for the screenshots, but easiest way :)
[18:29] <cyphermox> powersj: you're not getting that on artful?
[18:30] <cyphermox> I'll go play with preseeding keyboard-configuration on ppc64el
[18:32] <powersj> cyphermox: correct, not on artful
[18:32] <powersj> happening on all arch we test too
[18:49] <cyphermox> that's special
[19:04] <rlink> Anyone on ubuntu-sponsors that can look at an SRU for network-manager?
[19:04] <rlink> (For Xenial)
[19:27] <doko> great, pythonqt bus error on armhf
[19:39] <madigens> sladen: i just landed a job at dalton maag (barring any problems). maybe i can help move things from the inside :)
[19:41] <LocutusOfBorg> doko, libguestfs is a debhelper regression
[19:41] <LocutusOfBorg> the file is there
[19:41]  * LocutusOfBorg debugs and opens a debian RC bug probably
[19:41] <sladen> madigens: oh that would be quite spiffing, yes!
[19:43] <madigens> i'm terrified about the process of switching countries though and have no idea how to find a place to stay while not already living on the isles, but maybe i'll manage.
[19:43] <sladen> madigens: I guess offering to meet you on the Heidelberg-Frankfurt-Giessen axis isn't much use then?
[19:44] <madigens> depends on when! gießen would be terrific though. frankfurt works, too.
[19:45]  * sladen has a habit of being in Giessen on 24.  $certain_month,  and occasionally other times too
[19:46] <sladen> but this week should be in Frankfurt on ~Friday
[19:46] <madigens> which month
[19:46] <madigens> i just might be in ffm on friday for dancing purposes
[19:47] <sladen> well, lets aim for Thursday/Friday
[19:47] <sladen> somewhere between G. and Ffm
[19:47] <madigens> i'm free thursday starting at 7pm, friday after 4pm
[19:48] <madigens> and live right between G and FFM
[19:48] <madigens> you have my email address, tell me spcifics when you know them
[19:49] <sladen> I tend to stay in Bad Vilbel
[19:49] <madigens> mh, that should work out
[19:50] <madigens> i'm stationed in bad nauheim
[19:51] <sladen> which reminds me, I should pester the Ebay seller in Butzbach who didn't they'd lost the item won for e1
[19:51] <sladen> decided
[19:56] <madigens> haha :)
[21:32] <rlink> Anyone on ubuntu-sponsors available to look over an SRU for Xenial's network-manager?
[21:52] <tsimonq2> rlink: Have you subscribed ~ubuntu-sponsors to the bug report?
[21:52] <rlink> tsimonq2: Yes.  Did so on Thursday of last week.
[21:54] <Unit193> tsimonq2: Since packagesets aren't getting updated, want to sponsor a real simple one?  Just upstream bump and S-V.
[22:06] <tsimonq2> Unit193: Throw me a dsc?
[22:07] <tsimonq2> Unit193: Or link, rather?
[22:12] <Unit193> It's in ~/ :---D
[22:14] <Unit193> http://paste.openstack.org/show/E4BEhNdTBoGvr80WRauF - https://sigma.unit193.net/source/xfce4-statusnotifier-plugin_0.2.1-0ubuntu1.dsc
[22:19] <tsimonq2> Unit193: Enjoy.
[22:26] <Unit193> Right then, thanks.
[22:27] <tsimonq2> (it's very fast through sbuild)
[22:28] <Unit193> Builds quickly either way.
[22:30] <tsimonq2> Well, that was sort of my point.
[22:33] <Unit193> Urgh, I need to clean /source/