[00:29] <fta> i want that chromium build.. hurry
[00:29] <BUGabundo1> ehhe
[00:30] <fta> https://edge.launchpad.net/builders/sandpaperfig
[00:57] <fta> damned
[07:20] <micahg> hi gnomefreak
[07:20] <micahg> how are you?
[07:22] <gnomefreak> hi micahg im ok and yourself?
[07:22] <micahg> ok
[07:23] <gnomefreak> its was too damn early
[07:26] <micahg> what was?
[07:28] <gnomefreak> micahg: right now it is. its ~02:30
[07:28] <micahg> ah
[07:28] <micahg> indeed
[08:01] <gnomefreak> why do people think they need to say "this happens to me too" since that bug has 50+ people that already said it and sees the bug :(
[08:07] <micahg> well, in other forums that seems to be the general practice
[08:07] <micahg> they are not used to such an advanced forum as LP with the option to select without saying
[08:08] <micahg> bugday had some success
[08:08] <micahg> http://people.ubuntu.com/~brian/complete-graphs/firefox-3.0/plots/firefox-3.0-1day-triaging.png
[08:09] <micahg> I was just going to ignore those people gnomefreak
[08:09] <micahg> I guess that's bad :(
[08:11] <gnomefreak> its too early to ignore people atm. Thats true about they do it in other forums but that still doesnt sound logival. for example the right click master bug. people are still stating they see it. hint: look at the number of comments read 3 and you will know what you are looking at :(
[09:20] <BUGabundo> guud morning, FLOSS world!
[09:42] <gnomefreak> bug 78593
[09:51] <BUGabundo> hey gnomefreak
[09:51] <BUGabundo> did you already have the eye surgery?
[09:52] <gnomefreak> BUGabundo: hi, no first one looks to be on june 8th however that may change since i cant go 14+hrs without eating or drinking due to diabetes
[09:52] <BUGabundo> err
[10:30] <gnomefreak> one of these days before my surgery i have to figure out how to use hg for pre-release sunbird so we can get testing. all my other tries have failed
[12:15] <henux> hello and excuse me; this probably isn't the best place to ask but does anyone know what would be the best place to ask questions on writing mozilla firefox/thunderbird add-ons with XUL?
[13:04] <fta> henux, irc://irc.mozilla.org/extdev is a better place
[13:04] <fta> https://developer.mozilla.org/en/Extensions
[13:34] <henux> okay thanks
[13:59] <BUGabundo> uau
[13:59] <BUGabundo> he lasted 1h30 for that fta and then just left
[13:59] <BUGabundo> eheh
[13:59] <BUGabundo> brave man
[14:05] <fta> well
[14:26] <fta> bug 364074
[14:26] <fta> bug 364074
[14:26] <fta> pfff
[14:27]  * BUGabundo kicks the bot!
[14:27] <BUGabundo> fta try again
[14:27] <BUGabundo> bug 364074
[14:27] <BUGabundo> see? nothing like a little push ... with an hammer
[14:29] <fta> yeah
[14:35] <BUGabundo> fta: why not vlc?
[14:41] <fta> vlc? to record what's happening on the desktop?
[14:43] <BUGabundo> fta: yep!
[14:43] <BUGabundo> it won't allow you to choose just a part, but the all screen
[14:43] <BUGabundo> AFAIK
[14:44] <BUGabundo> I used to stream it to the web for lectures
[14:44] <fta> not what i want then, i want parts
[14:45] <fta> gtk-recordmydesktop is already the newest version.
[14:45] <fta> hmm
[14:51] <BUGabundo> !firefox
[15:22] <BUGabundo> fta: which PPAs have chromium?
[15:24] <FLjohn> Hello
[15:24] <FLjohn> I am having a problem with all video streaming
[15:25] <FLjohn> Since I am now using edubuntu there have been problems.  All video is blacked out
[15:25] <FLjohn> Except for youtube and a few others
[15:28] <BUGabundo> Estimated repository size: 20.0 GiB (100.00%) of 20.0 GiB
[15:28] <BUGabundo> LOL fta
[15:28] <BUGabundo> still full?
[16:25] <fta> BUGabundo, yes, each build is ~8.1GB, so i need 3 times that if i want 2 dailies + 1 fix in between, about 25G
[18:22] <asac> hola
[18:25] <fta> lo
[18:27] <fta> https://edge.launchpad.net/ubuntu/karmic/+source/db4.6/+builds needs to be fixed before i can update ia32libs
[18:29] <asac> checking
[18:30] <asac> hmmm configure: error: No unsigned 1-byte integral type
[18:31] <fta> http://paste.ubuntu.com/178076/
[18:32] <asac> hmm
[18:32] <asac> thats the config.log?
[18:32] <fta> yes
[18:32] <BUGabundo> hey asac..
[18:32] <asac> hi BUGabundo
[18:33] <asac> fta: that looks a bit like the headers are kind of out of sync
[18:33] <fta> asac, aren't they all from libc6-dev?
[18:39] <fta> more new icons: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[18:39] <asac> fta: odd ... i would thought that some libc aders come from the kernel
[18:40] <asac> fta: damn ... not rest here ... didnt notice its so late again. have to run out again.  end of allhands drink/dinner started already :(
[18:40] <asac> fta: i will ask doko
[18:40] <asac> ;)
[18:41] <fta> enjoy :)
[18:41] <fta> and thanks
[18:41] <asac> fta: do you arrive on sunday?
[18:41] <fta> yes, around 2pm at the airport
[18:41]  * BUGabundo thinks fta is envying all the party at barça
[18:41] <asac> lol
[18:41] <asac> its really just party in the night
[18:41] <BUGabundo> fta: lots to due at the office?
[18:41] <fta> no office today, i worked from home
[18:41] <asac> we have soo many obligatory sessions here that i didnt even read any mails in the last three days
[18:42] <asac> so cu tomorrow most likely
[18:42] <asac> if doko knows something that we can fix somehow, i will come back and let you know
[18:42] <asac> but i guess he has to look
[18:42] <fta> ok
[18:45] <fta> BUGabundo, #  Estimated repository size: 16.5 GiB (82.49%) of 20.0 GiB  maybe it will be enough to let it pass
[18:51] <BUGabundo> why don't you ask the LP admins for extra space?
[18:52] <fta> BUGabundo, https://answers.edge.launchpad.net/soyuz/+question/62386
[18:56] <BUGabundo> aahahhahahahahahahahahhahahaahaahahhahahahahahahahahhahahaahaahahhahahahahahahahahhahahaahaahahhahahahahahahahahhahahaahaahahhahahahahahahahahhahahaahaahahhahahahahahahahahhahahaahaahahhahahahahahahahahhahahaahaahahhahahahahahahahahhahahaah
[18:56] <BUGabundo> I lauching like crazy here
[18:56] <BUGabundo> glad no one is around
[18:56] <BUGabundo> I don't see it for 20GiBs
[18:57] <fta> i never got 15, jumped to 20 directly
[18:57] <BUGabundo> ahaahahah
[18:58] <BUGabundo> if I die, from lauching, ill haunt you
[18:58] <fta> dying from that is a good death
[18:59] <BUGabundo> do you have any idea where I can ask for help with my @ubuntu email address?
[18:59] <fta> -lauching+laughing
[18:59] <BUGabundo> I tried<EMAIL_ADDRESS>but it disappear
[19:00] <fta> just ping dholbach, he'll know who's behind this
[19:01] <BUGabundo> he is allhands
[19:01] <BUGabundo> won't see it
[19:01] <BUGabundo> then again I have all the time in the world
[20:23] <fta> -chromium-browser (<IP_ADDRESS>~svn20090521r16618-0ubuntu1) UNRELEASED; urgency=low
[20:23] <fta> +chromium-browser (<IP_ADDRESS>~svn20090522r16750-0ubuntu1) UNRELEASED; urgency=low
[20:23] <fta> !!
[20:24] <micahg> wow
[21:17] <fta> hmm firefox-3.5 - 3.5~hg20090522r25692+nobinonly-0ubuntu1~umd1
[21:17] <fta> no more 3.5~b5~xx
[21:18] <BUGabundo> yay
[21:19] <fta> no tag, it has to be a RC of some kind
[21:21] <micahg> they said they were close to RC
[21:21] <micahg> I thought it was next week though
[21:23] <fta> it's not there yet, they just bumped the version in trunk, it doesn't mean it's released
[21:25] <micahg> ok
[21:25] <micahg> yeah
[21:25] <micahg> release date of RC1 I think is May 29
[21:28] <micahg> I was just thinking how the beta version of FF is more stable than Jaunty
[21:29] <micahg> the daily builds
[21:29] <micahg> at least from my use of it
[21:29] <fta> eheh
[21:34] <fta> 3.5pre, that's it
[21:35] <micahg> that's what it says
[21:35] <micahg> Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1pre) Gecko/20090522 Ubuntu/9.04 (jaunty) Shiretoko/3.5pre
[21:47] <gnomefreak> ironicly i expect a bash command to listen to me yet i cant even get my g/f to listen to me :(
[21:48] <micahg> at least bash will follow instructions if you specify them correctly :)
[21:48] <gnomefreak> command |tee  2>&1 build-log.txt  << should pipe output of standard out and standard error to file but it doesnt do that while building. it picks nad chooses wha to pipe where
[21:49] <gnomefreak> micahg: i wish it did
[21:49] <micahg> no
[21:49] <gnomefreak> no?
[21:49] <micahg> try command 2>^1 | tee build-log.txt
[21:49] <BUGabundo> gnomefreak: sudo make me sandwish?
[21:49] <micahg> command 2>&1 | tee build-log.txt
[21:49] <gnomefreak> oh
[21:49] <gnomefreak> oops
[21:49]  * gnomefreak does to try
[21:50] <micahg> you were piping the errors of tee to the file :)
[21:50] <BUGabundo> gnomefreak: http://xkcd.com/149/
[21:50] <micahg> the only reason I know that is because asac gave me a command similar to that :)
[21:50] <gnomefreak> ah
[21:51] <gnomefreak> i did it backwards now i remember the command  :(
[21:51] <gnomefreak> BUGabundo: :)
[21:53] <gnomefreak> maybe wednesday will be next update, i have other crap i can work on lets see where i get with email nad updates maybe ill hit an extension or 3
[21:54] <micahg> well, I'm working this weekend, so not too much triage for me
[21:56] <micahg> gnomefreak: do you patch firefox itself at all?
[21:56] <gnomefreak> micahg: i can but im not actively working on firefox
[22:00] <gnomefreak> if you stop following someone on mozillas bug tracker it doesnt stop the emails coming in
[22:01] <micahg> ah
[22:01] <gnomefreak> hes not here. hes always here
[22:01] <micahg> is that a bug in bugzilla?
[22:01] <gnomefreak> micahg: yes alot of them
[22:02] <micahg> does it subscribe you to the issues that the person is involved in?
[22:02] <gnomefreak> micahg: i was following asac reed and gerv well i started gettting 200+ emails a few times a day so i dropped fololowing gerv and im still getting 200+ a day.
[22:03] <micahg> well, are some of them watched by multiple people inthat group?
[22:03] <gnomefreak> example this morning ~12 hours ago i had ~230 amnd another 141 now just bugs that are fololowing them
[22:03] <gnomefreak> micahg: you can follow single people's bugs comments
[22:03] <micahg> ah
[22:04] <gnomefreak> reed is handy to follow at least for me
[22:05] <gnomefreak> micahg: you had to bring up patching didnt you
[22:05] <micahg> why :(
[22:05] <gnomefreak> i have been forgetting about this patch, i wanted to test it before it landed
[22:05] <gnomefreak> 1st email on this bug in a week or 2
[22:06] <gnomefreak> its the reply to all patch
[22:06] <gnomefreak> mozilla 45715
[22:07] <gnomefreak> ubottu: thanks
[22:07] <micahg> beer ubottu
[22:08] <micahg> hmmm
[22:08] <micahg> guess that didn't work
[22:09] <gnomefreak> if you mark a bug in Lp upostream please add Lp bug link to upstream bug. I dont know if you have been or not this is just a request
[22:10] <micahg> I have been :)  I was worried about flooding upstream
[22:10] <gnomefreak> im looking for the LP bug in upstream report and cant find it (this is one i should have done)
[22:10] <micahg> I just saw that bug somewhere
[22:10] <gnomefreak> its always good to do incase they need more info that isnt on upstream bug but is on LP bug
[22:11] <micahg> bug 52667
[22:11] <gnomefreak> thanks
[22:12] <micahg> I was thinking of going through the mozilla-thunderbird package before the bugday next week for TB
[22:14] <micahg> is that worthwhile, or should I focus on FF
[22:14] <gnomefreak> micahg: i would love to see someone on tb bugs at least to maybe knock them down a bit
[22:15] <micahg> well, I figure if I can move the ones for TB2 to the TB pacakge
[22:15] <micahg> then the Bugday can work on them
[22:15] <gnomefreak> there shouldnt be a tb2 package it should only be mozilla-thunderbird
[22:15] <micahg> no, it's thunderbird now
[22:15] <micahg> mozilla-thunderbird was 1.5
[22:16] <gnomefreak> it is?
[22:16] <micahg> yep
[22:16] <micahg> https://bugs.launchpad.net/ubuntu/+source/thunderbird
[22:16] <gnomefreak> this is bad. i really need to work this out its getting old
[22:16] <micahg> https://bugs.launchpad.net/ubuntu/+source/mozilla-thunderbird
[22:17] <micahg> actually ubottu should kow
[22:17] <gnomefreak> micahg: its fine please do that. 1.5 is no longer supported by us or mozilla so they can be closed if not reproducible in 2.0
[22:17] <micahg> !info mozilla-thunderbird
[22:17] <gnomefreak> see
[22:17] <BUGabundo> fta: LOLOLOLOLOLOLOL n*8 (for now)
[22:17] <gnomefreak> thunderbird == 3.0
[22:17] <fta> BUGabundo, ??
[22:17] <gnomefreak> see your ~/.thunderbird-3.0 or ~/.mozilla-thunderbird
[22:17] <micahg> gnomefreak: what about dapper?
[22:18] <BUGabundo> fta: the ticket for PPA quota
[22:18] <gnomefreak> but either way we should really keep names the asme if possible
[22:18] <gnomefreak> micahg: its not supported
[22:18] <micahg> Ubuntu is still supposed to do security patches for another month
[22:18] <gnomefreak> micahg: dapper EOS is soon no sense in patching it now
[22:18] <micahg> ok
[22:18] <gnomefreak> micahg: ther eis no tb1.5 security
[22:18] <micahg> ok
[22:19] <fta> BUGabundo, what do you want me to tell instead?
[22:19] <gnomefreak> fta: can you decline nominations on bugs?
[22:19] <micahg> so this weekend I'll work on the mozilla-tb package instead of ff
[22:19] <fta> gnomefreak, i think so
[22:19] <micahg> gnomefreak: yes, it's been done to me many times :)(
[22:19] <gnomefreak> fta: bug 52667 should reject hardy
[22:19] <BUGabundo> fta: nothing... I just found it funny
[22:20]  * gnomefreak should really figure out what i need to declidne they and try to get it :(
[22:21] <gnomefreak> fta: im going to try a locale build of tb3 with reply to all patch if it works maybe we can patch dailies? atleast until its commited. this is the one bug i have been following most
[22:21] <fta> gnomefreak, apparently, i can't either.
[22:22] <fta> gnomefreak, asac was against the idea, he mentioned an addon
[22:22] <gnomefreak> oh ok well than ill build it localy for me
[22:22] <gnomefreak> or ill package it as .xpi even better
[22:23] <gnomefreak> alot harder but better
[22:23] <fta> and i prefer to keep the dailies as pristine as possible, ok to fix build issues but not to add features we would like to have
[22:24] <fta> someone could still fork the package and add as many patches from bmo as possible, to create a monster, but it means dropping the name & branding
[22:26] <gnomefreak> fta: thats fine i will look into making it .xpi and i will patch SM with the test patch for now. maybe next week or so
[22:32] <micahg> I might as well ask the Q now, are the FF -dev packages supposed to have any files in them besides the Copyright and debian.tar.gz?
[22:34] <gnomefreak> yes i would think so but honestly i have never looked
[22:35] <fta> micahg, which package?
[22:35] <gnomefreak> micahg: downloading to make sure
[22:35] <micahg> firefox-3.0-dev
[22:36] <fta> not really, it's in xul -dev now, but ff -dev is still used by some packages so we had to keep it
[22:37] <micahg> ok
[22:37] <micahg> there was a bug about hardy ff-dev having no files
[22:37] <micahg> that's been fixed
[22:37] <micahg> but I wanted to make sure there weren't any other issues
[22:37] <fta> well
[22:38] <fta> upstream provides no -dev files in firefox when it is built with the xul sdk, if some files are needed, it's an upstream bug, but as building ff with xul sdk is not really supported upstream, it's a catch 22
[22:48] <gnomefreak> shit forgot about dog
[22:58] <gnomefreak> hm cam no longer automounts or shows up at all to mount
[22:59] <gnomefreak> anyone use the app bugzilla?
[23:00] <gnomefreak> might be my fault
[23:02] <gnomefreak> ok cam mounts right noiw
[23:04] <micahg> gnomefreak: I have a Q about assignigng bugs
[23:04] <gnomefreak> micahg: shoot
[23:04] <micahg> if a bug is in xulrunner, should the package and upstream be xulrunner?
[23:04] <gnomefreak> micahg: is it a bug in xulrunner?
[23:04] <micahg> well, I look upstream at bugzilla
[23:04] <gnomefreak> if upstream says it is in xulrunner ours should match
[23:05] <micahg> and if I don;t see options for selecting FF, I assume the bug is in xulrunner
[23:05] <gnomefreak> micahg: can you give example?
[23:06] <micahg> https://bugzilla.mozilla.org/show_bug.cgi?id=388195
[23:06] <gnomefreak> micahg: people that file bugs may not be sure what package itis in
[23:06] <micahg> ok, you're ssaying in bugzilla as well
[23:07]  * gnomefreak not sure but that should be in firefox but lets see hwat i find out once link opens
[23:07] <micahg> well, that bug is for the underlying support which is in xulrunner
[23:07] <micahg> AFAIK
[23:08] <micahg> the LP bug might be more appropriate in FF though
[23:08] <micahg> that's the weird thing
[23:09] <micahg> and I didn't add the LP bug to this :(
[23:09] <micahg> but you're saying that if it's appropriate
[23:09] <micahg> the appropriate project should be used
[23:10] <gnomefreak> the first diff shows it in browser from what i can tell. AFAIK xulrunner does nothing on netwroking end
[23:10] <micahg> ah
[23:10] <micahg> maybe that's my confusion
[23:10] <micahg> NSS handles network, right?
[23:11] <micahg> do we have an NSS project/package
[23:11] <micahg> in LP?
[23:11] <gnomefreak> yes we have nss and nspr nowever nss deals with security related to networking but not sure if it handles networking directly
[23:11] <fta> https://edge.launchpad.net/nss
[23:11] <gnomefreak> micahg: in LP yes
[23:12] <gnomefreak> fta: nss doesnt handle gophor does it?
[23:12] <micahg> ok, so, should I just leave FF stuff in FF if I'm notsure
[23:12] <gnomefreak> micahg: yes if we dont know :)
[23:12] <micahg> ok
[23:12] <gnomefreak> what is LP bug number?
[23:12] <micahg> yeah, I just saw today that there are multuple libraries behind FF
[23:13] <micahg> bug 297837
[23:13] <micahg> not directly related
[23:13] <micahg> well
[23:14] <micahg> that's probably why I didn';t link it
[23:14] <gnomefreak> http should be FF directly nss would use htpps IIRC
[23:14] <micahg> ok
[23:14] <micahg> I think I'll leave things simple for now
[23:14] <micahg> when I delve into FF more, I can learn what goes where
[23:15] <gnomefreak> seems upstream is using xulrunner
[23:15]  * micahg has to go home
[23:28] <fta> no green chromium today, i'm over quota for the fix
[23:29] <gnomefreak> green?
[23:29] <fta> successful build
[23:31] <gnomefreak> ah


[00:31] <Peaker> hey, how come building python package from source runs its unit tests like 5-6 times (or more)?  why run them at all, and then why re-run them?
[00:32] <azeem> "why run them at all?"
[00:32] <azeem> was that a serious question?
[00:36] <Peaker> yeah - why run the unit tests as part of the build of the package?  they were run by those who distributed the source in that form
[00:37] <Peaker> most sources don't have a UT to run when building the package...
[00:37] <azeem> do you consider this a feature?
[00:37] <slangasek> changes to build environments can (and do) introduce regressions.
[00:37] <azeem> Peaker: the point of unit tests is testing the binaries
[00:38] <Peaker> I think its for testing the source
[00:38] <Peaker> the binaries will correspond to the source anyway, we have compilers we trust :)
[00:38] <azeem> Peaker: welcome to the real world
[00:39] <kees> Peaker: it's testing him in shared library form, static library form, maybe in other build ways
[00:39] <azeem> also, welcome to different architectures, etc.
[00:39] <Peaker> kees: does it ever get differing results ?
[00:39] <kees> Peaker: yup
[00:39] <Peaker> is there any way to cancel the unit tests?
[00:40] <azeem> export DEB_BUILD_OPTIONS=nocheck
[00:40] <azeem> might help
[00:40] <Peaker> thanks
[00:42] <azeem> well, not cancel, but disable
[00:42] <slangasek> kees: hmm, do you know of any toolchain behavior changes between hardy and intrepid, that wouldn't show up as added CFLAGS?
[00:43] <kees> slangasek: there was a lot of changes between gcc 4.2 and 4.3.
[00:43] <kees> slangasek: 4.3 is MUCH pickier about C++ stuff especially.
[00:43] <slangasek> but no deliberate behavior changes on C code, that you know of?
[00:43] <slangasek> I'm trying to debug the milestoned sysklogd bug
[00:44] <slangasek> I think, but haven't yet proven, that klogd is failing to call its internal openlog() implementation, the one that supports LOG_KERN
[00:44] <kees> slangasek: I'm personally not aware of anything that wouldn't yell loudly duriung compile.  (4.3 is more strict about builtins)
[00:44] <slangasek> but then when I've proven that, I'm still not sure *why* it's doing this
[00:45] <kees> (gah, 2.6.27 keeps io deadlocking on me...)
[00:45] <kees> (but only until I switch tasks or something hmpf)
[00:45] <kees> slangasek: which bug #?
[00:45] <slangasek> kees: bug #255635
[00:45] <slangasek> build the same source on hardy, it works fine
[00:45] <slangasek> (expected, the source hasn't changed much)
[00:46] <kees> wait, built with the intrepid toolchain?
[00:46] <kees> oh you meant build on hardy with intrepid source
[00:46] <slangasek> yes
[00:46] <kees> have you tried compiling with -U_FORTIFY_SOURCE ?
[00:47] <kees> (on intrepid)
[00:47] <slangasek> not yet
[00:47] <kees> but I confirm -- my kern.log is empty.  :)
[00:48] <kees> but it is getting into my messages file
[00:51] <kees> I do see some warnings from fortify, but nothing that would seem to indicate this kind of magic.  http://launchpadlibrarian.net/16992758/buildlog_ubuntu-intrepid-i386.sysklogd_1.5-2ubuntu5_FULLYBUILT.txt.gz
[00:53] <kees> slangasek: *sigh*
[00:53] <slangasek> ?
[00:53] <kees> CFLAGS aren't imported by upstream
[00:54] <kees>         ${CC} ${SKFLAGS} ${SYSLOGD_FLAGS} $(DEB) -c syslogd.c
[00:54] <slangasek> I know; how does that /break/ the build? :)
[00:54] <kees> SKFLAGS= $(RPM_OPT_FLAGS) -O3 -DSYSV -fomit-frame-pointer -Wall -fno-strength-reduce
[00:54] <kees> no, but it's frustrating my attempts at -U_FORTIFY_SOURCE
[00:54] <kees> and I love the use of RPM_OPT_FLAGS
[00:54] <azeem> -DSYSV FTW
[00:55] <slangasek> we could always fix this bug by replacing sysklogd with rsyslog
[00:56] <wgrant> I would have thought we would be doing that anyway.
[00:56] <kees> Aug 29 16:56:28 gorgon klogd: Kernel log daemon terminating.
[00:56] <kees> Aug 29 16:56:30 gorgon kernel: Inspecting /boot/System.map-2.6.27-2-generic
[00:57] <kees> somehow, it is fortify.
[00:57] <slangasek> are you sure it's not glibc?
[00:57] <slangasek> because my money is on glibc
[00:57] <kees> well, fortify is all implemented in glibc, so yeah, I'd bet it's a bug in glibc too, but cramming -U_FORTIFY_SOURCE does fix the behavior.
[00:57] <slangasek> well, except that I can't find any evidence of this in the glibc headers :)
[00:58] <slangasek> heh, ok
[00:58]  * kees wonders if there is a macro for openlog that causes the first arg to be ignored and replaced with argv[0]
[01:01] <kees> hm, guess not.  wtf
[01:02] <slangasek> no, but if I edit the syslog.c source to add a printf() to openlog, it only shows up if I build syslog.c with hardy
[01:03]  * kees scratches his head
[01:03] <slangasek> no, I take that back
[01:03] <slangasek> I'm just confused because the printf() is dumped to syslog, and buffered very oddly such that it shows up at the end :)
[01:08] <kees> slangasek: freaky -- it _is_ calling it with "kernel" as the arg (says the disassembly)
[01:12] <kees> slangasek: is it something else that causes it to direct stuff from klogd into kern.log?  if I juse use "logger -t kernel" it all goes into messages too.
[01:12] <slangasek> kees: logger -t kernel uses the glibc openlog() implementation
[01:13] <slangasek> which doesn't permit LOG_KERN
[01:13] <kees> what is klogd.c using?
[01:13] <slangasek> (it selects by facility anyway, so even if glibc let you, you would have to use logger -p kern.foo)
[01:13] <slangasek> it uses the openlog() implementation in syslog.c
[01:14] <kees> ah-ha
[01:15] <slangasek> so, recompiling just klogd.c on hardy fixes it
[01:17] <kees> slangasek: yup, -U_FORTIFY_SOURCE only klogd.o fixes it for me too.  wtf.
[01:18] <Peaker> its taking hours to build the python package, arrg
[01:21] <slangasek> Peaker: so the question we've jumped right over, why are you rebuilding the python package?
[01:21] <Peaker> slangasek: I thought it would be a quick way to test a source-level change I was contemplating
[01:22] <Peaker> a bug that has been annoying me for more than a year now, I think
[01:23] <slangasek> ah, well, good reason :)
[01:23] <azeem> Peaker: so a bug that annoyed your for more than a year is not worth several hours of unattended cpu cycles?
[01:23] <azeem> you*
[01:23] <Peaker> azeem: it makes the debug/test cycle quite a long one
[01:23] <Peaker> and its unnecessary :P
[01:23] <azeem> Peaker: you don't need to start over each time I assume
[01:24] <slangasek> well, yes; in that case, call ./debian/rules build, and don't bother moving things into packages after each test cycle?
[01:24] <slangasek> s/after/for/
[01:24] <kees> Peaker: did DEB_BUILD_OPTIONS=nocheck debuild ....  not work?
[01:24] <slangasek> assuming that debian/rules build isn't the part that's getting stuck in the testsuite, that is
[01:24] <Peaker> slangasek: does that avoid running the unit tests like DEB_BUILD_OPTIONS=nocheck does? or is that env-var still necessary?
[01:24] <Peaker> kees: I haven't tried yet - I thought it would be wiser to let it finish building (I am not sure whether that was the right thing)
[01:25] <azeem> Peaker: check debian/rules
[01:25] <slangasek> you would still want to set that var, to be safe
[01:25] <slangasek> or check, yes
[01:25] <azeem> depends on whether they are run by build or binary
[01:25] <kees> slangasek: fortify_source appears to be redirecting the syslog calls away from syslog.o
[01:26] <kees> +                 U __syslog_chk@@GLIBC_2.4
[01:26] <kees> +                 U __vfprintf_chk@@GLIBC_2.3.4
[01:26] <kees>                   U __vsprintf_chk@@GLIBC_2.3.4
[01:26] <kees> +                 U __vsyslog_chk@@GLIBC_2.4
[01:28] <slangasek> ahh
[01:28] <kees> at least, that's my guess
[01:28] <slangasek> doh, I was staring so hard at openlog, I didn't think to look at syslog
[01:28] <slangasek> yes, that stands to reason
[01:30] <kees> slangasek: shall I upload it with that fixed?
[01:31] <slangasek> just adding -U_FORTIFY_SOURCE for klogd.o?
[01:31] <kees> yup.
[01:31] <slangasek> yeah, go for it
[01:35] <kees> donions
[01:35] <slangasek> thanks
[01:36] <kees> sorry for the glitch.  I blame everything on fortify_source first.  ;)
[01:36] <slangasek> heh
[01:36] <slangasek> thing was, I /knew/ about syslog_chk because I'd seen it in objdumps, and didn't think to look for a local syslog() implementation to go with the openlog one... :)
[01:38] <kees> yeah, kind of a twisted source, klogd.  :P
[01:40] <kees> now if only I could fix firefox to run with fortify_source....
[01:40]  * slangasek grins
[02:42] <wgrant> Aw, who changed "Yes, do as I say" to "I am aware that this is a very bad idea"?
[03:53] <NCommander> Morning (or evening) wgrant
[04:10] <wgrant> NCommander: Early afternoon, NCommander.
[04:11] <NCommander> wgrant, I'm timezone challenged ;-)
[04:19] <NCommander> wgrant, can I call on you to sponsor a FTBFS fix?
[04:36] <slangasek> wgrant: hmm, in apt-get ?
[04:38] <wgrant> slangasek: Yes.
[04:38] <slangasek> aww
[04:39] <wgrant> NCommander: Perhaps; depends how big it is. I'm mildly busy at the moment.
[04:39] <NCommander> wgrant, relatively small debdiff, maybe 30 lines
[04:39] <wgrant> I'd recommend going through the usual u-u-s mechanism.
[04:40]  * NCommander will wait then
[04:40] <NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/alsaplayer/+bug/262581
[04:42] <Awsoonn> Is there a better place to talk about intrepid?
[04:46] <Awsoonn> are there any known issues wiht the latest intrepid kernel and the nvidia drivers?
[04:46] <wgrant> A friend of mine had to remove and reinstall nvidia-177 to get it working.
[04:46] <wgrant> But it apparently does work.
[04:46] <Awsoonn> wgrant: any logs or other data i should grab before doing that?
[04:47] <Awsoonn> thing that might be usefull to whoever works on that.. bryce maybe?
[04:47] <wgrant> That's probably tseliot's domain.
[04:48]  * Awsoonn wonders if he's around
[04:56] <NCommander> wgrant, could you reset the build records on postfix on all architectures? Soyuz goofed and marked it failed vs. dep-wait.
[04:57] <wgrant> That sounds mainish.
[04:57] <wgrant> I'm not a core-dev.
[04:57] <NCommander> I thought you were
[04:57]  * NCommander hides
[05:00] <NCommander> ScottK, are you around?
[05:00] <ScottK> Breifly
[05:00] <ScottK> Briefly even
[05:00] <NCommander> Can I ask you to retry a build on Postfix?
[05:01] <NCommander> (soyuz failed to mark it dep-wait and failed it instead)
[05:01] <ScottK> Is mysql fixed?
[05:01] <NCommander> yeah
[05:01] <NCommander> I'm going through the build failure logs trying to find the ones that are dep-waits that are resolved vs. actual failures
[05:01] <ScottK> Sure.  I'll try one arch and we'll see what happens.
[05:01] <NCommander> Got to get that FTBFS count down ;-)
[05:02]  * NCommander wants zero FTBFS if possible ;-)
[05:02] <ScottK> Queued for retry.
[05:02] <ScottK> I did amd64
[05:02] <NCommander> THanks Scott
[05:02]  * NCommander continues working on FTBFS fixes
[05:08] <NCommander> ScottK, can you reset the build record on amarok-kde4 on sparc? It bombed with Bus Failure, so it seems that is a transient failure
[05:09] <NCommander> hola LucidFox
[05:10] <ScottK> Postfix worked.  Let me do the other archs fist.  Please give me a link for amarok-kde4
[05:10] <NCommander> ScottK, http://launchpadlibrarian.net/16999884/buildlog_ubuntu-intrepid-sparc.amarok-kde4_1.90-0ubuntu1_FAILEDTOBUILD.txt.gz
[05:10] <NCommander> Ideally, I'd like to resolve every single FTBFS in main :-)
[05:11] <ScottK> NCommander: I need the package page, not the build log.
[05:11] <NCommander> oh, d'oh
[05:11] <NCommander> ScottK, https://edge.launchpad.net/ubuntu/+source/amarok-kde4
[05:12]  * ScottK loks
[05:12] <ScottK> looks
[05:12] <ScottK> What about hppa?
[05:12] <NCommander> Also, kde4bindings is another misidentified dep-wait, which was cleared (dep-wait python-qt4)
[05:13] <NCommander> I keep the hppa tab hidden on qa's page
[05:13] <NCommander> hold on
[05:13] <NCommander> HPPA should be dep-wait, I'm not sure all the dependencies are in place
[05:13] <ScottK> NCommander: If it's depwait and not FTBFS it'll take care of itself in time.
[05:13] <NCommander> it does?
[05:14] <NCommander> Wait
[05:14] <NCommander> No, it should be dep-wait
[05:14] <NCommander> but its not
[05:14] <ScottK> Sure.  Depwait will undepwait and build in turn.
[05:14] <ScottK> hppa was FTBFS.
[05:14] <NCommander> Looking at the log, its dep-wait
[05:14] <NCommander> Or it should be
[05:14] <NCommander> It failed because not all its build-deps were installable
[05:14] <ScottK> Yes.  I wonder about that, but that's how it works.
[05:15] <ScottK> build-deps missing or insufficient version you get depwait.  Not installable, you get FTBFS.
[05:15] <NCommander> It's a limitation in sbuild
[05:15] <ScottK> I don't understand why we would want that.
[05:15] <NCommander> Which I think is due to a limitation in apt-get
[05:16]  * ScottK wonders if there's already a bug in soyuz on that.
[05:16] <NCommander> Well, I'm asking cprov, because I know where changes have to be made in both apt-get, and sbuild to trigger the correct behavior
[05:16] <wgrant> There's been a bug about it for some time.
[05:17] <NCommander> From the way I understand it, the dep-wait status is triggered by sbuild's return code
[05:17] <NCommander> I guess log-parsing determines what should be dep-waited on
[05:20] <wgrant> Bug #160439
[05:20] <ScottK> Fixing that would be high on my soyuz list.
[05:20] <NCommander> Yup
[05:20] <ScottK> If, of course, I'd been asked for a soyuz input.
[05:20] <NCommander> What's MANUALDEPWAIT
[05:20] <NCommander> I assume that means the build is just randomly retried vs waiting for a specific dependency
[05:22] <wgrant> NCommander: I don't know why the MANUAL bit is there.
[05:22] <wgrant> It's automatically retried when the missing build-depends appear.
[05:22] <NCommander> Well, I know on Debian dep-wait is a status we, as buildd-maintainers have to set packages to automatically
[05:22] <NCommander> I assume SOyuz is smart enough to determine proper dep-waits
[05:22] <wgrant> Correct.
[05:23] <NCommander> ScottK, https://edge.launchpad.net/ubuntu/+source/pigment - care running this one on amd64?
[05:23] <NCommander> (a lot of these FTBFS are dep-wait mistakes)
[05:24] <ScottK> Yes.  To get kde3.5.10 to build it took a LOT of retries due to this problem.
[05:24] <NCommander> kdeutils also needs it on all archs expect HPPA
[05:26] <NCommander> ScottK, https://edge.launchpad.net/ubuntu/intrepid/+source/kvkbd/0.5.99-0ubuntu1 - here too
[05:27] <NCommander> ugh, your kidding, logwatch is still broken
[05:28] <ScottK> NCommander: Done.  I'm off to bed.
[05:29] <NCommander> Thanks
[06:25] <moquist> my package (moodle) depends on moodle-postgres | moodle-mysql, and I'm writing separate postinst scripts for moodle, moodle-postgres, and moodle-mysql, which come from the same src pkg. moodle.postinst creates a config file that differs depending on whether moodle-postgres or moodle-mysql is installed.
[06:26] <moquist> I don't know how I can (appropriately, non-hackishly) known in moodle.postinst which database is being used, without asking the user (which is an extra question that the user might get wrong, anyway).
[06:26] <moquist> slangasek: I'm not going to put something in debconf that I can look up later, but that's the best way I can think to do this. :\
[06:27] <moquist> ...or I could try to be clever and detect which database has been created...but that seems ridiculously over-complicated and error-prone.
[06:41] <moquist> ogra: ping
[06:47] <Eleaf> pong
[07:38] <slangasek> moquist: you might want to look into wwwconfig-common
[07:40] <moquist> this is in main; wwwconfig-common isn't allowed IIRC
[07:41] <moquist> slangasek: I'm in the process of implmenting this using shared/moodle/db_<param>, and db_setting shared/moodle/db_server in moodle-<dbtype>.config...should I just stop now? :\
[07:42] <slangasek> wwwconfig-common isn't currently present in main; that doesn't mean that it's better to reinvent the wheel if a solution exists that could be pulled in to main
[07:42] <slangasek> I don't know if wwwconfig-common is considered unsuitable for main for some reason, but I think it's worth investigating
[07:43] <moquist> slangasek: it is.
[07:43] <slangasek> it is what? unsuitable for main?
[07:43] <moquist> slangasek: the whole reason I ever touched this package in the first place was to get rid of the dep on wwwconfig-common (in gutsy days)
[07:43] <moquist> yeah, unsuitable for main
[07:43] <slangasek> hrm
[07:43] <slangasek> why is it unsuitable?
[07:43] <moquist> I don't know that.
[07:45] <moquist> ogra might know more details; he got me started
[07:46] <moquist> slangasek: I'll just finish what I'm doing and post it for review. at least I'll learn something from this, even if I end up undoing things.
[12:06] <NCommander> Is there anyone who can retry universe builds for me?
[12:27] <NCommander> Riddell, ping?
[12:47] <Riddell> hi NCommander
[12:48] <NCommander> Riddell, could you retry kdebindings? I've been running down FTBFS all morning, that one is a dep-wait misidentified as a failure :-)
[12:50] <Riddell> what's that script called for retrying?
[12:51] <NCommander> buildd
[12:51] <NCommander> ALso dovecot if I can get main retrys out of you
[12:51] <NCommander> (I've sorta been torturing MOTU for the universe all morning ;-))
[12:53] <Riddell> NCommander: done
[12:53] <NCommander> Riddell, thank you
[12:53]  * NCommander hates transient failures
[12:57] <NCommander> RainCT, as an aside, your update maintainer script broke on updating the changelog in intrepid
[13:02] <RainCT> NCommander: uhm.. here it works. which error did you get? (and it's not mine, although I may have contributed to it)
[13:02] <NCommander> no error
[13:02] <NCommander> RainCT, its your name in the man file
[13:03] <NCommander> Just no changelog entry
[13:03] <RainCT> NCommander: "and this *manual page* by Siegfried"
[13:03] <NCommander> whoops
[13:03]  * NCommander slinks away
[13:05] <RainCT> NCommander: and it doesn't add the changelog entry anymore. that was discussed in ubuntu-motu@ and it was decided(?) that it isn't necessary anymore to document that in the changelog file
[13:05] <NCommander> oh
[13:05] <NCommander> bah
[13:05] <NCommander> Ok
[13:05] <NCommander> Stupid question, what preprocessor symbol is defined on Linux
[13:45] <NCommander> Riddell, you'll be happy to know that with the exception of lpia (and dep-wait on hppa), it appears kdebindings4 now properly builds on at least amd64/i386
[13:46] <Riddell> yay
[13:46] <NCommander> Riddell, I'm working on resolving the FTBFS on koffice, which appears to be longstanding
[13:51]  * NCommander is going to try and get the FTBFS count on amd64/i486 to under 20, and the other architectures to be under 50 within universe (and main if any are still left there)
[13:57] <NCommander> Riddell, BTW, where can I file bugs for changes to P-a-s?
[13:59] <geser> NCommander: see the comment in P-a-s who to contact
[14:01] <NCommander> I saw that
[14:01] <NCommander> There is no Ubuntu specific P-a-s, is there
[14:01] <NCommander> Mostly cause I can't see ubuntu specific packages getting in there like linux-lpia
[14:01] <Riddell> P-a-s?
[14:02] <NCommander> Packages-arch-specific
[14:02] <NCommander> It tells the buildds what not to build.
[14:02] <geser> NCommander: no, Debian and Ubuntu share a common P-a-s
[14:02] <NCommander> bah
[14:24] <crevette> hello
[14:25] <crevette> is a Feature freeze request is necessary for package in universe ?
[14:26] <azeem> universe is handled in #ubuntu-motu I believe
[14:26] <crevette> I would like to request a sync for nemiver
[14:26] <crevette> okay
[14:26] <crevette> thanks
[14:26] <NCommander> Riddell, do you know where I can download buildd chroots? I'm going to try and squash the SCons + buildd issue
[15:12] <asac> tjaalton: libGL error: dlopen /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: undefined symbol: _glapi_tls_Context)
[15:12] <asac> tjaalton: (me trying X1950 with ati -> direct rendering: no)
[15:13] <asac> tjaalton: doest it mean we have the wrong version of something?
[15:23] <jcristau> asac: it means you have incompatible versions of the dri driver and libGL or X
[15:24] <asac> jcristau: ok. so why do i get that in intrepid atM?
[15:25] <asac> is there an upload pending?
[15:27] <jcristau> you shouldn't get that
[15:27] <asac> but i do ;)
[15:27] <jcristau> libGL.so.1 and /usr/lib/xorg/modules/extensions/libglx.so should export _glapi_tls_Context
[15:28] <jcristau> unless you've replaced one of them with the fglrx version, or something
[15:28] <asac> ok ... lets check if that is diverted
[15:29] <asac> cool
[15:29] <asac> at least i had it installed ... which explains it i guess
[15:39] <asac> jcristau: no success
[15:39] <asac> still the same thing
[15:47] <jcristau> asac: something's wrong, then :)
[15:53] <asac> jcristau:  nm -D /usr/lib/xorg/modules/extensions/libglx.so |grep tls
[15:53] <asac><PHONE_NUMBER>000008 B _glapi_tls_Context
[15:53] <asac><PHONE_NUMBER>000000 D _glapi_tls_Dispatch
[15:56] <asac> ok i think i have an idea
[16:00] <asac> jcristau: ok i had clutter in /usr/lib/xorg/
[16:00] <asac> thx
[17:08] <kees> asac, fta: I think I found the problems with xulrunner/firefox's misuse of realpath() (it wasn't setting MAXPATHLEN correctly)  I've got the debdiffs in bug #263014 that fix it for me (I can run and use firefox with FORTIFY_SOURCE enabled).  Can you review it and let me know it qualifies for upload?
[17:09] <fta> kees, we have a patch in upstream bugzilla for a while
[17:09] <fta> hold on, let me check
[17:10] <fta> mozilla bug 412610
[17:10] <azeem> uh
[17:11] <azeem> glibc's realpath() can deal without MAXPATHLEN, no?
[17:12] <fta> kees, i expected this upstream patch to be committed long ago, that why i didn't use the patch. then i forgot about it :P
[17:13] <fta> but upstream is not sure about the best approach
[17:13] <fta> kees, btw, it's more widespread than you debdiff, there are several places where this MAXPATHLEN is needed.
[17:13] <fta> youR
[17:14] <fta> (and also several packages)
[18:10] <kees> fta: ah, yeah, the upstream RH patch looks more complete -- can we use that?  I'd really like to actually fix the root causes since they are real issues.
[18:10] <kees> fta: actually, the last patch looks very close to mine: https://bugzilla.mozilla.org/attachment.cgi?id=335369
[18:10] <fta> kees, sure, I will grab the patch and merge it.
[18:11] <kees> fta: and please revert the -U_FORTI...
[18:11] <fta> yes
[18:12]  * kees hugs fta
[18:15] <fta> :)
[18:16] <kees> fta: did you report the "cvs" problem too?  I can't find any notes on FORTIFY in "cvs" or "mozilla-devscripts".
[18:17] <fta> i didn't, just in the wiki. it seems the problem disappeared since.
[18:18] <kees> ah, very good.  I will drop it from the wiki for now then.
[18:25] <fta> tseliot, this bug 259808 is killing me. Seems i'm not alone to have issues with 177.70
[18:26] <kees> fta: shall I assign you to 263014?
[18:26] <fta> kees, yes please
[18:26] <kees> fta: cool, done
[18:28] <tseliot> fta: can you try with kernel 2.6.26 +177.70 and see if it solves the problem? If it doesn't you should report the problem to NVIDIA
[18:30] <tseliot> actually, either way you should report to nvidia: http://www.nvnews.net/vbulletin/forumdisplay.php?f=14
[18:52] <fta> tseliot, reported to nvidia.
[18:53] <tseliot> fta: great, I hope they fix it before they release the driver as stable
[18:56] <fta> tseliot, could I use 177.68 with 2.6.27-2 ?
[18:57] <tseliot> fta: yes, sure
[21:31] <fta> tseliot, it doesn't make any sense: I tried all variations of kernel 2.6.26-5 / 2.6.27-2 and nvidia 173.14.12 / 177.70, Xorg locks with mplayer/xv (not to mention corrupted consoles, corrupted display, corrupted boot splash, dead keyboard/mouse when gdm is doing autologin) Yet, i only started to see those X locks today with 2.6.27-2 & 177.70.. now it's everywhere. It has to be something else.
[21:34] <leszek> hi
[21:35] <leszek> where can I found the config / python file  where the default filesystem is set by ubiquity / partman !?
[21:36] <leszek> is it in /home/leszek/Downloads/live/edit/usr/lib/ubiquity/ubiquity/components/partman.py !?
[21:38] <leszek> aynone any idea on this partman default system question ?!
[21:48] <leszek> anyone awake !?
[21:51] <jpds> leszek: http://jldugger.livejournal.com/16594.html
[21:52] <leszek> :)
[21:57] <tseliot> fta: can you try with both the "vesa" driver and the "nv" driver? Just to make sure that it's a driver problem and not hardware problem
[22:09] <cjwatson> leszek: it's not configurable, nor is it in python; it's set in shell code in /lib/partman/free_space/50new/do_option
[22:09] <cjwatson> (in several places; it's not particularly designed to be easy to change that right now)
[22:10] <cjwatson> leszek: p.s. don't reask your question three times in a 13-minute interval, please. It's excessive
[22:10] <leszek> sry
[22:11] <leszek> and thx ;)
[22:12] <cjwatson> leszek: although as far as ubiquity's UI is concerned, the default for a new partition is effectively the first in numeric order in /lib/partman/valid_filesystems/, I suppose
[22:12] <cjwatson> that might be easier to customise
[22:15] <leszek> ah ok thx


[08:21] <Saviq> pstolowski, the "search" part from https://wiki.ubuntu.com/Process/Merges/TestPlan/Unity8%20-%20Manage%20Dash can go away now, right?
[08:21] <pstolowski> Saviq, right, I forgot to update
[08:22] <Saviq> pstolowski, nw
[08:24] <pstolowski> thanks
[09:01] <tsdgeos> pstolowski: can you update the silo with my new branch? it has merges from trunk
[09:03] <pstolowski> tsdgeos, sure
[09:27] <Saviq> greyback, I kinda hijacked your qtmir branches for cmake, might wanna look through the latest changes
[09:27] <Saviq> greyback, also adding cmake-extras to the silo
[09:27] <greyback> Saviq: so I've observed
[09:28] <Saviq> greyback, seems -gles was really behind on debian/control changes, too...
[09:28] <Saviq> we need to do a better job there
[09:32]  * tsdgeos does evil eyes to unity-scopes- click for not using -j10 even if told to
[09:33] <tsdgeos> Saviq: Cimi: who is reviewing https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524 ?
[09:33] <greyback> Saviq: your OCD in debian/control showing :)
[09:33] <Saviq> greyback, wrap-and-sort -at
[09:33] <Saviq> greyback, but yeah, there's some of that
[09:34]  * greyback learns new command
[09:34] <Saviq> greyback, unfortunately it breaks comments
[09:34] <Saviq> greyback, so some manual love is needed afterwards
[09:34] <Saviq> but once it's done it's easy to keep sorted
[09:34] <Cimi> tsdgeos, I can
[09:35] <tsdgeos> Cimi: cool :)
[09:39] <Saviq> tsdgeos, see you found a scapegoat
[09:40] <tsdgeos> pstolowski: there?
[09:41] <Cimi> greyback, found an issue with shell rotation
[09:41] <pstolowski> tsdgeos, yes
[09:41] <greyback> Cimi: go on
[09:41] <Cimi> greyback, open gallery that is a fullscreen app
[09:41] <Cimi> greyback, power button to lock screen
[09:42] <Cimi> greyback, power to wake
[09:42] <Cimi> greyback, unlock
[09:42] <tsdgeos> pstolowski: i've tested that branch you gave me yesterday
[09:42] <Saviq> greyback, ok all that looks promising
[09:42] <Cimi> see a slow animation from greeter to gallery fullscreen
[09:42] <tsdgeos> and yes, if dash is in "utilities" and i go to the store, it ends in in "all" not in "utilities"
[09:42] <tsdgeos> but that's what scope.currentNavigationId is saying
[09:43] <greyback> Cimi: please add to our bug-tracking spreadsheet: https://docs.google.com/a/canonical.com/spreadsheets/d/140Icn5zcZwMvg1SONrwRKXYip-Pie7jtbEARpWwgxfw/edit#gid=0
[09:43] <tsdgeos> pstolowski: maybe scopes-shell needs changing? or the scope? how do i debug what the scope think it's returning as current navigation id?
[09:45] <greyback> Saviq: thanks for the help there.
[09:45] <pstolowski> tsdgeos, the scope get current nav id with search request (and you can tell it's ok looking at the search results). i think what's important is what shell thinks is the current nav id. I think you can get it via a property of Scope
[09:46] <Saviq> greyback, pleasure
[09:46] <tsdgeos> pstolowski: that's exactly what i am sayiing
[09:46] <tsdgeos> pstolowski: that property says it's all
[09:46] <pstolowski> tsdgeos, ah sorry, missed one sentence
[09:47] <pstolowski> tsdgeos, hmm, maybe plugin has a bug then
[09:47] <pstolowski> tsdgeos, ok, i'll debug the plugin and see
[09:47] <pstolowski> tsdgeos, thanks for looking at it
[09:48] <tsdgeos> no worries :) tell me if you need me to have a look at it again or something
[09:51] <Cimi> tsdgeos, added a comment
[09:51] <Cimi> greyback, added bug
[09:55] <greyback> Cimi: thanks
[09:55] <tsdgeos> Cimi: answered
[09:55] <greyback> Cimi: that's on phone, right?
[09:56] <Cimi> greyback, mako
[09:56] <greyback> Cimi: we have that bug on trunk right now actually
[10:09] <Cimi> tsdgeos, if cacheBuffer is int, shouldn't setCacheBuffer accept int and not qreal?
[10:10] <tsdgeos> Cimi: that sounds sensible
[10:10] <tsdgeos> let me fix it
[10:12] <Cimi> tsdgeos, also, when we add a negative cacheBuffer, shall we set 0 or not? what qt does when properties are set wrongly?
[10:12] <tsdgeos> the same
[10:12] <tsdgeos> ./qquickitemview.cpp:458:        qmlInfo(this) << "Cannot set a negative cache buffer";
[10:12] <Cimi> ok
[10:43] <pstolowski> tsdgeos, i'm getting plenty of "QGridLayoutEngine::addItem: Cell (0, 0) already taken" messages in unity8-dash.log; known?
[10:43] <Cimi> greyback, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1398770
[10:45] <tsdgeos> pstolowski: yeah, i've seen them too, don't seem to cause problems tbh
[10:45] <tsdgeos> but may be worth investigating more
[10:46] <greyback> Cimi: thank, but I marked as duplicate of bug 1398770
[10:46] <pstolowski> tsdgeos, ack
[10:46] <tsdgeos> pstolowski: i'll make a note here to investigate it
[10:48] <pstolowski> tsdgeos, k, thanks
[11:03] <Saviq> greyback, hmm I broke -gles somehow
[11:04] <Saviq> can't get the build deps resolved
[11:04]  * greyback looks
[11:06] <Saviq> huh
[11:06] <tsdgeos> Cimi: ok, pushed
[11:07] <Saviq> greyback, ok it's the libqt5gui5-gles dep
[11:07] <greyback> you removed it?
[11:07] <Saviq> greyback, yeah, and I tried that first
[11:07] <Saviq> greyback, but somehow sbuild still couldn't resolve ¿?
[11:07] <Saviq> but apt-get build-dep did
[11:07] <greyback> huh
[11:09] <Saviq> greyback, the test dep seems not needed though
[11:09] <Saviq> no wait, checking again
[11:09] <Saviq> yeah
[11:10] <Saviq> verifying
[11:11] <Saviq> ok that's not good, apt-get seems to resolve everything fine, but not sbuild
[11:14] <facundobatista> Holas
[11:17] <greyback> Saviq: doesn't sbuild use an apt-based resolver to determine dependencies (by default)?
[11:17] <Saviq> greyback, yeah, but not build-dep, but a dummy package (what mk-build-deps does)
[11:18] <greyback> ah
[11:19] <Saviq> greyback, hmm, TBH I might've broken something locally, can't get it to work on trunk either...
[11:20] <Saviq> *or* something broke with qt
[11:21]  * Saviq adds the dep blindly
[11:56] <mzanetti> tsdgeos: I don't think this conflicts, if you merge it with the prereq, not with trunk: https://code.launchpad.net/~mzanetti/unity8/buttons-in-panel/+merge/242644
[11:57] <mzanetti> anyways... merge it neverthelles
[11:57] <mzanetti> -l+s
[11:58] <mzanetti> ok. let's try again:
[11:58] <mzanetti> anyways... merged it nevertheless
[11:58] <mzanetti> :)
[12:03] <pstolowski> tsdgeos, i've found the issue with current department id in shell plugin which could be reset to default depending on timing (we had a race); i've a fix, with it looks correct now, but i don't see any siblings (my modified scope now reports all departments all the time now)
[12:04] <pstolowski> tsdgeos, so it can be now another issue with navigation models in the plugin (i'm not familiar too much with that yet), or uniyt8
[12:09] <Cimi> tsdgeos, when you calculate displayMarginBeginning and End, you use a lot of - signs
[12:09] <Cimi> tsdgeos, looks like it can be simplified
[12:10] <Cimi> mmm maybe not because they are min and max...
[12:11] <Cimi> I got the logic after
[12:19] <Saviq> greyback, ok yeah, libqt5gui5-gles and libqt5quicktest5 are indeed required, it's building in the PPA now
[12:20] <Saviq> greyback, don't ask me why it didn't work in my sbuild :/
[12:20] <greyback> Saviq: ok good. /me was also fighting with my sbuild
[12:20] <Saviq> and would be nice if we understood why those are needed, and maybe get rid of them (or at least comment)
[12:21] <Saviq> Mirv, hey, if you look at the build failures in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-001/+sourcepub/4600234/+listing-archive-extra
[12:21] <Saviq> Mirv, I had to add libqt5gui5-gles and libqt5quicktest5 to B-Ds for the builder to resolve deps
[12:22] <Saviq> Mirv, any idea why's that and what could we do about it (or do we just wait for runtime GL detection instead?)
[12:47] <Mirv> Saviq: hmm, no, I don't know why it would change in any way from what it used to be in the past. but it would look like to me the previous landing also already had them both? https://launchpadlibrarian.net/191126103/qtmir-gles_0.4.4%2B15.04.20141124-0ubuntu1.diff.gz
[12:48] <Saviq> Mirv, oh yeah, it was like that for a while
[12:48] <Saviq> Mirv, I was just doing some clean up
[12:48] <Saviq> and was wondering if we know where this comes from
[12:54] <Mirv> Saviq: r_salveti understands the gles packages best. my simple guess is that the "or" dependencies cause the need to specify some -gles package separately even when compiling against qtbase5-gles-dev. for example UI Toolkit depends on qt5-qmake-gles, qt5-qmake-gles, qtbase5-private-gles-dev and libqt5quick5-gles
[12:54] <Mirv> and that has been since the first gles version of that https://launchpadlibrarian.net/175113669/ubuntu-ui-toolkit-gles_0.1.46%2B14.10.20140502.6-0ubuntu2.diff.gz
[12:55] <Mirv> Saviq: maybe if you depended on qt5-qmake-gles, qt5-qmake-gles, qtbase5-private-gles-dev, you wouldn't need the libqt5gui5-gles
[12:55] <Mirv> but that isn't any cleaner
[12:55] <Saviq> Mirv, yeah
[13:59] <tsdgeos> mzanetti: i think the issue was that the prereq didn't merge, and thus all the dependents didn't either
[14:00] <tsdgeos> mzanetti: failing qmluitests in https://code.launchpad.net/~mzanetti/unity8/wallpaper/+merge/242461 ?
[14:30] <kgunn> bug 1367822
[14:35] <mterry> Cimi, the wizard is basically ready to go in a silo -- you can test it if you like, vivid silo 3 -- just needs an approve on the tests branch
[14:37] <mzanetti> tsdgeos: there isn't much chance that its related to that branch though
[14:38] <tsdgeos> mzanetti: no?
[14:38] <tsdgeos> mzanetti: seems the only branch with this failure i could find
[14:38] <mzanetti> tsdgeos: doesn't touch neither that code, nor that test
[14:39] <tsdgeos> let me see if i can repro
[14:39] <mzanetti> tsdgeos: I had fixed some flakyness of that test yesterday in another branch though
[14:40] <mzanetti> let me see if it got merged yet
[14:40] <mzanetti> yeah, it's merged
[14:40] <mzanetti> with the reversible-spread branch... exactly this was failing too
[14:42] <mzanetti> actually its a bit different
[14:42] <mzanetti> yesterday it was failing in <position1, now it's failing in >position3
[14:42] <mzanetti> will dig into it, but I'm sure it's not related to that wallpaper branch
[15:40] <balloons> mzanetti, I noticed the desktop-next iso allows you to install from the store without issue. And in general it's a bit different than the unity8 vm setup . .  Any idea why this is? I assume there is an RTM branch of unity8 as well as a vivid branch (perhaps more), but I would expect the image and installed versions to line up
[15:41] <mzanetti> balloons: I think it's related to some packagekit plugin/config which differs on a standard desktop
[15:42] <mzanetti> but I'm not exactly sure what it is
[15:45] <balloons> hmm... I'll try the latest lxc version as well. Might be a bit confusing to folks. I'm anxiously waiting for your desktop-stage branch to land
[15:51] <mzanetti> hah! I love to see one high-dpi fix coming in after another :D
[15:51] <mzanetti> as of today my screensaver is full screen again :D
[16:18] <mterry> Cimi, I made vivid silo 3 with all the wizard stuff, if you want to test again.  Just needs the tests branch to be approved and we can land
[16:19] <Cimi> mterry, yup, saw
[16:19] <mterry> Cimi, ok I thought I sent that earlier, but couldn't find it in my scrollback
[16:19] <Cimi> mterry, you did yup
[16:19] <mterry> :)
[16:19] <mterry> my damn internet connection has been crazy today, thought IRC ate it
[16:19] <Cimi> mterry, was having lunch then we had standup
[16:20] <Cimi> mterry, so I didn't reply
[16:20] <mterry> sure
[16:20] <Cimi> mterry, but I was already having a look earleir to the code
[16:51] <mzanetti> balloons: the branches are approved by now
[16:51] <mzanetti> balloons: so unless I messed up and broke something that'll be caught in the silo review, they should go in with the next batch
[16:52] <balloons> mzanetti, excellent. That will be a big boost to using it on the desktop. I'm sitting on a post waiting for it
[16:53] <mzanetti> O_o
[16:53] <mzanetti> I hope that post says that it's not finished yet, but rather a start of a long process
[16:54] <balloons> basically yes. I want to push people to using it on the desktop. I'd like to personally run it as a daily driver this cycle and convince some others to do the same. No pressure :-)
[16:54] <balloons> for now, it's just testing
[17:10] <Cimi> mterry, still one test to fix
[17:11] <mterry> cimi, uh oh which one?
[17:11] <Cimi> mterry, test_locationHereTerms
[17:11] <Cimi> mterry, could be for the " " check?
[17:13] <mterry> cimi, I don't get that failure.  is that local or in jenkins?
[17:14] <Cimi> mterry, jenkins
[17:14] <mterry> cimi, ah!  I only noticed the PhoneStage::test_enterSpread  failure
[17:14] <Cimi> https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/187/testReport/(root)/qmltestrunner/Wizard__test_locationHereTerms/
[17:15] <mterry> cimi, yeah I see it now
[17:15] <mterry> cimi, am looking, thanks.  duh
[17:15] <mterry> cimi, I bet it's because assigning 1i8n.language = "fr" doesn't do what I want if the french locale isn't setup
[17:16] <Cimi> ok..
[17:18] <mterry> oh actually, it's because Ubuntu.Web isn't installed
[17:23] <mterry> cimi, done
[17:23] <Cimi> mterry, let's wait jenkins then we can approve
[17:23] <mterry> cimi, yeah definitely, it's catching dep stuff that I wouldn't notice  :)
[18:13]  * mterry goes afk for a bit
[19:01] <mterry> Cimi, looks like wizard tests passed, yay!  (I was worried there would be some other dep needed)
[19:07] <Cimi> mterry, i'll approve soon
[22:49] <veebers> Saviq: What do you know about the edge demo? I have some queries, mainly can I start it with testability :-)
[22:50] <Saviq> veebers, not really, it's being redesigned, so will get a rework
[22:50] <Saviq> veebers, mterry knows best
[22:51] <veebers> Saviq: ok cool, so that's both first boot wizard and the edges demo that's getting reworked? (I'll ping mterry too)
[22:51] <Saviq> veebers, to some extent, yes, wizard is being moved into the unity8 tree right now
[22:52] <veebers> Saviq: ok, one more question :-) Any idea of when the rework for the edges demo will be complete/usable
[22:52] <Saviq> veebers, https://code.launchpad.net/~mterry/unity8/wizard-import/+merge/242245 and https://code.launchpad.net/~mterry/unity8/wizard-plugin/+merge/241912 and https://code.launchpad.net/~mterry/unity8/wizard-tests/+merge/242525
[22:52] <Saviq> veebers, there's no final design yet, so dunno
[22:52] <veebers> Saviq: cool, thanks for the info
[22:53] <Saviq> veebers, if you want to have a look, here's the design docs, but WiP still https://sites.google.com/a/canonical.com/apps-and-platform-team/3-platform/6-greeter
[22:56] <veebers> Saviq: fyi, we're looking at automating some of the sanity tests. I'm keen to get something for the demo, even if it's getting changed in the future.
[22:56] <Saviq> veebers, I understand, just saying don't spend much time on getting them Right™, clean and everything
[22:57] <Saviq> veebers, for now dirty is good enough
[22:58] <veebers> Saviq: heh, ack :-)


[22:59] <spridel> illunatic: depends on the channel.  austin, dallas, and houston all have channels iirc
[23:11] <illunatic> ah
[23:11] <illunatic> austin here


[02:38] <gooslap> Hi, is anyone online?
[07:19] <Sysi> ssds work and should keep working for years even without any tweaking, it's world of choices you have problems with :)
[07:54] <xnox> bug 1059083 not sure if this is lightdm problem or xubuntu specific.
[07:54] <xnox> are you using lightdm?!
[07:54]  * xnox is out of touch
[07:54] <ochosi> yup, we are
[07:54] <xnox> lightdm it is.
[07:55] <ochosi> suprising that this doesn't work, shouldn't it simply do the same thing in ubuntu and xubuntu?
[07:55] <astraljava> I suppose we had some settings for that, maybe something broke.
[07:56] <Sysi> I think that worked for me..
[07:56] <xnox> considering that my lightdm login is "funny" with massive spinning circles, I would not be surprised if it was lightdm regression.... or change of api..... or something like that.
[07:57] <ochosi> xnox: does this affect ubuntu as well?
[07:57] <Sysi> I used amd64
[07:57] <xnox> ochosi: no clue. Haven't tested yet. Just going through my bug mail.
[12:03] <knome> g'day
[12:04] <elfy> hi knome
[12:04] <knome> hello elfy
[12:04]  * elfy needs to get his around this qa thing - got somewhere simple for him to start?
[12:05] <knome> astraljava is quite a simple person...
[12:05] <elfy> :)
[12:05] <knome> what is it what you are specifically wondering about?
[12:05] <elfy> that'll be 2 of us then
[12:05] <elfy> what it is I'm supposed to be doing :D
[12:06] <knome> heh, ok so:
[12:06] <knome> first of all, make sure you announce mailing lists when we have milestone releases coming up
[12:07] <elfy> yep
[12:07] <knome> the second one is to attend the weekly QA meeting
[12:07] <knome> i got to say i have no idea what time that is...
[12:07] <knome> but astraljava will tell you
[12:07] <elfy> ok - I can find out - I talk to balloons anyway
[12:08] <knome> looks like it's wednesdays 14UTC
[12:08] <knome> and if there's something specific to report, report it back to us
[12:08] <elfy> right - not too onerous then :)
[12:09] <knome> no, not really
[12:09] <knome> then there's this one thing
[12:09] <knome> that we still need to get fixed
[12:09] <knome> the weekly reports to the release team
[12:10] <knome> i'm ok to do that, but that implies that people should really update the team reports
[12:10] <elfy> ok
[12:10] <knome> https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001846.html
[12:10] <knome> that's our last weekly mail, sent in august :P
[12:11] <knome> but those are the things that we need to report
[12:11] <knome> if you have ideas how we can make this reporting more effective..
[12:12] <elfy> I'll have a think knome - so at present - people tell you and then you report to release team?
[12:13]  * smartboyhw finds that the "not-sending-the-release-mail" isn
[12:13] <knome> elfy, well, no...
[12:13] <smartboyhw> that serious for Xubuntu, Ubuntu Studio's problem is bigger:P
[12:13] <knome> elfy, people doesn't tell me, and when we've sent the mail, the person who sent it finds out what has been done himself
[12:13] <knome> elfy, astraljava has been sending those mails mostly
[12:13] <elfy> ok
[12:14] <knome> elfy, our last "team report", which would be *really useful* for this, is from 2011
[12:14] <knome> https://wiki.ubuntu.com/Xubuntu/TeamReports/
[12:14] <smartboyhw> knome: Wow that is long
[12:15]  * smartboyhw thinks the last "team report" for Studio is about 4 years ago:P
[12:15] <elfy> knome: ok - I'll have a think about that then
[12:16] <knome> elfy, i was thinking if something @IRC would work...
[12:17] <elfy> yep probably - so the kind of thing that needs reporting is stuff that gets mentioned in meetings and from bugs etc
[12:18] <elfy> I'll talk to astraljava
[12:18] <smartboyhw> elfy, this might be useful
[12:18] <smartboyhw> https://wiki.ubuntu.com/ReleaseTeam/Meeting/Agenda/TeamTemplate
[12:18] <elfy> ty
[12:19] <knome> yep, that's the template
[12:19] <knome> elfy, anyway, don't geel *obliged* to do it if you don't want to :)
[12:20] <smartboyhw> elfy, you are luckier than me that knome got the testcases rewritten before you become QA contact, I have to do the tiring job:P
[12:20] <elfy> oh - I'm happy to do it knome - I'd not have said I would if I didn't want to :)
[12:20] <knome> elfy, ok, thanks :)
[12:21] <elfy> welcome :)
[12:22] <smartboyhw> :)
[12:22] <elfy> knome: got my new machine - didn't need to worry about uefi etc - just moved the drives, turned it on and carried on as normal
[12:22] <knome> hihi, good
[12:22] <knome> laptop/desktop?
[12:23]  * smartboyhw thinks UEFI is a bunch of **** developed by Microsoft who clearly does not know what is F/OSS
[12:23] <elfy> desktop - hate laptops - always end up with cramp from the touchpad things lol
[12:23] <elfy> was a barebones thing - no drives no OS
[12:23]  * smartboyhw is using a laptop to do EVERYTHING including testing:P
[12:23] <knome> they have their pros and cons
[12:24] <elfy> yep
[13:22] <astraljava> What does elfy need to talk to me about?
[13:22] <smartboyhw> astraljava, how to be a QA contact person:P
[13:23] <knome> astraljava, qa meetings, probably sending mails to release team
[13:23] <astraljava> knome: Aren't you sending those emails?
[13:24]  * smartboyhw now sends mails to release team after getting scott's permission:P
[13:25] <astraljava> But that's over on Studio's side.
[13:25] <knome> astraljava, well, i should be sending, but seriously talking, we should get stuff in order before anybody can send those reliably
[13:25] <knome> astraljava, i'm talking about team reporting
[13:26] <astraljava> Hmm... yet another email template, then?
[13:26] <knome> no, not anything like that
[13:26] <knome> internal reporting
[13:26] <knome> the one who sends the mail to release team should know what people have been up to
[13:27] <knome> and shouldn't really do the detective work
[13:28] <astraljava> Err... well, have fun trying to keep all that in mind.
[13:28] <astraljava> They expect to have a list of bugs being worked on, for instance. Can you keep those numbers all in your head?
[13:28] <knome> well exactly.
[13:28] <knome> no, i can't
[13:28] <astraljava> There you go then. :)
[13:29] <astraljava> That's why my inbox exploded, cause I wanted to keep all bug mail during the week, until report was sent.
[13:29] <knome> there should be a better way to track those bugs and items
[13:30] <astraljava> Also, [release]-changes ML was damn easy to pick the changed packages from, too.
[13:30] <knome> hmm?
[13:30] <astraljava> If you come up with any, by all means.
[13:30] <knome> i'm thinking the reporting could be tied to the work items tracking
[13:30] <knome> because we need to do that anyway, and i can see how we benefit from that
[13:31] <knome> if a work item is INPROGRESS, the team works on it, aight?
[13:31] <astraljava> Not all bugs directly relate to a work item on blueprints.
[13:31] <knome> that's true, but they should all be linked to the blueprints
[13:32] <knome> and if their status isn't fix committed/fix released, they are still worked on, unless they are new/triaged or so, when they're still... new
[13:32] <astraljava> I'm not at all sure you'd want to include all bugs to blueprints.
[13:32] <astraljava> I know I wouldn't.
[13:32] <astraljava> But you're... strange.
[13:32] <knome> why wouldn't you link all bugs you are workig on that contribute towards a blueprint?
[13:32] <knome> +n
[13:33] <astraljava> Well I suppose then you'd have an obligatory "Improve QA" blueprint for every release.
[13:34] <knome> not a problem: https://blueprints.launchpad.net/ubuntu/+spec/other-r-xubuntu-bugs
[13:34] <astraljava> Ok. Somebody has to update that blueprint throughout the release, then, to make sure that every new bug gets added.
[13:34] <astraljava> Volunteers?
[13:34] <astraljava> Oh, I know.
[13:34] <astraljava> ELFY!
[13:34] <knome> i mean, creating and maintaining one more blueprint isn't too bad, if that means we'll get the team reports done
[13:34] <knome> :P
[13:34] <knome> no, i don't mean *any new bug in xubuntu*
[13:35] <knome> because we don't need to track bugs we aren't working on
[13:35] <astraljava> Those are the bugs I meant when I said I wouldn't want all bugs into blueprints.
[13:35] <knome> if somebody starts looking at a bug, or is working on it, link it then
[13:35] <astraljava> Oh.
[13:35] <astraljava> Fine.
[13:35] <knome> oh. yeah, i don't want them in blueprints too
[13:35] <knome> s/too/either/
[13:36] <astraljava> Ok. You know how Lionel will feel about this change in the process, right? :)
[13:36] <knome> since we only need to report those we are working on, it's not too hard to track them under blueprints
[13:36] <knome> yes, i know, but i've been managing the blueprints anyway
[13:36] <knome> and i don't think it's a huge burden
[13:37] <knome> if you have time to look at the bug, or work with it, maybe you will have time to link it, or tell somebody to do that
[13:37] <astraljava> When you're battling 140+ bugs a release...
[13:37] <knome> we haven't been reporting those bugs to the release team before
[13:37] <knome> and i'm not sure what the policy should be on what is reported
[13:37] <astraljava> I did, for a brief period of time, anyway. :)
[13:38] <knome> yeah, thanks for that
[13:38] <knome> but the list per mail wasn't >10
[13:38] <knome> maybe i/we should talk with skaet
[13:38] <astraljava> But I think I was pretty much alone in that. Don't think many teams shared that hobby with me.
[13:38] <smartboyhw> Hey elgy astraljava is here
[13:39] <knome> "why do we have to report these, since you can simply look at our work items tracker"
[13:39] <smartboyhw> *oops hey elfy
[13:39] <knome> if a bug isn't worth mentioning in a blueprint, why would it be worth mentioning in the mail to release team?
[13:39] <knome> i mean, i can't see these *not* walking hand in hand
[13:39] <astraljava> Oh it would totally eliminate the need to do that, if they _were_ actually tracked somewhere.
[13:40] <astraljava> Currently _this was_ the tracking process.
[13:40] <astraljava> ...or _is_, rather.
[13:40] <astraljava> But then we're not really categorizing our bugs, either.
[13:41] <astraljava> I'm pretty sure the release team is actually interested about release blocker bugs anyway.
[13:41] <knome> +only
[13:41]  * smartboyhw is sucking in all those contents:P
[13:41] <astraljava> But since our work flow was lacking in this department (too?), it was clearer for me to report them all.
[13:41] <knome> but, don't you agree that these two procedures are just duplicating each other?
[13:42] <astraljava> Yea, I just said so a few lines above. :)
[13:42] <knome> yep, so that one is sorted out
[13:42] <astraljava> ACK
[13:42] <knome> meh, "what was done engineering wise"
[13:42] <smartboyhw> :P
[13:42] <knome> i think that's the worst question ever
[13:42] <smartboyhw> knome: +1
[13:42] <knome> what does that "engineering" mean really?
[13:43] <smartboyhw> Dunno. Maybe some new features?
[13:43]  * smartboyhw suggests going to #ubuntu-release to ask that question:P
[13:43] <smartboyhw> Oops;P
[13:45] <astraljava> knome: That was easy, pick up the new uploaded packages from -changes.
[13:45] <astraljava> No one ever complained about that method.
[13:45] <astraljava> It's actually stuff that matters, too. Versioning of packages in the archives.
[13:46] <astraljava> Not so much of Xubuntu's packages, of course, as not many (anyone?) depend on them.
[13:46] <astraljava> But still, from the release-team-POV, it's useful information.
[13:47] <astraljava> And for us, it's usually a no-brainer. Just pick the ones where uploader is either Lionel or Micah. :)
[13:47] <smartboyhw> lol
[13:47] <astraljava> Of course Micah uploads other packages when acting as a PP.
[13:48] <astraljava> But you get the idea.
[13:52] <knome> yeah.
[13:53] <knome> so, there's the "what did you do?" and "what bugs did you work on?" which are sorted
[13:53] <knome> now, what's about to land blah is trivial too, once you have those done
[13:53] <knome> and the dependencies/blocking/concerns too
[13:53] <astraljava> Yep, most often that was a "N/A" for us.
[13:53]  * elfy wonders if this conversation is about what I was being told earlier
[13:54] <knome> elfy, yeah, we're talking about the mails to the release team
[13:54] <elfy> if it is - I missed the beginning :p
[13:54] <smartboyhw> elfy: Yes:P
[13:54] <knome> elfy, i'll paste you
[13:54] <elfy> thanks knome
[13:55] <knome> elfy, http://paste.ubuntu.com/1253911/
[13:58] <elfy> ta
[13:59] <knome> np
[17:19] <philballew> Anyone wanna run a xubuntu session in open week in a little less then a month?
[21:04] <ailo_> I'm having a bit of problem with editing the menu. Added a submenu, more or less like here http://wiki.xfce.org/howto/customize-menu#create_sub-menus. And looking at other edits, I can't see what's different with mine. The problem I'm having..
[21:05] <ailo_> The submenu is named after its parent, instead of <Name>Myname</Name>
[21:06] <ailo_> To clarify, the submenu is displaying its parents name in the actual menu, while in the file, I'm using a custom name with <Name>Myname</Name>
[21:06] <ailo_> If I use <Layout>.., and inside it <Menuname>, using the custom menu name, I still see the parents name displayed
[21:20] <ailo_> Well, I've realized the <Directory> needs to exist somewhere


[11:35] <BluesKaj> 'Morning folks
[11:57] <guest82892348> i have installed the plasma5 packages from the next ppa - some bugs but all in all it's already usable - thanks for that!
[11:57] <guest82892348> should i make bug reports against these packages and if yes where?
[11:58] <shadeslayer> guest82892348: is something wrong in the packaging?
[11:58] <shadeslayer> or just the software
[11:59] <guest82892348> i guess most problems come from the software
[11:59] <guest82892348> so you mean software related bugs directly to kde and packaging problems to kubuntu?
[12:00] <shadeslayer> yes
[12:01] <guest82892348> ok then I will make some good quality bug reports, thank you
[20:47] <guest378273> is it possible to contribute to kubuntu packaging like on github?  -  fork / commit / pull request
[20:48] <guest378273> or is there another easy way? if I would like to propose a solution to a packaging bug?
[20:55] <yofel> guest378273: sure, just branch one of our packaging repositories, push to your own branch on launchpad and make a merge request
[20:55] <guest378273> ok will try that now :)
[21:01] <Riddell> it's in bzr rather than git, but if you know svn it's easy to use bzr
[21:01] <Riddell> you can also just send diffs manually if you want
[21:23] <soee_> someone tried unicorn with plasma-next lately? I have tested on VM and looks ok, some bugs with plasma but nice. Wonder how it works on laptops etc :)
[21:30] <Riddell> working ok for me
[21:30] <Riddell> plenty of issues but mostly it works
[21:33] <soee_> Riddell: issues in plamsa or system ?
[21:37] <Riddell> plasma
[21:37] <Riddell> can just kill it worst case
[21:37] <guest378273> ok i made a branch of plasma-workspace (next), made a change and pushed it to my own LP branch
[21:38] <guest378273> how do i make the merge request?
[21:39] <Riddell> can't remmeber but there's a button somewhere, google will know
[21:41] <guest378273> just found it... you have to go to the original branch...
[21:43] <soee_> Riddell: did you tried upgrade 14.04 -> 14.10 ?
[21:59] <guest378273> just submitted my first merge request :)
[22:26] <Riddell> soee_: yes, dist-upgrade worked fine
[22:31] <Riddell> guest378273: merged, thanks :)
[22:31] <yofel> soee_: you might hit a bunch of overwrite errors on dist-upgrade, we'll fix those with 4.14 beta1
[22:31] <soee_> yofel: when is it planed ? :)
[22:32] <yofel> early july I believe
[23:11] <soee_> yofel: also those overwrite errors might bbreak system upgrade /
[23:11] <soee_> ?
[23:13] <Riddell> just force them if you get them
[23:13] <Riddell> dpkg --install --force-overwrite /path/to/.deb


[03:11]  * Linden940 is away: going to go play with the dragon
[15:29]  * Linden940 is back (gone 12:17:50)


[12:13] <Mirv> hmm
[12:15] <profoX`> How is upstart linked to teardown? is teardown integrated in upstart now?
[12:17] <mrmojo> is there plans for a GUI bug reporter in feisty?
[12:18] <mrmojo> something like goto system --> report bug or similar, it would come up with a little program which woudl allow you to take a screenshot, add a few details and quickly publish a bug
[12:37] <imbrandon> wouldent work out well as you need to search for already reported bugs similar to yours ( but most dont think about that it seems by some of the dupes )
[12:44] <profoX`> imbrandon: the way kde bugreports work is that it automatically searches for possible related bugs after you type in a title and some keywords of your bug before actually writing the bugreport
[12:46] <profoX`> imbrandon: a gui program could also show that by using a wizard, first enter a title and some keywords, and then show possible matches.. click on a match to open the bug report in your browser.. and have a button to cancel the bugreport or to continue writing it..
[12:48] <AngryElf> what's the logic in not having specific branches of the kernel anymore? i.e. now there is just 'generic'
[12:48] <mdke__> you'll find a long thread about it on the -devel mailing list
[01:08] <imbrandon> profoX`: true, if it was done right :)
[01:09] <profoX`> imbrandon: yes, but when's the last time we did something wrong ^^
[01:09] <profoX`> j/k
[01:09] <imbrandon> :)
[01:27] <jdong> cjwatson: what are your feelings as to -backports building against -updates?
[01:27] <jdong> cjwatson: for cases like bug 63452
[01:27] <Ubugtu> Malone bug 63452 in Baltix "Please backport brasero CD burning tool from Ubuntu Edgy" [Low,Confirmed]  http://launchpad.net/bugs/63452
[01:41] <sid> elkbuntu: Do you have the results for the last Ubuntu poll?
[02:32] <sladen> what's the build tool that splits off the .po files for the language packs
[02:41] <Evaso2> hi guys anybody developing launchpad is here?
[02:42] <sladen> Evaso2: #launchpad
[02:42] <Evaso2> sladen: thanks
[02:47] <Nafallo> sladen: package-strip-translations? :-)
[02:48] <Nafallo> pkgstriptranslations even
[02:53] <sladen> nafallo: ta
[02:32] <rmjb> Hello cjwatson, I'd like to get some advice on putting through an SRU for a broken universe package
[02:33] <Burgundavia> rmjb: which package?
[02:33] <rmjb> dmrid
[02:33] <rmjb> dmraid
[02:34] <Burgundavia> rmjb: file a bug with your patch attachedc
[02:34] <rmjb> https://launchpad.net/distros/ubuntu/+source/dmraid/+bug/68294
[02:34] <Ubugtu> Malone bug 68294 in dmraid "[SRU]  Freeze Exception Request for dmraid" [Medium,Unconfirmed]
[02:34] <rmjb> and https://launchpad.net/distros/ubuntu/+source/dmraid/+bug/54246
[02:34] <Ubugtu> Malone bug 54246 in dmraid "DMRAID stopped to work in kernels > 2.6.15" [Undecided,In progress]
[02:34] <rmjb> the last one had the deb and source packages
[02:35] <rmjb> s/had/has/
[02:35] <Burgundavia> ah
[02:38] <Burgundavia> rmjb: is dmraid completely broken? that is not clear from the bug report
[02:39] <rmjb> I'm not sure, I've seen two people in the forum thread say it works for them on edgy, but lots more say it doesn't
[02:39] <rmjb> upgrading usually works
[02:39] <Burgundavia> ok, in order for that SRU to pass, you need more than that
[02:40] <Burgundavia> detail those forum reports
[02:40] <rmjb> do universe SRUs follow this same process: https://wiki.ubuntu.com/StableReleaseUpdates
[02:40] <rmjb> ?
[02:40] <Burgundavia> yes
[02:40] <Burgundavia> afaik
[02:41] <Burgundavia> the rules are a little lighter because it is universe
[02:41] <rmjb> I'll need to file a new bug or the UVFe one is enough?
[02:41] <rmjb> once I get more info I can just reassign it to... mdz?
[02:42] <Burgundavia> the latter, no idea
[02:42] <Burgundavia> the one you have it probably good enough
[02:42] <Burgundavia> just change the title
[02:42] <Burgundavia> oh wait, you have already done that
[02:42] <rmjb> it's that next step that has me confused
[02:42] <Burgundavia> which one?
[02:42] <rmjb> dholbach did
[02:42] <Burgundavia> the actual SRU?
[02:42] <rmjb> what to do now... has be confused
[02:42] <rmjb> yeah
[02:43] <Burgundavia> you at the SRU page?
[02:43] <rmjb> yep
[02:43] <Burgundavia> in the propose stage
[02:43] <Burgundavia> you have a bug number
[02:43] <Burgundavia> you need a better statement about impact
[02:43] <Burgundavia> ie: edgy's dmraid doesn't work
[02:43] <Burgundavia> period
[02:44] <Burgundavia> here are the people that have tried it
[02:47] <Burgundavia> rmjb: here is what I would also do
[02:47] <Burgundavia> rmjb: get the latest dmraid into feisty
[02:47] <Burgundavia> asap
[02:47] <rmjb> feisty is out??
[02:47] <Burgundavia> archives are open
[02:47] <Burgundavia> no idea about general uploading
[02:48] <rmjb> need to talk to an motu to get it in there then
[02:48] <Burgundavia> but back to the SRU
[02:49] <Hobbsee> Burgundavia: toolchain is still building.  general uploads next week or so, was the guess
[02:49] <Burgundavia> Hobbsee: ah
[02:50] <Burgundavia> rmjb: anyway, you have about 50% of what you need for the propose phase
[02:50] <Burgundavia> of course, IANAUD
[02:50] <rmjb> I'm going to link to the thread that has the users' reports: http://ubuntuforums.org/showthread.php?t=266807
[02:58] <rmjb_> dmraid was broken for 8 users in the thread
[03:08] <rmjb_> Burgundavia: I've updated the SRU bug, should I assign it to an SRU team?
[03:08] <Burgundavia> rmjb_: no idea
[03:09] <rmjb_> yeah... me neither... the report looks better now?
[03:09] <rmjb_> #68294
[03:23] <Fujitsu> rmjb: motu-uvf is the team for SRUS.
[03:23] <Fujitsu> *SRUs
[03:24] <rmjb> so it's at the right assignee then... cool
[03:25] <Flk> mjg59: heard ur had a night of drunken debuachery yesterday lol :P
[03:37] <jdub> having switched on WPA on my AP, i now understand why people like/want pam-keyring
[05:04] <rmjb> hello I'm looking for advice on packaging a java app
[05:04] <rmjb> I have the dependency to java-gcj-compat-dev right now, is that right?
[05:04] <rmjb> or can it be replaced with something "slimmer"?
[05:16] <Burgundavia> rmjb: you need to talk to doko
[05:23] <rmjb> thanks Burgundavia
[05:23] <Burgundavia> no worries
[12:01] <ukubuntu> If feisty is to be more about integrating multimedia, is it going to include codecs etc? I notice that Freespire, a derivative of lispire has these in its core install, but I do not know how they got around the legal aspect of codecs in non-proprietary software
[12:02] <Hobbsee> include codecs?  no.  maybe download them from somewhere
[12:02] <bhale> the only way to distribute most codecs legally is to obtain a paid license
[12:02] <mdke> ukubuntu: the idea is to make them easier to install
[12:02] <apokryphos> like ximian team did with helix
[12:03] <mdke> semi-automatically
[12:03] <ukubuntu> Ok, I know I use easybuntu to help at the moment,
[12:03] <mdke> hopefully even easier than that
[12:03] <bhale> fluendo, the company behind gstreamer, is working on license-able plugins for gstreamer
[12:03] <bhale> for a small fee
[12:03] <ukubuntu> kewl :)
[12:04] <bhale> they are giving away an mp3 decoder
[12:04] <ukubuntu> I see.
[12:04] <ukubuntu> Obviously the ultimate is to make it real easy for the non-tech user if possible
[12:06] <ukubuntu> And just a quick thanks to all involved in Ubuntu, it continues to astound me :)
[12:06] <bhale> rock on
[12:06] <ukubuntu> I am sure you have heard it before, but it does not hurt to reiterate :D
[12:21] <Czubek> when is planned to unfreeze feisty?
[12:27] <Hobbsee> Czubek: a week after the last person asked
[12:28] <Czubek> Hobbsee: 5 XI?
[01:05] <fabbione> Czubek: when the toolchain is ready
[01:06] <Czubek> fabbione: What?
[01:09] <Czubek> fabbione: You mean something like this: https://wiki.ubuntu.com/FeistyToolchainRoadmap?highlight=%28toolchain%29
[01:10] <fabbione> Czubek: i mean new kernel, new glibc, new binutils, new gcc
[01:10] <fabbione> and a test rebuild of the archive before we open the gates
[01:11] <Czubek> Yes, so it's written on wiki, thanks.
[01:22] <Czubek> Is, there any wiki for this specification: https://features.launchpad.net/distros/ubuntu/+spec/network-roaming ? Or should I create one from template?
[03:08] <mark> what's the best way to preseed/skip all the "detect keyboard layout" bits in Edgy?
[03:10] <bddebian> Howdy
[03:47] <shackan> uh oh, it.archive.ubuntu.com seems down
[03:52] <mark> and kr.* is not very stable...
[04:15] <highvoltage> hi. I can't find the ubuntu manifesto on the website. does it still exist?
[04:43] <gnomefreak> is it safe to remove libc6 to install the right version as long as you dont reboot?
[04:45] <yacoob> gnomefreak, I think it would be, as long as you do it in one go. Any new process created in between will fail.
[04:46] <yacoob> And because dpkg launches scripts... the answer is no I think :)
[04:46] <gnomefreak> ok ty
[04:47] <Amaranth> gnomefreak: yeah, you don't want to remove libc6 :P
[04:47] <Amaranth> i wonder how dpkg manages to upgrade it
[04:47] <tfheen> it unpacks it with .dpkg-new appended to the name, then renames it afterwards.
[04:48] <Amaranth> ah
[04:48] <Amaranth> i figured it was something like that
[05:37] <cjwatson> mark: preseed console-setup/layoutcode to the layout name (X-style), and if you want a keyboard variant, preseed console-setup/variantname too
[05:38] <cjwatson> mark: sorry, make that console-setup/variantcode
[05:38] <madduck> after dapper, you guys snapshotted sid; when did this happen, and under what conditions did you import new versions from sid to fix problems, and until when?
[05:40] <cjwatson> madduck: after every release, we merge everything from Debian; this process is continuous until upstream version freeze
[05:40] <cjwatson> (see EdgyReleaseSchedule in this specific case)
[05:41] <cjwatson> madduck: after UVF, we take new versions as it seems appropriate. Shortly after UVF, it's generally quite lenient, getting stricter as we approach release
[05:41] <cjwatson> the release team apply common sense
[05:42] <yacoob> hm
[05:42] <yacoob> linux lacks something like growl for mac osx
[05:43] <tfheen> yacoob: what is growl?
[05:43] <yacoob> tfheen, pop-up system. One demon to display them, any application can register and throw message to be displayed
[05:43] <yacoob> various styles, fully configurable
[05:44] <yacoob> it gained critical mass, so most of the apps already come with growl support
[05:44] <tfheen> yacoob: like, the notification daemon?
[05:44] <yacoob> something like that I think.
[05:44] <tfheen> which lives in.. the notification-daemon package. :-P
[05:44] <shackan> notification-daemon is already there..
[05:44] <Arador> it's something done by apple, or a third-party app?
[05:45] <yacoob> Arador, third party
[05:45] <yacoob> shackan, the thing is, not enough support. Still :)
[05:45] <tfheen> I have plenty enough of notifications, thankyouverymuch.
[05:50] <Amaranth> indeed, i get too many as it is :P
[06:25] <MrKeuner> hi, what else do I need other than build-essential in order to create deb packages?
[06:25] <cjwatson> the build-dependencies of the package in question
[06:25] <MrKeuner> dpkg-parsechangelog: error: cannot open debian/changelog to find format: No such file or directory
[06:25] <MrKeuner> dpkg-buildpackage: unable to determine source package is
[06:25] <MrKeuner> why do I get these?
[06:25] <cjwatson> once you have build-essential installed, you can run 'dpkg-checkbuilddeps' in an unpacked source package to see what's missing, or use 'apt-get build-dep <package>'
[06:26] <cjwatson> MrKeuner: because you haven't cd'ed to the right directory
[06:26] <cjwatson> assuming you just unpacked a source package and are trying to build it
[06:26] <cjwatson> if you're trying to create your own package, then you need to read more :-)
[06:27] <MrKeuner> I am trying to compile amyedit, unpacking it and entering the directory with configure script etc. and then running dh_make && dpkg-buildpackage -rfakeroot
[06:27] <jdong> cjwatson: would you object to Backports compiling against -updates in addition to -backports?
[06:28] <cjwatson> MrKeuner: then you need to read more documentation about creating packages
[06:28] <cjwatson> dh_make is not intended to be used without manually checking its output
[06:28] <cjwatson> it's not entirely automagic
[06:28] <cjwatson> jdong: I don't think so, no
[06:28] <jdong> cjwatson: where should I go to further advance this proposal?
[06:29] <cjwatson> jdong: talk to infinity
[06:29] <jdong> ok
[06:30] <MrKeuner> hmm, dh_make output says that: Could not find amyedit_1.0.orig.tar.gz can that be due to missing packages to be installed?
[06:30] <MrKeuner> Or OK could you direct me to a good resource for self compilers
[06:41] <simira> cjwatson: the people wants photos of your labraweiler!
[06:42] <Treenaks> s/the people/simira/
[06:42] <Treenaks> :P
[06:43] <imbrandon> !package guide
[06:43] <mc44> hmm would it be a good idea to tell people "no, bad user" if they try and apt-get dist-upgrade
[06:43] <imbrandon> hum dosent work in here, MrKeuner "/msg ubotu package guide" for the url
[06:53] <madduck> cjwatson: why did you guys then stay with mdadm 2.4.1-6 or edgy, and not follow the 2.5 chain? because of the one-month-in-experimental period?
[06:54] <madduck> i think my work of the last 4 months fixes many of your raid problems with edgy...
[06:54] <madduck> anyway, i better call it a night.
[07:01] <jordi> does anyone know of cases of ubuntu not going back one hour last night?
[07:03] <Treenaks> no
[07:03] <Treenaks> maybe if people set the wrong time zone..
[08:10] <ajmitch> morning all
[08:29] <aragorn_elessar> hi at all!
[08:31] <aragorn_elessar> it's normal that the "disks" entry is absent in the System-->Administration menu of edgy ?
[08:46] <Seveas> aragorn_elessar, this channel is not for support
[08:46] <Seveas> try #ubuntu
[09:39] <cjwatson_> simira: once I find the camera :-)
[09:40] <cjwatson_> madduck: we'll take it in feisty. Mostly, we eyeballed it post-UVF and it just seemed to have too high a volume of changes that we didn't have the in-house expertise to review accurately and which might well have required consequent changes elsewhere
[09:50] <amnezia> having found some issues while upgrading to edgy, should I file bugs against something or should I talk to someone first about those?
[09:52] <tepsipakki> amnezia: look for duplicates first
[09:56] <elmo> ugh - we ended up releasing with an ndiswrapper-utils in edgy that's << dapper?
[09:58] <cjwatson> elmo: I couldn't see any way to fix it
[09:59] <cjwatson> given the Depends generated by the module source in dapper
[10:01] <tfheen> cjwatson: we could have transitioned the -utils package to be generated by ndiswrapper-utils1.8?
[10:01] <cjwatson> tfheen: AIUI the module source package in dapper produced binaries that had a tight << Depends on ndiswrapper-utils which shafted us
[10:02] <tfheen> gnr, og
[10:02] <tfheen> ok, even
[10:02] <cjwatson> I don't remember all the details now (they were really slippery) but I looked at it at the time and couldn't see anything remotely sane to do :(
[10:02] <tfheen> ok
[10:02] <cjwatson> aside from "document and pray we never run into this again"
[10:02] <tfheen> can we do anything remotely sane for feisty?
[10:03] <cjwatson> it shouldn't be a problem for feisty any more?
[10:03] <cjwatson> well, apart from the lingering future problem of dapper->next-LTS upgrades, but I was hoping we could just teach the dist-upgrader to do the downgrade if necessary
[10:03] <tfheen> yeah, that's doable
[10:03] <cjwatson> ndiswrapper-utils is supposed to be transitional now and will eventually go away, I'm told
[10:03] <tfheen> (we do it for some compiz bits, at least)
[10:04] <cjwatson> that's for the benefit of unofficial repositories, but yeah
[10:08] <elmo> should I file a bug about it so we don't forget?
[10:08] <tfheen> elmo: yes, please.  And milestone it "later" so we don't end up forgetting
[10:08] <cjwatson> elmo: for what, the dist-upgrader?
[10:08] <elmo> cjwatson: yeah
[10:09] <cjwatson> IIRC it's already in mvo's branch (he tried to upload it before freeze but there were too many other changes and it got refused), but sure
[10:09] <cjwatson> IIRC is not necessarily reliable of course
[10:09] <elmo> err, heh
[10:09] <elmo> bug 45550
[10:10] <Ubugtu> Malone bug 45550 in ndiswrapper "Broken dependency of kernel module" [Medium,Unconfirmed]  http://launchpad.net/bugs/45550
[10:10] <cjwatson> yow
[10:10] <cjwatson> heh, so nobody could've been using those modules anyway
[10:10] <cjwatson> whoops
[10:11] <cjwatson> 33 "later" bugs - eek
[10:12] <tfheen> cjwatson: that's not too bad, really.
[10:14] <elmo> reported as bug 69158 in any event
[10:14] <Ubugtu> Malone bug 69158 in ndiswrapper "ndiswrapper-utils downgraded from dapper" [Undecided,Confirmed]  http://launchpad.net/bugs/69158
[10:14] <elmo> (hmm, I wish there was a way to hyperlink bugs in malone..)
[10:15] <tfheen> I think it linkifies "bug #1234"
[10:15] <Ubugtu> Bug 1234 on http://launchpad.net/bugs/1234 is private
[10:15] <tfheen> heh
[10:16] <elmo> haha, that's a great bug too
[10:38] <kingos>  hello, is there a plan to release a new version of binutils for edgy? I am a c++ developer, and there is an important bug in binutils (3111) that makes edgy almost unuseable for development ...
[10:40] <tfheen> kingos: uh, which bug is that?
[10:40] <tfheen> bug 3111 is about something else entirely
[10:40] <Ubugtu> Malone bug 3111 in launchpad-buildd "Use gzip python library instead of sys call for compressing buildlogs" [Medium,In progress]  http://launchpad.net/bugs/3111
[10:42] <Chipzz> kingos: weird that the buildd's don't have much trouble building c++ packages then?
[10:43] <kingos> tfheen: binutils 3111
[10:43] <kingos> Chipzz: only if linking with -g
[10:43] <kingos> Chipzz: ie. development!
[10:43] <Chipzz> kingos: that's what the buildd's do, yes
[10:44] <kingos><EMAIL_ADDRESS>[10:45] <kingos> I am seeing that bug and it is super annoying ... linking took 5 seconds on dapper, 3-4 minutes on edgy
[10:45] <tfheen> "ld being slow" isn't something we'd issue an update for, no.
[10:45] <kingos> argh
[10:45] <kingos> so what are my options?
[10:45] <tfheen> use the dapper binutils?
[10:46] <Chipzz> being patient? :P
[10:47] <kingos> tfheen: can I force install an old binutils or something? won't that break everything?
[10:47] <tfheen> kingos: why would that break anything?  Just downgrade.
[10:50] <kingos> tfheen: thanks
[11:55] <madduck> cjwatson: fair enough. i'll look at mdadm with fabbione for feisty. I agree that 2.5 had too many changes, I spent a shitload of time on it. :)


 Happy Wednesday, and happy Freedom Day! 😃
[10:00] <MooDoo> howdy all
[10:07] <zmoylan-pi> i thought today was check your backup day?
[10:09] <foobarry> for gitlab
[10:31] <popey> http://checkyourbackups.work/
[10:47] <diplo> After the week before lasts issues with my work.. they've supposedly been doing that
[10:47] <diplo> Went on to one of the sites they'd checked... they didn't check very well :P
[11:05] <SuperMatt> What I find the most troubling about the GitLab issue, is that they only had *one* replica of the database
[11:12] <TwistedLucidity> One? That's ∞% more than some people
[11:14] <SuperMatt> hah
[11:42] <davmor2> Azelphur: did you have a recent update to the drivers?   I'd like to know what are the hardware requirements for MAAS and Autopilot servers. Had a good look on ubuntu.com but can't see the info anywhere. Can someone point me in the right direction please?
[18:01] <daftykins> _MoBeats_: poor channel choice for support, message the bot 'alis' to find more appropriate channels - or visit #ubuntu direct.
[18:02] <_MoBeats_> thanks daftykins