[00:58] <xnox> barry: editor clash? =)
[01:23] <mdeslaur> bdrung: yes, I was waiting for it to finish building. I'll release it now.
[01:25] <mdeslaur> bdrung: ok, released now. Sorry for the delay.
[01:31] <geofft> raof: By any chance do you have a PPA or something with apitrace? or a source package?
[01:48] <Sarvatt> geofft: https://launchpad.net/ubuntu/raring/+queue?queue_state=0&queue_text=apitrace and http://anonscm.debian.org/gitweb/?p=pkg-xorg/app/apitrace.git
[02:26] <geofft> Sarvatt: thanks! ... why does pad.lv/u/apitrace not find that? (Was I supposed to be able to find that on my own?)
[02:42] <RAOF> geofft: Probably because it's in the NEW queue at the moment, so it's not technically in the archive.
[04:10] <BenC> infinity: How will the indep package(s) get built for linux-ppc?
[04:34] <pitti> Good morning
[04:39] <pitti> cjwatson: hmm, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html seems stuck?
[05:46] <pitti> cjwatson: no process seems stuck, and running "bin/run-britney --debug" manually finishes and yields no error; but above page doesn't get updated still
[05:47] <pitti> cjwatson: is that script now also generating the excuses, or still only generates raring_probs?
[06:06] <ScottK> pitti: re #u-m you were apparently supposed to chair the non-meeting yesterday, so I was making a poor attempt at a joke.
[07:50] <dholbach> good morning
[07:52] <pitti> ah, all channels lighting up, must be dholbach :)
[07:53] <pitti> dholbach: guten Morgen!
[07:53]  * dholbach hugs pitti
[08:12] <soren> pitti: I remember we "left the meeting at the same time slot" last when we switched to DST, but whether that was respective to UTC or to our local time... I'm not sure.
[08:14] <pitti> soren: binding this to UTC doesn't seem to make much sense really; noone in the TB team is in the southern hemisphere, so binding it to London time seems more sensible
[08:15] <soren> I'm fine either way.
[08:16] <pitti> or we really have to make a new time
[08:16] <pitti> at least for me we keep switching between "impossible" and "really inconvenient"
[08:20] <pitti> soren: I mailed TB, let's collect some opinions
[08:22] <cjwatson> pitti: the entry point is run-proposed-migration, not run-britney, and you don't need to run it by hand for this since it logs to proposed-migration/logs/; it's crashing due to (probably) yet another partial-suite-merging bug which I'll look into once I've properly started work
[08:23] <cjwatson> proposed-migration/log/, sorry
[08:23] <pitti> cjwatson: ah, thanks! good to know
[08:23] <cjwatson> I'll probably have to sit down with pdb again
[10:38] <pitti> rbasak, cjwatson: wrt. our conversation yesterday, it just so happened that I saw a rather good example yesterday why failing on stderr is good at least sometimes: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-libarchive/
[10:39] <pitti> it succeeds on amd64, so the creator of the test didn't see a problem
[10:39] <pitti> but it fails on i386 only due to some type incompatiblities
[10:39] <pitti> (gcc spits out unexpected warnings)
[10:39] <cjwatson> Agreed
[10:40] <pitti> rbasak: of course at other occasions it's still unnerving, so one needs to 2>&1 them
[10:46] <rbasak> pitti: it is certainly useful here. But I'd argue that gcc should be told to fail on warnings here (there's an option for that, right)? In the general case I still think that Unix convention is that the exit status alone tells you whether something succeeded. I'd even go as far as to argue that if anything stderr=failure should be a test option, rather than the default or a requirement for the reverse.
[10:46] <rbasak> (since status printing to stderr is common)
[10:46] <pitti> rbasak: yes, it can certainly be refined; I just found it funny that on that very day I found such a case :)
[10:47] <rbasak> :-)
[10:47] <pitti> rbasak: so, please feel free to file a Debian bug, so that we can dicuss it with the autopkgtest maintainers
[10:48] <rbasak> OK, will do
[10:48] <rbasak> (I do accept that it's debatable)
[10:52] <didrocks> cjwatson: hey
[10:52] <cjwatson> Hi
[10:52] <didrocks> cjwatson: jibel and I are looking at experimenting the workflow with daily automated upload of the PS stack
[10:52] <didrocks> cjwatson: we need a user logged in into launchpad, its ssh key and the gpg keys for signing and pushing to distro
[10:53] <didrocks> (even if the last step is disabled until the tests are passing)
[10:53] <didrocks> to avoid having too many bots, do you think we can use one?
[10:53] <cjwatson> You don't need a GPG key capable of pushing to distro
[10:53] <didrocks> ah?
[10:53] <cjwatson> We agreed you could do that with copies
[10:53] <cjwatson> Remember?
[10:53] <didrocks> right
[10:53] <cjwatson> You need a GPG key capable of pushing to a PPA, but that process should be divorced from copying to the distro
[10:53] <didrocks> but the source package should be signed in the ppa, with someone having upload access?
[10:53] <didrocks> oh nice
[10:53] <cjwatson> So I would actually prefer two bots here
[10:54] <didrocks> I agree :)
[10:54] <cjwatson> One to deal with your PPA, and one running as ubuntu-archive@lillypilly that deals with copying into the distro
[10:54] <cjwatson> If you run launchpadlib as that latter user, it'll run as ~ubuntu-archive-robot
[10:55] <cjwatson> Which can copy anything into Ubuntu
[10:55] <didrocks> cjwatson: the copy was part of a jenkins job, so I guess it's getting a little bit more complex
[10:55] <xnox> and a recipe cannot create the source packages they way it is needed? (to even avoid the gpg key signing bit)
[10:56] <cjwatson> I'm not at all convinced it would be safe to copy recipe packages into the distro; I'd rather we didn't try to break ground that's quite that new
[10:56] <xnox> ok.
[10:56] <cjwatson> didrocks: You could queue it up somewhere for a cron job to process
[10:57] <didrocks> cjwatson: yeah, we are going that way I think
[10:57] <Daviey> Not to mention crappy changelog messages. :)
[10:57] <cjwatson> xnox: It's an interesting idea, certainly, but let's experiment on something that doesn't matter first :)
[10:57] <xnox> cjwatson: sure.
[10:58] <cjwatson> Daviey: Well, you could construct a recipe that just worked off a single branch, without the automatic Debian package merging stuff
[10:58] <cjwatson> (At least in theory; I don't know if that's actually implemented)
[11:04] <Daviey> cjwatson: true, didn't consider that
[11:21] <lu_zero> hi
[11:21] <lu_zero> pitti: ping
[11:21] <pitti> hello lu_zero
[11:24] <xnox> persia: thanks for cryptsetup translations =)
[11:32] <rbasak> "package libldap-2.4-2 2.4.31-1ubuntu2 failed to install/upgrade: trying to overwrite shared '/etc/ldap/ldap.conf', which is different from other instances of package libldap-2.4-2:i386" -- is this a multiarch issue? I've read https://wiki.ubuntu.com/MultiarchSpec#Architecture-independent_files_in_multiarch_packages but am not sure
[11:33] <cjwatson> Sounds like it.  Any files in Multi-Arch: same packages shared between different architectures at the same version must be bitwise-identical
[11:35] <lu_zero> pitti: mind if I query you a bit?
[11:36] <lu_zero> siretart pointed me to you to discuss about udev in ubuntu
[11:36] <rbasak> Anything special for conffiles?
[11:36] <cjwatson> I don't think so
[11:36] <rbasak> OK, thanks
[11:36]  * rbasak pokes
[11:36] <cjwatson> But slangasek would know better
[11:36] <pitti> lu_zero: sure, just ask
[11:37] <slangasek> rbasak: however, I think I remember there being a bug in dpkg not doing the sensible thing in the event the conffile has been modified on the system
[11:37] <cjwatson> I don't know if there might e.g. be a bug with locally-modified conffiles
[11:37] <cjwatson> Yeah
[11:37] <rbasak> That seems likely here
[11:37] <rbasak> This is bug 1074777
[11:37] <rbasak> I presume /etc/ldap/ldap.conf is likely to be locally modified
[11:40] <slangasek> this was Debian bug #684776
[11:40] <slangasek> rbasak: which release are you seeing this on?  Looks like we might want a dpkg SRU
[11:41] <rbasak> slangasek: 12.04.1 -> 12.10 I think. Just checking now.
[11:41] <slangasek> rbasak: right; the fixed version of dpkg is only in raring
[11:41] <rbasak> Ah
[11:43] <slangasek> rbasak: bug state munged
[11:44] <toabctl> xnox, can you have a look at bug 1037588 again? and sponsor the package if that's ok for you?
[11:44] <rbasak> slangasek: thank you!
[11:44] <xnox> toabctl: ok.
[11:48] <toabctl> xnox, thx
[12:21] <apw> cjwatson, linux-ppc only build on powerpc, not on 'all' as well is that a packaging error or something outside the package
[12:22] <cjwatson> apw: all is only ever built on i386
[12:22] <cjwatson> Why does linux-ppc need to build Architecture: all binaries?
[12:23] <apw> cjwatson, it has a common headers which seems to be marked : all.  i guess there is no good reason for that in this case
[12:24] <apw> cjwatson, but does that imply that if a package has no :i386 packages it will not build its :all packages
[12:24] <slangasek> it doesn't imply that; but the source package does need to successfully build on i386
[12:24] <cjwatson> There is an argument that this is an LP bug
[12:24] <cjwatson> It wasn't tried on i386
[12:25] <slangasek> oh, and that's not due to P-a-s?
[12:25] <cjwatson> However, in this specific case, it would probably be simplest to just make all the binaries architecture-dependent
[12:25] <slangasek> yp
[12:25] <slangasek> e
[12:25] <slangasek> ê
[12:25] <cjwatson> I'd be surprised if this were due to P-a-s, given that this is an entirely new source package
[12:25] <apw> cjwatson, right i cannot see why they need to be as it is actually single architecture
[12:26] <apw> i am just supprised it didn't build there anyhw
[12:27] <cjwatson> But do file an LP bug about this; right now, it only considers "all" in the .dsc's Architecture field if it doesn't find any other architectures it can build
[12:27] <cjwatson> I don't think that interpretation is supported by policy, although it's not desperately clear
[12:28] <apw> cjwatson, will do
[12:33] <apw> cjwatson, bug #1078266
[12:35] <cjwatson> ta
[12:43] <cjwatson> pitti: fixed proposed-migration (britney2-ubuntu r319)
[12:46] <cjwatson> apw: BTW I don't know if you noticed but linux migration is also blocked on linux-lowlatency
[12:54] <AquaL1te> i'm running ubuntu 12.04 on a lenovo x220. i can't properly shutdown/power on if there is no network connection and AC power connected. downgrading the network manager worked to fix the power on. shutdown problems still persist, i changed the timeouts in /etc/init/failsafe.conf to max 15 seconds. no result. it keeps hanging in the plymouth animation. any help? is this a known problem? no logs can be found since it probably hasn'
[12:54] <AquaL1te> kernel upgrade didn't work either
[13:06] <Sweetshark> doko: anything from my side blocking to proceed with bug 1017125 as a SRU for quantal?
[13:06] <Sweetshark> pkg is on chinstrap
[13:07] <doko> Sweetshark, I did upload
[13:07] <Sweetshark> doko: ah, awesome. sorry.
[13:08] <Sweetshark> doko: I was drowed in upstreaming our stuff so did watch it.
[13:08] <doko> Sweetshark, or did you already prepare the quantal package?
[13:08] <Sweetshark> doko: ETA this week.
[13:08] <doko> it's uploaded to raring only afaics
[13:08] <Sweetshark> ah,
[13:08] <Sweetshark> doh
[13:08] <Sweetshark> the boost quantal package
[13:09] <Sweetshark> yes, the boost quantal package is on chinstrap and the debdiff is on the bug
[13:10]  * Sweetshark thought you were talking about a libreoffice 4.0 upload for raring first.
[13:15] <AquaL1te> i guess i'll just use debian...
[13:15] <doko> Sweetshark, now uploaded to quantal ... I think you did only ping me about the raring upload, or I didn't see the second ping
[13:16] <xnox> doko: is it _both_ boost1.49 and boost-mpi-source1.49 packages?
[13:16] <Sweetshark> doko: yes, sorry for the confusion, I should have been more explicit.
[13:16] <doko> xnox, no. Sweetshark: ^^^
[13:16] <xnox> otherwise uninstallable mpi package are introduced.
[13:17] <xnox> Sweetshark: doko: cjwatson had to upload the matching boost-mpi-source1.49 into raring to migrate it.
[13:17] <xnox> Sweetshark: doko: which is not ideal.
[13:17] <BenC> cjwatson: How will the "all" packages get built for linux-ppc?
[13:18] <pitti> cjwatson: \o/ thanks!
[13:18] <Sweetshark> I didnt see anything about the boost-mpi-sources.
[13:19] <Sweetshark> xnox: what would be a better way to handle it then?
[13:19] <xnox> Sweetshark: boost1.49 is split into two source packages in ubuntu.
[13:19] <xnox> Sweetshark: the one in main builds all package, but those that build-depend on mpi.
[13:20] <xnox> Sweetshark: the boost-mpi-sources is an exact copy of the boost1.49, except it builds those bits that build-depend on mpi.
[13:20] <cjwatson> BenC: apw and I talked about this a couple of hours ago
[13:20] <xnox> Sweetshark: as we keep mpi in universe.
[13:20] <xnox> Sweetshark: so grab the boost-mpi-source1.49 package and apply your boost1.49 debdiff & adjust changelog to keep them matching.
[13:21] <Sweetshark> xnox: yikes. nasty.
[13:21] <xnox> Sweetshark: see raring's boost-mpi-source1.49 as an example.
[13:21] <Sweetshark> xnox: will do.
[13:21] <slangasek> fortunately that split can go away once ArchiveReorg is done
[13:22] <xnox> s/once/if/ =)))))
[13:22] <BenC> cjwatson: I wasn't on IRC then..what was the verdict?
[13:23] <slangasek> xnox: your skepticism in the face of resourced blueprints wounds me
[13:25] <xnox> slangasek: well... depends how we will agree to keep the build-closure. cause my understanding was that we still want mir-like process to be included in the supported set which needs closed build-dependency loop.
[13:25]  * Sweetshark translates that to: .oO( slangasek: I find your lack of faith disturbing ...)
[13:26] <slangasek> xnox: no, the closure will be over binary packages only
[13:26] <xnox> slangasek: so "once" sounds very automatic, "if" makes more neutral, as in some work will still be needed to remove the split.
[13:26] <xnox> slangasek: oh, in that case it's all good.
[13:27] <xnox> slangasek: ok. thanks for correcting me.
[13:28] <cjwatson> 13:20 <cjwatson> BenC: It's LP bug 1078266, but really there's not a lot of point in those binaries being architecture: all in the first place
[13:28] <siretart> xnox: that sounds similar to libav / libav-extra
[13:28] <cjwatson> BenC: ^- dunno if you saw that - I was disconnected
[13:35] <BenC> cjwatson: There is in the main package, but I can see it isn't really needed for the architecture specific one like linux-ppc
[13:35] <BenC> Going to require some rewiring to make it binary-arch for just the non-master builds...
[13:36] <slangasek> BenC: there's probably prior art here, in the form of the various arm-specific kernel sources
[13:36] <slangasek> linux-ti-omap4, for instance
[13:37] <BenC> slangasek: I'm hoping for something I can push back to the linux master branch so alternate kernels don't have to reimplement this again :)
[13:37] <slangasek> (and hmm, why is that source package still present in raring, sigh)
[13:37] <slangasek> BenC: right, having it sensibly merged in master would be nice :)
[13:43] <apw> BenC, i believe this is already coped with ... specifically for arm etc
[14:12] <seb128> hum, https://launchpad.net/ubuntu/+source/gegl is "interesting"
[14:12] <seb128> "0.2.0-2ubuntu1 	release, proposed (main)"
[14:12] <seb128> the build on armel failed
[14:12] <seb128> so it didn't migrate out of proposed
[14:12] <seb128> the armel builders got removed since
[14:13] <seb128> is it ok to let it in this state?
[14:15] <cjwatson> seb128: let me debug that please - that shouldn't matter
[14:15] <cjwatson> because proposed-migration isn't considering armel at all
[14:15] <seb128> cjwatson, ok, thanks
[14:15] <cjwatson> eh
[14:16] <cjwatson> no, you've misdiagnosed that :)
[14:16] <seb128> oh?
[14:16] <seb128> well, it's both release and proposed
[14:16] <cjwatson> it *has* migrated out of -proposed, but there's a set of LP timeouts that mean it can't currently be removed from -proposed
[14:16] <seb128> so something happened :p
[14:16] <cjwatson> those are being worked on
[14:16] <seb128> oh ok
[14:16] <seb128> good
[14:16] <cjwatson> but you can entirely ignore this
[14:16] <seb128> great, thanks!
[14:16] <cjwatson> once the timeouts are gone I'll clean everything up
[14:33] <bdrung> mdeslaur: thanks.
[15:49] <BenC> cjwatson, apw: linux-ppc with the arch-all override has been uploaded
[15:49] <cjwatson> Thanks
[15:49] <cjwatson> apw: Is somebody handling linux-lowlatency, do you know?
[15:50] <barry> mterry: toabctl was pinging me about bug 1076186.  last week i uploaded an sru fix to quantal-proposed (though it's still sitting in the unapproved queue).  i see that you applied the patch to lp:ubuntu-release-upgrader trunk, thanks for that!  should we upload 1:0.192 (trunk) to raring or were there other things you wanted to get into that branch (i ping you instead of pitti or mvo 'cause you touched it last :)
[15:51] <mterry> barry, I don't have other queued up fixes.  Though it's not urgent itself for raring (though I guess you're asking because SRUs like to see it fixed in devel version?)
[15:51] <barry> mterry: yep
[15:52] <barry> mterry: i'm happy enough to upload from lp:u-r-u
[15:52] <mterry> barry, OK, thanks!
[15:53] <barry> mterry: np!
[15:55] <smb> barry, Now this is scary. I just was falling over the same and had the same resolution... :-P
[15:56] <barry> smb: synchronicity is a weird thing ;)
[15:56] <roaksoax> jdstrand: howdy! So we have started looking into SRU'ing maas features in precise to completely drop the use of cobbler. However, we have to SRU two new packages to precise-updates. So I was wondering what's the process I should follow to satisfy the security team?
[15:57] <smb> barry, Especially when you start to ping about it just while I am not looking while searching launchpad (well google) for a already reported bug and ending on the very same... :)
[15:58] <barry> smb: blame toabctl :)  he pinged me on it, and i had to restore those brainbits from backup tape ;)
[15:58]  * smb expects the agents any time soon...
[15:58] <barry> mterry: pre-build.sh requires apt-btrfs-snapshot :( :(
[15:59] <mterry> barry, just to have it installed, I don't think you need btrfs
[16:00] <barry> mterry: yeah, i'm just grousing.  i remember weird apt-get update complains when apt-btrfs-snapshot was installed.
[16:01] <xnox> barry: non-fatal =)
[16:01] <xnox> mterry: well in ubiquity we have pre-build that downloads source packages and extracts / repackages them, such that it's not needed to be installed.
[16:01] <xnox> mterry: and then the embedded copy is also in the source tarball of ubiquity =))))
[16:02] <mterry> barry, oh yeah, you'll get a warning during apt-get upgrade
[16:02] <xnox> (well we do a lot more than just copy the files we do monkey-patching as well as other stuff....)
[16:02] <barry> mterry: yep
[16:04] <cjwatson> We don't do any monkey-patching in the versions in ubiquity's source tarball; that's all done at build time
[16:04] <cjwatson> (Well, apart from removing some large files we don't need)
[16:05] <xnox> there is always small print =)))))
[16:55] <Laney> stgraber: did you forget to remove the templates from the 'lxc' package?
[16:55]  * Laney got a file conflict upgrade failure :-)
[16:56] <stgraber> Laney: hmm, let me check... I triple-checked the package replaces/breaks/... but not so much the actual content...
[16:58] <stgraber> ah, and my test machine had my PPA enabled so I never actually tested the new packages... that'd explain why I didn't notice it...
[16:58] <Laney> heh
[16:58] <stgraber> Laney: yep, confirmed, files are in both packages... fixing
[17:10] <stgraber> Laney: uploaded
[17:10] <Laney> \o/
[17:10] <Laney> ta
[17:36]  * mightyiam azzking wherez his Raring kernelz
[17:37] <BenC> How do I amend a bzr commit so it shows my correct commuter?
[17:37] <BenC> *commiter
[17:40] <cjwatson> BenC: uncommit, fix config, recommit
[17:43] <apw> cjwatson, yeah i will be handling it
[17:44] <infinity> BenC: Oh, regarding your question earlier about how a ppc-only package will build indep packages, the answer is "it won't".
[17:44] <mfisch> seb128: ping
[17:44] <infinity> BenC: Does linux-ppc need to be generating indep bits? :/
[17:44] <apw> infinity, we have that prob. under control i believe
[17:44] <infinity> apw: Ahh, good.
[17:44] <BenC> infinity: That's been resolved
[17:45] <infinity> BenC: Check, just catching up on nick hilights. :P
[17:48] <BenC> cjwatson: I'm hoping I did this right. I committed e500/e500mc powerpc bits to base-installer for proper kernel detection along with a test case, ran all powerpc tests, pushed to my own branch and requested a merge with lp:~ubuntu-core-dev/base-installer/ubuntu
[17:48] <BenC> cjwatson: Is that all up to spec?
[17:49] <cjwatson> BenC: That sounds fine - something will probably mail me about it in a bit then
[17:49] <sunweaver> davidbarth, fyi, I changed nick from m1k3 to sunweaver (realname Mike Gabriel) as sunweaver will be my login ID on Debian machines once I am through NM frontdesk process of Debian.
[17:50] <BenC> cjwatson: What other packages should I look into (cd creation and such)?
[17:50] <sunweaver> cjwatson, still have my GPG key at hand? Would love it to be signed. THANKS!!!
[17:50] <infinity> cjwatson: As to the LP bug/misfeature, I had considered a simple algorithm where if we see arch all in the list, but not i386, we pick the first non-all arch to do a -b build on.  That would neatly solve the affinity issue in some cases too.
[17:50] <infinity> cjwatson: But it would mean some reworking of some bits, I think, since we just assume the nominated indep arch is the only place arch all binaries will spew forth from.  I think.
[17:51] <infinity> apw: I don't support the resolution was to stop building the common headers entirely, which just plain makes more sense for out-of-tree builds?
[17:52] <infinity> apw: Oh, except in this case, where there are 4 flavours.  Nevermind.
[17:52] <sunweaver> cjwatson, 0x25771b31
[17:53] <cjwatson> BenC: debian-installer is the main other one for now
[17:53] <cjwatson> sunweaver: oh yeah, doing now
[17:54] <sunweaver> cjwatson, awesome!
[17:54] <BenC> cjwatson: I need to arrange for the correct kernels to be installed on the cd image, in the correct locations
[17:55] <BenC> And to make sure that the rootsquashfs has the modules for them too
[17:55] <cjwatson> BenC: There's a little bit in lp:~ubuntu-cdimage/debian-cd/ubuntu, and you'll need to change livecd-rootfs too
[18:17] <BenC> # and the bastard stepchildren
[18:17] <BenC> *sniff*
[18:22] <cjwatson> BenC: Ignore livecd.sh
[18:23] <cjwatson> BenC: live-build/auto/* is the stuff we actually use now
[18:23] <BenC> Oh, crap
[18:24] <seb128> mfisch, hey
[18:25] <BenC> cjwatson: I don't see anything in those files already related to powerpc. Is there some place I have to add this?
[18:26] <cjwatson> BenC: the kernels might actually be done with defaults in live-build instead - ah, yeah, see debian/patches/ubuntu-powerpc-smp.patch there
[18:26] <BenC> Ok, thanks
[18:26] <cjwatson> (you'd need to add a conditional based on the distribution)
[18:26] <cjwatson> (er I mean the release - whatever lb calls it)
[18:36] <BenC> cjwatson: ubuntu-cdimage is a huge pile
[18:45] <sunweaver> cjwatson: signed keys have reached me. THX!
[19:02] <siretart> slomo: do you intend to update gstreamer0.10-ffmpeg to a newer upstream any time soon?
[19:08] <mterry> bryceh, hello!  I see some MIRs filed for the various VAAPI drivers (gstreamer, nvidia, intel).  Is this something we want?  Is it suitable for main?
[19:11] <mlankhorst> didn't know nvidia had vaapi support? :p
[19:14] <bryceh> mterry, hi
[19:14] <mterry> mlankhorst, apparently  vdpau-video provides it
[19:15] <bryceh> mterry, no objections offhand, more video acceleration is probably good
[19:17] <bryceh> mterry, I'd guess the only reason it's not already in main is it's newness.  afaik there's no patent issues, it's an open standard and there's no fees or other nonsense.  Should be good.
[19:17] <mterry> bryceh, ok
[19:18] <mterry> bryceh, speaking to newness, do you know where they are quality wise?  Like if we include them, are people going to see problems using them?
[19:20] <bryceh> mterry, the drivers themselves should be fairly solid at this point; Intel has gotten pretty good at testing these days.  However issues are always possible, particularly with older or corner case hardware.  But I would expect most bugs that users would see would be due to the wrappering (i.e. in gstreamer, etc.)
[19:20] <bryceh> mterry, also, often these video acceleration codecs are configurable opt-in's.  Dunno if that's the case here, but if it is that lessens the impact of regressions.
[19:21] <mterry> k
[19:21] <mterry> bryceh, thanks!
[19:21] <bryceh> no prob
[19:21] <Sarvatt> mterry: it would require gstreamer0.10-plugins-bad to be in main also..
[19:22] <mterry> Sarvatt, hmm, that's a dep of gstreamer-vaapi?  seems problematic  :)
[19:49] <barry> @pilot in
[19:57] <mfisch> Does anyone know why we don't save the brightness setting and persist it across reboots?  I assume theres history there, but I've been unable to find it, other than an upstream bug with no activity, filed in 2009
[20:16]  * TankEnMate is building wine for the first time in years, it is much bigger then he remembered
[20:16] <TankEnMate> than even...
[20:24] <TankEnMate> privmsg tankenmate
[20:25] <TankEnMate> privmsg tankenmate foo
[20:58] <cjwatson> BenC: tools/boot/raring/boot-powerpc probably
[20:58] <cjwatson> BenC: but you can let me find/do it if you like, it's not a problem ...
[21:05] <apw> BenC, in this latest upload you changed that variable, did you also change the control.stub.in to match?
[21:06] <apw> barry, ie changing them to Architecture: powerpc
[21:06] <barry> apw: did you mean me, or BenC? ;)
[21:07] <apw> barry, soz, i mean benc ... i hate the way it does that
[21:07] <barry> no worries :)
[21:08] <apw> BenC, ^^ ... also you seem to have git cruft in the src package ... i use this incantation to keep the package clean when making: dpkg-buildpackage -S -rfakeroot -I.git -I.gitignore -i'\.git.*' "$@"
[21:10] <BenC> apw: dpkg-source should naturally remove cruft (maybe not .gitignore)
[21:10] <BenC> apw: Also, I did not change the Architecture: powerpc, since it seemed ok to leave it arch-all
[21:11] <apw> BenC, you can say that but your src package has .git stuff in it
[21:11] <apw> --- linux-ppc-3.7.0/.git/COMMIT_EDITMSG2012-11-12 21:52:41.000000000 +0000
[21:11] <apw> +++ linux-ppc-3.7.0/.git/COMMIT_EDITMSG2012-11-13 15:21:28.000000000 +0000
[21:11] <apw> BenC, i suspect it doesn't apply to format 1 package like us
[21:11] <BenC> apw: interesting…bug in dpkg-source I suspect, I'll be more careful on the follow up uploads
[21:12] <apw> BenC, hmmm, doesn't that mean a binary-arch only package will produce :all packages, i suspect they won't be accepted
[21:12] <BenC> apw: according to what I heard infinity say, it should not be a problem
[21:12] <apw> but i guess at this stage we'll let it run, if when i wake up its still missing i'll s/:all/:powerpc/ ...
[21:12] <apw> if it works, then all is good
[21:12] <apw> she can be fenickerty
[21:13] <infinity> Hrm?
[21:13] <infinity> BenC: Did you just invoke my name?
[21:13] <BenC> apw: IIRC, nothing should care, it's just that, normally, arch-all isn't built in binary-arch target, so, normally, you don't see it
[21:14] <BenC> infinity: in vain, but can you confirm that an arch-all package will not make launchpad choke if it comes from what it thinks is a binary-arch build?
[21:14] <infinity> BenC: Uhm, good luck making it happen at all...
[21:15] <apw> infinity, he has switched our package so it will build the commmon headers on binary-arch, but not switched the Arch headers
[21:15] <BenC> Well, I flipped a switch in the kernel build that made the indep package build on binary-arch…I suspected that this mechanism was tested with omap builds, so assumed it had been tested before
[21:15] <apw> infinity, so you will get powerpc and 'all' packages out of the build
[21:15] <apw> BenC, well as i said at the time "and switch the Archtecture: to powerpc in control.stub.in"
[21:16] <apw> which is how we have tested it
[21:16] <BenC> I missed that part :)
[21:16] <BenC> Guess we'll know for sure in about 3 hours
[21:16] <BenC> I confirmed it actually creates the package…but I couldn't test what launchpad would do with it
[21:16] <infinity> BenC: It's not going to work at all.
[21:17] <infinity> BenC: Cause dpkg-genchanges -B will ignore the _all.deb
[21:17] <apw> infinity, i assume it will ignore the :all packages
[21:17] <infinity> BenC: Not launchpad's fault at all.
[21:17] <BenC> Well that's a right trifling bit of naughtiness
[21:17] <infinity> BenC: But since there's zero point in that package being arch:all anyway...
[21:18] <BenC> Right, I'll correct that on the next upload
[21:18] <infinity> BenC: And since it's entirely wrong to generate arch:all packages in binary-arch. :P
[21:18] <infinity> BenC: The next upload may as well be now, since this one will be broken.
[21:18] <apw> BenC, just checked the logs, and we did talk about it on #u-k and you even went 'Ah' ... crap
[21:19] <apw> BenC, so yeah you need to flip that bit on and change control.stub.in to : powerpc
[21:19] <BenC> apw: In the interest of being more-correct, I'm going to make debian/control generation DTRT when do_binary_headers_indep is set
[21:19] <apw> BenC, can we just flip those bits in this upload and then do that
[21:19] <BenC> Maybe save some other architecture the trouble of dealing with this
[21:19] <BenC> Will an upload now ever start building before 0.6 is done?
[21:20] <apw> BenC, i had some other code to do that kind of thing, like add and remove the linux-headers if they are turned on ... i should dig that out
[21:20] <apw> BenC, should do indeed
[21:20] <BenC> Ok
[21:20] <BenC> infinity: is there a way to permanently pin linux-ppc to only build on sulfur?
[21:21] <BenC> It performs builds in about half the time (4 hours instead of 8)
[21:21] <infinity> BenC: No, but I was about to do this one out of the kindness of my heart. :P
[21:30] <BenC> infinity, apw: upload in progress
[21:36] <BenC> infinity: my job is done
[21:39] <YokoZar> infinity: poke ~wine :)
[22:04] <infinity> YokoZar: I'm not ignoring you, I'm just headless chickening a bit right now.
[22:04] <YokoZar> infinity: think of me as the farmer
[22:04] <infinity> YokoZar: The one that cut off my head?
[22:05] <YokoZar> infinity: if you want to be crass about it, yeah. I prefer "fulfilled your destiny"
[22:05] <infinity> Hrm, does wine have a circular dep?  Is that actually necessary?
[22:08] <YokoZar> infinity: wine (meta package) depends on latest wine (wine1.4) which then pulls in either wine-i386 or both wine-i386 and wine-amd64.   wine-amd64 cannot run without wine-i386, so it pulls in the rest.  wine1.4 contains the stuff that's relevant to its particular architecture only
[22:08] <infinity> YokoZar: It was the wine1.4-$arch Depends: wine1.4 that I was curious about.
[22:09] <YokoZar> infinity: this way an app can depend on either wine1.4:any (arch-inspecific dependency) or on wine-i386 if it needs an arch-specific thing
[22:09] <infinity> YokoZar: Hrm, I suppose.
[22:10] <infinity> YokoZar: Also, unrelated to any of this, you didn't run clean before you removed stuff from debian/control, so you ended up with cruft in your debian/ directory that dh_clean will never remove now. :P
[22:10] <infinity> YokoZar: http://launchpadlibrarian.net/122507568/wine1.4_1.4.1-0ubuntu1_1.4.1-0ubuntu2.diff.gz
[22:10] <infinity> YokoZar: Some substvars and directories, etc.
[22:10] <YokoZar> oops
[22:11] <YokoZar> good catch
[22:11] <YokoZar> I forgot about that
[23:02] <TheMuso> @pilot in
[23:05] <mterry> Any archive admins around?   Please reject my NEW upload of nexus7-dev-tools.  (will be re-uploaded later with a different name)
[23:08] <barry> @pilot out
[23:08] <barry> TheMuso: it's all yours :)
[23:10] <TheMuso> barry: Cheers, was thinking we would have to check with either other to make sure one of us didn't already have a lock on something. :)
[23:12] <barry> TheMuso: yeah, there's more lag built into the qa page now that we go through -proposed, but i think the comments tend to get updated fairly regularly.  anyway, i guess that's the advantages of being on opposite sides of the world :)
[23:13] <TheMuso> Yep.
[23:32] <cjwatson> mterry: done
[23:32] <mterry> cjwatson, thanks!