[00:41] <RAOF> Ahem.  "if (unity_running () && (width < max_texture_size || height < max_texture_size)) throw_error;".  Spot the *tiny* thinko. :)
[00:46] <ajmitch> heh
[00:47] <ajmitch> just a small < vs >? :)
[00:48] <broder> i was going to go with the lack of multiplication
[00:49]  * ajmitch guesses that the check was meant to be for width or height being larger than the max texture size
[00:53] <RAOF> ajmitch wins a cookie.
[00:53] <RAOF> broder: What multiplication would be needed there?
[00:54] <slangasek> if max_texture_size measured area rather than linear size, I guess
[00:55] <broder> oh, is it a restriction on each dimension? i thought it was area
[00:56] <ajmitch> isn't the texture usually square, like 2048*2048?
[01:00] <mwhudson> the texture is usually the same size as your monitor
[01:00] <mwhudson> i think?
[01:01] <mwhudson> well, the smallest rectangle that covers all your displays
[01:01] <ajmitch> right, I mean the max size is usually square from what little I know
[01:01] <mwhudson> ah yeah
[01:01] <mwhudson> ah memories of not being able to run my laptop display and my external monitor at the same time
[01:04] <RAOF> Yeah, it's a restriction on max linear dimension.
[01:04] <RAOF> So my netbook + 24" monitor stacked vertically works fine, but breaks stacked horizontally.
[01:05] <ajmitch> that would be a pain :)
[01:06] <RAOF> Well, fortunately I only ever use my netbook for testing this sort of breakage :)
[03:25] <tjaalton> is there a way to avoid using a static dependency on a library, if the package needs to strictly depend on the version it was built against?
[03:26] <tjaalton> looks like ${shlibs:Depends} doesn't use the version that build-dep has set
[03:39] <infinity> tjaalton: Why would you need that?
[03:39] <infinity> tjaalton: If the library isn't ABI compatible with the version in shlibdeps, that's a bug.
[03:40] <tjaalton> infinity: yes, libldb is such a piece, breaks sssd every time it's updated
[03:40] <tjaalton> so sssd needs to depend on the version it was built against
[03:40] <infinity> Erm.
[03:41] <tjaalton> but the problem is that the libldb upstream don't think that way
[03:42] <infinity> Is it really changing symbols but not revving the SOVER?
[03:43] <tjaalton> see bug 746981
[03:43] <infinity> If so, then it either (A) shouldn't be a shared library, (B) we should be revving the SOVER ourselves or, (C) as a hackish and gross workaround, we should be revving the shlibs at the very least.
[03:44] <tjaalton> sssd in fedora depends on the version it was built against, but yes it would be better to fix in libldb instead :)
[03:44] <tjaalton> jelmer: ^ ?
[03:47] <tjaalton> infinity: would an acceptable band-aid for oneiric be to just rebuild sssd, and postpone the real fix for later? I have a couple of other fixes pending for it too
[03:49] <infinity> tjaalton: I guess I'd like to understand what's really going on here.  Is sssd relying on internal symbols in the unversioned modules?
[03:50] <infinity> tjaalton: But yeah, a reasonable bandaid would be just recompiling all of the libldb1 revdeps after new versions are built and installed on all arches. :/
[03:50] <infinity> tjaalton: Not an ideal long-term solution.  I suspect one or more upstreams need a smack.
[03:50] <pitti> Good morning
[03:51] <tjaalton> infinity: from chatting with upstream my understanding is this; libldb provides a plugin interface that sssd uses, but the ldb upstream (=samba) thinks all the plugins should be built in-tree
[03:51] <tjaalton> so the one that sssd provides for its own use breaks every time ldb is updated
[03:52] <infinity> Oh, the plugin is shipped by sssd.  I see.
[03:52] <tjaalton> right
[03:52] <infinity> I used to deal with plugin ABI messes like this with PHP by offering a virtual package as a dependency.
[03:53] <infinity> libldb could do something similar.  libldb-plugin-abi-20110902, or whatever.
[03:53] <infinity> And have packages that compile plugins depend on that.
[03:53] <tjaalton> yeah, good idea
[03:53] <StevenK> infinity: Ew, PHP.
[03:53] <infinity> StevenK: Shush.
[03:53] <infinity> StevenK: linda.
[03:54] <StevenK> What was wrong with Linda?
[03:54] <infinity> It was a gateway drug to Launchpad.
[03:54] <infinity> And don't deny it.
[03:54] <StevenK> But they were *years* apart ...
[03:56] <infinity> Shows how deeply it affected you.
[03:56] <infinity> tjaalton: Anyhow, if the library ABI is stable, but the plugin interface isn't (which is icky, but whatever), that seems like a vaguely sensible approach.
[03:57] <infinity> tjaalton: If those are the only two packages affected, I can help you whip something like that up.  If it's a larger set, I say go for the rebuild bandaid and do it better later.
[03:58] <tjaalton> infinity: yeah, maybe I'll just open a bug about it and go for the bandaid for now
[03:59] <tjaalton> openchange, samba4 and sssd are the only ones build-depending on libldb-dev
[03:59] <infinity> But how many build plugins?
[03:59] <tjaalton> maybe just sssd :)
[03:59] <infinity> Since I suspect that's all that breaks.
[03:59] <infinity> If the library ABI breaks too, upstream just needs some extreme violence.
[04:00] <infinity> But samba.org tends to be slightly more sane than that.
[04:00] <tjaalton> well the shlibs suggests that it's been stable since 0.9.21
[04:01] <infinity> Unless the Debian maintainer is wrong. :P
[04:01] <tjaalton> hah, right
[04:01] <infinity> If he's using a symbol checker though, then yeah.
[04:01] <infinity> Which I believe dh* now does by default if you include a .symbols file.
[04:01] <infinity> Which makes it dirt easy, even if you don't really understand how it all works.
[04:02] <tjaalton> yep, it's there
[04:04] <infinity> Yeah, band-aid rebuild away then for now, but I'd work with the Debian maintainer to add a libldb-plugin-abi-$uniquestring Provides to libldb1, ideally a string yanked from the headers somewhere, so that people who build-dep on libldb-dev can pull the same string and Depends: on it.
[04:05] <infinity> (And only people building plugins should need to worry about that black magic, from the looks of it)
[04:06] <infinity> Which might just be sssd, as you say. :P
[04:08] <tjaalton> yep :)
[05:41] <didrocks> good morning
[06:54] <dholbach> good morning
[06:58] <jamespage> morning all
[07:08] <jamespage> @pilot in
[08:15] <apw> slangasek, that looks like a mode switch flash to me, feels very much that the panel goes properly black a common sign of one
[08:17] <slangasek> apw: ok.  any ideas why I'd be getting a mode switch there, given the information gathered so far?  any recommendations on how to further track it down?
[08:17] <apw> slangasek, well that is where i'd expect there to be one, pretty much always
[08:17] <slangasek> apw: eh? why should there be any mode switching?
[08:17] <slangasek> grub already hands it off in the preferred mode
[08:18] <slangasek> and plymouth is supposed to pick it up and run with it in the same mode
[08:18] <apw> slangasek, generally we have to reprogram from BIOS planar mode into a performant *missingword* mode
[08:18] <slangasek> apw: oh, blah
[08:18] <slangasek> it works on radeon without that, though
[08:19] <apw> slangasek, hmm i wonder how it is rejigging the layout without you seeing
[08:21] <apw> slangasek, perhaps you could get a boot with drm.debug=0x4 for me, which should tell us what the mode switch is
[08:22] <slangasek> apw: sure, happy to
[08:24] <apw> slangasek, TILED ... thought i was going mad, from planar to tiled framebuffer
[08:32] <jamespage> @pilot out
[08:32] <jamespage> biab
[08:37] <slangasek> apw: what bits of this drm.debug=0x4 output do you need?  should I just grep drm /var/log/kern.log and send it on?
[08:37] <apw> slangasek, or attache a dmesg from the boot with it on
[08:41] <slangasek> apw: sent
[08:41] <slangasek> (to the bug)
[09:00] <hrw> I have a new version of package to upload to universe. but it has new binary packages so normally it would end in NEW queue. But will it be accepted at all once we passed Beta?
[09:01] <janimo> hrw, FFE is not  needed for new binaries from a source that was already accepted
[09:01] <janimo> so I think you're ok
[09:02] <hrw> janimo: but this is multilib capable cross compiler so it is new feature too - ffe or not?
[09:03] <janimo> hrw, hmm, the you'd need to ask some of the toolchain people. It is a new feature but probably worthy of a FFE
[09:03] <hrw> ok, will then wait for doko
[09:03] <janimo> so file a bug with FFE in the subject, say why it is needed and subscriobe the ubuntu-release team to it
[09:03] <hrw> thx
[09:03] <janimo> and then maybe ping people to review/discuss it with you
[09:09] <Daviey> jhunt: Good morning!  Have you had a chance to look at the udev woes (race)?
[09:10] <Daviey> (bug 818177)
[09:11] <jhunt> Daviey: been away for a week but looking @ that today.
[09:12] <Daviey> jhunt: The world has been failing apart with you gone, glad you are back :)
[09:26] <linuxboy> can I ask questions about PPAs and thing here?
[09:26] <linuxboy> I'm struggling to get a package built correctly because of some backports I need
[09:31] <linuxboy> ppa dependencies is what I need!
[09:31] <linuxboy> thanks guys!
[09:39] <apw> slangasek, from what i can see what you have is "state of the art" for intel graphics, am discussing with upstream but KMS current mode pickup and mapping is hard (apparently) cause we have little idea where the framebuffer actually is
[09:39] <apw> slangasek, was it radeon you said did pickup correctly ?
[10:14] <jamespage> @pilot in
[10:19] <linuxboy> can I get the PPA build script to install an older version of a package?
[10:27] <pitti> linuxboy: you mean to remove a PPA and restore packages to the standard Ubuntu version?
[10:27] <pitti> linuxboy: that's "ppa-purge" (the package name and command)
[10:30] <hrw> bug 860432 - ideas?
[10:30] <linuxboy> pitti: I'm building a package against another PPA. But that PPA has lower versions numbers then the packages in lucid, so its installing the new packages and I want the old ones
[10:31] <jamespage> bdrung: hows eclipse 3.7 looking? do you want me to chase through the asm3 sync yet?
[10:33] <pitti> linuxboy: that's not easily possible, I'm afraid, as apt always installs the latest version (unless you use pinning)
[10:33] <linuxboy> pitti: or specify the version with = I assume I can't get the build script to do this?
[10:34] <pitti> linuxboy: you could try setting the build deps that way, but I still doubt it would work at install time
[10:34] <linuxboy> pitti: I did, didn't work
[10:34] <pitti> you should just update the other PPA to newer versions
[10:34] <linuxboy> pitti: I want older versions :/
[10:42] <bdrung> jamespage: it works: https://launchpad.net/~eclipse-team/+archive/debian-package and yes :)
[10:57] <jamespage> bdrung: ack
[11:18] <tjaalton> uh, so how does one run the traditional su-mode on oneiric?
[11:24] <tjaalton> ..by adding 'single' to the cmdline
[11:24] <xranby> tjaalton: try sudo su
[11:25] <tjaalton> xranby: can't even log in, so need to fix that first ;)
[11:26] <xranby> tjaalton: i would try boot up from a live cd and chroot into the system you want to fix
[11:26] <tjaalton> xranby: i replied to my question already and got it working, thanks
[11:26] <xranby> tjaalton: i am mostly running on arm sytems where we do not have as good interactive  bootloaders like on x86
[11:49] <jamespage> bdrung: asm3 upgrade ACK'ed and synced from debian
[11:50] <bdrung> jamespage: now we need a freeze exception for eclipse
[12:03] <Daviey> barry: Hey, bug 785706.. do you know what the plan is?
[12:10] <cjwatson> Daviey: um, I think that was a false positive of some kind
[12:10] <cjwatson> hm, bzr build-depends: cython-dbg | python-pyrex, python-pyrex is in main
[12:11] <cjwatson> oh yes, now I reread the comments
[12:11] <cjwatson> Daviey: I'll fiddle with the seeds and sort this out
[12:13] <Daviey> super
[12:18] <doko> for the p-series we should think about getting cython into main. it's the active project afaik
[12:21] <janimo> ScottK, shall I reupload glmark2 (or any other rejected package for that matter) after FFe is granted?
[12:22]  * janimo secretly hopes rejected means - put in a queue serverside where it can be released from with no further intervention from the uploader
[12:24] <cjwatson> it's certainly possible to accept a previously-rejected package, as long as there weren't subsequently-accepted changes
[12:28] <janimo> cjwatson, no, no further uploads happened
[12:36] <cjwatson> Daviey,doko,barry: seeds changed, feel free to revisit cython in P though
[12:51] <jamespage> @pilot out
[13:05] <cjwatson> where do I find the source code that generates http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-o-tracking-bugs.html ?
[13:05] <cjwatson> bjf: ^- do you know maybe?
[13:08] <cjwatson> hmm, looks like lp:ubuntu-reports maybe
[13:09] <Daviey> cjwatson: try ~ubuntu-defect-analysts/+junk/reports-trunk
[13:09] <cjwatson> except ... ah
[13:09] <Daviey> oh wait, that hasn't been touched for a while.
[13:12] <Daviey> cjwatson: Is it fair to say, bug 776701 should be re-targeted for P?
[13:14] <Daviey> and bug 759545 ?
[13:15] <alkisg_kubuntu> Hi, it looks like the greek translation for keyboard-configuration debconf dialogs uses the wrong encoding, I only get '???'.
[13:15] <alkisg_kubuntu> ps aux => whiptail --backtitle Ρύθμιση του πακέτου --title Ρύθμιση του keyboard-configuration --output-fd 12 --msgbox ???? ?????????????????????? (a very long line with question marks)
[13:15] <alkisg_kubuntu> Is it a known problem, or should I file a bug about it?
[13:17] <cjwatson> Daviey: yes
[13:17] <cjwatson> alkisg: mm, something has gone wrong there, let me look
[13:18] <cjwatson> not so much wrong encoding as entirely ? (i.e. ASCII 63)
[13:19] <cjwatson> Persian, Hebrew, Punjabi, and Traditional Chinese all have the same problem
[13:19] <alkisg> Does it use a .mo file to get the translations? Or is it in a debconf file?
[13:19] <alkisg> Ah
[13:19] <cjwatson> alkisg: could you please file a bug?
[13:19] <cjwatson> debconf
[13:19] <alkisg> Against keyboard-configuration? Sure, thanks
[13:19] <cjwatson> yes (well, console-setup)
[13:20] <cjwatson> assign it to me
[13:20] <alkisg> Will do, ty
[13:21] <cjwatson> it was fixed in console-setup 1.68 in Debian
[13:21] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609624
[13:21] <seif> dholbach, there?
[13:21] <seif> u got mail from me
[13:22] <cjwatson> it would be good if "you've got mail from me" type things were in private messages rather than on channels, I think
[13:22] <pitti> apw, ogasawara: cool, today's kernel (-12) gave me a free battery (/sys/class/power_supply/BAT0/); could -13 make it so that it doesn't just have 0 Wh capacity? :-)
[13:23] <pitti> [    0.865598] ACPI: Battery Slot [BAT0] (battery absent)
[13:23] <pitti> ah, seems it now parses the ACPI data differently
[13:23] <pitti> I took out the battery while it's docked
[13:24] <pitti> but we probably ought to teach upower about this
[13:25] <apw> pitti, does your doc have the possibility of a battery, also is your lappy one of those which can take a battery in the CD rom space
[13:25] <pitti> apw: neither
[13:26] <apw> that does seem odd then
[13:26] <pitti> apw: it's not a real biggie, I just noticed that because I'm currently doing a fix for control-center's power applet and wondered why it shows the battery settings
[13:26] <ogasawara> apw: even more odd in the fact that I don't recall any of the patches we applied to -13 being related to power
[13:26] <pitti> ogasawara: -13? I just got upgraded to -12 today
[13:27] <ogasawara> pitti: sorry, meant -12
[13:27] <apw> ogasawara, no me either, i wonder if its just to do with being docked without the battery on reboot or somthing
[13:27] <pitti> apw: I don't think so; I haven't changed this for ages
[13:28] <apw> but yeah -11 -> -12 was a small set of changes ...
[13:28] <smoser> Daviey, bug 810019 also affected pastedeploy.
[13:28] <smoser> if we don't get that fixed, we'll see the same issue
[13:28] <smoser> iirc
[13:29] <Daviey> crap
[13:29] <Daviey> smoser: it's fixed in Debian
[13:29] <alkisg> cjwatson: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/860562 => thanks again
[13:29] <smoser> right. we need request sync for 1.6.0-2 from unstable
[13:30] <smoser> er... 1.5.0
[13:30] <cjwatson> alkisg: ta, will get that sorted
[13:38] <ogra_> gar, why does dh_autoreconf pull git onto my disk now
[13:39] <juliank> ogra_: You installed with recommends enabled. dh-autoreconf recommends autopoint which depends on git
[13:39] <ogra_> bah, PEBCAK
[13:39] <ogra_> thanks
[13:41] <juliank> ogra_: Apparently, autopoint may checkout a specific git version of gettext if requested in configure.ac and copy that into your package tree
[13:41] <juliank> It's totally insane and if it happens at build-time, breaks things
[13:41] <ogra_> grmbl ... i really hate if packages run autoreconf in the clean target
[13:45] <smoser> Daviey, are you going to request sync of pastedeploy 1.5.0-2 ? or should i.
[13:46] <Laney> and pastewebkit
[13:55] <pitti> cjwatson: with the new ubuntu-defaults-zh-cn, we can actually build the chinese images out of main now, BTW
[13:55] <pitti> cjwatson: not sure whether this would give us any extra space savings? (we already remove the apt indexes)
[13:56] <pitti> erm, except for the defaults package itself; I guess that'd be a trivial MIR, though
[13:56] <cjwatson> oh, cool.  hm, requires a BuildLiveCD change which requires an RT
[13:56] <cjwatson> so maybe let's not bother if it's not required
[13:57] <pitti> right, as component-mismatches already ought to point out main->universe depends, it shouldn't actually pull in anything from universe now
[13:58] <Daviey> smoser: i already had...
[13:58] <Daviey> i haven't done pastewebkit... has anyone else?
[14:00]  * Daviey JFDI
[14:03] <jelmer> barry: ping
[14:03] <barry> jelmer: pong
[14:04] <dholbach> seif, yep, investigating
[14:05] <dholbach> kenvandine, happy birthday
[14:05] <kenvandine> dholbach, thx!
[14:12] <bjf> cjwatson: git://kernel.ubuntu.com/bradf/ubuntu-bug-report-kit
[14:12] <bjf> cjwatson, any particular reason ?
[14:12] <cjwatson> bjf: want to fix a bug in it, there's a task showing up that shouldn't
[14:12] <bjf> cjwatson, which?
[14:13] <cjwatson> bjf: bug 790240, all of whose oneiric tasks are either Won't Fix or Fix Released
[14:14] <bjf> cjwatson, i'll fix it
[14:14] <cjwatson> bjf: cool, thanks!
[14:17] <pitti> apw, ogasawara: ah, might not actually be the -12 upgrade; my machine just suspended itself over lunch break, and after resuming there's often some battery confusion (bug 852406)
[14:17] <pitti> apw, ogasawara: so I don't think it's new after all, sorry for the confusion
[14:17] <apw> pitti, ahh the "coool" random changing of your user options without asking effect
[14:18] <pitti> apw: it's being fixed
[14:18] <pitti> apw: we didn't notice the bad default until yesterday, when gnome was actually fixed to exercise that default
[14:18] <ogra_> does gnome actually keep it that way ?
[14:19] <pitti> yes, seems they are quite eager to impose suspend everywhere
[14:19] <ogra_> oh my
[14:19] <ogra_> evil
[14:19] <pitti> in gnome upstream, you can't configure lid action, suspend on idle is 30 min regardless of AC state, you can't configure the power button, power button always suspends, etc.
[14:19] <ogra_> sigh
[14:20] <pitti> takes some catching up on our side :)
[14:20] <apw> (and suspend if you hit return ?)
[14:20] <pitti> no, the S key
[14:20] <apw> that'd work there is no S in gnome
[14:20] <ogra_> the e key would have been more effective though
[14:31] <bdmurray> pitti: I've an apport merge proposal https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/bug-856826/+merge/77022
[14:34] <tahnok> is it safe to run apt-get upgrade on the beta releases?
[14:48] <astraljava> Interesting question from someone running a beta release in the first place.
[14:57] <pitti> bdmurray: saw it, will get to it ASAP
[14:57] <ScottK> janimo: I can accept the upload from Sept 23.  Where's the FFe?
[14:58] <ScottK> (I just woke up, so I don't yet have any recollection of past decisions, including most especially ones I made)
[14:59] <cjwatson> I might as well be a stateless automaton shortly after waking up
[14:59] <cjwatson> I often have entire conversations I don't recall later
[14:59] <ogra_> heh
[15:14] <cyphermox> cjwatson: do you know much about libnl? I'm trying to figure out why it won't list the routes I'm expecting it to (which is really the cause for bug 856333)
[15:17] <cjwatson> cyphermox: really nothing at all
[15:18] <cyphermox> d'oh
[15:18] <cjwatson> I think I poked it for libnl3 or something, but that was all superficial
[15:18] <cyphermox> it's why I was asking, hoping you had tricks or something :)
[15:18] <cyphermox> thanks anyway
[15:25] <doko> bdrung, is there an eclipse 3.7 FFe report?
[15:26] <slangasek> apw: yeah, a radeom is doing this right, in comparison
[15:39] <janimo> ScottK, it is a FFe you acked yesteday but I can dig it up I guess. The only one on glmark2
[15:43] <doko> slomo, ping
[15:45] <ScottK> janimo: Found it.
[15:46] <ScottK> janimo: Done.
[15:48] <tkamppeter> agateau, one question: Will the fix for the hp-systray icon not appearing on login be completely in sni-qt or will you also need to supply another patch for HPLIP?
[15:49] <agateau> tkamppeter: it's going to be in Qt itself actually
[15:49]  * agateau fears didrocks will hate him for that
[15:50] <tkamppeter> agateau, so I will upload HPLIP now so that tomorrow there will not be such a big package approval traffic jam.
[15:51] <tkamppeter> agateau, what takes care that sni-qt is installed on a system. Is it seeded?
[15:51] <agateau> tkamppeter: I am not sure about this, didrocks knows better
[15:54] <tkamppeter> didrocks, do you know about what takes sni-qt into an installed system?
[15:54] <janimo> ScottK, thanks
[15:57]  * agateau needs to go
[15:59] <hallyn> GAH!  why do package upgrades keep resetting my 'suspend on lid close' setting?
[15:59] <pitti> hallyn: they are not supposed to..
[16:00] <pitti> gsettings list-recursively org.gnome.settings-daemon.plugins.power  | grep lid
[16:00] <pitti> hallyn: a package upgrade has little influence on that actually; does this happen when you restart your session rather?
[16:01] <seb128> hallyn, what does it change from to?
[16:02] <pitti> good night everyone
[16:02] <pitti> hallyn: (will read backscroll tomorrow morning)
[16:04] <ScottK> agateau: We have a planned Qt upload tomorrow.  Please coordinate with didrocks about what you need in it.
[16:05] <tkamppeter> agateau, HPLIP is uploaded (pitti, can you approve?)
[16:05] <hallyn> pitti: seb128: I just reset them again, but will check gsettings list-recursively org.gnome.settings-daemon.plugins.power  | grep lid after i log out+back in to see if that' sit
[16:08] <hallyn> pitti: seb128: it might be worth noting that during the package upgrades last night, it also un-set my keyboard preference for caps-lock as another control (in the middle of the upgrade).  So maybe something went awry with gnome settings altogether
[16:10] <hallyn> (but that didn't make me lose data :)
[16:21] <didrocks> tkamppeter: it's seeded directly
[16:21] <didrocks> agateau: what ScottK told ^
[16:22] <didrocks> ScottK: I won't upload before we are in sync about it, no worry (I was tracking this small french guy, I was sure he had something to hide! ;))
[16:24] <tkamppeter> didrocks, thanks.
[16:25] <didrocks> tkamppeter: yw
[16:35] <bdrung> doko: not yet
[16:35] <doko> bdrung, jamespage did bring the required asm3 into oneiric
[16:36] <bdrung> yes
[16:36] <bdrung> let me file the freeze exception request
[16:42] <bdrung> doko: bug #860723 - did i forget something?
[16:44] <doko> it's enough for me, now maybe pester pitti?
[16:44] <doko> bdrung, ^^^
[16:44] <bdrung> pitti: ^^ :)
[17:10] <doko> https://launchpadlibrarian.net/81207327/buildlog_ubuntu-oneiric-armel.xzgv_0.9%2Bsvn40-1ubuntu1_FAILEDTOBUILD.txt.gz
[17:11] <doko> seb128, pitti: which gtk/gnome libary causes these build failures?
[17:11] <doko> it's not the only one, and I think it's too late for such changes. please could you consider reverting this?
[17:15] <seb128> doko, no idea
[18:10] <mdeslaur> slangasek: heh, thanks for the flashplugin-nonfree mess cleanup
[18:15] <mdeslaur> slangasek: oh, hrm, except I think you've broken flashplugin-installer on i386 since it doesn't pull in nspluginwrapper
[18:43] <mdeslaur> slangasek: I suspect people are running the stupid "flash fixer" firefox plugin that does a rm  /var/lib/flashplugin-installer/*, but added the versioned dependency on flashplugin-downloader as you did should take care of that
[18:44] <mdeslaur> s/added/adding/
[18:46]  * micahg wonders how a firefox plugin can rm anything in /var/lib
[18:48] <mdeslaur> micahg: it spawns a sudo script and asks the user to authenticate
[18:49] <micahg> mdeslaur: we shouldn't allow that
[18:49] <mdeslaur> micahg: not sure what you mean by that
[18:50] <micahg> mdeslaur: we shouldn't allow addons to spawn a sudo anything
[18:50] <SpamapS> micahg: people shouldn't blindly type their password in either. :)
[18:50] <mdeslaur> micahg: I'm not sure how you can restrict that
[18:50] <SpamapS> apparmor?
[18:50] <micahg> mdeslaur: apparmor in by default in 12.04? :)
[18:50] <micahg> s/in/on/
[18:51] <mdeslaur> micahg: lol
[18:52] <mdeslaur> micahg: we should just block browser plugins :)
[18:53] <micahg> mdeslaur: we dropped them from the archive already :D
[18:54] <slangasek> mdeslaur: oh blast, I missed that the nspluginwrapper dep was arch-dependent
[18:54] <mdeslaur> slangasek: heh, it's a can of worms :)
[18:54] <slangasek> mdeslaur: yeah, I guess that should be made conditional again on nspluginwrapper presence, at least on x86
[18:54] <slangasek> er, i386
[18:55] <slangasek> mdeslaur: are you re-fixing that then, or shall I?
[18:55] <mdeslaur> slangasek: please go ahead
[18:55] <mdeslaur> slangasek: moving the nspluginwrapper alternative to flashplugin-installer is a good idea, btw
[18:56] <micahg> hmm, flashplugin-installer I thought was i386 only
[18:56] <micahg> oh, sorry, that's the downloader
[18:56] <mdeslaur> micahg: no, flashplugin-downloader is i386 only
[18:57] <mdeslaur> and thankfully this all gets rewritten and simplified in a month when flash 11 comes out
[18:58] <slangasek> mdeslaur: while I'm at it, I'm going to clean up this use of update-alternatives --set, which should never be called from a package
[18:58] <slangasek> and do a bit of resetting with --auto
[18:59] <mdeslaur> slangasek: I think you can get rid of the "if readlink /etc/alternatives/"$p-flashplugin" | grep -c flashplugin-nonfree" part too...I think flashplugin-nonfree is way past our supported releases
[19:02] <slangasek> mdeslaur: yes, that'll get cleaned up as a side-effect
[19:03] <mdeslaur> oh, that's the --set part you meant, got it
[19:12] <doko> persia, do you know about the history of foo-plugins?
[20:21] <slomo> doko: pong?
[20:21] <doko> slomo, \o/
[20:22] <doko> slomo, any idea about bug https://launchpad.net/bugs/749262
[20:23] <slomo> doko: unfortunately not, it only happens on ubuntu for some reason. i tried to debug it but didn't get any useful results
[20:26] <doko> slomo, did you try to build without hardening?
[20:27] <slomo> doko: nope
[20:40] <stgraber> bdmurray: hey! any plan on making the QA bot aware of people's upload rights? I don't think it makes sense to subscribe sponsors/review team when a coredev (or whoever has upload rights) attaches a patch to a bug (in this case so that others can review it)
[20:42] <bdmurray> stgraber: that'd require using that tool from the archive admins bzr branch? or the same api calls right?
[20:43] <stgraber> bdmurray: yeah, you'd need an extra API call to check that. I can probably get you a LP API example of that, I've been poking at that part of the API quite a bit this week
[20:43] <micahg> bdmurray: can you just make your query exclude where the patch author is a member of ubuntu-dev?
[20:44] <bdmurray> micahg: that sounds like a reasonable short term solution
[20:45] <micahg> bdmurray: I think it's a reasonable expectation that if someone is an ubuntu-dev, they should know how to get a patch into the distro
[20:46] <bdmurray> micahg: would "how to" mean sometimes subscribing the sponsors team so why not ensure mistakes aren't made
[20:46] <micahg> bdmurray: more noise?  some people make special arrangements for patch review
[20:46] <Daviey> stgraber: I have a code example for getting upload access for a set..
[20:47] <Daviey> i use it to generate our team report.
[20:47] <Daviey> mostly stolen code.
[20:48] <micahg> bdmurray: sponsors isn't even appropriate in all circumstances, especially this close to release where -release review needs to come first
[20:48] <stgraber> bdmurray: http://paste.ubuntu.com/698110/
[20:50] <bdmurray> stgraber: it returns a 403? that seems kind of lame
[20:50] <Daviey> stgraber / bdmurray: i think it was all stolen, actually - http://pb.daviey.com/EoGw/
[20:51] <stgraber> Daviey: yep, that looks like a copy/paste of edit_acl.py :)
[20:51] <stgraber> bdmurray: yeah, I'd have expected "False" instead of a 403
[20:51] <ajmitch> micahg: it could be good to filter stuff out before inundating the release team
[20:52] <micahg> ajmitch: that's what the review team was for :P
[20:52] <micahg> ajmitch: I wasn't suggesting that the bot subscribe the release team
[20:52] <ajmitch> oh good :)
[20:52] <bdmurray> okay I've opened a bug regarding this and will work on it sometime
[20:53] <micahg> I was just saying that an ubuntu-dev should know who to subscribe when
[20:53] <ajmitch> right, I thought you might have been suggesting that the QA bot do so
[20:53] <stgraber> Daviey: btw, I also published http://people.canonical.com/~stgraber/package_sets yesterday which likely contains the same thing as your script :)
[20:53] <ajmitch> which would be a bit painful
[20:55] <Daviey> stgraber  / Laney : is it a bug that ~developer-membership-board has upload access to sets?
[20:55] <Daviey> stgraber: that is neat
[20:55] <Laney> yes, but a small one
[20:55] <Laney> micahg is fixing it
[20:56] <stgraber> it's an implementation bug actually. The DMB should just be the owner of the teams and not a member of them
[20:56] <micahg> yes, I just need to verify with the current owners that the change is ok, and have them make it
[20:56] <micahg> will try to do that early next week
[20:56] <bdmurray> micahg: and just because they should doesn't mean they will and having the bug bot act as a safety net seems reasonable to me
[20:56] <stgraber> in the past the owner would also get the access rights but that got fixed recently in LP, so we can actually have that implemented properly now :)
[20:58] <Daviey> Talking of which, how did the discussion on fast tracking core-dev's into package sets they already have access to go?
[20:58] <micahg> bdmurray: I prefer not to get spammed by a bot trying to "help" me, but c'est la vie (sp?)
[20:58] <Daviey> Laney: ^^ i raised that with you.
[20:58] <Laney> we have a position statement in the works
[20:58] <Daviey> micahg: You have procmail, right? ;)
[20:58] <Daviey> Laney: super
[20:59] <Laney> it's more general than core-devs and package sets though
[20:59] <micahg> Daviey: no, I suppose I can filter the bot, but I'd rather see it when someone else attaches a patch so I know something needs to be done
[21:00] <Daviey> micahg: I'm just glad i've been able to remove my special-case entry for bdmurray
[21:00] <micahg> heh
[21:00] <Daviey> He has a maildir just for him, until recently.
[21:00]  * ajmitch wonders if he can just get procmail to mark those messages as read, while keeping them in the same folder
[21:01]  * Laney thought "Kryten" was how you spelt that name, if that is indeed who the QA bot is supposed to be ;-)
[21:04] <Daviey> ajmitch: it's easy to do with mbox, not sure about maildir.
[21:06] <ajmitch> yeah, I moved away from mbox, a search shows that it's possible with maildir but takes a bit of .procmailrc hackery
[21:06] <infinity> procmail for maildir and mbox are pretty much identical...
[21:07] <Daviey> infinity: This doesn't work with maildir iirc ...
[21:07] <Daviey> :0Wfh
[21:07] <Daviey> * ^X-Spam-Level: \*\*\*
[21:07] <Daviey> | formail -I"Status: RO"
[21:08] <infinity> Oh, indeed, I didn't notice the request was about status changing.
[21:09] <infinity> Google leads me to this cleverly hackish recipe: http://raamdev.com/using-procmail-to-mark-as-read
[21:11] <ajmitch> http://blog.freethemallocs.com/wordpress/2008/06/09/procmail-maildir-and-marking-as-read/ implies it has issues
[21:11] <seb128> does anybody know what updates around 1 or 2 weeks ago could have broken screen output on a dvi monitor for a docked laptop config?
[21:11] <seb128> it used to work fine, booting with the laptop docked (lid closed or not), now nothing get displayed on screen either the laptop or the external monitor one
[21:12] <seb128> booting undocked and docking the laptop once it's on lightdm works fine
[21:12] <seb128> during the boot I see a purple background when I get the bug and the monitor stay on but no image (plymouth or lightdm) is displayed
[21:12] <seb128> switching to a vt doesn't update the screens either
[21:12] <infinity> ajmitch: The race on IDLE seems easily worked around.
[21:12] <seb128> but seems to work since the num lock change
[21:13] <infinity> ajmitch: But still good to know, should I ever be silly enough to try to do this. :P
[21:13] <seb128> slangasek, ^ do you know if that could have to do with plymouth?
[21:13] <stgraber> seb128: what laptop? works fine here on my x201s with a DVI monitor plugged in the docking
[21:13] <seb128> stgraber, dell e6410
[21:15] <slangasek> seb128: plymouth can't do anything to your video outputs without the kernel's consent... is this with kms?
[21:15] <slangasek> binary/free drivers, what video, etc?
[21:15] <seb128> slangasek, intel i5 card
[21:16] <seb128> the one integrated to the i5 cpu I mean
[21:16] <seb128> I've tried to boot the previous kernel without success
[21:35] <allee> vpnc stopped working in oneiric.  Work before without problems since karmic.  oneiric broken: http://paste.ubuntu.com/698128/   natty working: http://paste.ubuntu.com/698129
[21:35] <allee> slangasek: ScottK suggested to ask you ^^
[21:35]  * ScottK thought to blame multi-arch
[21:36] <slangasek> man
[21:36] <slangasek> no love
[21:37] <slangasek> nothing in that log suggests a multiarch problem to me
[21:37] <slangasek> doesn't mean it isn't, of course
[21:38] <Laney> one love
[21:38] <seb128> slangasek, sorry to ping you on that but any suggestion on what I could try reverting for that boot bug out of plymouth and the kernel?
[21:40] <slangasek> seb128: plymouth has had no code changes at all this cycle... if plymouth itself isn't rendering, I guess you should try an earlier kernel
[21:40] <seb128> did that
[21:40] <seb128> did grub changed what it does with video modes?
[21:40] <slangasek> seb128: hmm.  grub has also changed recently, to properly hand off video to the kernel where it *wasn't* doing so before
[21:41] <slangasek> seb128: so you could try forcing gfxpayload=text (instead of gfxpayload=$linux_gfx_mode, which tries to autodetect)
[21:41] <slangasek> seb128: (in your grub boot option)
[21:41] <seb128> slangasek, thanks, will do that!
[21:42] <slangasek> seb128: if that fixes it, please file a bug on the kernel
[21:42] <seb128> slangasek, btw I wonder if my "plymouth hangs for 5 seconds" bug isn't the same issue that bug #854986
[21:42] <slangasek> seb128: is your netbook using eDP?
[21:42] <seb128> it's a laptop ... how do I know? ;-)
[21:43] <slangasek> seb128: is it a Sony?
[21:43] <seb128> slangasek, no, it's a dell latitude e6 serie as well
[21:43] <seb128> i.e same as the bug I pointed
[21:44] <slangasek> seb128: oh.  The last I heard, only Sony and Apple were doing eDP... I guess Dell is now too, hmm
[21:44] <slangasek> how new is this laptop?
[21:44] <seb128> 1 year
[21:44] <slangasek> hrm, ok
[21:44] <seb128> kern.log.1:Sep 21 10:00:49 localhost kernel: [    3.623298] [drm] failed to retrieve link info, disabling eDP
[21:44] <slangasek> ah right
[21:45] <slangasek> so it's lag caused by eDP being present but not used
[21:45] <slangasek> if you actually *had* eDP, you'd get things like bug #835128 instead ;)
[21:45] <seb128> ok, so it does seem a duplicate of the other bug
[21:45] <seb128> i.e https://bugs.freedesktop.org/show_bug.cgi?id=41057
[21:46] <seb128> it just happens earlier in the boot for me because of the crypted swap I guess
[21:46] <slangasek> yep, makes sense
[21:47] <slangasek> seb128: I wonder what vbeinfo from a grub prompt reports when you have the DVI plugged in
[21:47] <seb128> is that a command I can run from grub in some way?
[21:48] <slangasek> seb128: hold shift to get a menu, press 'c' to get a prompt, run 'vbeinfo'
[21:48] <seb128> ok
[21:48] <seb128> will try the gfxpayload=text when I reboot and get a vbeinfo log
[21:48] <slangasek> great :)
[21:48] <seb128> thanks for helping me to debug those issues ;-)
[21:48] <slangasek> sure thing
[21:49] <slangasek> (I figure if I help other people debug theirs... maybe apw will find a fix for mine ;D)
[21:51] <infinity> slangasek: Some misguised sense of karma, or does apw just like it when you're nice?
[21:52] <slangasek> infinity: apw has more time to work on my bug instead when I'm nice? :)
[21:52] <slangasek> (maybe?)
[21:52] <slangasek> anyway, I'm sure he knows I'm good for the beer
[21:52] <infinity> I'd argue that you're pretty bad for beer.
[21:53] <infinity> If it had legs and a mouth, the beer would run screaming from you.
[21:54]  * infinity lunches.
[21:54] <infinity> (unrelated the screaming beer)
[21:54] <infinity> s/the/to the/
[21:55] <slangasek> allee: please try running /usr/lib/NetworkManager/nm-vpnc-service from the commandline and paste the output
[23:03] <Zack> im having a wlan0 problem
[23:04] <micahg> slangasek: gnash uses the flashplugin-alternative
[23:04] <slangasek> micahg: this is a good thing, yes?
[23:04] <micahg> slangasek: yes, but I got the impression that wasn't considered in your last upload
[23:05] <cjwatson> sigh, grub/maverick-proposed verification-failed, now I get to debug that again
[23:05] <Zack> could some one help me fix my wlan0 problem, it wont connect and modprobe does nothing
[23:05] <slangasek> micahg: ah, the changelog comment, yes
[23:06] <slangasek> micahg: so there is some possibility that the user had both gnash and flashplugin-nonfree installed, and had manually changed the alternative target away from the default; in that case this upload clobbers that setting
[23:06] <charlie-tca> Zack: Usually better to ask in #ubuntu for support
[23:07] <Zack> i did and was sent here
[23:07] <micahg> slangasek: yep, just wanted to make sure that was considered :)
[23:07] <slangasek> micahg: however, I don't see any way out of the current broken state that doesn't have *some* casualties, because update-alternatives --set is not meant to ever be called by maintainer scripts and when it is, there's information loss
[23:07]  * slangasek considers patching u-a to bail if --set is called and DPKG_MAINTSCRIPT_PACKAGE is set
[23:07] <micahg> slangasek: I'm actually considering dropping the gnash priority back to 10 like Debian has since generally, if someone installs flash, they just want it to work
[23:08] <slangasek> what's the prio set to currently?
[23:09] <micahg> slangasek: 50, same as adobe flash
[23:09] <slangasek> right... I would think gnash should take a lower pro
[23:09] <slangasek> prio
[23:09] <micahg> slangasek: ok, I'm planning one more upload before release (there's a crash that should be fixed), so will make the change
[23:10] <slangasek> cool
[23:11] <allee> slangasek: /usr/sbin/vpnc: IKE DH Group "1" unsupported.   I've tried the 3 possibilies  1 "2 default" and 5  and  always the same -> unsupported.    I've compared with natty nm-plasmoid and this  combobox with these 3 settings is the only addition in the  UI
[23:11] <mdeslaur> slangasek: I'm curious, what's the information loss with --set?
[23:12] <slangasek> allee: ok... that definitely doesn't sound like it's related to multiarch then, I think you'll have to find someone who's actually familiar with vpnc instead
[23:12] <slangasek> mdeslaur: the information about whether it's a user-selected preference vs. an automatic system-populated default
[23:12] <mdeslaur> slangasek: ah, I see
[23:16] <allee> slangasek: okay.  Nevertheless thx for you helping hand so far.  I'll #nm ...  Night
[23:17] <infinity> siretart: That libav upload seems a bit heavyweight for two days before Final Freeze.
[23:19] <infinity> siretart: I'm going to reject it for now.  Is there a chance we can get an upload that just had the security fix?
[23:28] <cjwatson> smoser,smb: do you think it might be remotely feasible for bug 684875 to be fixed in maverick as well?  I'm pretty sure that this is the cause of the maverick verification failure in bug 720558
[23:36] <smoser> cjwatson, would you really think it acceptable to change someone's device names on a stable relase kernel upgrade?
[23:36] <cjwatson> smoser: well, it depends whether it can possibly be working for them at all right now, which I'm not clear on
[23:36] <cjwatson> if it can only work in EC2, and that deals with it, then ...
[23:37] <smoser> we don't need it in ec2 any more. and i'm happy we bit that bullet when we did.
[23:38] <cjwatson> installation of maverick using d-i was very badly broken, which seems like it should limit the set of people who were using the old names
[23:38] <smoser> but i'm just afraid of changing someone's device names after a reboot and having them hang.
[23:38] <cjwatson> I agree it's not a trivial change, that's why I asked :)
[23:38] <cjwatson> I don't see any other safe way to fix the installation problems, though
[23:38] <smoser> the likely point of failure i think is just in people having '/dev/sdb' in /etc/fstab
[23:39] <smoser> and no 'nobootwait' option.
[23:39] <cjwatson> how will people have got maverick on there?
[23:39] <smoser> ec2
[23:39] <cjwatson> doesn't that use labels?
[23:39] <smoser> for root
[23:39] <cjwatson> or uuids or something?
[23:40] <smoser> for root it does, but for other disks, those are most likely added by the user.
[23:40] <smoser> who never expected to have a drive named /dev/xvdX.
[23:41] <smoser> the other big pain on EC2 at least is that amazon exposes an interface that is ill designed.
[23:41] <cjwatson> well, they're screwed on upgrade from maverick to natty anyway
[23:41] <smoser> one where you can say "attach this at /dev/sdg" and the xen guest kernel obliges.  pepole are used to that.
[23:42] <smoser> yeah, i agree those people are foobarred :-(
[23:42] <cjwatson> but yeah, in that case we ought to be a bit more careful in the stable release
[23:42] <cjwatson> gar
[23:44] <cjwatson> hmm, maverick xen-blkfront /dev/sd* devices have a different major number, according to that bug
[23:44] <cjwatson> maybe I can abuse that
[23:45] <cjwatson> since all I think I actually need to do here is say "it's xen-blkfront, don't convert the grub drive to uuids"
[23:57] <cjwatson> smoser: OK, thanks for the discussion, I think I have a passable workaround in grub