[00:10] <exarkun> is there anything I can do to bring some attention (and hopefully a resolution) to <https://bugs.launchpad.net/bugs/1356931>?
[00:51] <Logan_> siretart: ^
[00:51] <Logan_> you closed the other one
[00:51] <jdstrand> cjwatson: fyi, uploaded 2.8.96~2541-0ubuntu3.1 to https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages just now. I used ubuntu3.1 to avoid colliding with your no change build in the ppa
[01:34] <siretart> Logan_: oh boy, that was over 4 years ago
[02:10] <Logan_> siretart: why did you only add dvdnav support to mplayer in Debian?
[02:13] <Logan_> nvm
[02:13] <Logan_> exarkun: mplayer was removed from Debian, so it's a bit of a moot point
[02:32] <hallyn> jdstrand: d'oh.  a reboot did *not* bring the vm images back?
[02:40] <jdstrand> hallyn: no
[02:40] <jdstrand> I had to regenerate them all
[02:49] <ScottK> jtaylor: Not sure if you got an answer somewhere in the backscroll. ...  The SRU team has some latitude in that case. No reason to do extra work to avoid a version bump if it doesn't cause to much extraneous noise.
[02:54] <siretart> exarkun: doesn't mpv work for you?
[03:04] <mwhudson> is there a way to have a debian patch add a binary file?
[04:58] <pitti> Good morning
[05:50] <pitti> cjwatson, slangasek: new util-linux uploaded with putting back hwclock.sh and the initscripts dependency (and some other cleanup)
[07:36] <dholbach> good morning
[07:40] <Tribaal> hi dholbach
[07:41] <dholbach> hi Tribaal
[07:48] <LocutusOfBorg1> hi dholbach :)
[07:48] <LocutusOfBorg1> quick question, does grep-excuses works for ubuntu?
[07:49] <dholbach> I don't know - I haven't used it yet
[07:51] <LocutusOfBorg1> I'm trying to help here https://lists.debian.org/debian-devel/2014/08/msg00705.html
[08:24] <Saviq> jibel, hey, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1359065/comments/2
[08:58] <jibel> Saviq, I closed it. It was a one time failure, I couldn't start the dialer from the passcode dialog and thought it was because the SIM was locked.
[09:03] <bipul_> Hello, I am getting this error messages "bzr: ERROR: unknown command "dh-make", when i am trying to run this command in my terminal bzr dh-make hello-2.7 hello-2.7.tar.gz
[09:09] <Laney> pitti: argh, this is a polkit auth failing in the test environment
[09:10] <pitti> Laney: "this" -> colord?
[09:10] <Laney> yeah
[09:14] <Laney> how does pk work out if you're "Active" or not?
[09:16] <davmor2> Laney: magic, it's always magic
[09:17] <Laney> davmor2: this is magic: http://www.youtube.com/watch?v=XyybVarOurw
[09:19] <tinoco> back
[09:21] <davmor2> Laney: https://www.youtube.com/watch?v=Mm0EcpCkCi8 more like this
[09:23] <Laney> pitti: huh, maybe not - the test in utopic release is just skipped
[09:30] <Laney> new dbus actually fixes bus activation of colord which exposes some bugs
[09:30] <Laney> ha!
[09:30] <Laney> pitti: so pk ResultActive checks seem to not work inside these VMs
[09:31] <pitti> Laney: right, there is no active logind session
[09:35] <doko> pitti, so what about overriding the bzr test results? or do you know somebody working on these?
[09:37] <pitti> doko: yes, I think overriding them is fine; I think vila looks into bzr (but also only as a side project)
[09:37] <doko> pitti, is he aware of these?
[09:37] <pitti> doko: I pinged him the other day, but I believe he's on holidays ATM
[09:37] <pitti> I can tell him again once he's back
[09:38] <doko> Laney, ^^^do you have ubuntu-release powers?
[09:41] <pitti> Laney: btw, working on the udisks2 failure
[09:41] <Laney> doko: in a bit, looking at colord atm
[09:51] <cjwatson> jdstrand: thanks!  copied
[09:52] <cjwatson> mwhudson: not as such, but maybe debian/source/include-binaries in the 3.0 (quilt) format will help you (see dpkg-source(1))
[09:54] <mwhudson> cjwatson: ah probably
[09:55] <mwhudson> for bonus points i want to do this to gcc, the packaging of which basically completely confuses me
[09:56] <mwhudson> ah well, i guess i can always just bug doko endlessly
[10:03] <exarkun> siretart: It doesn't.
[10:04] <exarkun> siretart: I have an unpleasant combination of requirements.  Neither mpv nor mplayer2 is actually capable of the video playback, only mplayer is.
[10:05] <tinoco> back
[10:08]  * mwhudson rages at patch
[10:09] <exarkun> Oh, mplayer was removed from Debian?  Great... I'm screwed I guess.
[10:11] <mlankhorst> still see 3:1.1.1+20140703+svn37232-dmo1 in sid..
[10:14] <exarkun> I wonder what Logan_ meant, then.
[10:18] <doko> apw, ogasawara: just fyi, the oprofile 1.0.0 release dropped the opcontrol binary
[10:19] <apw> doko, hmmm ok
[10:24] <doko> apw, if you need, I think the best thing would be to look at the diffs between the prerelease and the release candidate, and add this as a patch again. but it's not supported anymore upstream
[10:25] <exarkun> mlankhorst: Any ideas?  https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/542268/comments/10
[10:25] <apw> doko, not sure if we care or not, have put it on my list for poking
[10:32]  * mlankhorst is not a mplayer dev
[10:33] <exarkun> I wonder why Logan_ thinks it was removed and you think it wasn't.
[10:36] <exarkun> Hm no, it doesn't look like it's in sid to me.
[10:36] <exarkun> https://packages.debian.org/sid/mplayer - virtual package provided by mplayer2.
[10:43] <tkamppeter> I have submitted a MIR for the "brlaser" printer driver package (bug 1359137). I would like to get it in before FF. The package is super simple and small. Could this be done? I have already posted on #ubuntu-release but did not get any answer.
[11:02] <mlankhorst> weird, still works for me, but i guess it's deleted in the archive
[11:02] <mlankhorst> maybe my mirror's old
[11:02] <cjwatson> mlankhorst: very old, or else you're using <=trusty
[11:05] <mlankhorst> no, was testing in a sid chroot
[11:25] <ochosi> hi cjwatson, would you be the right person to ask about a tasksel update so that xubuntu-core would show up there?
[11:25] <ochosi> (i think Unit193 might have gotten in touch with you about this previously)
[11:26] <doko> mlankhorst, will you upload xorg-server 1.16 before the ff?
[11:26] <cjwatson> ochosi: oh yeah, will try to get that done today
[11:26] <cjwatson> sorry for the delay
[11:27] <ochosi> cjwatson: no problem! we figured people are on holidays during the summer (and rightfully so) ;)
[11:27] <ochosi> and thanks!
[12:06] <mlankhorst> doko: would love to, but still waiting on fglrx, can't keep xorg-server in -proposed that long and people seem to want me to block on fglrx.. :/
[12:06] <doko> bah
[12:11] <siretart> exarkun: what are your requirements?
[12:14] <exarkun> siretart: Software-only playback on an AD2550R/U3S3 (no xv support)
[12:15] <exarkun> in mplayer, sdl/x11 can do it.  in mplayer2 and mpv, sdl chooses the opengl backend instead (which miserably fails).
[12:19] <siretart> strange low-power hardware without proper driver support. I see
[12:24] <exarkun> siretart: is that "I see, I'm thinking more about how that case might be supported" or "I see, I'm dismissing this issue as too obscure to be worth thinking about"? :)
[12:30] <cjwatson> doko: Mind if I merge rrdtool as part of my Perl 5.20 transition PPA?
[12:30] <doko> cjwatson, sure, one package less for me
[12:30] <cjwatson> :)
[12:39] <jdstrand> cjwatson: np. fyi, we are trying to do a landing of apparmor this week. in case the timing is such that our will yours, I've merged those perl changes into our stuff
[12:39] <jdstrand> s/will/will precede/
[12:40] <ogra_> jdstrand, FYi aptdaemon isnt seeded in touch ... will be a bit harder to get the package install stuff working on the phone :(
[12:40] <Riddell> RoozbehShafiee: KDE fans always welcome in #kubuntu-devel :)
[12:40]  * ogra_ is banging his head against that since last evening ... 
[12:47] <cjwatson> jdstrand: ok
[12:47] <jdstrand> cjwatson: I'm quite sure you'll beat us, but just fyi
[12:54] <siretart> cjwatson: I'm staging a libav11 test rebuild in https://launchpad.net/~motumedia/+archive/ubuntu/libav11. feel free to sync libav from experimental whenever seems fit to you. it's my birthday today, but I'll resume working on this tomorrow.
[12:54] <siretart> off to work now, cu tonight
[12:54] <cjwatson> ok, and happy birthday :)
[12:55] <cjwatson> OMG GCC + KDE + Perl 5.20, no builds for me any time soon
[12:59] <siretart> thanks
[13:05] <cjwatson> siretart: oh, well done, you managed to cause a queue on the PPA builders :)
[13:05] <cjwatson> (not a criticism, it's just rare that people manage that since we switched to scalingstack)
[13:06] <doko> well, looks more like Riddell than siretart
[13:07] <Laney> PPA not distro
[13:07] <exarkun> siretart: A "no, I don't care about that issue, good luck figuring it out on your own" at least would have been nice, instead of leaving me hanging.
[13:07] <exarkun> Happy birthday.
[13:07] <cjwatson> doko: Yeah, I should've said "virtualised builders"
[13:08] <cjwatson> for clarity
[13:08] <Riddell> what's scalingstack?
[13:08] <cjwatson> the new openstack-based infrastructure for the virtualised builders
[13:08] <cjwatson> we've managed to decommission something like 4.5 racks
[13:09] <Riddell> is that an internal cloud system or external?
[13:09] <cjwatson> so there are currently 36 builder guests running on 3 compute nodes, which don't fall over all the time any more and hardly ever queue
[13:09] <cjwatson> internal
[13:09] <cjwatson> if by external you mean "on a public cloud host"
[13:09] <Riddell> yeah I did
[13:10] <cjwatson> we'll be folding in chindi/furud/wani from the old Xen-based system soonish, I'm told, which should bring us up to 72 guests
[13:11] <cjwatson> and hopefully eventually will be able to plug in non-x86 hardware, and eventually eventually convert all the builders to run on scalingstack rather than having real hw builders
[13:12] <Riddell> sounds impressive
[13:12] <cjwatson> with any luck it'll eventually be possible to erase the non-virt/virt distinction
[13:12] <cjwatson> but for now the saving on electricity bills and frustration should help :)
[13:15] <cjwatson> infinity: were you planning to bump glibc to assume a post-hardy kernel before FF?
[13:21] <LocutusOfBorg1> do doko do you have any pointer for me? thanks ;)
[13:22]  * doko throws a dangling pointer
[13:30] <doko> Laney, bzr ping
[13:34] <LocutusOfBorg1> so I'll try my best to reproduce and fill a bug report
[13:34] <LocutusOfBorg1> I don't want to make you upset as you are when people fill useless bug reports, this is why I would like to know something in detail for a good bug report (already reading the docs)
[13:36] <doko> LocutusOfBorg1, reporting ICEs is not useless
[13:36] <doko> unless you don't include the preprocessed source
[13:36] <LocutusOfBorg1> yes, but reporting a build log without useful informations is, right?
[13:37] <LocutusOfBorg1> so just the preprocessed source? of the failing file, right?
[13:37] <LocutusOfBorg1> because the package is over 200MB, and the build takes a lot of space
[13:37] <cjwatson> LocutusOfBorg1: /usr/share/doc/gcc/README.Bugs
[13:37] <LocutusOfBorg1> yes, already reading this
[13:38] <LocutusOfBorg1> cjwatson, no mention of ICE there
[13:38] <LocutusOfBorg1> this is why I'm wondering if there is something "more" that can be useful :)
[13:54] <pitti> wgrant: would it be possible to stop the utopic langpack cron job (if necessary), and do a manual run on request, i. e. as soon as we land the set of rebuilds?
[14:07] <wgrant> pitti: That's doable as long as it's rare :)
[14:09] <pitti> wgrant: yeah, it's just for the next utopic full export; I'd like to do that as soon as I'm able to squeeze through these rebuilds (takes awfully long due to the CI train procedure :/), but once it's done we don't want to keep the phone untranslated longer than necessary
[14:09] <pitti> wgrant: and, FWIW, crazy hours!
[14:09] <pitti> wgrant: (I fully expected you to answer in a few hours only)
[14:12] <Laney> doko: I already did it
[14:15] <doko> Laney, ahh, libaunit as well (asked stgraber about it). same as libncursesada. package is already removed from -release
[14:15] <wgrant> pitti: It's only midnight!
[14:26] <infinity> cjwatson: Yes.
[14:26] <infinity> cjwatson: I'm not sure that's a "feature" that needs freezing, per se, I'd happily do it anywhere up to a month before release (basically, enough buffer to revert if it regresses, but I can't see how or why it will).
[14:28] <infinity> cjwatson: Plus, it's been set to 2.6.32 in Debian for ages with no complaint, so if it somehow explodes for us, that would be curious.
[14:29] <infinity> cjwatson: Anyhow, I'll do a merge and twiddle before Debconf.
[14:30] <cjwatson> Joyous
[14:31] <cjwatson> wgrant: I've fixed derive-distribution to do removals first if it needs to, not that I can test it
[14:52] <RoozbehShafiee> Riddell: thanks. sure ;)
[16:06] <pitti> Riddell: whoa, uninstallbility failure galore :(
[16:07] <Riddell> uh oh
[16:07] <Riddell> que passe?
[16:07] <pitti> Riddell: I'll re-run all those autopkgtests in a bit when the builds settled down
[16:08] <pitti> Riddell: two metric tons of k* packages failed their autopkgtests on amd64 as their deps are uninstallable in -proposed
[16:08] <pitti> I figure some binNEW, or publisher lag or something
[16:09] <Riddell> no binNew but there will be plenty of bits still compiling or dep-waiting until other bits compile
[16:10] <Riddell> also kde4libs failed on arm because gcc 4.7 isn't happy and I don't have an easy test machine to check if we still need gcc 4.7
[16:11] <tinoco> back
[16:13] <shadeslayer> any perl hackers around? I need a bit of help understanding what the qw at the end means : use Debian::Debhelper::Dh_Lib qw(error);
[16:13] <cjwatson> man perlop
[16:13] <cjwatson> "Evaluates to a list of the words extracted out of STRING, using embedded whitespace as the word delimiters."
[16:14] <shadeslayer> jebus, all I want to do is call dpkg_architecture_value('DEB_HOST_MULTIARCH')
[16:14] <cjwatson> the whole thing means "import just this symbol"
[16:15] <shadeslayer> aha
[16:15] <shadeslayer> that makes more sense now
[16:15] <cjwatson> So you want   use Debian::Debhelper::Dh_Lib qw(error dpkg_architecture_value);
[16:15] <cjwatson> or similar
[16:15] <shadeslayer> ack
[16:16] <shadeslayer> thx cjwatson
[16:16] <cjwatson> np
[16:17]  * Riddell out
[16:43] <slangasek> pitti: util-linux - yay
[16:43] <slangasek> pitti: btw, you know you're not marked as an uploader of systemd-shim, right? :)
[16:43] <pitti> slangasek: yeah, seems to be well-behaved now
[16:43] <Laney> salvaging
[16:43] <pitti> slangasek: oh, err, oops -- I guess I got carried away by collab-maint, and having done some previous uploads
[16:44] <pitti> slangasek: sorry if I stepped on your toe!
[16:44] <slangasek> pitti: as long as you committed it all to git, I'm ok - but as others have been quick to remind /me/ in the past, collab-maint doesn't mean free-for-all :-)
[16:44] <pitti> slangasek: its bzr, but yes, I committed everything there and then bzr bd'ed
[16:45] <slangasek> right
[17:26] <roadmr> hello folks, has anyone seen this (corrupted video) when booting utopic under virtualbox? http://people.canonical.com/~roadmr/utopic-vbox.png
[17:33] <stokachu> barry, ping
[17:36] <barry> stokachu: pong
[17:36] <stokachu> barry, hey i sent you a PM :D
[17:37] <barry> yeah, my irc notifications seem broken atm :/
[17:38] <stokachu> barry, was seeing what we could do to get some traction on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749943
[17:38] <barry> stokachu: i'll take a look
[17:38] <stokachu> barry, thanks man
[17:38] <barry> stokachu: it'll have to clear debian new of course
[18:08] <tkamppeter> mterry, hi
[18:08] <mterry> tkamppeter, hello!
[18:09] <tkamppeter> mterry, what do you mean with a "team
[18:09] <tkamppeter> bug subscriber for Ubuntu bugs"? Who should I subscribe to this bug?
[18:10] <mterry> tkamppeter, what team is going to look after it in Ubuntu?  (just you?)
[18:10] <mterry> tkamppeter, maybe Desktop team?
[18:11] <tkamppeter> mterry, it is just me, and ubuntu-printing.
[18:11] <mterry> tkamppeter, so maybe ubuntu-printikng
[18:11] <tkamppeter> So now I see, subscribe to the package, not to the bug.
[18:12] <mterry> tkamppeter, right
[18:12] <tkamppeter> mterry, done.
[18:13] <tkamppeter> mterry, so next step is to report a bug on ubuntu-meta to add printer-driver-brlaser to Recommends: Or can you quickly do this?
[18:14] <mterry> tkamppeter, I'm a bit busy right now
[18:14] <mterry> sorry
[18:20] <tkamppeter> mterry, can you approve the MIR now?
[18:21] <mterry> tkamppeter, done!
[18:25] <tkamppeter> mterry, thank you. Updated bug 1355136. Tell me whether I have to do something else still.
[18:26] <mterry> tkamppeter, seems sufficient, sure
[18:32] <tkamppeter> Anyone around who is working on the seeds (ubuntu-meta, ...)? I would like to get printer-driver-brlaser seeded, see bug 1355136 and bug 1359137.
[18:36] <doko> pitti, jibel: please have a look at the failed autopkg tests triggered by gcc-4.9. these seem to be machine issues
[18:46] <smoser> cjwatson, is there somewhere hwere i could look at d-i's choosing the default swap size ?
[18:52] <shadeslayer> smoser: seed files probably
[18:54] <smoser> seed files ?
[18:54] <smoser> i woudlhave thought it does some logic based on available
[19:00] <cjwatson> smoser: it's basically all in partman-auto
[19:01] <smoser> ok. thanks.
[19:08] <infinity> smoser: Like many other parts of partman-auto, I'm going to assume the algorithm is just plain wrong for modern systems.  But this is also why one can specify manually.
[19:09] <smoser> well, thats fine. but i have to come up with some algorithm.
[19:09] <infinity> (It's actually really hard to guess anymore what "right" is... swapless systems are very common, but then, so are systems where you expect load profiles that will dig you 128G of pages in the hole).
[19:09] <smoser> and had nothing better than that.
[19:10] <smoser> and same case there for curtin. it will be default and often wrong.
[19:10] <infinity> Ahh, you're asking so you can make curtin match partman, and just point at us when the defaults suck? :)
[19:11] <cjwatson> Right now it's between 100% and 200% of your available RAM; the complicated bit of the algorithm is deciding how to distribute free space between that and the other partitions, which is what the second field in each recipe stanza is for, but beyond that I've never bothered to learn exactly how it works.
[19:11] <cjwatson> partman-auto/recipes/atomic
[19:12] <cjwatson> Most of the actual work is done in partman-auto/perform_recipe, and expand_scheme in partman-auto/lib/recipes.sh is the thing that does the distribution
[19:12] <infinity> It gets more interesting when 100% ram is >> 25% disk or something, then it shrinks swap to the point where it's pointless (instead of just disabling it).
[19:12] <cjwatson> Fortunately it basically hasn't had to change much in several years so I have been able to get away with ignoring the implementation
[19:13] <infinity> I've had some hilariously small partman-generated swap partitions on systems with 128G of RAM but 50G of disk.
[19:13] <infinity> (Which, I admit, is a weird configuration)
[19:13] <cjwatson> I'm actually a bit surprised that that didn't make partman just say the recipe didn't fit
[19:13] <infinity> Oh, that specific case might have just not fit, I think I've run into that once too.
[19:14] <infinity> But I've had cases where the swap created was just so small as to be useless, and we probably should revisit those just defaulting to swapless.
[19:14] <infinity> I guess I'd have to wrap my head around the current algo.  Maybe smoser can do that for us. :P
[19:14] <tvoss> cjwatson, I was wondering why .framework files are not formatted in json. any deeper reason for that?
[19:15] <cjwatson> tvoss: not particularly, it was convenient the way it was
[19:15] <tvoss> cjwatson, I would argue for the sake of consistency :)
[19:16] <cjwatson> I generally prefer deb822 for human-edited key/value files.  The only reason we did json for click manifests was that we were expecting that to be particularly familiar to the target market, and we expected to possibly need more structure
[19:16] <cjwatson> I would argue why are we arguing :)
[19:16] <cjwatson> It doesn't seem worth more than five seconds' thought
[19:16] <cjwatson> They're not changed often or anything
[19:18] <cjwatson> Also, it was consistent with the hook declaration format
[19:18] <cjwatson> (In fact, uses the same code paths internally)
[19:19] <cjwatson> Anyway, it's very little code either way, ~50 lines to parse deb822, while json uses a library but is more effort to dig through the resulting structure and handle special cases, so there's no compelling reason to bother changing now
[19:20] <cjwatson> Actually more like ~30 lines, I was counting a block comment and other boilerplate
[19:45]  * ari-tczew is taking care of sponsoring overview before FF
[20:45] <Noskcaj> cjwatson, Were you going to merge gucharmap this cycle? It seems to be just build system and translation fixes
[20:51] <cjwatson> Noskcaj: feel free if you want to; I'm not going to
[20:52] <Noskcaj> ok. Should i be using the ~ubuntu-desktop branch? It seems neglected
[21:09] <nik90> stgraber: ping
[21:51] <Noskcaj> atlas-cpp, mercator, and wfmath have just had a series of NMUs to make them build. Could someone please sync them?
[22:00] <jtaylor> looking
[22:02] <Noskcaj> I'm not sure if wfmath will need a merge, crimsun had done some fixes for it
[22:03] <jtaylor> seems the symbol file is removed so sync should work
[22:04] <jtaylor> though it needs a mini transition
[22:04] <jtaylor> and I idiot already synced one of them ._.
[22:12] <barry> stokachu: easy peasy.  i'm building for upload into debian now.  whenever it clears new, it'll need a merge for ubuntu
[22:14] <jtaylor> whens the next unapproved trusty sweep?
[22:14] <jtaylor> a package is sitting in there for two weeks already :(
[22:27] <jtaylor> meh ppc64  still has issues, different thistime
[22:30] <jtaylor> probably needs a reconf
[22:34] <jtaylor> hm it is, is our autotools not working for arm64?
[22:34] <jtaylor> Invalid configuration `aarch64-linux-gnu': machine `aarch64' not recognized
[22:36] <stgraber> nik90: pong (on very very bad wifi though)
[22:37] <nik90> stgraber: hey I was directed to your awesome articles on lxc by sergiusens. I was wondering if you had experience running Qtcreator on LXC.
[22:38] <nik90> stgraber: I just learnt about LXC today, so I will give it a shot later, but figured should ask if it requires any special config like skype or google chrome
[22:40] <nik90> stgraber: also what time is best to contact you about this..I am pretty sure I am hit some blockers since I am quite new to this
[22:40] <stgraber> nik90: since it's Qt, I'd expect it'll need the same env variable as Skype does
[22:41] <nik90> stgraber: ok. I am looking forward to using LXC for developing apps for ubuntu touch. Atm I am using a virtual VM but it is painful too heavy and slow
[22:41] <stgraber> nik90: I'm usually around on the US/Canada eastern timezone, though this week I'm down in Chicago for a conference and wifi sucks (to say the least), so I've basically been offline 90% of the time today...
[22:42] <stgraber> nik90: QT_X11_NO_MITSHM=1 is the main env variable you need for Qt AFAIK and maybe it's not actually needed, very likely varies between version of Qt
[22:43] <nik90> stgraber: ack. Will give it a try to see how it goes later. thnx
[23:54] <Big_Mac> Hello
[23:54] <Big_Mac> Anyone there?
[23:55] <Big_Mac> :(