[01:12] <lamont> who is a good target for pestering about invoke-rc.d and the equivalent upstart stuff?
[01:16] <zul> SpamapS probably
[01:16] <broder> or slangasek, if you're asking about policy stuff around that
[01:26] <SpamapS> lamont: What did you want to whine^H^H^H^H^Htalk about regarding invoke-rc.d?
[01:27] <lamont> SpamapS: puppet uses it to tell what runstate we're in, and well, when puppet starts during system start up, it goes 'zomg dunno', and the dryrun output looks fugly.
[01:28] <lamont> I'd like something cleaner than: @reboot root echo service puppet restart | at now+2min
[01:33] <SpamapS> lamont: is puppet starting as a sysv init or an upstart job?
[01:34] <lamont> sysv
[01:34] <SpamapS> lamont: if it needs to run before anything else ever.. it needs to be converted to an upstart job most likely.
[01:35] <SpamapS> lamont: the alternative is starting it manually in an upstart task at the appropriate time
[01:35] <SpamapS> lamont: I would think puppet should run very late in the boot tho
[01:35] <SpamapS> like, almost last
[01:35] <lamont> well, actually, i think the real right answer is not to have puppet cache the startup answer FOREVER
[01:35] <lamont> since, you know, init level could change
[01:36] <SpamapS> so it checks the output of the 'runlevel' command ?
[01:36] <SpamapS> I'm not really sure I understand the problem actually.. :-P
[01:38] <lamont> invoke-rc.d --query
[01:38] <lamont> and doesn't like 105, which it then caches forever
[01:38] <lamont> which I believe to be a bug.
[01:38] <lamont> so nm... off to file a bug against puppet
[01:40] <SpamapS> Yeah.. I see now.. 105 is "don't ask me, I just work here"
[01:41] <SpamapS> They should probably check for an upstart job if 105 is returned.
[01:44] <lamont> SpamapS: and more to the point "we're in startup, so I really don't know"
[01:45] <lamont> the job in question isn't an upstart job
[01:45] <SpamapS> right yeah that sounds like a bug in the way they're handling the uncertainty
[01:46] <lamont> mind you, ISTR that adding support for upstart was on the roadmap for puppet/oneiric
[01:46] <lamont> which will be nice
[01:46] <lamont> as long as upstart doesn't make changes to make that possible
[01:47] <SpamapS> There's talk of having a more definitive "disable" capability added
[03:26] <ScottK> Is that the burn with fire option?
[05:18] <pitti> Good morning
[05:21] <LaserJock> morning pitti
[05:23] <ScottK> Whoah.  It's LaserJock.
[05:23] <ScottK> Hello LaserJock
[05:26] <pitti> hey LaserJock, how are you?
[05:27] <LaserJock> I'm doing OK
[05:27] <ajmitch> morning pitti
[05:27] <LaserJock> a bit jobless atm (hence being on IRC) but otherwise OK :-)
[05:28]  * StevenK rubs eyes, looks again
[05:30] <LaserJock> I know, I know, it's been a while
[05:30] <ajmitch> no excuses
[05:30] <StevenK> Haha
[05:30] <LaserJock> I got a PhD, move to Boston, taught a couple classes at my alma mater, and am now ... here
[05:44] <hmchinh1986> http://paste.ubuntu.com/612150/ ->ireally need this ! please, help me
[05:57] <broder> !support | hmchinh1986
[06:00] <hmchinh1986> ok
[06:54] <jerry_l> hello room i have to go to bed. sorry...
[07:47] <StevenK> pitti: Can you think of a library package off-hand that is in main but has some binary packages in universe?
[07:53] <diwic> StevenK, IIRC for jackd the library is in main but the daemon in universe
[07:53] <StevenK> diwic: I thought of a victim package already, but thanks
[07:54] <didrocks> good morning
[07:54] <diwic> good morning didrocks
[07:54] <didrocks> hey diwic
[08:00] <dholbach> good morning
[08:02] <didrocks> hey dholbach
[08:02] <dholbach> hi didrocks
[08:09] <didrocks> the new dbus depends on netbase (>= 4.45ubuntu3), but the one uploaded yesterday was 4.45ubuntu2 ?
[08:22] <smb> @pilot on
[08:22] <udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[08:22] <smb> @pilot in
[08:31] <pitti> StevenK: libnotify as well, if you want something tiny; libnotify-bin is in universe
[09:51] <pitti> SpamapS: FYI, fixing dbus netbase dependency to a version that actually exists, to make dbus installable again
[10:39] <Laney> is it known that cdbs is uninstallable on ppc?
[10:39] <cdbs> Laney: Half the archive is not installable on ppc :( Are you talking about Natty or Oneiric?
[10:39] <Laney> oneiric
[10:40] <Laney> cdbs is hardly 'half the archive' though — it's a relatively high-up package
[10:41] <cjwatson> it's probably the dbus breakage, which powerpc is an archive cycle behind on
[10:41] <Laney>  cdbs : Depends: dh-translations but it is not going to be installed
[10:42] <cdbs> no idea, I'm not a big archive evaluator, especially not on [ shadeslayer] [ vrodic    ]
[10:42] <cdbs> oops
[10:42] <Laney> again I wish for BD-uninst in launchpad ;-)
[10:42] <cdbs> blame the new gnome-control-center for pasting things randomly
[10:42] <pitti> Laney: yeah, this really should be considered as depwait
[10:43] <infinity> Y'know, I had half-finished an uninst->dep-wait parser years ago...
[10:43] <Laney> pitti: I filed bug 5277245 for that some time ago
[10:43] <Laney> er
[10:43] <cjwatson> hmm, not dbus
[10:43] <Laney> bug 5272453
[10:43] <Laney> bug 527245
[10:43] <infinity> Someone should talk me into finishing it.
[10:43] <Laney> argh!
[10:43] <cjwatson> Package liblwp-protocol-https-perl is not available, but is referred to by another package.
[10:43] <pitti> hm, and everything FTBFSes on armel :/
[10:43] <pitti> I've seen a couple of ld segfaults
[10:43] <infinity> Laney: That build state shouldn't exist, the correct solution is to drill down for the right dep-wait.
[10:43] <cjwatson> I think I just NEWed that
[10:44] <pitti> including the dbus fix
[10:44] <cjwatson> yeah, it's accepted, next publisher cycle should fix it
[10:44] <Laney> it's more complicated than dep-wait
[10:44] <infinity> Laney: Not in this case.
[10:44] <cjwatson> this case should be dep-wait: liblwp-protocol-https-perl
[10:45] <cjwatson> sometimes discovering the correct dep-wait is AI-complete though
[10:45] <infinity> Laney: If you literall mean "failed installation", then yes, you can't always intelligently dep-wait on, say, broken postinsts.
[10:45] <infinity> Laney: But "apt can't even being to install" (which is the case here) is always a dep-wait.
[10:45] <infinity> Laney: Just not always an immediately obvious one.
[10:45] <shadeslayer> cdbs: lol
[10:45] <cjwatson> oh, hmm, liblwp-protocol-https-perl needs an emergency MIR
[10:46] <cjwatson> in fact that's a split-out, so I'll promote it
[10:46] <cdbs> shadeslayer: Sorry for the ping, its because the new GNOME3 stack doesn't play well with Unity and can behave really weirdly at times
[10:46] <Laney> can you dep-wait on multiple packages?
[10:47]  * cjwatson does the override-in-accepted-queue trick
[10:47] <Laney> You can call it the same thing if you'd like, but I suspect you'll end up implementing a rather similar solution to that which Debian did :-0
[10:47] <Laney> :-)
[10:48] <infinity> Laney: Debian's solution re-checks installability, and is fairly opaque to the end user.  But it's the same concept, yes.
[10:48] <Laney> it uses an external tool to determine the same information, indeed
[10:48] <cjwatson> what does it do, edos-debcheck?
[10:48] <infinity> Laney: (Debian does dep-wait checks before pushing to needs-build, our checks happen at a different time, so the solution is different regardless)
[10:48] <Laney> cjwatson: yeah
[10:48] <infinity> cjwatson: Aye.
[10:50] <shadeslayer> cdbs: yeah no problem ;)
[10:50] <infinity> Laney: Either way, I agree that the functionality's been missing for a while, it just failed Round Tuit tests, I guess.  And the only person who cared stopped working on lp-buildd for a year and a half...
[10:51] <infinity> Laney: (The only person who seemed to care about this feature, that is, not lp-buildd entirely)
[10:56] <tjaalton> huh, cron update broke my personal crontab
[10:57] <tjaalton> nah, not a package update, but something did corrupt it
[10:59] <persia> infinity, So, what is a good way to generate a solution.  Cookies?
[11:01] <infinity> persia: Peanut butter cookies!
[11:01] <persia> Oooh.  That makes it trickier.
[11:02] <infinity> You'll sort it out.  You're a clever man.
[11:18] <mdz> pitti, have you looked into this ffmpeg/libav issue on the t-b list?
[11:18] <mdz> (April)
[11:18] <pitti> mdz: we quickly discussed it in the TB meeting
[11:18] <mdz> pitti, is it safe to let the mails be archived, or do I need to pay attention to it?
[11:18] <pitti> mdz: the outcome was that we really need to hear both sides of the story, someone had an action item to follow up with siretart
[11:19] <mdz> ,
[11:19] <mdz> ok
[11:20] <pitti> sabdfl: do you happen to have the minutes from that meeting somewhere? we should add them to https://wiki.ubuntu.com/TechnicalBoard/TeamReports/11/May
[11:20] <sabdfl> pitti: i definitely edited it
[11:20] <sabdfl> did i forget to save it?
[11:20] <sabdfl> fml
[11:20] <pitti> sabdfl: used editmoin by any chance? then they might still be in ~/.moin_lastedit
[11:21]  * pitti was rescued more than once by that
[11:21] <sabdfl> no, just in-browser
[11:21] <pitti> chrisccoulson_: please add full automatic etherpad-like revision control to firefox input fields :)
[11:22] <chrisccoulson_> heh :)
[11:25] <arand> pitti: "Lazarus" does that partly ;)
[11:27] <apw> cjwatson, i am about to do the MIR for the linux-lts-backports-natty backport kernel.  we don't seem to have any written proceedures for this, and its a little  bit of an odd case as its not in universe currently, should i be uploading it to lucid -proposed in advance ?
[11:28] <cjwatson> meh, I don't think the backport kernel bits need MIRs
[11:28] <infinity> ^
[11:28] <cjwatson> technically yes it's a new source package in main, but we've already had source packages with the same purpose in main before
[11:29] <cjwatson> and basically the same set of code
[11:29] <infinity> As long as there's a sane rationale for it existing at all, we already trust upstream and downstream maintainers.
[11:29] <apw> cjwatson, ok so just go ahead and upload it to lucid -proposed and get with your to get it sorted out ?
[11:29] <cjwatson> well, not me, but yes
[11:29] <cjwatson> linux-lts-backport-maverick was just uploaded to lucid-proposed
[11:30] <cjwatson> and it clearly can't go to a development release first
[11:30] <apw> cjwatson, yeah thats the previous one, so i'll just get it uploaded :)
[11:30] <cjwatson> except in the sense that the same code is already in the real kernel in newer releases
[11:30] <apw> right its identicle in code terms, packaging is slightly neutered to produce less architectures otherwise identicle
[11:38] <persia> infinity, Just to confirm, do the numbers 616, 4640, 52 and 6716 seem likely to be useful?
[11:38] <infinity> persia: I'm not a cookie expert, but I suspect you might be barking up the wrong tree.
[11:40] <debfx> cjwatson: do you know why translatoid isn't auto-synced?
[11:44] <cjwatson> sync-blacklisted: translatoid # james_w: Older version in Debian causing issue for autosyncer, drop this entry later.
[11:44] <cjwatson> I can retry it
[11:45] <cjwatson> debfx: seems fine, synced now
[11:46] <debfx> thanks
[12:18] <doko> seb128, pitti: could you have a look at component-mismatches? tracker xmldiff lightdm
[12:22] <seb128> doko, do we care that early in the cycle?
[12:23] <doko> seb128: yes, I care about buildability
[12:23] <seb128> doko, ok so you are welcome to file mirs for those ;-)
[12:23] <seb128> rodrigo is working on dropping the tracker one
[12:23] <seb128> xmldiff needs investigation
[12:23] <doko> ScottK: muon tries to pull in libqzeitgeist
[12:23] <seb128> lightdm needs a mir if it didn't get one yet
[12:23] <doko> ok, thanks
[12:24] <ScottK> doko: I'll ask someone to look into that.
[12:25] <ScottK> I imagine you'll see a MIR shortly since adding that feature was entirely not accidental.
[12:28] <didrocks> seb128: there is one filed by robert
[12:28] <seb128> doko, ^ what is the issue with lightdm? there is a mir waiting for it
[12:28] <seb128> didrocks, thanks
[12:29] <doko> seb128: ahh, didn't update the page
[12:31] <seb128> ok
[12:37] <cjwatson> seb128: if we don't care early in the cycle, we end up panicking latere
[12:37] <cjwatson> *later
[12:39] <seb128> cjwatson, well there is some desktop ones we know about but we are just busy and didn't manage to get to those yet
[12:40] <cjwatson> seb128: sure, nobody expects it to be at zero; all I'm asking is that we don't blow off people when they ask about it
[12:41] <seb128> cjwatson, ok, fair enough, the question was rather to know if we should drop everything we are doing and prioritize those or if they can wait a few days
[12:42] <cjwatson> we seem to have this conversation every time somebody from the archive team asks about something :)
[12:42] <cjwatson> we'll tell you if it's drop-everything urgent ...
[12:43] <sabdfl> pitti: i found a copy of the minutes i had
[12:43] <sabdfl> can i just save it to .../11/May ?
[12:44] <seb128> cjwatson, ok, I never if people ping to raise a bit the priority or just as an informational hint when they do ping about such things ;-)
[12:45] <cjwatson> well, I would expect that it's generally meant to raise the priority above background-noise, since there's an awful lot of the latter
[12:47] <seb128> well in any case we might need a better way to list those as "block <....>" where .... can be CD build or other thing because IRC pings are not really the best way to deal with such notices
[12:47] <seb128> especially than often it doesn't reach the right people
[12:48] <seb128> like xmldiff is coming from a sync of debian, I'm fine having a look when I will have time but other people might be less busy or have a better clue about it
[12:54] <sabdfl> pitti, mdz: https://wiki.ubuntu.com/TechnicalBoard/TeamReports/11/May
[13:02] <mdz> sabdfl, thanks
[13:09] <shadeslayer> doko: did you promote qt-gstreamer as well?
[13:09] <shadeslayer> or do we fix the said issues first?
[13:12] <shadeslayer> thanks!
[13:18] <ScottK> doko: If you're still on component mismatches, please promote kdegames-card-data-extra binary.  It's a split of an existing Main package that inadvertently dropped to Universe in Natty.  I've just seeded it so it'll show up on the next component mismatches run if not promoted.
[13:19] <pitti> doko: robert is writing a MIR for lightdm, but that doesn't affect buildability
[13:19] <pitti> it was just added to the seeds
[13:20] <pitti> xmldiff seems harmless, we can do a MIR
[13:20] <pitti> sabdfl: thanks
[13:21] <seb128> pitti, the mir is already written
[13:21] <pitti> seb128: IMHO we should fix brasero to not pull in tracker, OK for you?
[13:22] <seb128> pitti, rodrigo is already on it, we discussed that on #ubuntu-desktop early today
[13:22] <pitti> ah, cheers
[13:28] <doko> seb128, pitti: is bacula desktop stuff? tries to pull in postgresql-8.4
[13:28] <seb128> no it's server
[13:28] <pitti> probably enough to bump the b-dep to -9.0
[13:29] <doko> Daviey: bacula ^^^
[13:29] <pitti> Daviey: ^
[13:29] <doko> faster ;)
[13:29]  * Daviey looks
[13:30] <Daviey> doko, it's 'both' :)
[13:31] <doko> cool, aliasing 'both' to 'not me' :)
[13:31] <Daviey> bah.. it's the foundations that ties desktop to server :)
[13:32] <doko> ScottK: done
[13:32] <ScottK> doko: Thanks.
[14:05] <ogasawara> @pilot in
[15:05] <stgraber> slangasek: I posted the initial review for libtirpc in bug 781516 and I'm now looking at rpcbind. For libtirpc it seems like I could just re-upload the package without the build-dep on libgss-dev as it doesn't seem to be used at all, though if you know that package better than I do, I'd appreciate a second opinion.
[15:22] <ScottK> pitti or SpamapS: (I assume) one of you copied qt4-x11 from natty-proposed to natty-updates, but didn't forward copy to oneiric.  I'd appreciate it if one of you would do this to save an upload/multi-day build.
[15:24] <cjwatson> I could just do another bulk copy run
[15:24] <ScottK> That would work for m.
[15:24] <ScottK> m/me
[15:25] <cjwatson> and it's just qt4-x11 at the moment anyway
[15:25] <cjwatson> done
[15:26] <ScottK> Thanks.
[15:37] <apw> jhunt, who looks after udev ?
[15:37] <soren> apw: You. Didn't you get the memo?
[15:38] <apw> pitti, i think you sync'd udev recently?  am getting reports that a full oneiric install is a 25% chance of booting, downgrading udev sorts it ... no real details other than that yet
[15:38] <pitti> apw: not synced, updated, but yes
[15:38] <pitti> apw: do you have a machine which reproduces it? works fine here (oneiric du jour, but I never had such a problem any time in oneoric)
[15:39] <pitti> oneiric .. one eye rick .. whatever
[15:39] <apw> pitti, i've asked them to get it all in a bug and i'll get the number i
[15:39] <apw> when i have it ... nothing here with oeniric userspace as yet
[15:41] <stgraber> apw, pitti: I "think" I have this issue in one of my VMs here. Gets stuck at boot time almost 50% of the time, rebooting eventually makes it start.
[15:41] <stgraber> it's a simple server VM with just isc-dhcp-server, radvd and ssh installed, so nothing fancy
[15:42] <apw> stgraber, yep, looks like a broked udev, with udev barfing about Address already in use
[15:42] <apw> pitti, i'll have to get a vm updated to oneiric then
[15:42] <apw> sig
[15:42] <apw> sigh
[15:45] <pitti> apw: FTR, there are several folks in #u-desktop running oneiric as well, haven't heard about problems from anyone; might that be kvm specific somehow?
[15:46] <apw> pitti, checking with my reporter ... possible indeed
[15:47] <apw> pitti, ok this one is a real machine ... will see what i can find out once we have a bug
[15:47] <hallyn> kirkland: not sure if you get at all into this kind of maintenance for byobu, but one thing that bugs me is that in escape mode, i can't do things like 'f' - it just brings me back to insert mode.  Have you considered fixing that?
[15:48] <kirkland> hallyn: hmm, i'm not sure I understand the problem, but I'd like to ... can we take this to #ubuntu-server ?
[15:50] <smoser> doko, do you know how i can see a java console (in firefox) with openjdk ?
[15:51] <hallyn> k
[16:02] <dpm> hi pitti. Could you point me to that wiki page where the syntax of work items in a blueprint's whiteboard is explained?
[16:02] <pitti> dpm: https://wiki.ubuntu.com/WorkItemsHowto#Defining%20work%20items
[16:02] <dpm> pitti, great, thanks
[16:13] <geser> doko: do we miss anything important with the last gcc-defaults upload being "Failed to upload"? (https://launchpadlibrarian.net/71061220/upload_2523174_log.txt)
[16:18] <SpamapS> pitti: huh? did I typo the version?
[16:19] <pitti> SpamapS: yes, you said >= ubuntu3, but netbase is at ubuntu2
[16:20] <SpamapS> pitti: oh no the real problem is that I didn't upload netbase 4.45ubuntu3!
[16:20] <SpamapS> pitti: 4.45ubuntu2 is bad
[16:20] <pitti> SpamapS: hm, the changelog of https://launchpad.net/ubuntu/+source/netbase/4.45ubuntu2 seemed to add what you wanted
[16:21] <SpamapS> pitti: but --wait is a non-existant parameter
[16:21] <SpamapS> pitti: I forgot to debuild -S again and upload.. the .deb I was using to test was 4.45ubuntu3
[16:22] <pitti> SpamapS: ok, sorry about that; then I figure you need to revert my dbus change as well
[16:22] <SpamapS> pitti: I'll take care of it
[16:23] <SpamapS> ahh oops.. I accidentally tried to upload 4.45ubuntu3 to natty.
[16:23] <SpamapS> thats what I get for not going to inbox 0 every day. ;)
[16:23]  * SpamapS really wishes the upload process would tell him that and not an email 5 minutes later
[16:32] <slangasek> stgraber: hmm, I don't know why libtirpc would need libgss-dev, but I also can't categorically say that it's spurious... I don't know what's going on there
[16:43] <ScottK> dholbach: Where can I find these open backports request statistics?
[16:44] <dholbach> ScottK, on my local hard-drive - I'll publish in a bit
[16:44] <ScottK> dholbach: OK.  I was going by the "DONE" status in the work item.
[16:45] <dholbach> I'll update the blueprint with an url in a bit
[16:45] <ScottK> I guess the work item was for create.
[16:45] <ScottK> Sharing would be another one.
[16:45] <ScottK> ;-)
[16:45] <ScottK> Thanks.
[16:45] <cjwatson> [5~/wg 159
[16:45] <cjwatson> bah
[16:46] <doko> smoser: I think the icedtea plugin never had one
[16:47] <doko> geser: know, currently doesn't hurt
[16:47] <smoser> so how should one go about seeing java console output?
[16:47] <smoser> is there anything better than running firefox from a console and getting the output there?
[16:51] <ScottK> doko: I'm promised the libqzeitgeist MIR will be filed 'today'.  Not sure how that relates to today where you and I are, but soon in any case.
[17:03] <dholbach> ScottK, published the url - the reason they look boring and have no lines is because there's just one data point right now :)
[17:03] <ScottK> Right.  Thanks.
[17:08]  * pitti chuckles at SpamapS' dbus changelog -- I declare defeat!
[17:09] <pitti> SpamapS: now you are TIL again, I'm not unhappy about this ;)
[17:15] <tkamppeter> pitti, ping
[17:17] <tkamppeter> pitti, I have reported a CUPS SRU bug, bug 787635. The special thing is that I have discovered the problem and I have fixed it and posted the SRU. How does the verification work then. I have naturally tested the fix and it works for me.
[17:20] <SpamapS> tkamppeter: first it should be fixed in Oneiric actually.
[17:21] <SpamapS> tkamppeter: once it is in Oneiric, the fixed package should be available in natty-proposed for 7 days at least, and at least one user needs to "verify" the package, then it should move to natty-updates
[17:41] <ScottK> SpamapS: Looks like a fun FTBFS on armel for you to go with your witty dbus repartee.
[17:47] <SpamapS> ScottK: yeah I saw the earlier build failure too. :-/
[17:49] <SpamapS> collect2: ld terminated with signal 11 [Segmentation fault]
[17:49] <SpamapS> Toolchain bug?
[17:50] <stgraber> slangasek: as building with and without libgss-dev gives me an identical resulting lib, I'd be tempted to just drop the build-dep. I'll poke the Debian maintainer see if he knows why the build-dep is there.
[17:51] <infinity> SpamapS: ld should never segv, so yes.  But you may be able to work around it fiddling with flags.
[17:51] <infinity> SpamapS: (Which can be handy in isolating the bug too)
[17:52] <slangasek> stgraber: cool, thanks
[17:55] <stgraber> slangasek: the Debian maintainer is planning on uploading a new upstream release and will drop the build-dep in that upload. I guess we can just wait for it then.
[17:55] <slangasek> cool
[17:56] <SpamapS> infinity: I suppose first tep would be getting access to armel hardware.. :-P
[17:56] <infinity> SpamapS: qemu, go?
[17:57] <SpamapS> I have zero experience w/ this
[17:57] <SpamapS> if there's a HOWTO tho.. I'd be interested in playing
[17:58] <slangasek> SpamapS: https://wiki.linaro.org/Resources/HowTo/Qemu-beagleboard
[17:58] <slangasek> that's for full-system emulation
[17:58] <slangasek> alternatively, you can do a qemu chroot
[17:59] <slangasek> not sure if we have a howto for that somewhere
[18:00] <SpamapS> slangasek: ty!
[18:01] <slangasek> SpamapS: if you just want syscall emulation on a chroot, you can install qemu-user-static and use /usr/sbin/qemu-debootstrap to set up a chroot
[18:01] <slangasek> (will run faster than whole-machine emulation)
[18:01] <stgraber> SpamapS: I was planning on setting up my pandaboard with LXC a bit later today so I can easily run multiple Oneiric ARM systems for testing. I can probably give you access to one of them once it's ready ;)
[18:01] <infinity> But won't catch if your ld segv is actually a kernel bug.
[18:02] <infinity> (But it probably isn't)
[18:02] <SpamapS> slangasek: I think given the segfault I want full machine
[18:03] <infinity> SpamapS: Generally not, unless you really do suspect the kernel.
[18:03] <infinity> SpamapS: And then, you need to run against the same kernel the buildds are using...
[18:03] <slangasek> SpamapS: what infinity said; 9 times out of 10 you'll be able to reproduce with just syscall emulation, which is faster *and* easier to configure, so you might as well try it first
[18:04] <SpamapS> Ahh ok
[18:05] <infinity> SpamapS: Realistically, if the kernel *is* breaking ld, you'd be seeing it across many/most builds.  If you're just seeing it in a specific case, it's probably binutils.
[18:05] <infinity> SpamapS: (And it's binutils being tickled by a very specific grumpy output from gcc)
[18:05] <infinity> *handwavy*
[18:25] <RoAkSoAx> kirkland: ping, did you find the bug against gnome-settings-daemon?
[20:00] <jhunt> SpamapS: I'm seeing armel toolchain weirdness too (that upstart FTBFS plus nih)
[20:01] <RoAkSoAx> barry: ping
[20:02] <barry> RoAkSoAx: pong
[20:02] <RoAkSoAx> barry: I have a qcuik question about UDD that's driving me crazy :)!! Should be submit branches with patches applied or not?
[20:03] <RoAkSoAx> barry: cause when doing some merges I encounter the situation that there's diff's in .pc/what-ever-patch.patch
[20:03] <barry> RoAkSoAx: you're not alone about that one ;)  it's somewhat of an open question, but current thinking is that your branch will both have the debian/patches file(s) *and* the patches applied in tree
[20:03] <barry> RoAkSoAx: thinking goes:
[20:04] <barry> when you branch, you have the patches applied, so you'll just make your changes, do a bit of magic to generate the d/p file, commit and push
[20:05] <barry> RoAkSoAx: yes, that's one large suck about the process.  i think the best thing to do is to revert the .pc directory before you push
[20:05] <kees> cjwatson: how do I check to see if a given LP user has package upload rights? where is that visible?
[20:05] <RoAkSoAx> barry: right, so I';d revert the .pc directory and leave the patches unapplied?
[20:06] <maco> kees: cant do it in lp itself
[20:06] <maco> kees: pull down ubuntu-archive-tools from lp
[20:06] <barry> RoAkSoAx: you can certainly do that.  when i said "revert the .pc" directory, i mean 'bzr revert .pc' so that could lead to a patches applied push
[20:06] <kees> maco: I thought not. But I don't know where to look. Ah-ha.
[20:06] <maco> kees: and run edit_acl.py
[20:06] <stgraber> kees: bzr+ssh://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/
[20:07] <barry> RoAkSoAx: just realize that this is a very uncomfortable place you're in, and something the bzr guys have a high motivation to fix
[20:07] <RoAkSoAx> barry: but would it hurt to  push with patches un-applied?
[20:07] <barry> RoAkSoAx: no, i don't think it would because a reviewer is mostly going to be looking at the debian/ directory anyway
[20:07] <maco> ./edit_acl.py query -p lpusername
[20:07] <maco> kees: ^
[20:08] <barry> RoAkSoAx: and they should be able to 'quilt push -a' for example if they wanted to see the effects in tree
[20:08] <kees> maco: oh, it can be done. you meant LP web, not LP API?
[20:08] <barry> RoAkSoAx: so i think you're okay either way
[20:08] <maco> kees: right
[20:08] <maco> kees: sorry, this is the part of my brain that likes guis talking :)
[20:08] <RoAkSoAx> barry: right, cool! Cause I've run into situations that I unpack the source and end up with patches applied with nothing under .pc, however, when quilt push -a, it fails to apply patches because they are already applied
[20:09] <RoAkSoAx> so I have to do some magic to get that fixed
[20:09] <barry> RoAkSoAx: yep.  when you 'bzr branch ubuntu:foo' you always get patches applied
[20:10] <barry> RoAkSoAx: just as an example, i've rewritten that section in the udd docs like three times already ;)
[20:10] <RoAkSoAx> barry: cool I think I'll just start pushing without patches applied cause at the end generates issues when extracting the source with dpkg
[20:10] <RoAkSoAx> barry: hjehe yeah grey area :)
[20:10] <RoAkSoAx> barry: but anyways, Thanks for the input I now have a clearer view
[20:11] <barry> RoAkSoAx: please do feel free to email the udd list and/or submit bugs for any problems or experience you have.  i know the bzr guys would love to get more data points :)
[20:11] <RoAkSoAx> barry: hehe will do ;) thanks!
[20:11] <barry> np!
[20:14] <kees> maco: who was supposed to put brad-figg in ~ubuntu-kernel-uploaders ?
[20:14] <maco> kees: i dont know but i guess i could do it now
[20:15] <maco> ok. did.
[20:15] <kees> maco: thanks!
[20:15] <maco> np
[20:20] <stgraber> ogra_: you may be interested by bug 787749
[21:02] <seb128> slangasek, you broke gdk-pixbuf in oneiric! ;-)
[21:03] <slangasek> seb128: I won't claim to be surprised ;), but I don't know what's broken - pointer?
[21:03] <seb128> slangasek, IRC reports but
[21:03] <seb128> https://launchpadlibrarian.net/71185137/gdk-pixbuf_2.23.3-0ubuntu1_2.23.3-0ubuntu2.diff.gz
[21:03] <seb128> +            /usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders \
[21:03] <seb128> +                /usr/lib/#MULTIARCH#/gdk-pixbuf-2.0/2.10.0/loaders/*.so \
[21:04] <seb128> slangasek, the gdk-pixbuf-2.0/gdk-pixbuf-query-loaders dir is false it's in #MULTIARCH# as well
[21:04] <seb128> slangasek, that broke today with the librsvg update, the trigger empty the cache and no icon can be loaded
[21:04] <seb128> slangasek, you forgot to push your update to the vcs also btw
[21:04] <seb128> slangasek, do you want to fix it or should I add that to my list for tomorrow?
[21:05] <slangasek> seb128: oh, indeed; I see that I had the right path in postinst configure, but wrong for postinst trigger, doh
[21:05] <seb128> (it's 10pm and I was about to go but I can fix that tomorrow when I start my day)
[21:05] <slangasek> seb128: I'll try to get to it today but no promises
[21:05] <seb128> slangasek, ok, thanks
[21:06] <seb128> well seems easy enough, let see if I can get that done now before going
[21:06] <slangasek> Vcs> sorry; further evidence that this some-UDD-some-not world is error prone :/
[21:06] <seb128> slangasek, do you have the vcs revision and forgot to push or should I fix that?
[21:06] <seb128> slangasek, debcheckout is your friend ;-)
[21:07] <slangasek> seb128: I have it all on the wrong Vcs (the UDD branch), you should probably go ahead and fix it
[21:07] <seb128> (we just sort of decided today in the desktop team meeting to stay away from UDD for another cycle)
[21:07] <seb128> slangasek, ok
[21:07] <slangasek> eh, no, debcheckout isn't my friend, it doesn't have a sensible fallback to UDD
[21:32] <brendand> i have a problem with logging into unity, every few times i login the desktop doesn't appear
[21:32] <brendand> anyone have any thoughts on which logs i should be checking to see what's hanging?
[21:34] <psusi> brendand: .xsession-errors
[21:34] <brendand> psusi - in?
[21:36] <charlie-tca> ~/.xsession-errors
[21:37] <brendand> a bunch of nm related warnings at the end
[21:39] <brendand> compiz (core) - Error: Plugin 'text' not loaded.
[21:39] <brendand> ?
[21:39] <brendand> not sure if that should do any harm
[21:40] <charlie-tca> psusi knows more than I do about that stuff
[21:40] <brendand> this happens seemingly randomly
[21:40] <brendand> and so far has never happened when trying to login to classic desktop
[21:54] <ogasawara> @pilot out
[22:19] <slangasek> SpamapS: OOI, why is it dbus that needs to 'stop on deconfiguring-networking', rather than network-manager?
[22:20] <SpamapS> slangasek: because network-manager also needs to 'stop on stopping dbus'
[22:21] <SpamapS> slangasek: in order to express it differently, we have to jump through similar hoops to the portmap issues...
[22:21] <SpamapS> slangasek: I don't like it.. but until we have 'while' ... the hacks are going to pile up. :(
[22:21] <slangasek> SpamapS: oh, because n-m shutdown would race dbus shutdown, heh
[22:21] <slangasek> got it
[22:22] <SpamapS> As proud as I am of wait-for-state .. I'm hoping to avoid actually using it again. :)
[22:23] <slangasek> SpamapS: can you document in dbus.conf that this is a workaround, so someone like me doesn't go "fixing" it later? :)
[22:23] <seb128> slangasek, ok, gdk-pixbuf vcs sorted and new version uploaded to fix the path issue
[22:23] <slangasek> seb128: you rock :)
[22:23] <seb128> ;-)
[22:24] <SpamapS> slangasek: sure. Would pushing a change into lp:ubuntu/dbus w/o an upload be a good way to do that?
[22:25] <slangasek> SpamapS: should work
[22:25] <SpamapS> slangasek: its still not clear to me if that is a good way to stage low priority changes.
[22:25] <slangasek> it's a method I endorse :)
[22:25] <seb128> 'night
[22:25] <slangasek> seb128: 'night!
[23:47] <cpatrick008> i was wondering when the daily and daily-live isos are coming out because they are not out yet and the natty ones came two weeks eairler in the cycle
[23:48] <broder> cpatrick008: there's some major re-working of the cd build process happening this cycle
[23:48] <broder> and i think iso builds have been turned off until that's finished
[23:48] <cpatrick008> ok thanks
[23:55] <cjwatson> broder: actually not as such, I just haven't really got round to it
[23:55] <cjwatson> plan is to do it tomorrow morning, assuming the desktop's still installable
[23:55] <broder> oh, ok. /me shrugs
[23:56] <cjwatson> mostly didn't get round to it because initially it was thoroughly blocked by various transitions, and I got distracted into running those
[23:56] <stgraber> I did a desktop netinstall today and it installed. It doesn't "work" but it installs ;)