[00:54] <superm1> lamont, what's broke about gtkpod?
[00:54] <superm1> i used it recently with no troubles
[01:57] <lamont> superm1: what's broke is that it's config says to run xmms to play a song...
[01:57] <lamont> so rather, it's my gtkpod config that's b0rked.
[03:43] <dbmood2> hi ah you guys have a google problem
[03:43] <dbmood2> put ubuntu logo into google
[03:43] <dbmood2> the first logo is fine the bother two really should not be there
[03:45] <ScottK> We don't really control what Google does.
[03:45] <dbmood2> ScottK: you can inform them about it
[03:45] <dbmood2> that is a real image problem
[03:46] <dbmood2> oh wait it is fine now ... weird
[04:04] <woli> how do i rsync 2 folders?
[04:06] <woli> is that part of ssh?
[04:07] <ScottK> rsync is a separate pacakge.
[04:07] <ScottK> You need to install it and then if you look at the man page, it should be reasonably clear.
[04:07] <ScottK> woli: #ubuntu is the channel for help.
[04:08] <woli> yes but nobody knows the answer
[04:08] <woli> ScottK, i already have rsync
[04:08] <ScottK> That doesn't make this a help channel.  I've already given you a pretty strong hint.
[04:08] <ScottK> Did you read man rsync?
[04:08] <woli> but when i do rsync motherFolder childFolder it returns 'skipping motherFolder'
[04:09] <woli> oops, i didn't know its existance. currently reading
[04:11] <woli> but can i rsync locally without specifying machine-name?
[04:20] <woli> well now i know how
[04:20] <woli> sorry for the channel noise
[06:43] <pitti> Good morning
[06:44] <StevenK> Morning pitti
[06:44] <pitti> hey StevenK!
[06:45] <Hobbsee> pitti!
[06:45] <Mithrandir> Hobbsee!
[06:45] <Hobbsee> Mithrandir!
[06:45]  * Hobbsee stomps on Mithrandir's feet in greeting
[06:47] <Mithrandir> good thing I levitated first.
[06:53] <Hobbsee> aww
[07:08] <superm1> pitti, i was talking to tseliot briefly about the last thing I need to add for fglrx's source package.  He mentioned that there is a modaliases list that comes with it normally so that jockey knows when it can activate things.  Currently it is shipped somewhere in /usr/share I believe in a kernel specific directory (since it comes with every LRM package).  Is there a generic place I can drop one instead and have the same effect?
[07:18] <Tm_T> hi kids
[07:22] <stgraber> moin
[07:31] <tjaalton> lamont: audacious is the xmms lookalike
[07:31] <tjaalton> and descendant
[07:58] <dholbach> good morning
[07:59] <Tm_T> indeed
[08:01] <pitti> superm1: yes, it is
[08:01] <pitti> superm1: /usr/share/linux-restricted-modules/`uname -r`/modules.alias.override/
[08:15] <mdke> dholbach: morning
[08:18] <dholbach> hi mdke
[09:38] <asac> pitti: did the lang pack builds go well? whats the ppa so i can test?
[09:39] <pitti> https://edge.launchpad.net/~ubuntu-langpack/+archive
[09:39]  * pitti tests now, too
[09:40] <pitti> asac: German and English ones are there, yes
[09:41] <pitti> asac: hm, updated language-pack-gnome-de, now my ffox is English
[09:41] <pitti> asac: the langpack does have the .jar and friends, though
[09:41] <asac> pitti: do you have RC1?
[09:41] <asac> xul+ffox?
[09:42] <pitti> asac: no, whatever is in hardy
[09:42] <asac> otherwise thats expected
[09:42] <pitti> beta5, I think
[09:42] <asac> pitti: yeah. thats fine then ... install RC1 from mozillateam ppa
[09:42] <asac> or let the batch into proposed
[09:42] <tseliot> pitti: would you pull your hair if we had more nvidia-modealiases packages (one for each driver flavour) e.g. ﻿nvidia-new-modealiases, etc. and perhaps different modealiases files in different folders?
[09:44] <tseliot> err... ﻿pull your hair out
[09:44] <asac> pitti: ok gnome-de works fine here
[09:45] <pitti> tseliot: sounds like a lot of clutter
[09:45] <pitti> tseliot: why should they go into different directories?
[09:45] <pitti> tseliot: /usr/share/linux-restricted-modules/`uname -r`/modules.alias.override/ was meant to be that one place
[09:45] <pitti> tseliot: they should go to different files in that directory
[09:45] <tseliot> ﻿pitti: we are going to have separate source codes and separate packages for the different flavours
[09:46] <pitti> tseliot: until we have an online db, this would be a reasonable compromise
[09:46] <tseliot> ﻿pitti: wouldn't /usr/share/modealiases/nvidia be a better place?
[09:46] <pitti> ("this" -> separate -modalias package)
[09:47] <pitti> tseliot: no, because then you need another meta-thing again which collects all those differnet directories
[09:47] <pitti> tseliot: I'm fine with renaming the dir, but it should be *one* common dir
[09:48] <tseliot> ﻿pitti: so ﻿using something like /usr/share/modealiases/ for any driver would be ok?
[09:48] <tseliot> and we would have something like ﻿ nvidia-new-modules.alias.override, etc.
[09:48] <pitti> tseliot: s/mode/mod', yes
[09:49] <tseliot> yes, mod stands for modules
[09:49] <pitti> tseliot: it probably doesn't need to be kernel abi specific any more then
[09:49] <tseliot> this is why I want to change the path to the modaliases
[09:50] <tseliot> pitti: if you agree with the use ﻿/usr/share/modealiases/ I can tell Mario about it
[09:51] <pitti> tseliot: modalias, not modealias
[09:51] <tseliot> sorry I copied and pasted the previous path
[09:51] <pitti> :)
[09:52] <tseliot> I won't mispell it in the package
[09:52] <tseliot> I promise :-P
[09:52] <pitti> superm1: just sent a reply with some more questions wrt. wl
[09:55] <asac> pitti: ok i tested fi es pt de fr ... look fine
[09:55] <pitti> nice
[09:56] <pitti> asac: I requested a full langpack export, I should have it tomorrow around noon
[09:57] <asac> pitti: ok. just wanted to ask if we want to roll them like they are now and do the move later. let me know what suites you better
[09:58] <pitti> asac: I'd prefer one update instead of two; can it wait until Thursday, or do we need it right nwo?
[09:59] <pitti> asac: the entire lot needs to be built on the non-PPA buildds anyway, so the diff is actually just one day
[09:59] <asac> pitti: ok. just wanted to tell you that i would be fine if we'd do the move in the next regular "fulL" update
[09:59] <pitti> ah, I see
[10:00] <asac> the benefit of pushing the move back to next regular update would be that we could let the RC1 batch in now and start SRU verification
[10:00] <pitti> well, given their current huge size, a -base refreshment makes sense now
[10:04] <asac> pitti: the things that would need to go in are http://paste.ubuntu.com/15026/
[10:04] <pitti> right, they are in the queue; I'll accept them tomorrow, together with the new langpacks
[10:04] <asac> good
[10:04] <asac> thanks
[10:05] <pitti> asac: why two devhelp uploads?
[10:05] <pitti> asac: or, rather, versions? the second one (0.19-1ubuntu1.8.04.2) should still be 0.19-1ubuntu1.8.04.1
[10:05] <pitti> since 8.04.1 was never accepted
[10:05] <pitti> (just a nitpick, though)
[10:06] <asac> pitti: cant remember the exact issue. can you see the changelog?
[10:06] <pitti> asac: rejecting the older broken one
[10:06] <pitti> http://launchpadlibrarian.net/14709944/devhelp_0.19-1ubuntu1.8.04.2_source.changes
[10:06] <asac> yep
[10:06] <pitti> 'fix glue code' was the addition
[10:06] <asac> right
[10:07] <asac> the other embedders i tested worked properly without a rebuild. But Ill try harder during verification to track regressions
[10:08] <asac> ArneGoetje: i installed language-packs for de, es, pt, fr, fi ... now i have this annoying SCIM thing again
[10:12] <soren> Could some apply some archive admin love to ubuntu-vm-builder in the hardy unapproved queue?
[10:13] <ArneGoetje> asac: should not happen
[10:13] <asac> ArneGoetje: what info do you need?
[10:13] <asac> ArneGoetje: maybe i have some old configuration?
[10:13] <ArneGoetje> asac: probably
[10:14] <asac> that was never automatically cleaned up?
[10:14] <ArneGoetje> asac: it should have been cleaned up
[10:14] <asac> ArneGoetje: yeah. so what info do you need?
[10:15] <asac> i had -de installed and it didn't show up... then i installed http://paste.ubuntu.com/15031/
[10:15] <ArneGoetje> asac: ls ~/.xinput/
[10:15] <asac> ArneGoetje: i only have .xinput.d
[10:16] <asac> there is en_US
[10:16] <ArneGoetje> asac: which locale do you use?
[10:16] <asac> ArneGoetje: i installed those packages and didn restart gnome
[10:16] <asac> ArneGoetje: i am on en_US by default
[10:17] <ArneGoetje> asac: as none of those packages depend on scim related software, I don't know why it triggered the problem again...
[10:18] <fabbione> seb128: ping?
[10:18] <ArneGoetje> asac: what is the output of im-switch -l ?
[10:18] <fabbione> seb128: a very generic gnome question.. i am trying to debug gdm.. and it looks like gdm+glib2.0 are really strictly requering kernel inotify support
[10:19] <fabbione> seb128: is there a way to disable it?
[10:19] <asac> ArneGoetje: http://paste.ubuntu.com/15035/
[10:19] <asac> hmm ... what is -th doing there
[10:20] <seb128> fabbione: hey, gdm requires inotify are you sure? that's weird, what version are you looking at there?
[10:22] <fabbione> seb128: i am looking at 2.22.
[10:23] <fabbione> seb128: there are tons of levels of indirections via g_io_add_watch(..) that boils down to a bunch of calls in glib2
[10:23] <fabbione> seb128: it seems that it uses inotify to create the user list to show at login
[10:23] <fabbione> seb128: or update it realtime if you add/remove a user
[10:24] <seb128> fabbione: I didn't look at gdm 2.22 yet, only redhat is using this one
[10:24] <fabbione> seb128: ok.. i thought you might know :) thanks
[10:24] <seb128> fabbione: do they use g_file_monitor?
[10:24] <fabbione> seb128: i am not.. i am debugging the filesystem underneath :)
[10:24] <ArneGoetje> asac: im-switch -z all_ALL -a and then paste the output of im-switch -l again
[10:24] <fabbione> seb128: basically gdm keeps restarting if /home is on gfs2
[10:25] <fabbione> seb128: and so far i found out that gdm/glib2 fail to set an inotify watch and then segfault a bit later
[10:26] <fabbione> seb128: so basically i am trying to collect info to understand why it craps out and prepare a decent bug report for gnome upstream and you are still my best source of gnome info :)
[10:26] <asac> ArneGoetje: http://paste.ubuntu.com/15040/
[10:28] <seb128> fabbione: the glib monitoring should just fall back to something else (dnotify, fam, etc) if inotify is not supported
[10:28] <ArneGoetje> asac: ok, try the same with sudo
[10:28] <fabbione> seb128: ok.. it might be the fallback is buggy....
[10:28] <fabbione> seb128: thanks a lot dude.. i really appreciate
[10:28] <asac> ArneGoetje: so its an alternative bug?
[10:29] <asac> ArneGoetje: e.g. status set to manual?
[10:29] <ArneGoetje> asac: yep
[10:29] <seb128> fabbione: you are welcome
[10:29] <asac> ArneGoetje: hmm
[10:30] <ArneGoetje> asac: the latest packages of scim and scim-bridge-agent should fix it
[10:31] <asac> ArneGoetje: latest as in 8.04 or -proposed?
[10:33] <ArneGoetje> asac: 8.04
[10:33] <ArneGoetje> asac: does calling it with sudo fix the problem?
[10:34] <asac> ArneGoetje: i think so its gone now :)
[10:36] <ArneGoetje> asac: then the issue on your system was, that we changed language-selector during hardy developent to store the im-switch setting in the user's home directory and not system wide anymore. Seems there was some leftover from the system wide setting on your system
[10:36] <asac> ok
[11:47] <davmor2> Guys quick query on sound juicer.  As Rhythmbox is now the default player and it rips cd's into it's library is sound juicer going to be phased out?
[11:50] <gnomefreak> davmor2: rythmbox isnt the same as sound juicer. rythmbox doesnt rip cds
[11:50] <pitti> davmor2: yes, we'll drop it from main and the default install
[11:50] <pitti> gnomefreak: RB rips CDs just fine, and much better integrated with music collection, etc.
[11:50] <davmor2> gnomefreak: rhythmbox does.  I've ripped all my cd's to hd using rhythmbox
[11:51] <gnomefreak> i didnt see an option for it
[11:52] <davmor2> gnomefreak: click on the cd it opens the cd dialogue window then click on add to library
[11:52] <davmor2> I think just drop in a cd and see :)
[11:52] <seb128> pitti: we will not drop it from main
[11:52] <seb128> pitti: will we?
[11:53]  * cjwatson uploads a dpkg merge and hopes the world remains unexploded
[11:53] <pitti> seb128: if you want to keep it in main, fine for me; but it should disappear from the default install at least IMHO
[11:53] <pitti> cjwatson: good luck!
[11:53] <seb128> pitti: I've not though about this one but usually we have official GNOME components to supported no?
[11:53] <pitti> seb128: right
[11:53] <davmor2> pitti: seb128: As far as I know RB uses serpentine libs to burn cds and SJ libs to rip them so pass.
[11:53] <pitti> I didn't know that it still was an official component
[11:53] <seb128> pitti: right, we agreed on that during uds
[11:54] <seb128> pitti: rhythmbox is not an official GNOME component
[11:54] <seb128> pitti: so they have no reason to deprecate s-j
[11:54] <seb128> davmor2: sound-juicer has no lib
[11:55] <seb128> davmor2: and rhythmbox doesn't use serpentine no
[11:55] <ogra> s-j is only about 100-200 lines of pygtk code iirc (but i didnt look for more than 1.5 years though)
[11:55] <stgraber> so rhythmbox is directly using sound-juicer to rip CD ?
[11:55] <davmor2> seb128: Ah okay :)
[11:56] <stgraber> or rhythmbox has a recommend I don't understand :)
[11:56] <seb128> ogra: sound-juicer has been written in C from the start
[11:57] <ogra> seb128, ergh, really ? i thought i remembered it to be pygtk ... but as i said thats 1.5years ago ... to much code has passed my eyes since  :)
[11:57] <seb128> ogra: you are speaking about serpentine, aren't you?
[11:57] <ogra> ooohh, right !
[11:57] <ogra> thanks
[11:57] <ogra> indeed
[11:58] <davmor2> RB does depend on sound-juicer
[11:58] <seb128> stgraber: rhythmbox used to open rhythmbox when you wanted to copy a cd, the recommends has likely not been cleaned
[11:59] <gnomefreak> davmor2: from here it recomends it
[11:59] <stgraber> seb128: ok, makes sense
[11:59] <seb128> davmor2: it doesn't
[11:59] <davmor2> gnomefreak: you are correct it's me looking in the wrong place sorry
[11:59] <gnomefreak> :)
[12:00] <davmor2> need caffeine
[12:00] <gnomefreak> it depends on a bunch of other things though
[12:14] <tjaalton> rhythmbox does not integrate that well with musicbrainz, there's no option to submit the data if the information is missing from mb
[12:14] <tjaalton> but, maybe that'll change
[12:22] <emgent> morning
[12:28] <davmor2> tjaalton: your right have you reported it as a bug?
[12:28] <davmor2> if not then I can
[12:29] <seb128> siretart: we are using team assignment for all the desktop bugs for information (just reading your mail on the list)
[12:30] <tjaalton> davmor2: no I haven't, please do :)
[12:30] <davmor2> tjaalton: Np's
[12:31] <davmor2> I'll bug it upstream do we want it adding to LP too ?
[12:31] <tjaalton> musicbrainz is very cool, hope people will use it more :)
[12:32] <tjaalton> davmor2: either way is fine by me, let me know the bug #
[12:34] <siretart> seb128: I don't understand why you choose assignments over subscriptions for allocating a bug to a team, mostly because I see quite some limitations with that approach. Could you perhaps elaborate on the merits?
[12:34] <seb128> siretart: it allow to define a set of bugs that the team will fix for a milestone without deciding on the individuals who will do the work
[12:35] <siretart> seb128: that part I did understand. I don't understand whats superior to just subscribing the team
[12:35] <seb128> siretart: then people can claim bugs when they start working on those and change the assignement
[12:35] <seb128> siretart: subscription doesn't appear on the milestone bug lists, etc
[12:36] <siretart> so you need to see what team is going to work on a bug on the milestone bug list?
[12:36] <seb128> yes
[12:36] <siretart> what if a bug could be allocated to two teams?
[12:36] <seb128> I know we had other cases too, that's one I'm thinking about now
[12:36] <siretart> e.g. it is not sure if it is a compiz or xorg bug?
[12:37] <seb128> you don't assign when you don't know
[12:37] <seb128> or you assign to the most likely team and it can be reassigned if required
[12:38] <davmor2> tjaalton: http://bugzilla.gnome.org/show_bug.cgi?id=535065
[12:39] <siretart> seb128: I need to think about this argument a bit more. maybe you could raise this point on the mailing lists? Perhaps some other people could elaborate further on this thought.
[12:39] <seb128> siretart: I need to think about it, but we are using this workflow for years, not sure why you consider it as wrong
[12:40] <siretart> I currently have a feeling that this is mostly an UI issue. changing assignments is currently easier exposed in the UI than subscription, which might be a reason why some people prefer that
[12:41] <siretart> seb128: we are currently discussing bug handling extensively, both at UDS and now post-UDS on the bugsquad mailing list. My current observation is that bug assignments are used inconsistently which does cause quite some confusion on different sides
[12:42] <siretart> seb128: and I do consider this confusion as problematic and am currently thinking about how to reduce it
[12:42] <seb128> ok
[12:42] <siretart> assigning a bug to a team has always confused me a lot for several reasons
[12:43] <siretart> like if a team is assigned, then there is still no responsible person for this task. this is likely to give a false sense about what is going to happen with the bug.
[12:43] <siretart> or the fact that you cannot assign to multiple teams
[12:43] <siretart> I think on ubuntu-devel@l.u.c are some more arguments against
[12:43] <seb128> assigning to a team means a group of people is responsive for the issue
[12:44] <siretart> which in practice means no one is responsible
[12:44] <seb128> subscription give you no information about who is going to work on something
[12:44] <siretart> at least to my observation
[12:44] <seb128> well, it means that you have a point of contact to discuss the issue
[12:44] <seb128> and that the team members have a todo
[12:45] <siretart> the archive administrators demonstrate that a todo list can be implemented as good with subscription as with assignments
[12:45] <siretart> s/good/well/
[12:46] <tjaalton> davmor2: thanks, subscribed
[12:46] <siretart> my point is that these two techniques are used inconsistently, which causes confusion. let's settle on the better method to reduce that, I'd say
[12:48] <seb128> siretart: archive admin has an easy job, they have a low number of bugs than they bring to almost 0
[12:48] <seb128> siretart: so you can go through the list easily
[12:48] <seb128> siretart: which is not true when you have some thousand bugs
[12:49] <siretart> which team takes desktop bugs?
[12:49] <seb128> desktop-bugs
[12:50] <siretart> https://bugs.edge.launchpad.net/~ubuntu-bugs/+assignedbugs shows 2 bugs
[12:50] <siretart> oh
[12:50] <siretart> wrong team
[12:50] <davmor2> tjaalton: also bug 77346 was open referring to the same thing so I tagged the upstream bug to it :)
[12:50] <siretart> https://bugs.edge.launchpad.net/~desktop-bugs/+assignedbugs shows 3515 bugs
[12:51] <seb128> siretart: right ;-)
[12:52] <siretart> I'm suprised why you claim that assignment works better than subscription. I guess I need to take that.
[12:52] <tjaalton> davmor2: oh cool, subscribed to that too :)
[13:16] <ScottK> pitti: I'm going over the clamav backports -> updates copies and it a appears that claws-mail 2.10.0-3ubuntu3+gutsy1 did not get copied. The rest all look good.  Thank you very much.
[13:16] <ScottK> pitti: Do you think we should remove them from backports?
[13:19] <pitti> ScottK: seems that slipped; for feisty, too, I suppose?
[13:19] <pitti> StevenK: we can remove them to reduce confusion, yes
[13:19] <ScottK> pitti: No.  It's a new package for Gutsy, not in Feisty.
[13:20] <ScottK> pitti: One less set of things to worry about security updates for.
[13:20] <pitti> ScottK: copied
[13:20] <ScottK> pitti: Thanks.
[13:30] <cjwatson> slangasek: is bug 234901 interesting for you in samba?
[13:53] <luisbg> how can I compare the list of packages in the gutsy cd to the packages in the hardy cd?
[13:54] <tjaalton> luisbg: try 'dpkg --get-selections'
[13:54] <pitti> luisbg: download the .list/.manifest files on releases.u.c. and run diff -u on them
[13:59] <luisbg> pitti, I see the .lists but not the manifests
[13:59] <luisbg> at http://releases.ubuntu.com/hardy/
[14:00] <pitti> luisbg: .manifest is only for desktop CDs
[14:00] <pitti> (contents of live fs)
[14:00] <luisbg> very true
[14:00] <luisbg> pitti, thanks!
[14:04] <pitti> ScottK: removed from -backports
[14:04] <ScottK> pitti: Thanks.  This is a good day.  I started working on this 11 months ago ....
[15:12] <emgent> hello people
[15:15] <mvo> cody-somerville: could you please check LP #235113 and let me know what you think?
[15:16]  * cody-somerville dies.
[16:18]  * mpt blinks
[16:19] <mpt> Did anyone else receive, less than an hour ago, a message that was sent to ubuntu-devel-discuss@ on 1st June last year?
[16:19] <Festor> O.o
[16:19] <Ng> I did :)
[16:20] <cody-somerville> What was it about?
[16:20] <mpt> Not just a wonky datestamp, either, it's all about 7.04
[16:20] <cody-somerville> "Do we need a new 'Welcome to Ubuntu'?"?
[16:20] <cody-somerville> hehe
[16:20] <cody-somerville> I replied to that :P
[16:21] <cjwatson> mpt: sounds like it was stuck in a moderation queue
[16:21] <mpt> Did you say "Greetings from the distant future"?
[16:21] <Spads> Ng reckons it was in the moderation queue for a year
[16:21] <cjwatson> presumably since it triggered a spam check or something - ubuntu-devel-discuss isn't normally moderated
[16:21] <cjwatson> hence why its moderation queue doesn't get looked at a whole lot, probably ;-)
[16:21] <mpt> Once a year is often enough :-)
[16:23] <evand> probably my fault.  ubuntu-devel-discuss has a large queue from before I started admining it, I imagine I accidentally clicked approve on one of the older messages when processing the new ones.
[16:28] <sebner> elmo: around? I heard I have to annoy you to get my @ubuntu.com mail activated ;)
[16:29] <emgent> sebner: canonical sysadmin working to it, dont worry
[16:41] <sebner> ember: =)
[16:41]  * ScottK hands sebner some tab completion.
[16:42] <sebner> ScottK: löl. thx
[16:42]  * sebner wishes that users would use more significant nicks :P
[16:53] <thom> (fix the word support)
[16:54] <raeLLL> I just happened to try to changed the topic, why a normal user here have the permission to change the topic?
[16:54] <stdin> because people generally don't try to change the topic here
[16:54] <stdin> "trust"
[16:57] <cjwatson> raeLLL: it's more convenient to deal with the odd breach than it is to administer topic change requests
[17:03] <mario_limonciell> pitti, since the source package will be NEW, I should be able to directly upload the fglrx source package to the archive without needing a core-dev right?
[17:08] <cjwatson> mario_limonciell: NEWness is applied after GPG checks
[17:08] <cjwatson> oh, but you mean since it wouldn't know what component it was meant for
[17:08] <mario_limonciell> exactly
[17:08] <cjwatson> I could check the code, but it might be easier just to try it. :)
[17:08] <mario_limonciell> okay :)
[17:11] <mario_limonciell> yup that worked.  well guess that's the only upload I'll be able to do for it directly myself once it's all overridden and such, at least until the archive reorg stuff goes through. :P
[17:12] <ScottK> mario_limonciell: That or kick in to gear and get core-dev.  It'd probably be faster.
[17:13] <mario_limonciell> ScottK, good point, but that is dependent on how much stuff I'll be able to do for core-dev worthy things these next few months.  We'll see
[17:14] <ScottK> mario_limonciell: They took me.  How hard can it be?
[17:15] <Tm_T> raeLLL: you don't need to be an idiot just because noone is stopping you before you start ;)
[17:16] <raeLLL> Tm_T: start what?
[17:18] <mario_limonciell> ScottK, yeah you already had a lot of focus on items with main implications (Kubuntu related).  this would be more territory for myself.  All of my main implications have been indirect thus far
[17:20] <Tm_T> raeLLL: being an idiot ;(
[17:21] <raeLLL> I just feel it strange.
[17:23] <ScottK> raeLLL: We do a lot of things differently in Ubuntu.  One of them is generally expecting people to behave nicely and responsibly.
[17:27] <cjwatson> mario_limonciell: archive reorg wouldn't magically let you upload to things in the core anyway
[17:27] <cjwatson> if you aren't already core-dev
[17:27] <mario_limonciell> cjwatson, i'm meaning that I would be asking for permissions on that particular package
[17:28] <cjwatson> mario_limonciell: I see that as sort of an add-on to the main thrust of archive-reorg
[17:28] <cjwatson> mario_limonciell: in fact that could be done completely independently
[17:29] <ScottK> cjwatson: Since I didn't manage it personally before I left, I wanted to thank you for the developer docs session Friday AM.  I wasn't able to make it, but from reading the gobby page and talking to those that were there it seems like a very needed, good idea.
[17:30] <cjwatson> ScottK: siretart mentioned some conversations he'd had with you; thanks, indirectly
[17:30] <cjwatson> I'll get that onto ubuntu-devel once I have a little more to show
[17:30] <mario_limonciell> cjwatson, are you meaning that independently of the reorg, it would be possible to adjust permissions on a per package basis?
[17:33] <pochu> mario_limonciell: hi :) bug 134456?
[17:33] <pochu> This will allow us to have a Dell engineer, or team, maintain a
[17:33] <pochu> Dell-specific package even if it is in main. It will allow an upstream
[17:33] <pochu> engineer from product foo to get involved in the foo package in Ubuntu.
[17:33] <pochu> that's you! ;)
[17:34] <cprov> pochu: very well explained :)
[17:35] <mario_limonciell> hi pochu :).  oooh.  This is very good to see.  I wonder how it will be exposed though?  Does there have to be a LP interface to match it, or will it end up in in the source package itself?
[17:35] <pochu> mario_limonciell: no idea, but cprov probably knows :)
[17:37] <pochu> cprov: hi! I wonder what bug 207680 means exactly... I guess it's not that MOTUs will be able to accept packages from NEW :)
[17:37] <cprov> mario_limonciell: the infrastructure will in place tomorrow, the changes will be done by request.
[17:38] <mario_limonciell> cprov, by request to whom particularly, LP admins, or archive admins?
[17:38] <cprov> mario_limonciell: get in touch with the distro-team, once they approve we will adjust the data.
[17:38] <Amaranth> ooh, maybe i'll be able to upload compiz soon then :)
[17:38] <pochu> heh
[17:38] <cprov> mario_limonciell: first talk with archive-admins / cc
[17:39] <pochu> Amaranth: luckily I use metacity ;-)
[17:39] <cprov> mario_limonciell: I think that's the way it's supposed to work.
[17:39] <mario_limonciell> cprov, very cool.  glad to see this happening
[17:39] <pochu> Amaranth: I read that metacity message from you on "3 things you don't know about me" and I believed it o_O
[17:39] <Amaranth> hehe
[17:40] <Amaranth> I really was most of the time while I was there, the laptop I was using was buggy
[17:40] <StevenK> I don't recall that one, what was it?
[17:40] <Amaranth> "I use metacity"
[17:41] <cprov> mario_limonciell: yes, I will certainly shake ubuntu-community organisation.
[17:41] <zul> mvo: ping
[17:48] <cjwatson> cprov: err, please don't just say "get in touch with the distro-team", we don't have a process for dealing with such requests yet and having everybody turn up on our doorstep tomorrow won't be immediately helpful; and furthermore it should be the Ubuntu Technical Board or some group delegated by it, absolutely not the Canonical distro team
[17:49] <cjwatson> the best approach is probably for people who want to upload packages outside their normal permissions to apply at a TB meeting, and once the TB is swamped then they can delegate
[17:49]  * Amaranth applies :)
[17:50] <cjwatson> cprov: please don't take requests for this from people not on the TB or authorised by it though, even if they're on the distro team (for example I shouldn't be authorised to make such a request, right now)
[17:50] <mvo> zul: pong (about to leave for the evening)
[17:51] <zul> mvo: can I take net-snmp off your hands?
[17:51] <ScottK> The TB might even want the MC to pre-screen requests much as it handles MOTU and core-dev applications.
[17:52] <cprov> cjwatson: okay, I apologise for the misleading suggestion.
[17:52] <mvo> zul: sure
[17:52] <zul> mvo: thanks
[17:52] <cjwatson> cprov: no problem, gives me the opportunity to explicitly disclaim responsibility ;-)
[17:52] <mvo> zul: I have no idea why I touched it, probably some sort of upgrade issue
[17:52] <cjwatson> (makes a change)
[17:53] <cjwatson> ScottK: quite possibly, though not for me to say. The TB still has veto over ubuntu-dev applications, doesn't it (at least in theory)?
[17:53] <ScottK> Yes they do.
[17:54] <ScottK> Off the top of my head I was thinking MC could authorize individual uploaders for Universe and recommend to TB for Main.
[17:54] <ScottK> TB still gets a veto of course.
[18:14] <cjwatson> hmm, merges.ubuntu.com is slothful to update again
[18:22] <raytruz_>     Anyone know why padlock_aes.ko went away with today's kernel upgrade?
[18:59] <Tophat> how do i get started on the ubuntu kernel ?
[18:59] <Tophat> i've read over the wiki but there isn't much of a how-to get started for the average windows developer.
[19:15] <pochu> Tophat: I don't really know, but #ubuntu-kernel may be a better place to ask :)
[19:18] <Tophat> oh snap.  sorry mate
[19:53] <pitti> superm1: right
[19:54] <raytruz_> I get this error after the update today: http://pastebin.org/38946
[19:54] <raytruz_> Anyone have any insight
[19:58] <pitti> hm, WFM on amd64
[19:58] <pitti> BenC: ^ any idea?
[20:02] <emgent> someone remember in what file mozilla-thunderbird read mailbox user/pass of accounts?
[20:30] <geser> pitti: any ETA on when bug #229901 and bug #229906 get processed? both are needed to get further with the perl 5.10 transition
[20:30] <Mirv> if someone who knows me is awake, please add some cheers to my wiki page at https://wiki.ubuntu.com/TimoJyrinki for the Ubuntu membership meeting (in case they'd help)
[20:31] <pitti> geser: can do
[20:31] <geser> thanks
[20:49] <mario_limonciell> hmm well why would these fail to upload? https://edge.launchpad.net/ubuntu/+source/fglrx-installer/2:8.493.1-0ubuntu3  they built successfully
[20:49] <tjaalton> Mirv: done!
[20:50] <Mirv> tjaalton: thanks :)
[20:50] <mario_limonciell> is this related to ogre model messiness since the source package is in multiverse?
[20:52] <mario_limonciell> or is it because a new LRM upload needs to be done still without fglrx in it so there are no conflicts?
[20:52] <mario_limonciell> tjaalton, would you be able to do that LRM upload with the fglrx stuff commented out?
[20:53] <tjaalton> mario_limonciell: hmm, I don't think that's why. do you have the error message?
[20:53] <mario_limonciell> tjaalton, "#   intrepid amd64   Failed to upload "
[20:53] <mario_limonciell> same thing for i386
[20:54] <pitti> seb128: argh, gnome-desktop went straight to hardy-updates
[20:57] <seb128> pitti: ups, I got a cold when coming back and did some mistakes in those updates apparently
[20:57] <mario_limonciell> tjaalton, the failed to upload seems to be referring to the binary packages I  think
[20:57] <seb128> pitti: I'm pretty sure it'll not screw anything though, the changes are in gnome-about which is a side application
[20:58] <tjaalton> mario_limonciell: so fglrx-installer is the source package generated from the upstream blob?
[20:58] <seb128> pitti: and the libgnome-desktop change is a few lines to use unsigned int rather than int and fc9 is using it
[20:58] <mario_limonciell> tjaalton, yes
[20:58] <mario_limonciell> all of the stuff that happens in these first few uploads i'll sync up with that package.
[20:59] <pitti> seb128: *hug* get well soon!
[20:59]  * seb128 hugs pitti
[21:00] <fde> Hello, sorry to bother you, when you hit ESC in recovery mode, what is ran?
[21:00] <fde> ie, what tool or service performs the magic?
[21:01] <mario_limonciell> fde, recovery mode uses the friendly-recovery package
[21:01] <fde> mario_limonciell: thank you!
[21:03] <tjaalton> mario_limonciell: ok, it could be something like you suggested after all, but I can't really tell for sure
[21:03] <mario_limonciell> tjaalton, okay i just posted in #launchpad.  maybe a soyuz dev can chime in
[21:04] <norsetto> pitt, seb128: re. gnome packages to -updates, just installed, so far so good
[21:04] <seb128> norsetto: thanks
[21:04] <seb128> as said gnome-desktop should be no issue
[21:19] <seb128> siretart: subscribing doesn't tell you who is going to work on the bug, there is a zillion of people subscribed to some GNOME packages who never work on those
[21:21] <tjaalton> mario_limonciell: btw, you are using the module version number and not the catalyst version?
[21:21] <mario_limonciell> tjaalton, internal version number of the package is what ATI had wanted people to use
[21:21] <mario_limonciell> so it was consistent
[21:21] <mario_limonciell> via ./ati-package-helper.sh --version
[21:22] <tjaalton> ok
[22:21] <detrolex> does ubuntu provide any support for mp3/ntfs ?
[22:22] <norsetto> !support | detrolex
[22:22] <norsetto> detrolex: the short answer is yes
[22:23] <detrolex> k
[22:24] <detrolex> thx