[00:27] <dobey> isn't there some magic variable to set to add extra options to ./configure with dh?
=== StevenK_ is now known as StevenK
[02:51] <seyeongkim> There is mini.iso update schedule on the web? eg http://bugs.launchpad.net/bugs/1461620 can be integrated to mini.iso ?
[02:51] <ubottu> Launchpad bug 1461620 in linux (Ubuntu Trusty) "NUMA task migration race condition due to stop task not being checked when balancing happens" [Medium,Fix committed]
[02:52] <seyeongkim> or netboot
[04:43] <smartass> hi, where can I find the policy for LTS releases? https://wiki.ubuntu.com/LTS seems more like promises than a real policy
[04:43] <smartass> btw, I was told to ask this question here after aksing in #ubuntu
[05:28] <pitti> Good morning
[06:22] <cjwatson> dobey: dh doesn't do magic variables.  You would write an override_dh_auto_configure rule to add configure options.
[07:31] <dholbach> good morning
=== nudtrobert1 is now known as nudtrobert
[07:33] <didrocks> hey dholbach, thanks for your email last week! :)
[07:33] <dholbach> salut didrocks
=== Chipaca` is now known as Chipaca
[08:11] <tjaalton> doko: so llvm 3.7 still fails to build on i386, guess I'll switch the new mesa default back to 3.6 so that it can be uploaded
[08:38] <jamespage> doko, I had a query from ceph upstream about how they might reduce the size of their debug packages with dwz (as they do for centos/rhel/fedora)
[08:38] <jamespage> doko, do we have an equiv for Ubuntu/Debian?
=== Chipaca is now known as Chipakeitor
=== Chipakeitor is now known as __chip__
=== __chip__ is now known as Chipaca
[09:54] <doko> tjaalton, I'm not going to pull in the third llvm version into main. if you want to do that please get rid off 3.5 first
[09:58] <doko> jamespage, not on my radar. I'll look at using compression by default with binutils 2.26
[09:58] <doko> jamespage, any feedback on my dovecot question?
[10:16] <jamespage> doko, dovecot?
[10:16]  * jamespage reads backscroll
[10:17] <doko> jamespage, I was looking at the dovecot merge, neglected for the 18 months ... debian dropped the ssl cert support between 2.2.13-5 and 2.2.13-8. do you have any suggestion how to handle that in ubuntu?
[10:17] <jamespage> doko, blimey - let me take a peek
[10:24] <jamespage> doko, personally I'd +1 following debian's removal of that stuff
[10:24] <jamespage> upgrades should remain intact, new installs don't get self-signed certs
[10:26] <jamespage> doko, whilst we're chatting ;)
[10:26] <jamespage> doko, the "Multi-Arch: same" updates for the jerasure and gf-complete libs - does that just apply to the actualy library package (i.e. not the -dev package)
[10:31] <doko> jamespage, -dev too. I didn't see anything that would fail with this
[10:32] <jamespage> doko, I think jerasure is probably OK for that - but I just added some binaries to -dev for gf-complete to support unit testing in reverse-depends
[10:32] <doko> jamespage, ohh, maybe split these out into a tools or bin package?
[10:32]  * jamespage ponders that
[10:33] <doko> ok, still looking at the snakeoil handling in dovecot
[10:34] <rbasak> infinity: your comment in https://bugs.launchpad.net/ubuntu/+bug/1487538/comments/2 is contrary to https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages which I think is the source of my previous confusion. Please can you clarify? Can I update "FeatureFreeze for new packages" in the wiki, effectively replacing it with your comment?
[10:34] <ubottu> Launchpad bug 1487538 in Ubuntu "Add dpdk to wily universe" [Wishlist,New]
[10:36] <doko> jamespage, but that was not a "must have". just wondering if this could be done
[10:36] <jamespage> doko, actually a tools package makes alot of sense
[10:36] <jamespage> doko, I can do that now
[10:37] <jamespage> its a NEW handle - are you OK with that?
[10:37] <doko> sure
[10:42] <tjaalton> doko: right, let's do that in w+1 then
[10:45] <jamespage> doko, I'll just get a +1 from the debian maintainer on that approach and then I'll do the work
[10:45] <jamespage> doko, I've also been chatting with the new upstream for jerasure and gf-complete (Loic - works for redhat ex inktank/ceph)
[10:46] <jamespage> doko, although they have tagged some new releases, its not that well thought out yet re versioning etc... so I'd prefer not to bump versions this cycle, and work with them on getting that resolved
[10:48] <doko> sure, I'm just checking. and reading that things were not maintained upstream raised an eye ;)
[10:49] <jamespage> doko, upstream has a new owner :-)
[10:50] <jamespage> doko, I'll repoint all the docs to the new location, and we'll work with them to move forwards next cycle
[10:50] <jamespage> doko, the functional diff between what we have and what's upstream is 0
[14:10] <sandero12> ciao
[14:10] <sandero12> !lista
[14:10] <ubottu> sandero12: No warez here! This is not a file sharing channel (or network); read the channel topic. If you're looking for information about me, type « /msg ubottu !bot ». If you're looking for a channel, see « /msg ubottu !alis ».
=== manjo` is now known as manjo
[15:38] <infinity> rbasak: Yeah, so, 8 years ago, we didn't have a formal release team (or many of the machinery we do now), and MOTU was directly making any call on the archive outside main.  I'm not sure why they made this one, and I've never noticed it was documented. :P
[15:39] <infinity> rbasak: But as long as a package isn't meant to be installed by default (by any flavour, not just Ubuntu, obviously), then it's not a feature change.  That's just straight up logical.  An argument can still be made for really late inclusion being stupid because you might have an immature package in the archive that's harder to fix post-release, but that falls under "don't be an idiot", not "we need arbitrary rules to restrict you", I'd think.
[15:40] <rbasak> infinity: yeah that's all reasonable. I'm just asking that we update the wiki because this point has caused confusion a number of times now I think.
[15:41] <infinity> rbasak: I'm all for updating the wiki.  We seem to have a habit of documenting ancient history and underdocumenting current practice. :P
[15:45] <cjwatson> I think the original MOTU call here was because there was a habit of shoving lots of new packages in at the last minute and not fixing them to, like, build and stuff.  But p-m may have helped here.
[15:46] <juliank> mvo: infinity: I was wondering about getting the final python-apt 1.0 release into wily. The changes are rather small, and it would fix problems with other unrelated packages that would complain about the current version number (which is not PEP440 compliant, there's actually also an vivid upload planned for that), and some other crazy stuff [like you stuff two Version objects for different packages with the same version number in a set,
[15:46] <juliank> and only one of them is kept]
[15:47] <juliank> It can also be synced again now, as the increases gcc 5 deps are gone, as the transition is practically done for it in Debian.
[15:47] <infinity> juliank: I was actually going to merge it a while ago, but mvo's l10n mess confused me a tad, so I was going to leave it to him (I'm not sure if his delta is intentional or build system buggery).
[15:48] <juliank> infinity: You must be talking about something else [APT?]. I'm talking about python-apt, which I uploaded 1.0 final yesterday
[15:49] <juliank> OK, not yesterday, two days ago
[15:49] <juliank> (uploaded to Debian)
[15:49] <juliank> infinity: Or do you mean the vivid thing?
[15:49] <infinity> juliank: Err, oh.  Yeah.  I read that as 'apt', not 'python-apt'.  I'm not awake yet. ;)
[15:51] <infinity> juliank: So, yeah, python-apt could have just been synced if apt was merged (because of the build-dep bump), that's the only reason we have a delta.  If you dropped the build-dep again (as the changelog claims), I have no issues with just syncing it, I think.
[15:53] <juliank> infinity: Yeah, the build-dep was dropped, which was interesting, because it was actually mostly a side-effect of mvo not having committed that change to the repo :)
[15:53] <mvo> infinity: thats build system aritfacts most likely, fortunately we worked on fixing this
[15:54] <mvo> I will claim it was intentional
[15:54] <infinity> mvo: So, 'diff debian ubuntu | filterdiff -x '*/*/*.po' | patch' would be a reasonable way to merge?
[15:54] <juliank> mvo: The thing with APT translation is, the order in which strings are extracted from files depends on the specific file system.
[15:55] <juliank> Because we auto-generate the file list from a glob pattern and did not sort it
[15:55] <juliank> Yes, exclude the po diff
[15:55] <mvo> thats fixed in git, right
[15:57] <infinity> mvo: Kay.  Because of the ordering issue mentioned, it was really hard to see if the delta was breakage or intentional imports of LP translations (for instance).
[15:58] <infinity> mvo: If our package just has the same translations as Debian, but in a different order, I'm happy to do that merge, since I'm TIL (and the merge will conflict with my last upload).
[16:00] <juliank> Was the C++ ABI transition done in Ubuntu too?
[16:00]  * juliank is not entirely up to date
[16:00] <infinity> juliank: Before Debian, yes.
[16:00] <juliank> Ah, OK
[16:00] <infinity> juliank: (Which was super fun, as we renamed a lot of libraries Debian chose not to rename, and then has to un-rename them)
[16:00] <juliank> :(
[16:00] <mvo> infinity: yeah, just do it (or use the git ubuntu/master branch)
[16:02] <infinity> mvo: Give me commit to that repository and I'll do it in git, but I had planned to just be old-fashioned and let you commit the result. :P
[16:02] <mvo> infinity: :) fair enough
[16:05] <gQuigs> hi, I've got this pending review - https://code.launchpad.net/~bryanquigley/ubuntu-seeds/ubuntukylin.wily   -  I did the same thing for Ubuntu
[16:12] <infinity> gQuigs: Lemme update my local seeds and have a look.
[16:13] <gQuigs> gst0.10 removal, just cleaning up some old branches and realized this one never made it through
[16:13] <gQuigs> infinity: thanks!
[16:13] <infinity> gQuigs: Yeah, the delta looks reasonable, I'm just updating ALL the seeds here so I can grep and see if more flavours need the same love.
[16:14] <infinity> (huge pet peeve when someone fixed a bug in one seed and says "eh, I guess the flavours will figure it out on their own without being told")
[16:14] <gQuigs> just fyi, gst0.10 is still needed on phone/KDE - unless a new QT lands
[16:14] <infinity> gQuigs: Check.
[16:14] <infinity> gQuigs: So, all GTKish flavours can/should drop 0.10?
[16:15] <gQuigs> I told Gnome
[16:15] <gQuigs> nope, Mate still had a dependency too
[16:16] <gQuigs> and Studio and Edubuntu aren't close (I did go through them all a month ago)
[16:16] <infinity> gQuigs: Oh, kay, fair enough.
[16:17] <infinity> gQuigs: Do you have a handle on what needs to be done to clean the mess for everyone for 16.04?  Seems like dropped 0.10 from the LTS supported set would be a nice win.  For 15.10, I'm less concerned.
[16:17] <infinity> s/dropped/dropping/
[16:19] <gQuigs> mostly, here are my raw notes - http://pastebin.ubuntu.com/12409537/
[16:19] <infinity> pitti: Still around?
[16:19] <gQuigs> basically QT and WxWidgets are the two biggest blockers
[16:19] <infinity> pitti: http://autopkgtest.ubuntu.com/packages/n/nvidia-graphics-drivers-304/wily/amd64/ <-- two tmpfails in a row seems not entirely ideal.
[16:20] <infinity> ERROR: Quota exceeded for instances: Requested 1, but already used 10 of 10 instances (HTTP 413) (Request-ID: req-f7f823d2-9327-48a6-8e03-dabb85fc28dc)
[16:20] <infinity> pitti: Can we not queue those up somehow, rather than failing?
[16:45] <infinity> gQuigs: Iz merged.
[16:45]  * infinity updates the meta to match.
[17:00] <gQuigs> thanks!
[17:01] <gQuigs> while in the zone :)  - https://code.launchpad.net/~bryanquigley/ubuntu-seeds/ubuntu.wily/+merge/270981
[17:02] <gQuigs> 'doh, figured I forgot about kylin for this one ^
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[17:11] <gQuigs> now complete - https://code.launchpad.net/~bryanquigley/ubuntu-seeds/ubuntukylin-xul.wily/+merge/270991
[17:41] <hallyn> slangase`: i'm afraid i don't know what to make of bug 1493590
[17:41] <ubottu> bug 1493590 in shadow (Ubuntu) "package login 1:4.1.5.1-1.1ubuntu4.1 failed to install/upgrade: package login is not ready for configuration cannot configure (current status `half-installed')" [Undecided,Incomplete] https://launchpad.net/bugs/1493590
=== slangase` is now known as slangasek
[17:47] <sarnold> what's this thing in the AptOrdering.txt attachment?  NULL: ConfigurePending
[17:48] <flexiondotorg> Evening
[17:48] <flexiondotorg> cyphermox, infinity Is there any chance you could do some sponsoring for me please?
[17:48] <cyphermox> flexiondotorg: sure, shoot.
[17:49] <flexiondotorg> cyphermox, Cheers, I'll prepare a list ;-)
[17:50] <cyphermox> flexiondotorg: just a reminder though, if you have things that ship new features there should be a feature freeze exception for them
[17:50] <flexiondotorg> Bug fixes and some UI changes.
[17:50] <flexiondotorg> And translation strings.
[17:50] <cyphermox> we're also in UI freeze
[17:51] <flexiondotorg> cyphermox, I filed these before that came into effect.
[17:51] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1493034
[17:51] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1493065
[17:51] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1493274
[17:51] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-desktop-environment/+bug/1493771
[17:51] <ubottu> Launchpad bug 1493034 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 15.10.2 bugfix release [debdiff attached]" [Undecided,New]
[17:51] <ubottu> Launchpad bug 1493065 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 15.10.3 new release [debdiff attached]" [Undecided,New]
[17:51] <ubottu> Launchpad bug 1493274 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 1.0.3.2 update [debdiff attached]" [Undecided,New]
[17:51] <ubottu> Launchpad bug 1493771 in mate-desktop-environment (Ubuntu) "Sync mate-desktop-environment 1.10.0+1 (universe) from Debian unstable (main)" [Undecided,New]
[17:51] <slangasek> hallyn: it's a bug at least two steps removed from the shadow package; ignorable / closable as invalid
[17:51] <slangasek> there's not going to be enough information there to ever debug it
[17:52] <cyphermox> flexiondotorg: https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions, but I'll comment on the specific bugs as I review
[17:53] <flexiondotorg> cyphermox, https://bugs.launchpad.net/ubuntu/+source/mate-sensors-applet/+bug/1492557
[17:53] <ubottu> Launchpad bug 1492557 in mate-sensors-applet (Ubuntu) "Sync mate-sensors-applet 1.10.4-1 (universe) from Debian unstable (main)" [Undecided,New]
[17:53] <flexiondotorg> cyphermox, https://bugs.launchpad.net/ubuntu/+source/mate-netspeed/+bug/1492558
[17:53] <ubottu> Launchpad bug 1492558 in mate-netspeed (Ubuntu) "Sync mate-netspeed 1.10.2+dfsg1-1 (universe) from Debian unstable (main)" [Undecided,New]
[17:53] <hallyn> slangasek: but how do we tell him to work around?  i expected dpkg-configure to do it
[17:54] <slangasek> hallyn: the dpkg --configure failed because the error message was spurious and the login package is *not* currently half-installed
[17:54] <hallyn> ah!  ok, thanks :)
[17:54] <slangasek> hallyn: he got the error pop-up after restart only because something deferred the crash reporting
[17:56] <hallyn> ok, thx
[18:34] <sarnold> I'm not seeing the ubuntu diff for pulseaudio at https://patches.ubuntu.com/p/ -- with version numbers like 1:4.0-0ubuntu11.1 I figured for sure we'd have a delta.. https://launchpad.net/ubuntu/+source/pulseaudio
[18:39] <mdeslaur> sarnold: the 0 in 0ubuntu pretty much means we're not tracking debian for that package
[18:39] <mdeslaur> sarnold: so no delta from debian
[18:39] <sarnold> mdeslaur: ahhh
[18:39] <sarnold> I think I know what's going on and then I find out that I really only understand our tiny little corner of the world :)
[18:40] <mdeslaur> hehehe
[18:59] <infinity> sarnold: Or, to expand on what mdeslaur said, even if we are tracking debian/* to stay in sync packaging-wise, the -0ubuntuN version means we've been skipping ahead on upstream versions, so the full debdiff is usually a many megabyte useless mess.
=== Guest39525 is now known as anthonyjf
[19:33] <sarnold> Unit193: congratulations :)
[19:33] <Unit193> sarnold: Thanks!
[19:34] <Unit193> Now, coffee time.
[19:34] <sarnold> \o/
=== anthonyf is now known as Guest95842
=== Guest95842 is now known as anthonyjf
[19:43] <infinity> Unit193: And added to ~xubuntu-uploaders ... You should be good to go.
[19:44] <Unit193> Thanks, infinity!  Did you get my other ping a few days ago, btw?
[19:44] <infinity> Unit193: If you never got a response, I'm going to go with "no".
[19:44] <infinity> Unit193: Because the alternative is "I intentionally ignored you", which seems less nice.
[19:44] <Unit193> Hah. :D
[19:46] <Unit193> https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167 pinged with that, and the other two MRs in there.
[19:49] <infinity> Unit193: Oh, right.  This.  I suppose it's too late to revisit the "maybe you should call it something other than core, so you don't have users confused by your product not at all relating to the thing the Canonical media machine is telling them about"?
[19:49] <infinity> Unit193: I won't block it based on that (though I do need to find time, or another sucker to review it all), but it seems like it would be in your best interest to call it Xubuntu Minimal or Xubuntu Lite or something catchy that isn't Core.
[19:50] <infinity> (But, we also overload "core" so much, I'd be amazed if any user wasn't already confused)
[19:51] <Unit193> Yeeeeah, kind of already had started before all that broke, would be hard to reverse it all now but I do agree xubuntu-minimal would be much nicer.
[19:51] <Unit193> bluesabre, ochosi: ↑
[19:52] <infinity> Unit193: Well, it's not like you'd need to fix seeds and metas and such, except at a leasurely pace, but once you have a product with a name, names are hard to change. :)
[19:52] <Unit193> The meta/task wouldn't be so bad if the ubuntu-upgrader tool hadn't already been patched, and we'd gotten some use for 'xubuntu-core' already. :3
[19:52] <infinity> Unit193: Totally up to you guys, though.  If Core is a settled thing and you're happier with the weird name confusion than with trying to change it, I'm cool with that.
[19:53] <Unit193> infinity: I see the problem with changing in having to patch everything, and calling it Minimal but having the task/meta be -core.  I poked the others at any rate.
[19:56] <infinity> Unit193: Metas are easy enough to change, you just make the old one depend on the new one.  Tasks might be more problematic.  EIther way, just get me an answer, and we'll move ahead with the reviews.
[19:57] <infinity> Unit193: To recap, "Ubuntu Core" is a minimal rootf, "Snappy Ubuntu Core" is the thing everyone and their dog write blog posts about, and the "core" packageset is the intersection of all flavours.  So, one more Core probably doesn't make it much worse than it already is. :P
[19:57] <infinity> Unit193: It just means your users might think it's Snappy-based.
[19:57] <Unit193> Yep, already had that one with a blog post on xubuntu.org...
[19:59] <infinity> Unit193: I'm partial to the kitsch of "Xubuntu Lite", personally.  Sort of fits the theme of xfce in general.
[19:59] <infinity> Unit193: For the CD product, that is.  The tasks/metas can really be named anything, and who cares.
[20:07] <roaksoax> q/win 19
=== mfisch is now known as Guest15777
[21:00] <Unit193> infinity: Core it is.
[21:01] <infinity> Unit193: Mmkay.
=== Guest15777 is now known as mfisch