[02:18] <Viper550> Okay, I'm trying to build something with GRUB2 based off a mockup I made, but grub-mkfont spat back at me a whole bunch of gsub errors, and a completely broken font when I get to the grub screen
[02:24] <infinity> Viper550: You know, the further from 1999 we get, the more obscure your nick gets.
[02:25] <Viper550> lol
[02:28] <Viper550> infinity, yeah. I'm trying to construct this. http://i.imgur.com/TgxQv.png
[02:28] <Viper550> however, grub-mkfont is not cooperating
[02:29] <infinity> Beer calls.  But I wish you luck.
[04:08] <pitti> Good morning
[04:10] <pitti> bdrung, doko: you mean the xzgv FTBFS? looks like a missing -lm?
[04:10] <pitti> bdrung: looks like eclipse was uploaded and accepted, anything else that needs to be done there?
[04:31] <soreau> How can I tell what configure options were used when building a certain package?
[04:47] <sladen> soreau: apt-get source name-of-package
[04:49] <pitti> @pilot in
[04:54] <soreau> sladen: Sorry, it was my understanding that only downloads the source of the package, including ubuntu patches
[04:54] <pitti> doko: ah, was this the gdk-pixbuf one? seems seb128 reverted the libs.private thing there
[04:57] <slangasek> soreau: the "source of the package" includes all scripts used to control compilation and installation of the package contents
[04:58] <soreau> slangasek: Ah ok.. I did not know that
[04:58] <soreau> slangasek: Specifically, where would I find the configure line though?
[04:59] <slangasek> soreau: if you want to know the precise configure line used, it's easiest to check the build log
[04:59] <soreau> slangasek: Which is also included I'm assuming
[04:59] <slangasek> otherwise, it's somewhere in debian/rules and friends
[05:03] <soreau> slangasek: The build log isn't jumping out at me from what I can see
[05:04] <soreau> Where can I find it?
[05:04] <slangasek> soreau: under the package page on launchpad
[05:04] <soreau> :P
[05:04] <slangasek> (it's not part of the source, that would be a bootstrapping paradox)
[05:05] <slangasek> https://launchpad.net/ubuntu/+source/$pkg, -> click on the version, click on the architecture name, click on the build log
[05:06] <soreau> ah ha
[05:06] <soreau> slangasek: thanks
[05:07] <soreau> found the configure shebang and what I needed to know
[05:46] <didrocks> good morning
[05:52] <ScottK> didrocks: Good morning.
[05:52] <didrocks> hey ScottK
[05:52] <ScottK> didrocks: Qt did finish on armel, so your way is clear to upload it again.
[05:52]  * ScottK is off to bed.
[05:52] <didrocks> ScottK: ok, just waiting some minutes to have some feedback from agateau and then pushing both patches. Thanks for the notice!
[05:52] <didrocks> ScottK: have a good night
[05:52] <ScottK> Thanks.
[06:22] <pitti> sladen: did you see https://launchpadlibrarian.net/81266457/buildlog_ubuntu-oneiric-i386.ubuntu-mono_0.0.35_FAILEDTOBUILD.txt.gz ?
[06:56] <siretart> infinity: that's a bit sad, because there are a number of IMO quite important issue fixed by this upload. I think I could do a new upload with something like less than 6 patches
[06:59] <infinity> siretart: Even the crazy 63 upstream cherrypicks, I can deal with, I'm not sure that multi-arching a library without SERIOUS revdep testing when we're this cose to release is safe, though.
[07:02] <dholbach> good morning
[07:03] <infinity> siretart: Any chance for an upload with all the upstream fixes, but none of the multiarch scary?  vorlon, doko, and I were all on the same page there.  It's just too late to test if it'll break.
[07:05] <poolie> hi dholbach
[07:05] <dholbach> hey poolie
[07:05] <poolie> doko, congratulations, you are officially affected by more bugs than anyone else in lp
[07:05] <poolie> (per bug 858618)
[07:06] <infinity> Maybe he's just drawn to green text?
[07:06] <poolie> or bugs
[07:06] <infinity> Well, reporters are automagically "affected", right?
[07:07] <infinity> So, mass FTBFS filings would do it. :P
[07:07] <poolie> maybe not for api filing
[07:11] <siretart> infinity: oh, sure, I'll just revert the multiarch commit then
[07:11] <infinity> siretart: That would be lovely.  Make sure it wasn't several commits (ie: don't let it linger half-baked) :)
[07:12] <siretart> no, it was implemented in single commit by ceros
[07:12] <infinity> Shiny.
[07:12] <dholbach> hey infinity
[07:13] <infinity> Then give us a non-ma version of the last upload, I'll cringe at the 63 cherrypicks, and let it through.
[07:13] <dholbach> hey siretart
[07:13] <dholbach> how are you all doing?
[07:13] <infinity> Hey Daniel.
[07:13] <infinity> Sleepy.  You? :)
[07:13] <dholbach> sleepy too :-P
[07:13] <dholbach> I hope the coffee is going to fix it :)
[07:14] <infinity> I've heard claims that it does.
[07:15] <siretart> dholbach: hey! thanks, I've just returned home on monday from my trip to california (where, among others, I've met infinity at LPC) :-)
[07:15] <dholbach> nice :)
[07:16] <infinity> Turns out that siretart's still German.
[07:16] <infinity> He should really fix that.
[07:16] <siretart> do we already know the name for the ubuntu p-series?
[07:16] <siretart> infinity: working on it, but probably requires a job for me in the us
[07:17] <infinity> siretart: Prepubescent Pterodactyl.
[07:17] <infinity> siretart: Just to make sure no one can spell it.
[07:17] <siretart> perfect
[07:32] <soreau> infinity: Is that a joke or the real name?
[07:33] <infinity> soreau: A joke. :P
[07:33] <soreau> infinity: That's a pretty good one in any event
[07:33] <soreau> how long did it take you to come up with that? :)
[07:34] <infinity> soreau: A few seconds?
[07:36] <soreau> infinity: Twas rhetorical but touché
[07:49] <doko> poolie, filed by a script, but the fixes are unfortunately non-scriptable ;-P
[07:51] <infinity> doko: I wouldn't call that unfortunate.  We'd all be out of jobs if we could script things like that. :P
[07:51] <micahg> infinity: we could do bug fixes instead of build fixes :)
[07:52] <infinity> micahg: If we can script one, we can script the other. :)
[07:53] <micahg> infinity: build fixes especially DSO ones seem scriptable in theory
[08:02] <doko> pitti: new glibmm needed :-/
[08:02] <pitti> doko: new in what regard?
[08:03] <pitti> it built fine everywhere?
[08:03] <pitti> and matching gtkmm3.0 uploaded as well
[08:03] <doko> pitti, it's stalled everywhere
[08:03] <pitti> "stalled"?
[08:03] <doko> according to http://qa.ubuntuwire.org/ftbfs/
[08:04] <pitti> I don't see glibmm there
[08:04] <pitti> what do you mean by "stalled"?
[08:04] <doko> dep-wait
[08:05]  * pitti is still confused what you mean -- https://launchpad.net/ubuntu/+source/glibmm2.4/2.30.0-0ubuntu1 looks just fine
[08:05] <jamespage> morning all
[08:05] <pitti> doko: oh, do you mean the orange gtkmm3.0 there?
[08:05] <doko> yes
[08:05] <pitti> doko: it's building on armel, and built on all others
[08:06] <doko> pitti: re 749159, you're fighting a bot. have fun
[08:06] <pitti> heh
[08:06] <seb128> slangasek, hey
[08:07] <seb128> slangasek, ok, so booting with gfx...=text "fixes" my monitors being screwed when booting docked
[08:08] <pitti> doko: FYI, retrying ubiquity; looks like the g-i fix that I uploaded a few days ago
[08:29] <doko> seb128, pitti: please care about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640450, seen in oneiric too
[08:30] <pitti> ah, ubiquity builds now
[08:39]  * pitti throws gobject-introspection FTBFS fix queue-wards
[08:42] <bdrung> pitti: no
[08:44] <pitti> ogra, asac: should linux-linaro-vexpress get seeded somewhere? (see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt)
[08:44] <pitti> kirkland, Daviey: also from component-mismatches, powernap wants to go to universe again; I thought this was meant to be in main/default server instasll?
[08:45] <Daviey> hmm, i thought i fixed that
[08:46] <infinity> pitti: It should be pulled in by d-i, I believe, once Colin re-enables that target.
[08:46] <infinity> pitti: I think.
[08:49] <Daviey> pitti: should now be fixed
[08:49] <pitti> Daviey: cheers
[08:53] <infinity> pitti: I pinged Colin about the d-i/vexpress thing, but I'm heading to bed soon.  Might want to follow up with him and make sure I'm not full of it.
[09:05] <cjwatson> pitti: yeah, I'm sorting that out now, please leave it in main or it'll make d-i FTBFS
[09:06] <pitti> cjwatson: oh, I didn't want to demote it; just asking how we want to keep it in main; thanks!
[09:17] <pitti> cjwatson: ah, seems we missed merging live-build from Debian again; do you mind if I upload a targetted one-line patch to fix bug 857494?
[09:17] <pitti> this is mainly to make ubuntu-defaults-image's --package option work with a local .deb
[09:17] <cjwatson> pitti: go ahead
[09:17] <cjwatson> the merge was big and complicated
[09:17] <pitti> (want to test it again, so still need an hour or so)
[09:17] <didrocks> pitti: if you want using the french package… :-)
[09:18] <pitti> yeah, a merge at this point would be way too intrusive now
[09:18] <seb128> cjwatson, hey
[09:18] <pitti> didrocks: I have a local -ch-zh here, for downsizing; I'll use that for testing
[09:18] <didrocks> pitti: I noticed that there is no way to add search engines as well (we did that for the french documentation). I think I'll work on that for P.
[09:18] <didrocks> great :)
[09:19] <pitti> didrocks: ah, I think we removed that because firefox doesn't allow us to
[09:19] <didrocks> not sure if I forgot on the list of things we did in the french respin
[09:19] <tjaalton> could a member of the release team ack/nack the ffe for sssd I filed, bug 860297
[09:19] <pitti> didrocks: I discussed that with Chris, and there was something which prevented us from adding them
[09:19] <didrocks> pitti: hum, we have an agreement with mozilla europe as the french loco team, so we will maybe retweak it (the head of mozilla europe is french, it helps)
[09:19] <pitti> ah
[09:20] <seb128> cjwatson, grub gfxpayload=... option is breaking my screen outputs when docked
[09:20] <seb128> cjwatson, it was when setting it to =text (slangasek suggestion from yesterday)
[09:20] <seb128> cjwatson, do you know what info would be useful in a bug and where to file it?
[09:21] <seb128> where ... is $linux_gfx_mode (or whatever is the default, not sure of the name now)
[09:21] <seb128> ups
[09:22] <seb128> "it works when setting it to =text"
[09:23] <cjwatson> seb128: not on grub, sounds like a kernel bug
[09:23] <seb128> ok
[09:24] <cjwatson> I mean, unless grub2 is leaving the registers in some kind of invalid state which is possible, but grub2 isn't the place to start analysing that I think
[09:26] <seb128> cjwatson, ok thanks
[09:27] <seb128> I will open a kernel bug
[09:35] <sladen> pitti: ta
[09:35] <apw> seb128, does your machine work ok on natty, and does it have seemless boot there ?
[09:35] <sladen> pitti: (hadn't seen it, was asleep)
[09:35] <seb128> apw, yes and yes
[09:35] <seb128> apw, it's a dell latitude e6410
[09:35] <apw> oh god not those heaps
[09:36] <seb128> apw, oneiric works when I boot undocked, if I boot docked I get the external monitor to turn purple (grub background like) and then never get anything else on screen
[09:36] <seb128> no plymouth, no lightdm, not vts
[09:36] <seb128> I can switch to vts, the num lock status change
[09:36] <seb128> so I think it boots and work, the screen just stay purple (and on)
[09:36] <seb128> same on the laptop and external screens
[09:36] <apw> so the machine boots then ... well thats something.  means we can get register dumps off it ... sigh
[09:36] <seb128> if I boot undocked, wait for lightdm to show up and dock the laptop it works fine
[09:37] <seb128> if I boot docked with gfxpayload=text it works fine
[09:37] <apw> where does grub show up when its docked, the same place ?
[09:37] <seb128> seems so
[09:37] <apw> what sort of graphics does it have ?
[09:37] <seb128> well I usually boot docked with lid closed, i.e only external monitor
[09:38] <seb128> apw, the i5 integrated card
[09:38] <seb128> i.e intel
[09:38] <apw> so sounds like unpicking bios setup is still broken, *cries*
[09:38]  * apw HATES BIOS
[09:39] <seb128> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/857434 might have some details about my config
[09:39] <seb128> apw, it's a bug I opened recently on plymouth, which seems to be a duplicate of bug #854986
[09:39] <apw> seb128, that title is missing a 'what'
[09:40] <seb128> apw, oh, I use ecryptfs which means plymouth is loaded in the initramfs
[09:40] <seb128> apw, "what" was the component I opened the bug against, i.e plymouth
[09:40] <seb128> apw, i.e see the plymouth bar on https://launchpadlibrarian.net/80738739/oneiric-20110923-1.png
[09:41] <seb128> apw, but I think it's the same as the other bug, edp probbing being slow, it just happens in the initramfs there due to ecryptfs use
[09:41] <apw> its curtainly stupid that cryptsetup ends up doing things even when you don't have root encrypted, but hey
[09:41] <seb128> yeah, it's another bug...
[09:41] <apw> 5s added to the boot won't show up against the myriad of other delays
[09:42] <seb128> apw, heh, that chart shows that unity is loaded at 10s, it means it double the boot time to greeter for me ;-)
[09:43] <seb128> ups, unity->unity-greeter (lightdm)
[09:43] <sladen> pitti: weird.  It's building here without 'rsvg' installed;  imagemagick must have some other way of doing .svg rasterisation
[09:43] <apw> but its ok, you get a nice 20s to look at a blank desktop after that, so its just getting you used to it
[09:43] <seb128> lol
[09:44]  * apw notes that the "google" command line tool just stopped working for natty ... seems its using the wrong URLs
[09:44] <seb128> apw, still, what info would be useful in a bug about the "booting docked with gfxpayload=$linux_gfx_mode screws screen outputs"
[09:44] <seb128> ?
[09:45] <apw> if you filed it against linux,t hen i'd expect we have whats needed in basic.  if its intel i am going to ask you for an intel_reg_dump from a good boot and a bad boot, which means you'll need to get ssh working i suspect
[09:45] <MacSlow> RAOF, ping
[09:45] <seb128> apw, ok
[09:54] <RAOF> MacSlow: Pong.
[09:55] <MacSlow> RAOF, hey there... what's the source-package of libgl1-mesa-dri? Just "mesa3d"?
[09:55] <RAOF> MacSlow: mesa
[09:55] <MacSlow> ah ok thanks
[09:56] <RAOF> (apt-cache show libgl1-mesa-dri will show "Source: mesa" for future reference)
[09:58] <MacSlow> RAOF, I'm not sure I'll remember this a week from now :)
[09:58] <RAOF> :P
[09:58] <MacSlow> RAOF, and grepping through my megs of xchatlogs-data isn't usually my typical way to search for info ;)
[09:59] <RAOF> Just remember "apt-cache show".  It's the font of all knowledge!
[10:12] <Laney> http://www.guardian.co.uk/travel/2011/sep/28/orlando-florida-cultural-top-10 :-)
[10:22] <pitti> didrocks: live-build fix uploaded
[10:22] <didrocks> pitti: thanks! :)
[10:44] <pitti> micahg: eww @ autom4te.cache/ in the blueman upload
[10:44] <pitti> micahg: (not a blocker, but would be nice to clean up in the next upload)
[12:00] <micahg> pitti: sorry, where was that
[12:01] <pitti> micahg: blueman
[12:01] <micahg> pitti: right, but I don't see it anywhere
[12:09] <pitti> micahg: hm, it was in the diff
[12:10] <micahg> pitti: ah, I didn't look that hard at the 1.21 -> 1.22 part of the diff
[12:11] <micahg> pitti: it's really weird, I don't have that in my local copy of the blueman source...
[12:11] <micahg> pitti: I'll look at the diff a little later, nap time now :)
[12:12] <pitti> micahg: perhaps debian/rules clean calls autoreconf or so (dh_autoreconf DTRT)
[12:12] <pitti> micahg: but not a biggie, sleep well!
[12:12] <micahg> pitti: thanks
[12:38] <alfmatos> hi
[12:38] <alfmatos> oneiric beta 2 is not downladable, atm...
[12:38] <alfmatos> HTTP 403
[12:38] <alfmatos> http://releases.ubuntu.com/oneiric/ubuntu-11.10-beta2-desktop-amd64.iso
[12:38] <pitti> hm, works here
[12:38] <alfmatos> really?
[12:39] <alfmatos> :/
[12:39] <sagaci> works here
[12:39] <sagaci> via wget :)
[12:40] <ion> alfmatos: Try without a proxy.
[12:40] <alfmatos> no proxy here
[12:40] <alfmatos> (or transparent)
[12:41] <alfmatos> so it works for everyone
[12:41] <alfmatos> uhmm
[12:41] <alfmatos> weird
[12:42] <alfmatos> i'm in europe, what ip do you guys get?
[12:43] <alfmatos> host releases.ubuntu.com releases.ubuntu.com has address 91.189.92.160
[12:43] <alfmatos> the same?
[12:45] <ogra_> thats a round robin DNS entry i think, will return varying IP adresses
[12:45] <pitti> 91.189.92.157 here, but what ogra said
[12:45] <pitti> alfmatos: do you use a proxy?
[12:46] <ogra_> or a provider that secretly puts one in the loop :)
[12:49] <alfmatos> pitti: don't think so
[12:49] <alfmatos> pitti: not explicit
[12:51] <Amaranth> I don't think that one is round-robin DNS actually
[12:53] <alfmatos> uhmm, i can't seem to wget directly from the ip
[12:53] <alfmatos> 91.189.92.157/11.10/ubuntu-11.10-beta2-desktop-amd64.iso
[12:53] <alfmatos> i get redirected
[12:54] <alfmatos> but the weird thing is that i can download the .torrent or zsync
[12:55] <ogra_> Amaranth, well, in any case it returns different IPs for different requests
[12:55] <ogra_> i get a 403 here with wget ... now thats weird
[12:55] <Amaranth> ogra_: I guess something is caching it for me, I always get the same thing
[12:55] <ogra_> i get .157 pitti does
[12:56] <alfmatos> so, it is 403
[12:56] <ogra_> though the 403 is bothering
[12:56] <alfmatos> uhmm
[12:56] <pitti> ogra_: #is then?
[12:56] <ogra_> yes
[12:56] <alfmatos> is that just something someone can chmod ?
[12:56] <pitti> no idea
[12:59] <ogra_> alfmatos, seems to be a issue with the machine that resolves to .160
[12:59] <ogra_> retrying it several times here, if i get a different IP it seems to work
[13:04] <alfmatos> ogra_: so possibly someone should fix that
[13:04] <alfmatos> i'll try to flush my dns cache
[13:04] <alfmatos> and retry
[13:04] <alfmatos> got it now
[13:04] <alfmatos> 157
[13:04] <ogra_> the datacenter troops are on it
[13:04] <alfmatos> downloading
[13:04] <alfmatos> 160, sucked again =)
[13:04] <alfmatos> cool, hope i helped. :)
[13:05] <ogra_> they will fix it :)
[13:05] <ogra_> thanks for reporting !
[13:19] <pitti> tseliot: hey Alberto!
[13:19] <pitti> tseliot: any chance I could debug bug 855396 on your machine with ssh?
[13:19] <tseliot> pitti: hi Marin
[13:20] <tseliot> pitti: I don't have a static ip
[13:20] <pitti> tseliot: just tell me the current one :) usually you just need to enable port forwarding in the router
[13:21] <pitti> tseliot: but you could also do ssh port forwarding to e. g. chinstrap
[13:21] <pitti> seems easier
[13:21] <tseliot> pitti: I think I did ssh port forwarding to chinstrap, let me check
[13:22] <pitti> tseliot: ssh -R 2222:localhost:22 chinstrap...
[13:53] <stgraber> slangasek: ping
[14:07] <stgraber> mvo_: ping
[14:09] <stgraber> mvo_: just talked with wendar about getting a staging PPA for the ARB. Could you create one? (you're the owner and administrator of the ARB team on LP)
[14:12] <mvo_> stgraber: done https://launchpad.net/~app-review-board/+archive/staging
[14:12] <stgraber> mvo_: thanks
[14:13] <mvo_> stgraber: y
[14:13] <mvo_> yw
[14:13] <wendar> mvo_: thanks!
[14:14] <tjaalton> stgraber: hey, do you remember why the libpam-sss pam-config priority was bumped? upstream says pam_sss.so should always be after pam_unix.so, and the change "broke" pam_ecryptfs.so in that you had to enter the password twice
[14:18] <stgraber> tjaalton: "- Bump pam-auth-update priority to 960 (512 + 256 + 128 + 64)" if that's what you're referring to, that was done based on pam-auth-update's documentation
[14:19] <stgraber> tjaalton: 512 = central network service, 256 = local authentication (through the cache), 128 = crypto, 64 = delegation of credentials for SSO
[14:21] <tjaalton> stgraber: ok, where's that documentation?-)
[14:21] <ion> 512 + 256 + 128 + 64? I didn’t know it was a bit field. I thought it was just a value for linear ordering.
[14:22] <smoser> cjwatson, you have a minute?
[14:22] <cjwatson> smoser: ye
[14:22] <cjwatson> s
[14:22] <smoser> i add http://paste.ubuntu.com/698522/
[14:22] <smoser> to /etc/default/grub.conf
[14:22] <smoser> and then 'update-grub'
[14:22] <tjaalton> stgraber: ok it's on the spec
[14:22] <smoser> but i still dont see a prompt
[14:23] <cjwatson> show me the resulting grub.cfg please
[14:23] <cjwatson> and do you mean you don't see a menu?
[14:23] <smoser> http://paste.ubuntu.com/698526/
[14:23] <cjwatson> also I hope you mean /etc/default/grub
[14:23] <smoser> i want to see the grub dialog/timeout.
[14:23] <smoser> yes, i meant /etc/default/grub
[14:23] <smoser> soryr.
[14:23] <smoser> wait
[14:23] <smoser> sorry
[14:24] <cjwatson> you probably need GRUB_HIDDEN_TIMEOUT_QUIET=false too
[14:24] <cjwatson> oh, you have that, confusingly written
[14:24] <smoser> http://paste.ubuntu.com/698528/ is the /etc/default/grub
[14:24] <cjwatson> could I have grub.cfg please?  you've pasted /etc/default/grub twice :)
[14:25] <smoser> sorry.
[14:25] <smoser> http://paste.ubuntu.com/698531/
[14:26] <ScottK> barry: Would you be able to look at https://launchpadlibrarian.net/81310249/buildlog_ubuntu-oneiric-i386.unbound_1.4.13-0ubuntu1%7Eppa1_FAILEDTOBUILD.txt.gz
[14:26] <smoser> its possible that the gfx mode is screwing up, and/or just switching too quickly.
[14:28] <barry> ScottK: i'll try.  i'll keep the browser window open
[14:29] <ScottK> Thanks.
[14:30] <cjwatson> smoser: sorry, I'm not entirely sure right now.  You could try GRUB_TIMEOUT=-1 as a workaround which I think will probably force it.
[14:42] <slangasek> stgraber: pong
[14:42] <Tanguy> Hello.
[14:42] <Tanguy> I am the maintainer of the Debian packages itstool and latexila.
[14:43] <Tanguy> Both of which have been diverging from Debian for release needs.
[14:43] <Tanguy> Now that the last versions are in Debian testing, they may be integrated back, if it is relevant.
[14:43] <stgraber> slangasek: that was about bug 854967 and whether blacklisting nvidia in gfxpayload would be a problem for flickerless boot. Though you already answered that flickerless isn't working with binary drivers at the moment anyway.
[14:44] <Riddell> barry: ping
[14:44] <slangasek> stgraber: right - true flickerless boot requires an in-kernel handoff without modeswitching, and we don't get that with binary drivers
[14:44] <barry> Riddell: pong
[14:45] <stgraber> tseliot: ping (bug 854967). Anything against blacklisting all the nvidia chips in gfxpayload? that'd need an upload of each of the nvidia binary drivers.
[14:45] <Riddell> barry: for UDD I'm thinking there should be a get-tar command.  my use case is  bzr co ubuntu:foo; make a change; bzr get-tar; debuild.  is that a common workflow?
[14:46] <cjwatson> Tanguy: we're almost at our final freeze for 11.10; can it wait for the next release cycle?
[14:46] <barry> Riddell: it's not typically how i work.  usually after the checkout, `bzr bd -S` does the trick for me
[14:46] <Tanguy> cjwatson: I guess it can, I was just mentionning the possibility in case it wuold have been useful.
[14:47] <Tanguy> Personally I do not care.
[14:48] <tseliot> stgraber: no objection at all, and I have to re-upload them all because of another change anyway
[14:48] <Riddell> barry: well that just gives you a source build, I'm wanting to see if I get a successful build and make changes based on that
[14:48] <Tanguy> Riddell, barry, I have just arrived in the middle of your description, but are you talking of storing an upstream tarball in a package's version repository?
[14:48] <Riddell> Tanguy: no, I'm talking about the full ubuntu package branches
[14:48] <tseliot> stgraber: therefore I'll take care of it this week
[14:49] <barry> Riddell: right, i always switch to sbuild or pbuilder to get the binary built.
[14:49] <stgraber> tseliot: thanks
[14:49] <tseliot> yw
[14:50] <Riddell> barry: mm, I don't so I guess our workflows differ
[14:50] <barry> Riddell: yep.  i gravitate toward sbuild because it gives me all the control of the build environ i need, and a good environ for debugging build problems
[14:53] <seb128> slangasek, apw: I opened bug #861477 about my no screen when docked issue
[14:56] <apw> seb128, asked you for the intel_reg_dumps in the bug
[14:59] <seb128> apw, ok, getting that
[15:24] <pitti> @pilot out
[15:30]  * dholbach hugs pitti
[15:50] <smoser> mvo, does do-release-upgrade address entries in /etc/fstab at all ? for devices that will have changed names ?
[15:51] <smoser> ie, when we upgrade from 10.10 to 11.04 in EC2, the kernel will start changing the name from 'sda' to 'xvda'.  if there are entries like /dev/sdb in /etc/fstab (espeically without 'nobootwait') a reboot is going to result in a unavailable system.
[15:52] <mvo> smoser: it does that in the quirks handler if we tell it to, we did that in the past. but I don't think we do anything currently (natty->oneiric)
[15:52] <cjwatson> this is for maverick->later
[15:52] <mvo> smoser: that sounds like something we ought to fix in a quirks handler
[15:52] <mvo> smoser: I don't think we did this one
[15:52] <cjwatson> note that lucid used xvd*
[15:53] <smoser> cjwatson, lucid-ec2 used sda
[15:53] <cjwatson> fair enough, plain lucid in Xen didn't though
[15:53]  * smoser apologizes for all the crap that he/ec2 has brought upon ubuntu 
[16:06] <wookey> mvo: does anything guarantee the sources at http://ports.ubuntu.com/ and http://archive.ubuntu.com/ubuntu to be the same?
[16:06] <wookey> or does one have to carefully use the sources from the correct repo to be sure of not getting strageness?
[16:07] <ogra_> wookey, there might be minimal mirroring delays, bit thats about it
[16:07] <ogra_> *but
[16:07] <wookey> and another question: apt-get source gets the source for the highest-priority/newest binary in the cache
[16:07] <wookey> it does _not_ get the highest-priority/newest source package in the cache
[16:08] <wookey> I assume that's how it's intended to work?
[16:08] <wookey> so is there a way to tell it to get the newest source avaialble?
[16:08] <wookey> (this behaviour confused me immensely for hours last night...)
[16:09] <seb128> apw, ok, I updated the bug and the description, it seems to be happening only when booting with the lid closed, I'm pretty sure it was buggy lid open and docked as well before but maybe an update fixed it
[16:09] <seb128> apw, I got the intel_reg_dump logs for broken and working boots, I can't try without the station since the laptop has no dvi-d output, I can try with a vga cable later
[16:10] <apw> seb128, sound good ta
[16:10] <seb128> apw, thank you for looking at it ;-)
[16:16] <smoser> mvo bug 861535
[16:23] <mvo> thanks smoser - is this P or do we need it for oneiric too?
[16:23] <mvo> smoser: nevermind, I just see that we should actually SRU it
[16:23] <smoser> mvo, for this case, it would actually only affect 10.04 -> 12.04 or 10.10 -> 11.04
[16:23] <smoser> yeah.
[16:24] <mvo> ok
[16:24] <mvo> should be simple to do
[16:26] <wookey> mvo: did you see query re apt-get source behaviour above?
[16:27] <mvo> wookey: yeah, I need to look at the source, but IIRC it should select the higest one. you can pass a version number too. do you see different behavior?
[16:29] <wookey> yes. I have a pastebin with some detail in...
[16:31] <wookey> http://pastebin.ubuntu.com/698582/
[16:31] <wookey> the version that apt-cache policy shows is the one that is downloaded, but that only the newest binary available, not the newest source available
[16:32] <wookey> if I change the config so that the PPA binary arch (amd64) is listed in apt sources, instead of armel (which currently isn;t built) then is find the newer source package
[16:33] <wookey> s/is find/it finds/
[16:34] <wookey> I could use the showsrc to find the version number and then pass that as a workaround.
[16:34] <wookey> but I really wanted preferences to do this for me (because sometimes the PPA version won't be newest)
[16:35] <mvo> wookey: thanks, I check it after dinner, but I'm unfortunately a bit overloaded with $stuff at this point
[16:35] <wookey> yeah sure - me too :-)
[16:35] <wookey> shoudl I file a proper bugrep with that info in it?
[16:35] <wookey> Now I've understood what's going on it no longer urgent
[16:37] <wookey> I also found that pinning doesn't work unless the archive key has been installed, which seems a bit odd.
[16:41] <Daviey> jhunt: Hello sir, how is udev looking?
[17:54] <hallyn> pitti: seb128: Just did an apt-get dist-upgrade on two oneiric laptops, and again, I now see
[17:54] <hallyn> gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
[17:54] <hallyn> 'suspend'
[17:54] <hallyn> those were 'nothing' before the upgrade
[17:56] <hallyn> then I set it back to 'nothing', logged out and back in, it's still 'nothing'
[17:56] <hallyn> (and, again, my capslock-as-control preference got lost during the upgrade which is why i thought to check)
[17:57] <ogra_> hallyn, if you touch a keys, it gets stored in your home and wouldnt get touched by an upgrade of the system key
[17:57] <ogra_> at least thats how gconf operated, i suspect the same is true for dconf
[17:58] <ogra_> you need to wipe the key from your personal config to make it use the system default again
[17:59] <ogra_> (i think there is a  reset key option in dconf-editor)
[17:59] <hallyn> ogra_: what does 'touch a keys' mean?
[17:59] <ogra_> you changed a value
[17:59] <hallyn> ogra_: yesterday i opened the power settings manager, and set the values to 'do nothing'
[17:59] <hallyn> then i did apt-get dist-upgrade, and they got unset
[17:59] <ogra_> by i.e. selecting something in the control center
[17:59] <hallyn> and since suspend is broken, i'm afraid that could cost others beside me some data
[18:00] <ogra_> oh, that actually sounds like it wiped your personal setting
[18:00] <ogra_> i dont think thats supposed to happen ... unless the key name changed or some such
[18:00] <hallyn> i didn't pay enough attention to the packages being upgraded, whic his hwy i've not filed a bug yet.
[18:00] <hallyn> (was in a hurry, did '-y dist-upgrade)
[18:04] <ogra_> well, there was a change in gnome-power-manager for the "suspend after 30min regardless" issue
[18:04] <ogra_> and that actually touched the default settings
[18:20] <seb128> hallyn, ok
[18:26] <Daviey> Is removing ureadahead a viable workaround to bug #523484?  (/var being on a seperate parition)  The use case is a server enviroment, where i don't think the boot perf matters so much.
[21:34] <jbicha> sladen: the new ubuntu-mono breaks the user-desktop icon
[23:17] <robert_ancell> @pilot in