[00:00] <directhex> DktrKranz, thanks. bugs.debian.org is probably best - the ones i have the ability to change i get a ping from (as the bug gets mailed to the pkg-cli-apps mailing list)
[00:01] <directhex> hm. i think i'm going to try for DD. i spend too much time prodding DDs in an irritating manner when i should be doing things myself. sound sensible?
[00:01] <DktrKranz> ok, I'll have a test build with a exp chroot to see if it's the case to submit to them
[00:01] <slangasek> StevenK: hmm, you might want to have a look at DktrKranz's latest post on ubuntu-devel, if you're in the NBSing right now
[00:02] <slangasek> i.e., apparently the NBS report is rather wrong ATM
[00:02] <StevenK> slangasek: Making plans, not executing
[00:02] <directhex> DktrKranz, building for exp is pain :(
[00:03] <directhex> DktrKranz, question is when slomo is going to upload gnome# 2.24 to unstable
[00:03] <DktrKranz> directhex, yep, but gnome# has not migrated to unstable, ATM
[00:03] <directhex> DktrKranz, hopefully not until after hanska gives it some policy love
[00:06] <directhex> hm, i'll need an advocate and a signed gpg key
[00:06] <RAOF> ...a bible, and a stopwatch?
[00:07] <directhex> and a bucket of weasels
[00:07] <DktrKranz> RAOF, FYI, evolution-sharp dot release is out
[00:07] <RAOF> DktrKranz: I know.  They closed the bug I filed :)
[00:07] <DktrKranz> directhex, and some $deity help :)
[00:07] <DktrKranz> good :P
[00:08] <DktrKranz> so, we're done with gnome# finally! \o/
[00:08] <Laney> someone sponsored tomboy?
[00:09] <RAOF> Yup.  It's waiting for gnome-panel-sharp to be promoted to main before it builds, though.
[00:10] <Laney> yayness
[00:10] <StevenK> It's been promoted, waiting for a publisher run
[00:10] <Laney> double yayness
[00:10] <directhex> if some lovely archive admin on binary new duty let  libsublib-cil_0.9-0ubuntu1_all.deb  slip in, then i could test a merge for gnome-subtitles 0.8 and sign off on the mono 2.0 app transition too
[00:11] <Laney> I think we should promote gnome-do and replace the default bottom panel with docky
[00:11] <directhex> assuming i don't keel over from exhaustion first. zzzzzzzzz
[00:11]  * StevenK looks at the NEW queue and then wishes he hadn't
[00:11] <directhex> Laney, ask shuttleworth! i heard he likes do :p
[00:11] <Laney> heh
[00:12] <directhex> Laney, perhaps with savings from the lib transition, there'll be room :p
[00:12] <Laney> consider it done
[00:12] <StevenK> directhex: libsublib released from binary NEW
[00:12] <Laney> sweet!
[00:13] <directhex> StevenK, sweet!
[00:13]  * directhex fires up his jaunty vm
[00:14] <cjwatson> right, I'll be able to test a britney modification to treat Recommends in metapackages as Depends, just as soon as I can build the C code involved since cocoplum doesn't have libapt-pkg-dev :-(
[00:14] <cjwatson> tomorrow, I feel
[00:14] <cjwatson> (I snarfed a copy of the test data)
[00:26] <Keybuk> slangasek: look at the line right above where you're reading
[00:26] <_tulio_123> hello all
[00:26] <_tulio_123> can somebody help me with a python class please
[00:26] <slangasek> Keybuk: ah
[00:26] <slangasek> Keybuk: clever!
[00:26] <Keybuk> _tulio_123: try #python ?
[00:26] <_tulio_123> ok
[00:26] <_tulio_123> thanks
[00:26] <_tulio_123> =D
[00:27] <Keybuk> slangasek: yeah ;)  I snuck that one into udev a while back
[00:27] <Keybuk> but hadn't got around to using it until now
[00:29] <_tulio_123> #python need to be registered
[00:31] <ion_> Perhaps this channel should switch to that, too.   I can mount ext3 as ext4 without problem, and http://ext4.wiki.kernel.org/index.php/Ext4_Howto has some hints at the bottom
[00:47] <calc> long term conversion is supposed to work, but i don't think it does yet, and not until online defrag fully works anyway
[00:48] <kees> directhex: true, but that's all I want for the moment.  :)
[00:48] <calc> kees: well i meant to get all the benefits of ext4 you need to reformat
[00:48] <kees> but comparing filesystem features between mkfs.ext3 and mkfs.ext4 shows more than the wiki suggests
[00:48] <kees> right
[00:49] <Laney> write a script to recreate all files!
[00:49] <kees> erf.
[00:49] <Laney> cat foo >> foo~; mv foo~ foo
[00:49] <Laney> >*
[00:49] <kees> that won't retain permissions, but I get the picture.  :)
[00:50] <Laney> it is too late for such considerations
[00:50] <StevenK> If you're doing that hack, you may as well mkfs ...
[00:50] <calc> just tar it to some other fs then back ;-)
[00:51] <calc> i can't recall for certain but iirc even moving the files around doesn't get you full ext4 feature set iirc
[00:51] <calc> its been a while since i looked though so i might be wrong
[00:51] <TheMuso> calc: tar depends on having space elsewhere.
[00:51] <calc> TheMuso: yea
[00:52] <kees> thank goodness I use LVM.  :)
[00:52] <persia> Well, that only helps if you have space elsewhere :)
[00:52] <kees> yup
[00:53] <StevenK> kees: I keep saying that too and then people like Keybuk call me insane
[00:53] <kees> :)
[00:55] <Keybuk> my calling you insane has nothing to do with your filesystem choices
[00:56] <StevenK> LVM isn't a filesystem, kthxbye
[00:56] <StevenK> But, fair point :-P
[00:56] <Keybuk> besideswhich, I was heard not so long ago saying we should just do LVM by default
[00:57] <Keybuk> but now I'm all about the btrfs
[00:57] <StevenK> I like my data enough to not try and lose it
[00:57] <Keybuk> StevenK: really?  I could swear you once claimed to like XFS
[00:58] <calc> ext4 should be stable by 10.04 and btrfs maybe 12.04? :)
[00:58] <calc> XFS is evil
[00:58] <StevenK> Keybuk: So not me.
[00:58] <ion_> I hear the XFS problem was corrected about 1½ years ago.
[00:58] <Keybuk> ion_: not that I'm aware of
[00:58] <calc> if XFS was a gauge of how long it takes to become stable it would be ~ 8 years
[00:58] <Keybuk> last time I looked, XFS was still not safe to do fclose (); rename() without fsync() in there
[00:58] <Keybuk> interestingly, ext4 seems to suffer from the exact same problem
[00:58] <StevenK> I've used XFS once, and that was under duress because ext3 can't do online resizing by default
[00:59] <ion_> http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F
[00:59] <ion_> keybuk: Oh, ok.
[00:59] <calc> ion_: yea people refer to that like someone should trust XFS when it had a serious bug that ate fses for 6-8 years before that unfixed
[01:00] <calc> my system got hit by that bug about 5-6 years ago which nearly caused me to lose all my data, luckily i managed to get it back
[01:00] <ion_> In Finland, we have these things called “backups”.
[01:01] <Keybuk> I often make backups
[01:01] <Keybuk> generally just after losing something
[01:01] <Keybuk> some of the btrfs features are just made of awesome
[01:02] <Keybuk> like you can upgrade ext3 to btrfs
[01:02] <Keybuk> and if you don't like it, you just hit a button, and all the btrfs stuff vanishes leaving you with your original ext3 filesystem
[01:02] <calc> ion_: i recovered my data and never used another untested fs again (eg just ext2/ext3) after that
[01:03] <Keybuk> since btrfs is copy-on-write, there's no reason it _has_ to clean up the old data
[01:03] <Keybuk> which means, if you have lots of cheap disk, you needn't bother
[01:03] <Keybuk> and at any point, can simply roll back a file, a directory or your entire filesystem to any previous version
[01:03] <ion_> keybuk: Neat
[01:03]  * calc hopes it defrags well
[01:04] <persia> Almost like VMS, really.
[01:04] <jdong> Keybuk: ugh YES ext4 picked up that nasty trait from XFS, just got hit by it a month ago.
[01:04] <Keybuk> jdong: I was chatting to tytso about it at FOSDEM
[01:05] <jdong> cool
[01:05] <StevenK> Keybuk: What did he say?
[01:05] <jdong> it's also picked up a greater chance of losing transient/in-cache data too compared to ext3
[01:05] <jdong> I mean for all I see as an end-user ext4 is XFS with faster metadata operations and slower large-file performance....
[01:05] <Keybuk> StevenK: "argh, my laptop got stolen, I hate brussels, everything wikitravel says is true"
[01:05] <StevenK> Haha
[01:05] <jdong> and a poorer suite of backup tools ;-)
[01:05] <StevenK> Keybuk: I meant about the fsync() needed thing
[01:06] <Keybuk> jdong: since the principle change from ext3 to ext4 (other than extents) is delayed block allocation - which is the prime feature of XFS - that's about right
[01:06] <jdong> at least with XFS I can take an xfsdump every night and call it peace-of-mind
[01:06] <Keybuk> StevenK: he mentioned he may be considering an implicit data sync on fclose()
[01:06] <jdong> Keybuk: is that going to give those lovely infamous reiser4 delays where :wq triggers a flush of everything in-cache to disk?
[01:07] <jdong> I guess more recently, firefox/sqlite
[01:07] <Keybuk> no, he was saying it'd be more intelligent and only flush that file's blocks
[01:07]  * StevenK shivers.
[01:07] <jdong> mmm, I see
[01:07] <Keybuk> ie.perform block allocation on close
[01:07] <ion_> keybuk: That’s nice.
[01:08] <jdong> I thought due to that ordered metadata commit stuff that could imply flushing out other data too? or was that changed?
[01:08] <jdong> or are my views completely misguided ;-)
[01:08] <persia> So if you've several large files open with data growth (say all the Ubuntu torrents on release day) on a small disk (say 20G), you could conceivably not allocate until you've overused your disk?
[01:12] <calc> persia: the torrent program should preallocate
[01:13] <calc> persia: and the new transmission has support for regular create a really big file already (iirc)
[01:13] <jdong> lol that doesn't sound like the correct solution/answer to the question though.
[01:13] <calc> not sure if it does the ext4 preallocate stuff though
[01:13] <jdong> "My foot hurts, doc ==> well stop using it.."
[01:13] <persia> calc, So the answer is "Yes, but don't do that"?
[01:14] <persia> calc, For a less contrived example, consider server logs.
[01:14] <calc> persia: unless i am missing something the try to download too much via torrents is already an issue with other fs as well?
[01:17] <persia> calc, Not quite the same: when you run out of disk, the writing program stops writing, even if you have lots of potential disk cache could could fill in RAM, because they tend to be allocate-on-write.  If it's truly allocate-on-close, that creates a somewhat different model.
[01:17] <persia> So, in short, yes, running out of disk is bad, and breaks your files, but this would do it in a different way, I think.
[01:18] <persia> On the other hand, you could probably delete space pre-close and save the contents of the precious file with allocate-on-close in a way that might not be possible with allocate-on-write.
[01:18] <calc> persia: ah i see now
[01:18] <persia> I could be completely wrong of course.
[01:20] <jdong> persia: I thought delayed-allocation still accounted for the currently-accurate free blocks state in RAM, just didn't put it on disk until a (convenient) later time?
[01:21] <persia> jdong, That's excellent news.  So it keeps track of the available blocks, and expected allocations, and does the right thing?
[01:22] <jdong> persia: that's the way XFS works and how I assume ext4 works
[01:22]  * persia ceases to worry
[01:22] <jdong> the only thing being "delayed" is writing the updated accounting info onto the disk until it is reasonably certain it's not going to fluxuate
[01:22] <jdong> so I guess the ill effect is a higher probability of losing in-transit data on bad shutdown
[01:23] <persia> Well, sure, but that's a performance tradeoff anyway.  Same as buying disks with larger memory caches, or setting high swappiness with lots of RAM to use the kernel disk cache.
[01:32] <directhex> oh, wow, is it me or did NEW shrink by 33% in the last hour? nice going
[01:39] <maxb> i386      678 builds waiting in queue
[01:39] <maxb> Yikes!
[01:40] <ScottK> Language packs do that.
[01:43]  * directhex translates ScottK into klingon
[01:51] <StevenK> directhex: Klingon is too low to get a language pack :-(
[01:51] <StevenK> I should translate gdm into Klingon
[01:53] <directhex> StevenK, does unicode include klingon glyphs? :/
[01:53] <directhex> oh, poop, problem
[01:53] <directhex> StevenK, ubuntu is linux for human beings
[01:53] <directhex> so no klingon
[01:54] <LaserJock> directhex: I don't think that's an issue
[01:55] <LaserJock> directhex: since humans, for whatever reason, sometimes speak it
[01:55] <directhex> time for bed. tomorrow i need to construct a big thank you message
[01:55] <LaserJock> so "Ubuntu is Linux for Human Beings (who may speak klingon)"
[01:56] <ajmitch> LaserJock: next you'll be arguiing for quenya language packs
[01:57] <persia> ajmitch, Get quenya to > 90% coverage, and you could probably find support.
[01:57] <ajmitch> persia: I suspect there's probably a team for it on launchpad
[01:59] <LaserJock> ajmitch: I wasn't arguing anything other than "for human beings" doesn't limit klingon as it can be spoken for human beings
[01:59] <LaserJock> I personally can't understand why people would be so silly
[01:59] <LaserJock> but to each his own I guess
[02:00] <ajmitch> People can be that silly quite easily, I'm not sure why either
[02:01] <LaserJock> I should make a periodic table language
[02:01] <ajmitch> chemists...
[02:01] <ion_> Unfortunately, Klingon hasn’t been included in Unicode AFAIK.
[02:02] <LaserJock> I wonder how that happened
[02:02] <LaserJock> I would have thought some genius would have said "who needs ASCII?  Offtopic, sorry. :-P
[02:04] <persia> There are fonts using the user space in unicode, and well-known codepoints to use for both Klingon and Quenya.
[02:18] <mneptok> Keybuk: explode with rage. you promised me first.
[02:25] <NCommander> pitti, mvo, ping? can you review a packagekit branch for me?
[03:44] <TheMuso> When working with usplash and requiring user input, should I use usplash's input mechanism, or just read from console? Only want one letter entered as a response.
[05:05] <ScottK> Is the publisher running?  I've just watched binaries from more than one package sit at accepted for their second publishing opportunity.
[05:05] <StevenK> ScottK: From my untrained eye, yes
[05:06] <ScottK> OK.
[05:07] <ScottK> StevenK: I've seen it happen before where LP doesn't know stuff is published, but it is.  Do you have (and would you be willing) a way to see if phone and akonadi in intrepid-backports actually published?
[05:08] <StevenK> Which version?
[05:08] <ScottK> akonadi 1.1.1-0ubuntu2~intrepid2
[05:09] <ScottK> phonon 4:4.3.0-0ubuntu1~intrepid1
[05:11] <StevenK> Source is
[05:11] <StevenK> Binaries I can't find
[05:13] <ScottK> StevenK: OK.  I guess I'll wait until tomorrow and see what happens.
[05:16] <ScottK> StevenK: Thanks for checking.
[05:16] <StevenK> ScottK: No problem
[05:17] <LaserJock> is there an X IRC chan?
[05:17] <ScottK> LaserJock: #ubuntu-x
[05:17] <ScottK> At least for Ubuntu
[05:17] <ScottK> Dunno about upstream
[05:18] <LaserJock> ScottK: no, that's what I wanted
[05:26]  * NCommander sighs
[05:26] <Hobbsee> heh.  good to be back, apparently
[05:26] <NCommander> Who's bright idea was it to backport KDE 4.2 and clog up the buildds one day before feature freeze
[05:26] <NCommander> Hey Hobbsee
[05:27] <StevenK> NCommander: Er, I was complaining about that yesterday and you didn't say anything, Mr. Backporter
[05:27] <NCommander> StevenK, I didn't approve it, and I want to smack whoever did
[05:27] <StevenK> Why didn't want to do so yesterday when I was complaining, then?
[05:28]  * NCommander wasn't paying attention.
[05:28] <NCommander> ^to that.
[05:28] <NCommander> I was on holiday :-)
[05:28] <StevenK> That explains oh so much
[05:28] <NCommander> :-P
[05:28] <NCommander> Well, we could always rescore everything else, or downscore the kde* packages so they won't build until after feature freeze ... although I'm not sure anyone ever used rescore in such a way before ...
[05:29] <Hobbsee> you got buildd admin?
[05:29] <NCommander> Hobbsee, yeah.
[05:29] <Hobbsee> nice.
[05:30] <NCommander> Comes with the nice bonus I can retry main builds once the buildds stop going boom.
[05:30] <Hobbsee> i hope you're trustworthy to do so ;)
[05:30] <Hobbsee> man, this feels weird...
[05:30] <NCommander> Hobbsee, what does?
[05:30]  * Hobbsee hasn't touched a keyboard since last tuesday.
[05:31] <Hobbsee> it's now wednesday aftenoon.
[05:34] <TheMuso> Hobbsee: I've had that before, haven't used a computer for over a week, and it feels weird to type when coming back.
[05:35] <Hobbsee> TheMuso: and use a touchpad.  very bizarre.
[05:35] <TheMuso> wow
[05:35]  * NCommander looks for a list of intrepid-backports packages to downscore
[05:37] <ScottK> NCommander: As long as you keep kde4libs back, the rests will depwait.
[05:37] <NCommander> ooh, thats handy
[05:37] <ScottK> No need to work at it too hard.
[05:37] <NCommander> (we'll still loose some buildd time for the dep-waits, but that isn't bad)
[05:38] <NCommander> That's pathetic, I scored it to zero, and it only went up by an hour on estimated build start time -__;
[05:39] <NCommander> Oh
[05:39] <NCommander> You can rescore to negetive numbers
[05:39] <NCommander> Which does extactly what I wanted it to do
[05:40] <StevenK> Careful
[05:41] <StevenK> Then they won't build by themselves
[05:41] <NCommander> StevenK, they won't?
[05:42] <StevenK> I don't think they will
[05:54] <NCommander> StevenK, I'll watch the two packages I did score to negetive. All the other KDE packages are now dep-waiting or will hit dep-wait, so now jaunty packages will take president.
[05:54] <NCommander> So any last minute uploads will not get stuck behind the backports packages
[05:54] <StevenK> "precedence"
[05:56] <NCommander> sorry :-/
[06:43] <dholbach> good morning
[06:45] <Hobbsee> hi dholbach
[06:46] <dholbach> hi Hobbsee
[06:47] <RAOF> Howdie dholbach, Hobbsee.
[06:47] <dholbach> hiya RAOF
[06:48] <Hobbsee> heya RAOF!
[06:50]  * StevenK waves to RAOF
[06:50] <RAOF> Sam found a best of /Supergrass/ CD while we're preparing to move.  This is good :)
[06:50] <Hobbsee> woot!
[06:50] <StevenK> Ugh, moving
[06:51] <RAOF> Eh.  It hasn't been so bad the (2) times I've done it.
[06:52] <StevenK> Moving away from the uni?
[06:52] <RAOF> Yeah, but it's quite close to busses straight into the city, which makes it not bad.
[06:52] <RAOF> And it roughly halves Sam's travel time.
[06:53] <StevenK> And what, quadruples yours?
[06:53] <RAOF> But quadrupling 5 minutes isn't so bad :)
[06:53]  * StevenK grins
[06:54] <StevenK> I liked the commute change with the last job change -- an hour each way to about 30 seconds
[06:54] <Hobbsee> i'm jealous
[06:56] <slangasek> the telecommutative property
[07:00] <pitti> Good morning
[07:00] <StevenK> Morning pitti
[07:00] <pitti> NCommander: PK branch> please sub me to the bug, or mail me?
[07:00] <pitti> hey StevenK
[07:03] <Hobbsee> heya pitti!
[07:04]  * pitti hugs Hobbsee
[07:04]  * Hobbsee hugs pitti back
[07:04] <Hobbsee> LTNS!
[07:08] <pitti> ArneGoetje: langpack export for jaunty is finished
[07:08] <pitti> Hobbsee: LTNS?
[07:08] <StevenK> Long Time No See
[07:08] <Hobbsee> yes
[07:08] <pitti> ArneGoetje: I think langpack-o-matic is ready to go now, too
[07:08] <pitti> ah, indeed
[07:09] <slangasek> oh.  Not "Lose The Source, Nuke"
[07:09] <slangasek> Or "Lose the Norse, Sook" I guess that is
[07:09] <StevenK> That would be LTSN ...
[07:09] <ArneGoetje> pitti: ?
[07:09] <StevenK> ... Because Odin is excess baggage?
[07:10] <ArneGoetje> pitti: langpacks for jaunty (export from 13th) are currently building.
[07:10] <pitti> ArneGoetje: I did some fixes for bug 316174, bug 204705, and so on
[07:10] <pitti> ArneGoetje: there's one from the 16th
[07:10] <pitti> ArneGoetje: but well, won't matter so much I guess
[07:10] <ArneGoetje> pitti: I know. that one came after I uploaded the ones from 13th
[07:11] <ArneGoetje> pitti: yeah, doesn't matter. we will have new ones before release anyways.
[07:11] <StevenK> slangasek: I think I prefered NBS before you fixed checkrdepends
[07:12] <ArneGoetje> pitti: langpack-o-matc choked on the latest intrepid and hardy exports... need to fix some code there,
[07:12] <pitti> ArneGoetje: oh, what did it do?
[07:13] <ArneGoetje> pitti: when importing, it ignores ll_CC and the like, including ll_CC@var. But it choked on ll@var an aborted.
[07:15] <ArneGoetje> pitti: although it is not quite clear to me why we ignore ll_CC and @var locales... they are valid locales and translations for those may differ from the standard ll locale.
[07:15] <slangasek> StevenK: tough :)
[07:16] <StevenK> Haha
[07:16] <pitti> ArneGoetje: we ignore non-UTF8 locales
[07:17] <StevenK> Hmmm. I wonder about syncing koffice from experimental
[07:17] <StevenK> Maybe that one will actually *gasp* build
[07:18] <ArneGoetje> pitti: from the import log: "Skipping obsolete locale fr_CA" <- why?
[07:19] <ArneGoetje> pitti: and the error, where it choked: Copying nds@NFE/yelp into package ../intrepid-proposed/sources-update/language-p
[07:19] <ArneGoetje> ack-gnome-nds
[07:19] <ArneGoetje> Traceback (most recent call last):
[07:19] <ArneGoetje>   File "./import", line 375, in ?
[07:19] <ArneGoetje>     (lang, country) = noat.split('_')
[07:19] <ArneGoetje> AttributeError: 'module' object has no attribute 'subst_string'
[07:21] <StevenK> Riddell: So, pointless or not trying to shove koffice from experimental under the FF door?
[07:21] <LaserJock> hmmpf, I'm stuck in the middle of a git merge but I can't change branches to investigate the merge
[07:22] <LaserJock> I guess that's why branch-is-a-dir is nice
[07:24] <ArneGoetje> pitti: in this case nds@NFE is not a valid locale. First it doesn't exist, but nds_DE and nds_NL do, and second, it should be nds_{DE|NL}@nfe if at all... so, something went wrong in rosetta I guess. It shouldn't have accepted an invalid locale.
[07:26] <persia> LaserJock, You could always clone into another directory, and fiddle there ...
[07:26] <ArneGoetje> pitti: and the log from the hardy import: Processing locale pt_PT...
[07:26] <ArneGoetje> Skipping obsolete locale pt_PT
[07:26] <ArneGoetje> Traceback (most recent call last):
[07:26] <ArneGoetje>   File "./import", line 394, in ?
[07:26] <ArneGoetje>     r = macros.subst_string('%RELEASEVERSION%')
[07:26] <ArneGoetje> AttributeError: 'module' object has no attribute 'subst_string'
[07:28] <LaserJock> persia: hmm, good idea, let me try that
[07:34] <slomo> directhex: when gnome 2.24 is in unstable and mono 2.0 ;)
[07:34] <slomo> lool: i can take a look later probably, but directhex can do it too ;)
[07:42] <rimbi> hi
[07:44] <pitti> ArneGoetje: macros.subst_string breakage fixed and pulled on rookery
[07:44] <pitti> ArneGoetje: untested, though
[07:44] <ArneGoetje> pitti: both of them?
[07:45] <pitti> ArneGoetje: the first AttributeError looks identical to the second one
[07:45] <ArneGoetje> ok
[07:45] <pitti> ArneGoetje: but the traceback on the first one doesn't make sense
[07:46] <pitti> ArneGoetje: is that in the log somewhere?
[07:46] <ArneGoetje> pitti: well, it looks for ll_CC, but gets ll@var
[07:46] <ArneGoetje> pitti: yes, in ../logs/intrepid-updates.log and ../logs/hardy-updates.log ant the end of the file.
[07:46] <pitti> ArneGoetje: hardy-updates.log only has the second exception
[07:47] <ArneGoetje> pitti: yep
[07:47] <pitti> ArneGoetje: hm, that still doesn't make sense to me
[07:47] <pitti> ArneGoetje: can you please try again with the current version?
[07:48] <ArneGoetje> pitti: ok
[08:07] <ArneGoetje> pitti: the intrepid tarbal version is the same as the last imported one... how can I override?
[08:20] <DktrKranz> doko: re bug 324636, ludovic uploaded version 4.3.3-1, could gnat-4.3 be synced then?
[08:28] <directhex> slomo, the kde team is already on at us for mono 2.0 - i think gnome is YOUR department though
[08:34] <DktrKranz> pitti: no rush at all, but when you have time could you please comment on bug 315101? Thanks.
[08:34] <pitti> ArneGoetje: just delete sources-updates/*, shoudl work
[08:35] <ArneGoetje> pitti: ok
[08:35] <pitti> DktrKranz: can you please subscribe me to the bug? I'll respond later then (after FF)
[08:35] <DktrKranz> sure
[08:38] <doko> DktrKranz: please merge from gcc-4.3 4.3.3-4 instead of syncing
[08:40] <DktrKranz> doko: sure, I'll have a look. Thanks!
[08:51] <mdke> morning all. Is there an irc channel for ubuntu netbook remix? I can't see the details on the wiki page
[08:59] <jpds> mdke: Maybe #ubuntu-mobile ?
[09:00] <mrvanes> virt-manager is uninstallable on amd-64 in jaunty at the moment, is python-virtinst (0.400.1) scheduled?
[09:01] <slomo> directhex: what do you mean?
[09:01] <directhex> slomo, "<slomo> directhex: when gnome 2.24 is in unstable and mono 2.0 ;)" - gnome 2.24 is the gnome team's department
[09:02] <mdke> jpds: thanks, will try
[09:03] <slomo> directhex: yes, sure... and i'll try to move as much gnome 2.24 stuff to unstable as time permits... but i guess gtk 2.14 will take another 10 days or something because of some issues (directfb)
[09:03] <directhex> new gtk too? woo
[09:03] <directhex> and i was just learning to love 2.12
[09:04] <slomo> directhex: well, 2.14 is part of gnome 2.24 ;) and i guess some stuff is currently blocked by it
[09:23] <Mirv> is there a reason for gnome-spell to be in main anymore, and a dependency of ubuntu-desktop? AFAIK the last user of it evolution migrated to using enchant already.
[09:24] <Mirv> just wondering before filing a bug
[09:25] <Tm_T> Mirv: I'd say yes, it should be removed
[09:25] <Tm_T> Mirv: as no reason to be there
[09:27] <Mirv> bug #330931 - now if I just find if there is an actual process for demoting from main etc...
[09:32] <directhex> is anyone wearing an archive admin hat?
[09:58] <apw> Keybuk, was it you who was doing bootcharting of various kernels?
[10:00] <MacSlow> any idea what could be causing the system-monitor applet to fail being loaded under jaunty?
[10:03] <seb128> MacSlow: look to .xsession-errors for errors?
[10:06] <MacSlow> seb128, nothing added to .xsession-errors
[10:07] <seb128> MacSlow: is gnome-applets installed?
[10:07] <seb128> MacSlow: dpkg -l gnome-applets
[10:07] <MacSlow> listed as rc
[10:07] <MacSlow> ?
[10:08] <MacSlow> reinstall?
[10:08] <seb128> that's your issue then
[10:08] <seb128> removed and configured
[10:08] <MacSlow> outch
[10:08] <seb128> yes reinstall it
[10:08] <seb128> dunno what you did but you uninstalled it
[10:09] <MacSlow> seb128, I now have a vague clue, what might have caused this
[10:09] <MacSlow> seb128, certainly a "pebkac" :)
[10:09] <seb128> yeah ;-)
[10:11] <Riddell> StevenK: KOffice?
[10:11] <Riddell> we have koffice-kde4
[10:12] <StevenK> Oh, so koffice should die horribly?
[10:21] <Silicium> hi there
[10:22] <Silicium> where in the Squashfs on the LiveCD is the Home environment of the Live User (Ubuntu) defined?
[10:22] <Silicium> i want to change some user specific settings on my custom CD
[10:23] <mrvanes> Anybody any idea about python-virtinst (0.400.1) in amd64? It breaks virt-manager.
[10:24] <soren> mrvanes: I uploaded it half an hour ago.
[10:24] <mrvanes> thx ;)
[10:26] <cjwatson> Silicium: mostly not in the squashfs at all, but in the initrd (/scripts/casper-bottom/10adduser)
[10:27] <Silicium> cjwatson: thanks
[10:38] <tkamppeter> pitti, hi
[10:44] <ogra> hmm, so with evolution indicator installed i have no mail notification at all anymore
[10:47] <ogra> njpatel, what is supposed to happen with evolution-indicator installed ?
[10:48] <pitti> hi tkamppeter
[10:48] <ogra> (aside from not doing anything it seems to break the notification plugin)
[10:49] <pitti> ogra: now it's time to file lots of bug reports :)
[10:49] <ogra> yeah, i just want to know what actually is supposed to happen before i start ;)
[10:49] <pitti> ogra: and thanks for testing that; I tested the Pidgin indicator and alsdorf, but not the evo-indicator
[10:49] <njpatel> ogra: its meant to replace the default notification plugin
[10:49] <tkamppeter> pitti, I want to do a MIR of python-smbc. It is needed by s-c-p.
[10:49] <ogra> that the notification plugin doesnt even show the little mail icon in the systray anymore is definately a heavy bug
[10:50] <pitti> ogra: if you ask me: you should never *ever* be notified about getting email; that defeats the entire purpose of using email and is a productivity killer :)
[10:50] <ogra> i'm no so much concerned about notifications, but want to know if mail arrived while i was afk
[10:50] <pitti> njpatel: is it also supposed to eventually take over the evolution-alarm-notify functionality?
[10:50] <tkamppeter> Once, I cannot find the instructions in the Wiki (too much noise in search results), and second, I do not know whether the whole formalism is needed.
[10:50] <njpatel> ogra: it should show a popup for new messages, add the count to the message inidicator applet on the panel. optionally play a sound. Prefs are in edit->preferences->mail prefs->general
[10:50] <ogra> pitti, well, i *explicitly choose* to be notified
[10:50] <njpatel> pitti: No, not that I am aware
[10:50] <ogra> thats why i deliberately enabled the plugin
[10:50] <pitti> ogra: (I'm just bashing, nevermind)
[10:51] <ogra> njpatel, oh, i need an applet now ?
[10:51] <pitti> tkamppeter: it's on https://wiki.ubuntu.com/MainInclusionProcess
[10:51] <ogra> hrm
[10:51] <pitti> ogra: yes, you need to add the indicator applet
[10:51] <tkamppeter> pitti, it is a simple Python Bindings package for libsmbclient, written by Tim Waugh as he needed it for s-c-p
[10:51] <pitti> ogra: that will happen automatically, but it isn't yet
[10:51] <njpatel> pitti: you can change the prefs to switch off the popups, and only have the count added to the message indicator applet
[10:51] <ogra> bah, so i need to permanently waste panel space ...
[10:52] <pitti> tkamppeter: sounds easy, indeed; but please still submit a MIR (don't waste too much time on it, though, if it's simple)
[10:52] <njpatel> ogra: not for the popups, but yes, for the extra functionality. you need to `apt-get install indicator-applet message-indicator` (unless the names have changed)
[10:52] <ogra> njpatel, both are installed but i didnt add the applet to the panel yet
[10:52] <njpatel> ogra: stop complaining! ;-)
[10:53] <njpatel> ogra: popups should work without the panel applet
[10:53] <ogra> njpatel, not if you change my evolution !
[10:53] <ogra> :)
[10:53] <tkamppeter> pitti, there is no "Depends:" in the s-c-p package for it yet. Do I have to add this before the MIR?
[10:53] <njpatel> ogra: it's better, I promise! :)
[10:54] <pitti> tkamppeter: not before the MIR, but before the package can get promoted
[10:54] <ogra> njpatel, i'll come to your house if it isnt :)
[10:54] <pitti> ogra: the applet disappears if it is "empty"
[10:54] <njpatel> ogra: some tea + cakes will be waiting for you:)
[10:54] <ogra> no, there is a handle
[10:54] <pitti> njpatel, ogra: FYI, I just uploaded an updated ubuntu-meta with these added dependencies
[10:55] <ogra> and apparently a dotted frame
[10:55] <njpatel> ogra: intrepid or jaunty?
[10:55] <pitti> ogra: yes, the handle is a bug; I already told Ted
[10:55] <ogra> njpatel, jaunty
[10:55] <ogra> Pici, ok
[10:55] <ogra> err
[10:55] <ogra> pitti,
[10:55] <ogra> hmm, so adding the applet makes the old notification work again, thats strange
[10:56]  * ogra has the little windows popping up in his face again
[10:57] <ogra> hmm, no package named message-indicator
[10:57] <njpatel> ogra: it's indicator-messages now (just installed it myself)
[10:57] <ogra> heh, k
[10:57] <ogra> ah, got already the latest
[10:59] <ogra> njpatel, will you automatically disable the evolution notification in a user setup if you switch the defaults ?
[10:59] <njpatel> ogra: the message applet should allow you to switch to evolution, and also show the unread mail count when you have some new messages (which again, takes you to evolution). I wanted to do some more fine-grain stuff, like showing some message metadata, but Evolutions plugin arch. is really sandboxed. Can't get any info without loading and parsing all the libcamel stuff :-/
[10:59] <njpatel> ogra: default mail client?
[10:59] <ogra> no default notification
[11:00] <ogra> the old notification plugin shows a little blinking mail icon and a notification if messages arrive
[11:00] <njpatel> ooh, you mean the old plugin
[11:00] <ogra> i assume that clashes with the indicator plugin if both is enabled
[11:00] <njpatel> well, I think evolution will be built without it, or with it disabled
[11:01] <ogra> iirc its off by default ...
[11:01] <njpatel> (as evolution indicator does the same, sans flashing mail icon (using the message panel thing instead)
[11:01] <njpatel> )
[11:01] <ogra> but we should leave it optional for people using other desktops imho
[11:02] <njpatel> cool. I think if the user knows how to switch it on, they can switch of evolution indicator too. We don't need to automate that imo
[11:02] <njpatel> sure, makes sense
[11:03] <ogra> right, just dont disable it during build :)
[11:03] <ogra> so people still have it available if they want to
[11:03] <njpatel> sure, good point. /me emails to make sure that doesn't happen
[11:04]  * ogra wonders if he has to re-login or something ...
[11:04] <ogra> i get mais but there is noting in the applet yet
[11:04] <ogra> nor do i get a notification
[11:05] <tkamppeter> pitti, dependency to s-c-p added, MIR in progress ...
[11:06] <Silicium> cjwatson: hmm, the scrips are only for live definitions but not for desktop icons and so.
[11:06] <njpatel> ogra: hmm, that doesn't sound good. I'll check and see what's up
[11:07] <ogra> ok, a re-login got me the mail icon
[11:07] <ogra> is it not supposed to vanish if all mail is read ?
[11:08]  * ogra would prefer to not have a permanent button in the panel
[11:08] <njpatel> ogra: I just tested new install, and got a popup
[11:08] <ogra> i didnt get a popup, but i have a little icon that expands a menu item to open a minimized evo now
[11:09] <njpatel> ogra: can you just check mail-prefs->general tab, and make sure it's set-up to send popups (and that you've set whether you want notifications for all mail boxes or just inbox)
[11:09] <ogra> though the original one is more usable imho, it disappears automatically if there are no unread mails
[11:09] <ogra> so i can see if new messages arrived when i was afk by noticing the additional icon quickly
[11:10] <njpatel> ogra: yep, there is some missing functionality on the message panel right now, which will make that easy to see
[11:10] <ogra> ok
[11:11] <njpatel> ogra: i can see its not reporting the unread message count, which implies something changed on the server-side. I'll have a proper look tomorrow, on my "dx day" ;-)
[11:11] <ogra> well, i'm not fond of having to read numbers :)
[11:12] <njpatel> ogra: you won't need to. The icon should change to reflect status. It will be very easy to spot
[11:12] <ogra> i just want the icon to appear/disappear, else i would use some real mail notification applet that shows the counts
[11:12] <ogra> thats a huge advantage of the edisting plugin
[11:12] <ogra> it doesnt get in your way
[11:12] <ogra> *existing
[11:12] <ogra> ah, k
[11:12] <ogra> i'll wait for what you implement then :)
[11:13] <njpatel> ogra: you'll be the first to know when it's done, promise :D
[11:13] <ogra> i'll be the firt to complain too :)
[11:13] <ogra> *first
[11:13] <ogra> ask seb ;) i'm the pain in his butt with weird evo bugs
[11:13] <cjwatson> Silicium: the only icon we put on our desktop is for ubiquity (the installer); that's done in the script I pointed you to by copying in a desktop file from the squashfs, which includes a reference to an icon
[11:14] <Silicium> and the examples
[11:14] <njpatel> lol
[11:14] <Silicium> but i will check that again
[11:15] <Silicium> thanks
[11:30] <tkamppeter> pitti, MIR is posted, bug 330973
[11:39] <tkamppeter> pitti, the SRU bug 310575 got verified by its reporter, you can pass the package to -updated now.
[11:39] <pitti> tkamppeter: just marked so
[11:39] <pitti> tkamppeter: can you please have a look at bug 320873 ?
[11:55] <asac> Keybuk: do you know out of head which date you took the udev-extras snapshot on? (only found git id)
[11:56] <asac> dont need exact date ... just approx. i assume it was around the time when you did first packaging?
[11:56] <pitti> asac: oh, so that's the thing which ships probe-modem
[11:57] <asac> pitti: yes.
[11:57] <Keybuk> asac: yeah it would have been up to date at the point I uploaded the packagte
[11:57] <asac> Keybuk: seems you have a snapshot from 5th jan
[11:57] <Keybuk> is there something new you want from it?
[11:57] <asac> Keybuk: any reason not to bump it to latest?
[11:57] <asac> Keybuk: yes. there is more modem-prober code
[11:58] <Keybuk> no reason
[11:58] <asac> http://git.kernel.org/?p=linux/hotplug/udev-extras.git;a=summary
[11:58] <Keybuk> quest udev-extras% ./update.sh
[11:58] <Keybuk> bumping ;)
[11:58] <asac> Keybuk: great. also write a MIR ;)
[11:58] <asac> hehe
[11:58] <pitti> asac: it was from http://cgit.freedesktop.org/~dcbw/udev-extras/commit/?id=95b96e3 FYI
[11:58] <asac> i can do that though
[11:58] <pitti> asac: juding by Keybuk's version number :)
[11:58] <Keybuk> MIR?
[11:59] <Keybuk> do you have something that depends on it now?
[11:59] <asac> Keybuk: well it would help to get rid of the modem mess we are doing in 10-mode.fdi
[11:59] <ogra> NM ?
[11:59] <asac> for 3g
[11:59] <asac> NM supports that now
[11:59] <Keybuk> asac: have you tested probe-modem at all?
[11:59] <cjwatson> such a hack, it should be done in the kernel instead :P
[11:59] <Keybuk> I packaged udev-extras simply because it was there
[11:59] <asac> heh
[11:59] <Keybuk> I haven't ever even installed it or played
[12:00] <Keybuk> I don't think Kay's done much testing yet
[12:00] <asac> Keybuk: well. we had a more hacky probe-modem code in 0.7 :)
[12:00] <cjwatson> indeed the kernel *does* do this for some modems
[12:00] <cjwatson> sporadically
[12:01] <asac> Keybuk: so NM falls back to hal if probe-modem fails. what kind of testing would you want?
[12:01] <cjwatson> (assuming that this is the "switch modem out of silly CD mode" thing)
[12:01] <asac> cjwatson: no its not
[12:01] <cjwatson> oh, ok
[12:01] <asac> cjwatson: its about probing for modem capabilites ... so we dont have to add a hal rule every modem out there
[12:01] <asac> cjwatson: the CD mode thing is kernel issue for sure
[12:01] <Keybuk> asac: well, some basic "does it work" testing would be good :)
[12:01] <cjwatson> capabilities> gotcha
[12:01] <pitti> cjwatson: it's supposed to replace /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi with a dynamic probing solution, to get rid of those static lists, which are always behind, and in some cases wrong
[12:02] <cjwatson> asac: right, ISTR the CD mode thing being in udev-extras as well which is why I mentioned it
[12:02] <asac> cjwatson: hmm. could be that they added something there. but dan always prays that it should be done in kernel
[12:03] <Keybuk> there's quite a bit in udev extras
[12:03] <asac> cjwatson: btw, did your hso fix flow upstream? is there anything we need to do for your modem in jaunty?
[12:03] <Keybuk> the prototype ACL code is in there too
[12:03] <Keybuk> (to replace the equivalent bit in HAL)
[12:03] <Keybuk> in fact, udev-extras could be described as "stuff to replace bits in HAL when it goes away"
[12:03] <Keybuk> right now, the right thing to do is probably still to use HAL
[12:03] <asac> Keybuk: hmm. so maybe we should make a probe-modem package out o it and promote just that (if our testing shows that it works a bit)
[12:04] <Keybuk> asac: maybe
[12:04] <asac> Keybuk: anyway. you said you already bumped it. i will test once the new versoin is in universe
[12:04] <Keybuk> *nods* it's uploaded, so test and play to your heart's content :p
[12:04] <asac> dan said its not ready for prime time, but its not hurting especially since we still have hal
[12:04] <cjwatson> asac: it's a bit stalled at the moment
[12:05] <asac> cjwatson: ok. where did it get stuck?
[12:05] <cjwatson> asac: I care a lot more about the kernel fix than about the hal fix, because the kernel is harder for me to tweak locally; Dan said, upon prodding, that he thought it looked OK and that he wanted to test it with some other hardware first, but I never heard anything else
[12:05] <cjwatson> asac: the hal fix is stalled because it was frankly a hack :-)
[12:05] <cjwatson> and they wanted to define a proper spec for this type of hardware instead
[12:05] <asac> cjwatson: ok. do you have any pointers? i can bug dan a bit ;)
[12:06] <cjwatson> asac: kernel: https://lists.one-eyed-alien.net/pipermail/usb-storage/2009-January/004499.html
[12:06] <cjwatson> asac: hal: http://lists.freedesktop.org/archives/hal/2009-January/012783.html
[12:06] <asac> hehe ... that first list uses HTTPS with a self-grown cert ;)
[12:06] <cjwatson> I think maybe the hal one will be superseded by this udev-extras work
[12:07] <cjwatson> so I'm not really interested in nagging about that part
[12:07] <asac> yeah
[12:07] <asac> just kernel part. understood
[12:07] <ogra> njpatel, so i now noticed why i dont see the notifications :) they are simply shown in black over the content of my black terminal background, the new positioning scheme is a massive mess ...
[12:07] <pitti> I recently sent a question about a pretty insolvable problem with 10-modem.fdi, and I also got that reply ("will get fixed with the udev modem prober")
[12:08] <asac> pitti: where did you send it?
[12:08] <cjwatson> https://lists.one-eyed-alien.net/pipermail/usb-storage/2009-January/004556.html -> "give me a day or two"
[12:08] <cjwatson> s/two/so/ - on Jan 24
[12:08] <pitti> asac: http://lists.freedesktop.org/archives/hal/2009-February/012995.html
[12:08] <cjwatson> asac: note that Option (the manufacturer) are a bit upset about all this, because they want the CD enabled by default for marketing purposes
[12:09] <cjwatson> asac: and there was a thread about that by e-mail
[12:09] <asac> cjwatson: eehh ... what use does that have on linux?
[12:09] <cjwatson> asac: Dan and I were both pretty firm that the OS should do the right thing damnit :-)
[12:09] <asac> thought they use it to install drivers on windows
[12:09] <asac> pitti: ah ok. hal list. thanks
[12:09] <cjwatson> asac: apparently it might occasionally contain documentation or other shiny things - TBH the engineering case is really weak
[12:10] <njpatel> ogra: ah right, that's not good
[12:10] <asac> cjwatson: i dont even see the marketing case ;)
[12:10] <asac> cjwatson: if the modem doesnt work that seems to be kind of perfect marketing ;)
[12:10] <cjwatson> that's what we said
[12:10] <asac> doesnt work as advertised ;)
[12:10] <cjwatson> work out of the box, damnit
[12:10] <pitti> tkamppeter: eww, debian bug 515918 looks like a serious regression
[12:10] <cjwatson> I think they maybe have some pressure from carriers, but I'm only reading between the lines here
[12:11] <cjwatson> however, we have no contract with the carriers
[12:11] <pitti> tkamppeter: that's probably due to switching to ghostscript mode from -13 to -14
[12:11] <cjwatson> I'm a little conscious that this is a company that is at least *trying* to work with Linux, mind ... but I don't think there's much we can sensibly do, we have a general goal of out-of-the-box
[12:12] <cjwatson> Dan suggested some technical adjustments they could make to future revisions to make things easier for us, which they seem to have tentatively acknowledged
[12:12] <cjwatson> in the meantime I think we should proceed as before
[12:15] <tkamppeter> pitti, Debian bug 515918 was not cauised by the transition from 13 to 14. 13 alreeady had tyhe problem according to the reporter of the bug.
[12:15] <pitti> tkamppeter: hm, but he says it hasn't happened with the non-PDF workflow
[12:16] <tkamppeter> pitti, ask him to post the PDF files which failed, the evince version, the PPD file(s) of his print queue(s).
[12:16] <pitti> tkamppeter: okay
[12:21] <Geek`N`Proud> Hey guys:  How safe are "proposed updates" with regards to core system functionality?  I'm more than happy to encounter a few bugs to prevent the average user, what's the worst I could expect realistically?
[12:22] <directhex> worst? unbootability
[12:22] <pitti> Geek`N`Proud: depends; if you install a new kernel from -proposed, then this might not even boot, and you need to go back to the previous one in teh grub boot menu (but of course those are the very things we are interested in getting feedback about)
[12:22] <Geek`N`Proud> ah that's fine
[12:23] <pitti> Geek`N`Proud: it really depends on the package; in the theoretical worst case, a package could fail to work completely
[12:23] <pitti> Geek`N`Proud: that doesn't actually happen that often, but we did have at least two miscompilations in Ubuntu's history, for example
[12:24] <pitti> Geek`N`Proud: with some effort and asking for help here, it should always be possible to recover from this, though
[12:24] <Geek`N`Proud> Was one of those glibc on Hardy BETA? :P
[12:25] <Geek`N`Proud> i'm willing to give it a go... with exception to the time glibc broke i've always recovered :D
[12:25] <Geek`N`Proud> thanks guys ^^
[12:25] <pitti> Geek`N`Proud: entirely possible, I don't remember any more; but "proposed" -> stable releases, != development release (beta)
[12:26] <pitti> Geek`N`Proud: thanks a lot; if you encounter a regression, please come here immediately and ping me, cjwatson, or slangasek; we all are 24/7 in IRC and read scrollback
[12:34] <Silicium> anyone know where in or around the casper on a live CD the gtkrc file for the live user is placed?
[12:34] <Silicium> and also the themes and gnome style
[12:37] <cjwatson> Silicium: ... what gtkrc file for the live user? it uses system defaults
[12:45] <asac> Keybuk: seems you use bzr-git for the udev-extras branch? how are your experiences. is that reliable?
[12:45] <asac> btw, there is no new commit yet
[12:47] <Keybuk> I'm not using bzr-git
[12:47] <Keybuk> I'm using git fast-export | bzr fast-import
[12:47] <Silicium> cjwatson: ok
[13:13] <AnAnt> Hello, is Ian Jackson here ?
[13:14] <soren> AnAnt: Nope.
[13:14] <directhex> doesn't he work for sun these days?
[13:15] <evand> Citrix
[13:15] <soren> Citrix
[13:15] <evand> :)
[13:15] <directhex> bah, i confused him with ian murdoch. i need more sleep!
[13:16] <directhex> murdock
[13:16] <directhex> even more sleep
[13:17] <AnAnt> so<EMAIL_ADDRESS>is invalid ?
[13:17] <cjwatson> it may still exist but that doesn't mean it gets read ...
[13:18] <cjwatson> actually it probably doesn't exist any more
[13:18] <cjwatson> perhaps you should say what you want rather than asking for a particular person, and somebody else may be able to help
[13:18] <AnAnt> well, regarding LP 144468
[13:19] <AnAnt> he solved it by doing: ulimit -Hl unlimited before running slmodemd
[13:19] <soren> Yes.
[13:20] <AnAnt> someone on Debian, commented on this fix as follows: If I'm not wrong, assigning unlimited locked memory can give the process
[13:20] <AnAnt> the ability to lock the whole machine: dropping the privileges loses
[13:20] <cjwatson> the justification for that in the changelog seems reasonable, yes
[13:20] <AnAnt> then part of its sense.
[13:20] <cjwatson> I don't think Ian would mind if somebody figured out a better fix that actually solved the original problem as well
[13:20] <AnAnt> the full comment is on debian bug 511996
[13:21] <cjwatson> such as making it use less memory
[13:21] <cjwatson> in the meantime it behooves anyone dealing with it in Ubuntu to avoid introducing regressions
[13:21] <AnAnt> cjwatson: well, I wanted to know his opinion about the comment
[13:22] <cjwatson> if a sane upper bound has been determined that's actually reliable, then I see no reason not to have a stricter bound
[13:23] <AnAnt> cjwatson: ok, thanks
[13:23] <cjwatson> you can google for Ian and find his contact details if you want
[13:24] <cjwatson> http://www.chiark.greenend.org.uk/~ijackson/contact.html
[13:29] <Koon> Archive Admins: what is our position regarding CDDL ?
[13:30] <directhex> Koon, CDDL is a free software license, it's just not GPL-compatible. why would it cause concern?
[13:31] <Koon> directhex: I thought it was controversial in Debian. If it's not, then I'm happy with it.
[13:31] <Koon> directhex: thx
[13:31] <directhex> Koon, i think some projects mix GPL with CDDL when they can't
[13:31] <directhex> e.g. cdrecord
[13:36] <Silicium> where is defined the liveCD default theme?
[13:36] <Silicium> so, i have changed the human themes color an icons
[13:36] <Silicium> and now i want to use this in the live cd
[13:37] <Silicium> i just have a .theme file
[13:38] <Silicium> ./usr/share/themes/Human/index.theme ?
[13:38] <Silicium> hmm i will try :p
[14:21] <Keybuk> slangasek: well, if you have UTC, one of the biggest changes in the new hwclock setting code is that hwclock isn't called at all <g>
[14:21] <Keybuk> so it's good to know it still works
[14:29] <pitti> Keybuk: I have this version installed as well, FYI, no problems so far; hwclock is still correct
[14:29] <pitti> Keybuk: but I also use UTC, and I didn't test large offsets or anything; is there something we should try?
[14:30] <Keybuk> the old bug was an American using a local time clock, who needed a filesystem check
[14:30] <Keybuk> reboot after the filesystem check, and all your modification times are in the future, and you need another one
[14:37] <Silicium> is there a channel for get help which are not dev type but also not beginner ones?
[14:38] <cody-somerville> mdke, I sent you an e-mail re: your e-mail this morning.
[14:40] <Silicium> sorry guys i need to ask this here, but nobody can answer me...
[14:41] <cody-somerville> Silicium, #ubuntu
[14:41] <Silicium> i cant get the point where is the actual user gnome theme defined
[14:41] <cody-somerville> Where the current one in use is defined?
[14:41] <Silicium> yes
[14:42] <cody-somerville> Probably in gconf
[14:42] <Silicium> that also i think\
[14:42] <Silicium> but i cant find
[14:43] <Silicium> nowhere i get help about that, no support chans, no mailinglists and no googling...
[14:43] <Silicium> is so damn crap
[14:43] <cody-somerville> Try /desktop/gnome/interface
[14:44] <Silicium> ok thanks
[14:44] <cody-somerville> (btw, google told me that)
[14:44] <Silicium> :/
[14:44] <cody-somerville> It was in the Gnome FAQ
[14:46] <MacSlow> mvo, I was a bastard and assigned you to https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/331037 sorry :)
[14:46] <mvo> MacSlow: I'm sure it includes a patch?
[14:46] <MacSlow> mvo, not yet
[14:47] <mvo> I like the "yet" in this :)
[14:47] <MacSlow> I knew :)
[14:47] <ogra> MacSlow, did you assign it to mvo because the subject starts with "alter" ? :)
[14:48] <mvo> lol
[14:48] <mvo> that would be more a dholbach bug ;)
[14:48] <MacSlow> ogra, Alter Schwede ... you're almost right :)
[14:48] <mvo> he started it all!
[14:48] <ogra> well, for dholbach it needs an additional exclamation mark or two :)
[14:48] <MacSlow> dholbach uses "Alter!"
[14:48] <dholbach> ¡¡¡¡ !!!!
[14:48]  * MacSlow uses "Alter Schwede!"
[14:48] <MacSlow> subtle difference :)(
[14:48] <MacSlow> :)
[14:55] <MacSlow> mvo, we use cdbs for compiz right?
[14:55] <MacSlow> outch ... not
[14:55] <MacSlow> it uses quilt
[14:55]  * MacSlow pukes
[14:55] <MacSlow> sorry for that :)
[14:56] <mvo> MacSlow: no need for a debdiff really
[14:56] <mvo> MacSlow: just the config snippet is enough, I can do the integration
[14:56] <MacSlow> mvo, phew ... ok
[15:00] <mvo> MacSlow: you probably want the "fade" from the animation plugin though
[15:00] <MacSlow> mvo, well I'm looking at the default install and there we have the normal Fade-plugin enabled in Jaunty
[15:01] <MacSlow> so that'll just get a new window-match rule "!Notification" instead of the old value "any"
[15:01] <mvo> MacSlow: right, but animation overrides the fadeing (if its enabled)
[15:01] <MacSlow> mvo, hm... didn't happen here
[15:01] <mvo> MacSlow: is the name of the window "Notification" ? I can add it then
[15:02] <MacSlow> I'll just make sure I'll add the needed bits to the animation -plugins changes too
[15:02] <MacSlow> mvo, it's acaually the class
[15:02] <MacSlow> not the window-title/name
[15:03] <mvo> MacSlow: thanks. strange still, animation should overrule fade, might be a but somewhere
[15:14] <MacSlow> mvo, just added the two patches to https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/331037
[15:15] <mvo> thanks MacSlow
[15:17] <mvo_>  MacSlow: with the patch that remove "Notification" from the default, will that mean that the old notifications will no longer be faded?
[15:17] <mvo_>  (if someone wants to use notification-daemon instead of alsdorf^Wnotify-osd?
[15:17] <mvo_> (sorry, got disconnected *again* *sigh*)
[15:17] <allquixotic> Are there any PPAs or otherwise out there which apply Ubuntu's .config (and maybe patches, but not important) to the latest prepatch of the upstream kernel, e.g. 2.6.29-rcX?
[15:17] <allquixotic> (and ship binary builds)?
[15:19] <cjwatson> apw: ^-
[15:19] <mvo_> MacSlow: could we make it so that the old ones sitll work? i.e. is there osmething to test for
[15:19] <apw> cjwatson, will answer in a sec
[15:21] <apw> allquixotic, https://wiki.ubuntu.com/KernelMainlineBuilds
[15:22] <MacSlow> mvo_ well we can at somepoint just name the notification windows differently
[15:22] <allquixotic> apw: thank you, I appreciate it :)
[15:22] <allquixotic> and thanks cjwatson for pinging
[15:22] <mvo_> MacSlow: that would be nice
[15:22] <MacSlow> mvo_ hm... wait with the patches
[15:22] <MacSlow> I'll just change that
[15:23] <mvo_> MacSlow: thanks, maybe type Notification is fine, just some name to be able to identify it?
[15:23] <mvo_> MacSlow: we have the !(name=compiz) rule
[15:24] <mvo_> we could extend that
[15:27] <mvo_> MacSlow: anyway, I'm standing ready and can upload at once :)
[15:49] <stgraber> ogra: any idea why ltsp-build-client wouldn't be called with current daily ?
[15:49] <stgraber> ogra: http://www.davmor2.co.uk/syslog
[15:50] <davmor2> ogra: if you need any other logs give me a shout
[15:51] <ogra> stgraber, hmm, weird, no ... i know cjwatson wanted to make some changes to the defaults for the actual inclusion of ltsp-client-builder, but i see the udeb is clearly executed, it just doesnt call ltsp-build-client
[15:52] <stgraber> ogra: I did a small change to disabled --mount-cdrom but I really doubt that's it
[15:53] <ogra> no, you would see errors
[15:53] <ogra> it doesnt even attempt to run ltsp-build-client
[15:54] <Keybuk> I think I need another monitor
[15:54] <cjwatson> the udeb isn't being loaded
[15:54] <cjwatson> oh
[15:54] <ogra> cjwatson, hmm ? what installs ltsp-server and frinds then ?
[15:54] <cjwatson> stgraber,ogra: I forgot to roll out my debian-cd change to antimony
[15:54] <ogra> *friends
[15:54] <ogra> ah
[15:54] <cjwatson> ogra: other bits of the preseed file
[15:54] <cjwatson> fixed for the next build, thanks
[15:55] <cjwatson> davmor2: ^-
[15:55] <davmor2> cjwatson: And there was me thinking it was the installer :)
[15:56] <BUGabundo> pgraner: ping
[15:56] <BUGabundo> can you take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/329254
[15:57] <BUGabundo> I'm starting to think it's the hibernate test of apport
[15:57] <BUGabundo> ogasawara: ping ^^^^^^^^
[15:59] <pgraner> BUGabundo: apw is handling all the suspend/resume testing...
[15:59] <pgraner> apw: ^^^^^^^^^^
[16:00] <BUGabundo> okay
[16:00] <BUGabundo> I've subs you to the bug... please remove your self then... sorry
[16:00]  * apw looks
[16:02] <BUGabundo> thanks apw
[16:03] <manjo> superm1, ping
[16:03] <manjo> superm1, I have 2 laptops for you
[16:05] <jdstrand> seb128: hi! I wanted to quickly ask you if I'm missing something obvious or should file a bug. 'Alt+F2' (Run application) hasn't worked for me in jaunty in a while (my keyboard shortcuts are correct). Does it for you? What package should I be looking at?
[16:08] <BUGabundo> apw: anything else you need from me, to add to the bug?
[16:08] <apw> sorry been on the phone
[16:08] <BUGabundo> np
[16:12] <apw> BUGabundo, ahh, those call traces are simply warnings that resume took a little longer than expected
[16:12] <BUGabundo> humm
[16:12] <BUGabundo> but hibernate now failes
[16:12] <apw> and yes, the web cam does seem to be the straw that takes up over the 5 second mark
[16:12] <BUGabundo> it was working on Saturday
[16:12] <BUGabundo> I removed the module, and installed -8 today
[16:12] <BUGabundo> and it still fails
[16:13] <BUGabundo> just awakes before shuting down
[16:13] <apw> Feb 17 01:17:00 blubug kernel: [15010.424230] PM: resume devices took 8.112 seconds
[16:13] <apw> ok if its not shutting down at all then its not that trace thats the issue
[16:14] <BUGabundo> then it has just coincidence?
[16:14] <Keybuk> cjwatson: you know that Fedora said they're supporting btrfs in F11 and ext4 is going to be the *default*?
[16:14] <BUGabundo> how lucky for me
[16:14] <cjwatson> Keybuk: mm-hm?
[16:14] <BUGabundo> Keybuk: really?  there goes competition
[16:14] <apw> that is just saying that the wake up took a long time, it doesn't change the behavior on eesume
[16:15] <Keybuk> cjwatson: and Fedora 11 is going to be the basis for RHEL 6
[16:15] <apw> if you clean boot and remove the webcam driver and it doesn't hibernate then there is a separate
[16:15] <cjwatson> how long will RHEL 6 take to stabilise, though?
[16:15] <apw> bug going on.
[16:15] <Keybuk> these two statements to me appear to be at odds with each other
[16:15] <cjwatson> could take quite a while ...
[16:15] <apw> i would file a new bug for that, and the first thing you should do is
[16:15] <BUGabundo> apw: but it simply fails... I don't know how to put it...
[16:15] <cjwatson> anyway, I imagine it wouldn't be hard to change the default filesystem in RHEL
[16:15] <Keybuk> true, that is the question I don't know the answer to
[16:15] <apw> try the hibernate from VT1 and run pm-hibernate there
[16:15] <BUGabundo> start regular hibernate, and then awakes, before disk stop
[16:16] <apw> BUGabundo, well that is a reasonable statement of the error
[16:16] <apw> if you could file it like that
[16:16] <BUGabundo> I tried yesterday from recovery console
[16:16] <apw> then do the test i just suggested, and also attach the dmesg output following the attempt to hibernate to the new bug
[16:16] <BUGabundo> already without driver loaded
[16:16] <BUGabundo> but with kernel -7
[16:17] <apw> and i would like to see the dmesg output from that, or a repeat on -8
[16:17] <BUGabundo> I haven't installed the driver to this new kernel
[16:17] <Keybuk> james_w: I vaguely remember you saying you'd eliminated a hwclock call
[16:17] <apw> even better
[16:17] <BUGabundo> will do in a few minutes
[16:17] <apw> as that confirms that its not that driver
[16:17] <Keybuk> james_w: was that in pm-utils or acpi-support
[16:17] <apw> if its not working without that driver, best to test without the driver
[16:17] <MacSlow> mvo__, outch I attached the wrong files to the compiz bug ...
[16:18] <apw> BUGabundo, i will write up what this erorr means in this old bug and close it off, so others who find it know what i means
[16:18] <apw> and let me know the new bug number
[16:18] <Riddell> james_w: what was the bzr-buildpackage command to create a temporary shell with your sources and packages together so you can edit then exit ?
[16:18] <BUGabundo> ok
[16:18] <BUGabundo> I'll sub you to it once I open it
[16:18] <BUGabundo> do you need the regular kernel tests too?
[16:18] <BUGabundo> or just dmesg apw?
[16:19] <apw> i am particularly interested in dmesg after the failed hibernate, as that should have hints as to how far down it got
[16:20] <BUGabundo> ok
[16:20] <mvo__> MacSlow: no worries, just give me the name/type to match against and I add it
[16:20] <BUGabundo> brb , reboot
[16:20] <tjaalton> hrm, apport tried to open the bug-filing page, but the url was "file:///ubuntu/.../+filebug/<hash>", which obviously failed
[16:20] <apw> tjaalton, that is the glib2.0 bug
[16:21] <apw> if you downgrade that to the previous ubuntu15 version it works again
[16:21] <tjaalton> apw: ok.. the kernel crashed on resume from hibernate, again.. but it's possibly just nvidia doing it's business
[16:22] <tjaalton> hmm, I've got 2.19.6-0ubuntu3
[16:22] <Keybuk> pitti: you have unreleased changes to acpi-support/
[16:22] <apw> nivce
[16:22] <apw> tjaalton, will check the versions i have either side of the bug
[16:22] <apw> i had to build the old one to confirm it was broken
[16:23] <tjaalton> apw: maybe I'll just upgrade and hope the problem goes away :)
[16:23] <apw> didn't for me yet
[16:23] <tjaalton> apw: the one that caused the crash
[16:23] <tjaalton> :)
[16:24] <apw> oh heh
[16:24] <apw> lets hope
[16:25] <tjaalton> resume from suspend just crashes X, so it's not quite as bad :)
[16:25] <apw> tjaalton, what a lovely life your laptop leads
[16:26] <tjaalton> apw: actually this is my desktop, but they both share the symptoms
[16:28] <apw> worse even
[16:29] <ScottK> bigon: In Debian when you updated pymsn to Change python-elementtree to python (>= 2.5) | python-elementtree that you changed just depends and not build-dep too?
[16:29] <ScottK> ... was there a reason ... is missing out of there
[16:32]  * Keybuk gets confused
[16:32] <Keybuk> so we have /etc/pm/sleep.d, /etc/acpi/suspend.d and /etc/apm/suspend.d
[16:32] <Keybuk> and all of them have different scripts in them
[16:32] <Keybuk> which is used? :)
[16:33] <cjwatson> Keybuk: yes
[16:33] <jdong> I thought pm/* was the only one that mattered these days?
[16:33] <ogra>  /etc/pm should be the default
[16:33] <Keybuk> so what are the others doing there?
[16:33] <jdong> "legacy API"
[16:33] <jdong> ;-)
[16:33] <ogra>  /usr/lib/pm-utils/ for systemwide settings
[16:34] <Keybuk> so what's all that /etc/acpi-support/suspend.d stuff doing there?
[16:34] <Keybuk> did somebody just not get around to removing it yet?
[16:35] <jdong> I think we still use some config optiosn in /etc/default/acpi-support
[16:35] <ogra> apmd ships the /etc/apm/ tree
[16:35] <ogra> (dont ask me why though)
[16:35] <jdong> and that just happens to ship the /etc/acpi-support tree
[16:35] <Keybuk> ogra: right, apm makes sense - some machines still only support apm
[16:35] <ogra> Keybuk, slangasek fiddled with acpi-support changes this cycle iirc
[16:36] <ogra> might still be something with hdparm stuff
[16:36] <slangasek> jdong: we aren't using them by choice; the whole thing should be phased out, but it should be faced out gracefully
[16:37] <Keybuk> slangasek: so what do the old suspend.d scripts do?
[16:37] <pitti> Keybuk: yes, slangasek asked me to not upload them yet
[16:37] <slangasek> Keybuk: handling suspending when you're using acpi-support for suspending instead of pm-utils
[16:37] <jdong> are the ac.d/battery.d events handled by acpi-support still?
[16:37] <Keybuk> slangasek: and how might you be using acpi-support instead of pm-utils?
[16:37] <pitti> Keybuk: yes, /etc/acpi-support/suspend.d/ should be killed, and the good bits perhaps carried over to /etc/pm/ scripts
[16:38] <slangasek> Keybuk: which I think happens, currently, if the suspend is triggered via an ACPI event and acpi-support sees that you don't have an active X session
[16:38] <ogra> and /etc/pm scripts need to be reviewed to not be darn slow :)
[16:38] <Keybuk> ok
[16:39] <slangasek> (I haven't dug into that to confirm; it should certainly be considered a bug, regardless)
[16:40] <Keybuk> ok
[16:40] <Keybuk> I'll update acpi-support "just in case"
[16:41] <Keybuk> james_w, slangasek: from the docs of pm-utils
[16:41] <Keybuk> +* If your clock drifts across a sleep/wake cycle, you can use
[16:41] <Keybuk> +  NEED_CLOCK_SYNC="true" to force pm-utils to synchronize clocks.
[16:41] <Keybuk> +  This is a change in the default behaviour of pm-utils -- <IP_ADDRESS> and earlier
[16:41] <Keybuk> +  always synchronized clocks, but doing so is slow and most hardware stays in
[16:41] <Keybuk> +  sync without assistance.
[16:41] <Keybuk> that's incorrect
[16:41] <Keybuk> it's not that the hardware stays in sync without assistance
[16:41] <Keybuk> it's that the kernel already contains code to synchronise them
[16:42]  * Keybuk isn't sure whether that was added upstream, the MoM diff is hard to read ;)
[16:52] <Keybuk> slangasek: ok, hwclock changes committed to bzr
[16:52] <Keybuk> upload at your leisure
[16:53] <slangasek> @whee
[16:54] <BUGabundo> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/331101
[16:55] <taavikko> someone able to say anything about this? https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/329161
[17:03] <Keybuk> slangasek: moving over here
[17:03] <slangasek> yah
[17:03] <Keybuk> powernowd uses the scaling driver and adjusts the frequency based on polling
[17:03] <Keybuk> I cannot see why ondemand wouldn't work?
[17:03] <slangasek> I don't know
[17:03] <slangasek> but that's what the init script claims to do
[17:04] <Keybuk> the init script simply seems to guard against the ondemand governor not existing
[17:04] <slangasek> hmm, ok
[17:04] <Keybuk> (ie. it pokes ondemand into scaling_governor, and is happy if that succeeds)
[17:04] <BUGabundo> apw: ping
[17:04] <Keybuk> certainly there's nothing in the ondemand governor code itself that would fail
[17:04] <apw> BUGabundo, hi
[17:04] <slangasek> Keybuk: right - let's axe the thing then :)
[17:05] <BUGabundo> did you see the bug linki?
[17:05] <BUGabundo> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/331101
[17:05] <apw> yep seen it
[17:08] <apw> BUGabundo, an update added to the bug
[17:08] <BUGabundo> ok
[17:08] <Keybuk> slangasek: this hwclock change fixes a lovely bug
[17:09] <slangasek> oh?
[17:09] <Keybuk> DST getting applied/removed across a suspend/resume cycle
[17:09] <Keybuk> what happened before
[17:09] <Keybuk> system clock saved to hardware clock on suspend (delta without DST)
[17:09] <Keybuk> on resume, system clock restored from hardware clock
[17:09] <Keybuk> but localtime() called, so it's assumed the delta was with DST
[17:09] <Keybuk> but since the kernel already adjusted it, it wasn't
[17:09] <slangasek> hee
[17:10] <Keybuk> and the whole thing got into a bit of a mess, and depending whether you're east or west
[17:10] <Keybuk> you'd either not have DST applied
[17:10] <Keybuk> or have double-DST
[17:10] <Keybuk> by not doing any of this, the hardware clock stays in non-DST localtime across a suspend/resume
[17:10] <Keybuk> which means the system clock stays in correct UTC across a suspend/resume
[17:10] <ogra> it should pop up a message "please move one TZ east/west" :)
[17:10] <Keybuk> which means all the software in userspace just works (because DST is calculated there anyway)
[17:11] <Keybuk> when we shut down, we're free of mid-air collisions, so the hardware clock is written out with the DST-adjusted time
[17:11] <slangasek> so when the user reboots to Windows they'll still get it double-applied, but that's why you shouldn't have your clock in localtime. :)
[17:12] <BUGabundo> apw: set to kernel again"
[17:12] <Keybuk> slangasek: exactly
[17:12] <BUGabundo> do I need to reboot, or does it work
[17:12] <apw> BUGabundo, ?
[17:12] <BUGabundo> right now?
[17:12] <BUGabundo> /etc/pm/config.d/00sleep_module
[17:12] <Keybuk> but Windows is pretty idiotic and if left on overnight, some versions still apply DST every time it reaches 2am
[17:12] <Keybuk> 2am, ah, DST, 1am now
[17:12] <Keybuk> 2am, ah, DST, 1am now
[17:12] <Keybuk> 2am, ah, DST, 1am now
[17:12] <Keybuk> 2am, ah, DST, 1am now
[17:12] <Keybuk> ...
[17:12] <apw> i would like to see if that workes yes
[17:13] <BUGabundo> but do I need to reboot?
[17:13] <apw> i don't believe so no
[17:13] <BUGabundo> or can I try it right now?
[17:13] <BUGabundo> ok
[17:13] <BUGabundo> brb
[17:17] <Keybuk> slangasek: I'll just de-seed powernowd, shall I?
[17:18] <slangasek> Keybuk: sure
[17:18] <slangasek> do you know an ETA for the corresponding kernel upload?
[17:19] <slangasek> also, should we be kicking this package clean out of the archive rather than demoting to universe?
[17:19] <Keybuk> well, it's claimed to be unmaintained by the author now
[17:20] <Keybuk> slangasek: "a few minutes" :)
[17:20] <slangasek> heh
[17:21] <BUGabundo1> apw: it works /TM)
[17:21] <BUGabundo1> slow as hell, but it works
[17:22] <BUGabundo1> took way too much to hibernate (compare to pm-utils with compressed image)
[17:22] <soren> Could a friendly archive admin please demote eucalyptus to multiverse?
[17:22] <BUGabundo1> and resume, just froze my desktop for a while (it used to be almost immediate)
[17:22] <soren> It has build-deps in there right now, so to get it built and all that before FF, we need it demoted.
[17:23] <Keybuk> slangasek: seed changes committed, shall I just go ahead and do ubuntu-meta on the basis the kernel is coming soon
[17:23] <soren> We'll be fixing this all up and moving it to universe (or main or whatver) later on.
[17:23] <slangasek> Keybuk: if it's really that soon, sure
[17:23] <Keybuk> since powernowd's init script is actually broken right now and not installing the scaling driver in the majority of cases, it's not likely to really break anything if people have it deinstalled before getting the kernel
[17:24] <BUGabundo1> apw: set to invalide the linux task?
[17:24] <slangasek> Keybuk: "in the majority of cases"?
[17:24] <Keybuk> slangasek: anything that should use acpi-cpufreq afaict
[17:24] <apw> BUGabundo1, cool.  i will handle the bug close, and shove it off to s2disk people
[17:24] <slangasek> Keybuk: acpi-cpufreq is loaded correctly for me here
[17:24] <apw> as they should be made aware s2disk isn't working in jaunty
[17:25] <Keybuk> slangasek: you have a /sys/devices/system/cpu/cpu0/cpufreq ?
[17:25] <slangasek> Keybuk: yes
[17:25] <BUGabundo1> apw: it was up until Saturday
[17:25] <apw> it was working until Sat?
[17:25] <BUGabundo1> will ubuntu ever use a faster hibernate kernel mode?
[17:25] <Keybuk> what does /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver say?
[17:25] <BUGabundo1> apw: yes it was
[17:25] <apw> BUGabundo1, define faster?
[17:25] <BUGabundo1> I even tested it and added to the wiki page for resume testing
[17:26] <slangasek> Keybuk: 'acpi-cpufreq' - this was all implicit in my statement that it was "loaded correctly" :)
[17:26] <Keybuk> slangasek: lucky git <g>
[17:26] <Keybuk> it's not loaded at all for me
[17:26] <apw> BUGabundo1, a good plan
[17:26] <BUGabundo1> humm I guess the best way for you to know, is for you to test
[17:26] <Keybuk> acpi-support seems to irrationally prefer speedstep-* to acpi-cpufreq
[17:27] <Keybuk> which of course promptly fail to load
[17:27] <BUGabundo1> for me, hibenate took much less and the timed count down helped A LOT
[17:27] <slangasek> hmm
[17:27] <ogra> Keybuk, still having the scripts in use ?
[17:27] <ogra> or is that plain kernel now
[17:27] <Keybuk> err
[17:27] <Keybuk> powernowd
[17:27] <BUGabundo1> apw: and then, desktop would be much faster to react
[17:27] <Keybuk> powernowd seems to irrationally prefer speedstep-* to acpi-cpufreq
[17:27] <Keybuk> wrong evil package
[17:27] <apw> BUGabundo1, with uswsusp ?  i see, well lets get someone from there to look at it
[17:27] <BUGabundo1> not its just slow.... and a black screen for 10 secs
[17:28] <BUGabundo1> apw: I been using it since hardy
[17:28] <Keybuk> BUGabundo1: what happens if you buy a faster disk?
[17:28] <BUGabundo1> and then you guys kicked it of the kernel
[17:28] <apw> if you could paste in any informaiton you have on the uswsusp into the bug
[17:28] <BUGabundo1> Keybuk: both uswsusp and kernel mode be faster?
[17:28] <apw> like what its version is now, and check if it got updated since saturday
[17:28] <BUGabundo1> humm apw I added my installed version
[17:29] <apw> see /var/log/apt/term.log or similar for that info
[17:29] <BUGabundo1> already deleted my weekend apt-changes
[17:29] <BUGabundo1> let me see if apt has it
[17:29] <BUGabundo1> yep that's it!
[17:30] <apw> mostly things get thrown own of the kernel when upstream gets it in their head that its not going to ever get finsihed
[17:30] <apw> and we don't get much control over that kind of thing
[17:30] <apw> BUGabundo1, heh its upgraded from 0.6 to 0.8 ... yeeks
[17:31] <BUGabundo1> revert then ?
[17:31] <BUGabundo1> or fix
[17:32] <apw> Keybuk, you look to be the last person who touched uswsusp you know who merged it from debian about 4 days ago?  The changelog doesn't seem to have a name in it?
[17:32] <Keybuk> apw: no idea
[17:33] <apw> the LP page myust be broken, will look at the diff ... sorry to bother
[17:33] <ogra> there should be a merge bug as well
[17:34] <ogra> if there is no name in the changelog it likely was synced from debian via a bug request
[17:34] <apw> there is one in the real changelog, just the LP page on the versions stops short of the -- WHO line for some reason
[17:35] <ogra> apw, Changed-By: Devid Antonio Filoni<EMAIL_ADDRESS>[17:35] <apw> ogra, thanks
[17:35] <ogra> it has done a jump from 0.7 to 0.8 with several debian versions inbetween
[17:35] <apw> yeah is all a bit scarey
[17:36] <apw> now to find Devid
[17:36] <ogra> well, its in niverse for a reason :)
[17:36] <ScottK> apw: He goes by devfil on IRC.
[17:36] <ogra> LP id ... should list his IRC nick
[17:36] <BUGabundo1> ogra: sure
[17:36] <BUGabundo1> but its way better then the kernel mode
[17:36] <apw> yeah and he is not about
[17:36] <apw> poop
[17:36] <BUGabundo1> much faster, and interative
[17:37] <ogra> BUGabundo1, if it would be better we would use it by default
[17:37] <ogra> it works faster on some machines
[17:37] <apw> and segfaults on others it seems
[17:37] <ogra> and breaks many others heavily
[17:37] <BUGabundo1> LOL
[17:37] <BUGabundo1> it just stared segfaulting...
[17:37] <BUGabundo1> not on any laptop I ever touched
[17:37] <BUGabundo1> but I followed one of it bugs....
[17:38] <BUGabundo1> heads rolled in there
[17:38] <BUGabundo1> ppl got to extremes
[17:38] <ogra> such is life ...
[17:38] <apw> its a contensious issue.  the kernel maintainers for the suspend stuff are more than one, and all very opionionated
[17:39] <ogra> i think the case BUGabundo1 means were ubuntu users
[17:39]  * ogra thinks he remembers that bug from the time where he cared for gnome-power-manager
[17:40] <apw> BUGabundo1, ok done what i can get this this to his attention,
[17:40] <apw> hopefully you will get contacted via your bug to test things
[17:41] <BUGabundo1> thanks
[17:41] <BUGabundo1> ogra: let me see if my ff awesome bar remember is
[17:41] <apw> you should have email updates for it
[17:43] <slangasek> Keybuk: wrt your request for a standing freeze exception, from a freeze policy standpoint I'm uncomfortable with this because it's not clear to me what is or isn't in scope (so I don't know what I'm agreeing to)
[17:43] <slangasek> Keybuk: could we narrow this somewhat?
[17:43] <Keybuk> how would you like it narrowed?
[17:43] <slangasek> well, start by telling me what you think is in scope? :)
[17:43] <Keybuk> anything that is started at boot-time
[17:44] <slangasek> heh
[17:44] <slangasek> see, that's why I'm concerned about it being a standing exception
[17:45] <slangasek> if it were "killing startup scripts we don't need" or "converting some init scripts to upstart jobs", that I could see giving a blanket exception for; but not "anything at boot"
[17:46] <Keybuk> it's not mostly that kind of thing
[17:46] <mathiaz> slangasek: I've tried to build openldap 2.4.14 based on your work and it works well
[17:46] <mathiaz> slangasek: which tests were failing?
[17:46] <mathiaz> slangasek: (that was on jaunty)
[17:47] <slangasek> mathiaz: one of the concurrency tests locked up with the hdb backend; I ran it twice more and it succeeded, so I guess it's racy :(
[17:48] <mathiaz> slangasek: ok - so do you plan to upload to unstable?
[17:48] <mathiaz> slangasek: I've got a package ready for jaunty
[17:49] <slangasek> mathiaz: there was a commit Quanah said we should pull, I was going to do that before upload to unstable
[17:51] <mathiaz> slangasek: are you still on track for an upload for today?
[17:51] <slangasek> mathiaz: to unstable, or to jaunty? :)
[17:52] <mathiaz> slangasek: unstable
[17:52] <mathiaz> slangasek: I can take care of jaunty
[17:52] <slangasek> mathiaz: if getting it in unstable helps you get it sorted in jaunty for FF, I will; otherwise the upload won't be a priority today
[17:52] <mathiaz> slangasek: I've already got a pkg ready (it's in a loomified bzr branch)
[18:01] <mathiaz> slangasek: I don't need an upload to debian. I'll base my work on the current content of the svn repository then.
[18:01] <mathiaz> slangasek: I'll add the two patches Quanah refered to
[18:01] <slangasek> mathiaz: ack
[18:02] <LaserJock> does anybody know if the archive reorg plan has any allowance for Universe-like lobes? some sort of split between supported and community-supported
[18:14] <persia> LaserJock, How do you mean?  I can't speak authoritatively, but I'm mostly familiar (and "lobes" is deprecated: "layers" is the appropriate term for (usually depends/recommends/build-depends closed) package sets)
[18:17] <LaserJock> persia: well, I'm wanting to create 2 layers (although I'm not sure if it's exactly equal to the seed "layer") for Edubuntu
[18:17] <LaserJock> one that roughly corresponds to Main and one corresponding to Universe
[18:17] <LaserJock> I don't want to create something that's going to disappear in a couple of months
[18:18] <Keybuk> asac: what happens if nm-applet starts but NetworkManager isn't running
[18:18] <cjwatson> it certainly won't disappear in a couple of months anyway
[18:18] <Keybuk> does it die, or does it wait patiently for it to start
[18:18] <cjwatson> I haven't updated the spec yet, but we're decoupling the permissioning changes from the actual component reorganisation
[18:19] <LaserJock> cjwatson: well, for Jaunty+1?
[18:19] <asac> Keybuk: it waits ... i even patched out that it doesnt show up ... so now you get an erroful icon and if you click on it it says "netowrkmanager not running"
[18:19] <Keybuk> so we don't need to start NetworkManager before gdm?
[18:19] <persia> cjwatson, so the components will probably remain, but the permissions will shift?  Will the components be considered to have semantic value?
[18:19] <asac> Keybuk: err. well. we have system-connections now
[18:20] <asac> so you can have a working network even without logging into X
[18:20] <Keybuk> asac: what I mean is, currently Network Manager is started before gdm
[18:20] <Keybuk> whereas if we started it after, we'd save a tenth of a second or so
[18:20] <Keybuk> and NM can do its thing while X starts
[18:20] <cjwatson> so the extension of permissions will happen first, and then we'll look at component work later once there are better facilities in LP
[18:20] <persia> LaserJock, Very loosely, a layer will correspond to a seed branch, and layers ought be permitted to depend upon other layers (as seed branches can depend upon other seed branches).  So, if you have two sets of seeds, you'll be well aligned.
[18:21] <allquixotic> Does anyone else get an error when running xdriinfo on Jaunty?
[18:21] <Keybuk> if the race went slow and NM wasn't quite ready when the session was logged in (which should be practically impossible, given X is 6s to start and compiz 10s) then is the worst that would happen that they'd get a brief error logo
[18:21] <asac> Keybuk: sure. as long as gdm can properly deal with a "suddenly appearing" network
[18:21] <cjwatson> also, I think we're just going back to "package sets" as the naming. [sorry.]
[18:21] <asac> Keybuk: at some point we hopefully get an applet like thing into gdm
[18:21] <Keybuk> asac: it has to anyway, starting NM just means the daemon is started - not that there's a network interface
[18:21] <asac> Keybuk: true. but starting it early enough ... ;)
[18:21] <Keybuk> the NM init script doesn't wait for NM to get a network connection up
[18:21] <cjwatson> LaserJock: as long as you think of them in terms of who's supposed to have upload access rather than in terms of main and universe, then with what persia says you should be fine
[18:21] <asac> right
[18:22] <asac> Keybuk: so which numbers should i use ;)?
[18:22] <LaserJock> cjwatson: I'm more concerned about the level of support than who can upload
[18:22] <Keybuk> asac: > 30 - 50 sounds sensible
[18:22] <asac> Keybuk: what is > 30 - 50? > 50 ?
[18:22] <asac> or between 30 and 50 ;)
[18:22] <persia> cjwatson, Actually, if there are no negative permissions based on Depends/Recommends/Build-Depends complete sets, "package sets" makes more sense than "layers".
[18:22] <Keybuk> asac: I mean "greater than 30", "50 sounds like a sensible number"
[18:23] <LaserJock> right now we can call Main the core set of apps and Universe the community supported "extras"
[18:23] <LaserJock> but I'm wondering if the archive reorg will make it very difficult to define any of that
[18:23] <persia> LaserJock, Well, that semantic meaning lost value a few releases ago, in terms of actual coordination of packages.
[18:23] <asac> Keybuk: ok so i use update-rc.d NetworkManager start 50 2 3 4 5 . then
[18:23] <Keybuk> asac: yup
[18:24] <persia> I believe Intrepid included changes to allow declaration of "Supported" separately from component.
[18:24] <cjwatson> LaserJock: if you regard this as an important distinction, there's no reason not to have separate sets
[18:24] <cjwatson> LaserJock: either in the old model or the new model
[18:24] <asac> Keybuk: ok done
[18:25] <LaserJock> persia: really? do you happen to know if gnome-app-install knows about that
[18:25] <asac> next upload will get that
[18:25] <LaserJock> the only bit I've seen is Main = "Canonical-maintained" in Intrepid
[18:25] <cjwatson> persia: I hadn't heard of that
[18:25] <persia> LaserJock, I think that's where it's implemented.
[18:25]  * persia hunts changelogs
[18:26] <cjwatson> (of course it's entirely possible it exists nevertheless, I'm not omniscient ;-) )
[18:26] <LaserJock> *gasp*
[18:26] <LaserJock> ok, so do people not find different levels of support as useful then?
[18:26] <persia> I don't know exactly where, but I recally being told by a couple people it was done.
[18:27] <LaserJock> I've always found the "Main is the core subset of apps we heavily support as a project" useful
[18:27] <asac> Keybuk: so why do you want this change actually? you think it reduces startup time?
[18:27] <Keybuk> asac: it does reduce startup time
[18:27] <asac> how much of a win?
[18:28] <Keybuk> moving a whole bunch of things in rc2.d to after gdm seems to buy us 3 seconds
[18:28] <asac> ok. lets try it then
[18:28] <persia> Hrm.  https://blueprints.launchpad.net/ubuntu/+spec/package-supportedness-ui is similar, but not quite it.
[18:30] <persia> LaserJock, cjwatson My apologies: I don't see it, which may well mean I'm mistaken.  mvo would know for sure.
[18:44] <cjwatson> LaserJock: I think it's useful, but main/universe has too many other things associated with it. That's, er, rather a lot of the point of archive reorg :)
[18:44] <LaserJock> cjwatson: right, I guess Edubuntu's a bit of a corner case
[18:45] <LaserJock> I think we're likely to have more problems than gains by permission changes
[18:45] <LaserJock> and the supportability bit was useful
[18:45]  * Keybuk has a moment
[18:45] <Keybuk> I've just completely forgotten what I just changed
[18:46] <Keybuk> oh, I remember
[18:46] <cjwatson> LaserJock: I don't see how anyone would have problems, TBH. It makes things more flexible; you can always constrain it back if you like
[18:47] <LaserJock> cjwatson: well, I wanted to leverage MOTU and they're kinda going away from what I understand
[18:47] <shtylman> cjwatson: so...I have hit a roadblock...the debian installer user-setup currently being used is hard coded to the /etc/kde3 directory
[18:47] <shtylman> what would I need to do to change that?
[18:47] <shtylman> I have found the user-setup script I need to change...but beyond that..
[18:48] <Keybuk> http://people.ubuntu.com/~scott/jaunty-20090218-5_cropped.png
[18:48] <shtylman> oops...wrong window...my bad others
[18:48] <LaserJock> for instance, will it be easy to say anybody in todays ~ubuntu-dev can upload a package that's in one of Edubuntu package sets?
[18:49] <geser> LaserJock: if I understood it correctly then yes, ~ubuntu-dev will be generalists that can upload nearly everything
[18:50] <LaserJock> geser: and ~ubuntu-dev will be roughly what it is today?
[18:50] <geser> yes, ~motu + ~core-dev
[18:51] <LaserJock> geser: and then can I restrict to something that's more ~core-dev?
[18:52] <LaserJock> I thought ~ubuntu-dev was going to get to upload to anything that wasn't in the package sets
[18:52]  * geser checks the wiki page again
[18:56] <geser> LaserJock: ~ubuntu-dev will get uploads to the entire archive (minus the restricted layer)
[18:56] <LaserJock> geser: so that sounds like ~core-dev
[18:57] <LaserJock> so MOTU are getting a promotion? :-)
[18:57] <geser> LaserJock: yes
[18:57] <LaserJock> well, I can't say I'm very excited about that
[18:58] <geser> LaserJock: it's not clear yet now the transition of ~motu to the new ~ubuntu-new will look like
[18:58] <LaserJock> that seems like something we should vote on or something
[18:58] <LaserJock> since it's a big bump in trust
[19:02] <geser> yes :/ but with the archive reorg you either have to promote motu or demote it to unseeded packages
[19:02] <ScottK> geser: With the exception of Universe flavors it's unseeded packages today, so it's not much of a demotion.
[19:03] <persia> And if you want to enable arbitrary overlapping package sets (e.g. The Ubuntu Haskell Team), the demotion can be very deep indeed.
[19:03] <ScottK> True.  Depends on how package sets are defined.
[19:03] <LaserJock> but that gives the package set owners the flexibilty to determine the appropriate level of trust
[19:04] <persia> LaserJock, *overlapping*
[19:04] <geser> ScottK: exactly, if you move the several gnome packages in universe to the desktop layer, the KDE packages to the KDE layer, the science programms perhaps to Edubuntu there won't be much left that many people might get interested in
[19:05] <persia> ScottK, Last I heard they were just lists of packages.  Most of the discussion has involved alignment with seeds, but I think that's not enforced currently.
[19:05] <LaserJock> geser: but I don't see why we can opt-in to that
[19:05] <LaserJock> *can't
[19:05] <LaserJock> since I seriously doubt we're gonna have exclusionary permissions
[19:09] <geser> but you might want to have a "core" set of packages in the layer which are important for the layer where only regular contributors/developers should be able to upload and auxiliary programs you might want MOTUs to allow to upload, so you need two package sets again
[19:10]  * Keybuk figures out where all the CPU is going while X is starting
[19:10] <LaserJock> geser: right
[19:11] <LaserJock> geser: so with the archive reorg can I set one package set permissions as current ~core-dev + edubuntu-dev and then another package set permissions as current ~ubuntu-dev?
[19:11] <geser> LaserJock: I don't understand the outcome of the ArchiveReorg completely myself yet, only some fragments
[19:11] <Keybuk> I was wondering why nautilus was eating lots of CPU
[19:11] <Keybuk> turns out it's "fading in" the desktop background
[19:12] <Keybuk> likewise gnome-panel chews CPU "sliding in" the panels
[19:12] <ogra> Keybuk, well, thats the reason we have dual core cpus nowadays, one core is for X the other for processing :P
[19:12] <persia> I didn't think arbitrary "core sets" were going to be considered.  I thought "restricted" package sets were only for things that were very special, like the kernel, or gcc.
[19:12] <jdong> hahahaha
[19:13] <jdong> I note that I never see panels "fading in" anyway because compiz bloody hangs the UI for 5 seconds on login anyway
[19:13] <davmor2> ogra: I thought that was why we had gpus :P
[19:13] <LaserJock> persia: that seems like a serious limitation
[19:13] <geser> persia: with "core" I meant the core of e.g. KDE or Gnome, which is important for the layer to work
[19:13] <ogra> davmor2, naaah, the gpu's are the replacement of the math co-processors :)
[19:13] <davmor2> :)
[19:14] <davmor2> Ah the geeks brain :)
[19:14] <jdong> I thought they were the replacement spaceheater unit now that we don't have Netbursts.
[19:14] <persia> geser, Right.  I think there won't be that.
[19:15] <geser> LaserJock: as there won't probably be a group which consists of currently ~core-dev, it might get difficult to grant upload right to current core-devs and I don't know either if it will be possible to exclude the new ~ubuntu-dev from upload rights
[19:15] <LaserJock> geser: right, which seems very uncool to me
[19:15] <persia> LaserJock, Why?
[19:16] <LaserJock> I didn't think the purpose of the archive reorganization was to promote current trust levels without asking
[19:16] <LaserJock> I thought it was to make it easier to add relevent people
[19:17] <persia> Well, it is, but the trick is to figure out what to do with all the existing people.
[19:17] <LaserJock> I don't particularly see why the current trust levels need to change
[19:17] <LaserJock> let the maintainers of the package sets figure out what permissions work for their project
[19:18] <persia> Well, surely you need some people who can upload to nearly anything, if only to handle NBS type stuff.
[19:18] <LaserJock> right
[19:19] <LaserJock> I think the TB/CC could help moderate if big issues come up
[19:19] <LaserJock> but for the most part, it's in the best interest of the project to allow as many uploaders as you're comfortable with
[19:20] <LaserJock> we've already set up that kind of system with ~motu and ~core-dev
[19:20] <persia> Right.  So, why wouldn't you be comfortable with anyone currently in ~ubuntu-dev?
[19:20] <LaserJock> on stuff that's currently in Main I'm most *certainly* not comfortable with that
[19:20] <persia> Well, for some classes of installations, but not others.
[19:20] <persia> I see.  What about the stuff in main that hasn't been touched by a core-dev since Dapper?
[19:21] <LaserJock> I barely trust half of MOTU with Universe, I sure as heck don't want them screwing around with core packages
[19:22] <lupine_85> allo allo. Anyone seen the .list for libcaptury0 recently?
[19:22] <LaserJock> persia: that should get fixed, but not by lowering the bar to uploading, IMO at least
[19:22] <persia> Well, what's a "core package"?  Is nautilus a "core package"?  How about for Kubuntu users?
[19:22] <lupine_85> 0.3.0+svn20070725-0ubuntu3
[19:22] <LaserJock> persia: something roughly Main
[19:22] <lupine_85> lupine@nick:/var/lib/dpkg/info$ file libcaptury0.list
[19:22] <lupine_85> libcaptury0.list: ASCII HTML document text, with very long lines
[19:23] <persia> LaserJock, And what about the many flavours of Ubuntu that aren't restricted to Main?
[19:23] <LaserJock> Main is by definition the core set of packages Ubuntu has chosen to fully support
[19:23] <lupine_85> kde-window-manager Depends: on this package and the broken .list prevents me from doing any upgrades
[19:24] <LaserJock> if a flavour or project wants to have a set of package they fully support then they should go for it
[19:24] <persia> Well, that was the original definition.  It's stretching it to say it's been true for the past few releases, which is the why behind Archive Reorganisation.
[19:24] <LaserJock> but I reject that the origina definition is a bad one
[19:24] <Riddell> lupine_85: no such problem here
[19:24] <LaserJock> *original
[19:24] <Riddell> lupine_85: try an apt-get install --reinstall libcaptury0
[19:24] <lupine_85> Riddell: same version?
[19:24] <persia> LaserJock, I don't claim it's bad, just that it hasn't matched practice in a while.
[19:25] <LaserJock> persia: right, so perhaps we should look at practice
[19:25] <lupine_85> I guess it could be filesystem corruption on my side
[19:25] <LaserJock> I see the archive reorganization as an oppritunity to match practice better with *existing* philosophy
[19:25] <Riddell> lupine_85: 0.3.0+svn20070725-0ubuntu3 is the latest, hasn't changed in a while
[19:25] <LaserJock> not match philosophy with existing practice
[19:26] <lupine_85> ok, thanks for looking
[19:26] <lupine_85> I think I should fsck it :D
[19:27] <persia> LaserJock, I think it's somewhere in-between: to define a philosophy that is meaningful for the current scale of activity, and a practice that matches that philosophy, where neither precisely matches the current environment.
[19:27] <LaserJock> I suppose, yeah
[19:27] <LaserJock> it just doesn't seem to be heading in a useful direction for me
[19:28] <persia> Otherwise, I'd argue that every official flavour ought be in Main, which makes Main much bigger, and unverse much smaller.
[19:28] <LaserJock> I think they should be
[19:28] <persia> OK, and so all the developers for those flavours should be core-dev?
[19:29] <LaserJock> core-dev + flavour specific devs
[19:29] <persia> OK.  That works.
[19:29] <LaserJock> if the flavour is fully supporting their project then it should be "Main"
[19:30] <persia> Now, on top of that, let's add the idea that there are certain specialist developers in a given area (e.g. Java, Games, Mozilla), and let them upload those things.  Are you still good with that model?
[19:30] <LaserJock> not so much
[19:30] <persia> OK.  Why shouldn't the mozillateam be able to upload the mozilla packages?
[19:30] <LaserJock> but I guess I could kinda roll with it
[19:31] <persia> OK.
[19:31] <LaserJock> I would prefer they be ubuntu-dev+
[19:32] <LaserJock> i.e. your an ubuntu-dev who specializes in Mozilla
[19:32] <persia> OK.  Let's say that someone who does Mozilla packaging can be allowed to upload the Mozilla packages, if they meet the requirements for being an Ubuntu Developer.
[19:33] <persia> Are you comfortable with that?
[19:33] <LaserJock> yeah, but they should me the requirements of a Core Dev for the core mozilla packages
[19:33] <LaserJock> *meet
[19:34] <persia> And we'll restrict those people to just their area (whatever it might be) until they either get inolved with other areas, or meet the requirements to upload to all of main.
[19:34] <persia> Well, I'd trust the team to manage that.  Presumably there's enough social pressure within the team that it's not an issue.  It's not like most of these teams are that big.
[19:35] <LaserJock> the requirements to uploading FF for instance should be quite a bit higher than generic extensions, say
[19:35] <persia> Well, I'd leave that to the team.  If there are separable sets of stuff with different requirements, they can have two subteams.  Would that work for you?
[19:36] <LaserJock> sure
[19:37] <persia> And then we add per-package uploaders, who can upload a specific package or packages where they have a deep specialisation, assuming they meet the requirements of an Ubuntu Developer.  Still good?
[19:37] <LaserJock> ish, yeah
[19:38] <LaserJock> I generally think per-package uploaders should be a necessarily evil at best
[19:38] <persia> Sure.
[19:39] <persia> So, with all of that, every person who qualifies as an Ubuntu Developer has the ability to upload to any of the packages in which they have sufficient knowledge or involvement with a team.
[19:39] <persia> So all the rest of the packages will probably only be uploaded by someone doing large-scale transisions, or similar work.
[19:40] <LaserJock> sorta yeah
[19:40] <persia> Given that most of those affect both Main and Universe, and given that we've already given special upload rights to everyone in ~ubuntu-dev, let's restrict that to core-dev.
[19:41] <LaserJock> well, I would say "Ubuntu Developer" is a necessary but not sufficent condition
[19:42] <persia> necessary but not sufficient for which?
[19:42] <LaserJock> for package sets
[19:43] <persia> Of course not.  As we've outlined above, they have to be core-dev, or involved with and accepted by a team, or have specialist knowledge in a package.
[19:43] <LaserJock> right
[19:44] <LaserJock> I'm onboard with that
[19:44] <persia> So, the easiest way to restrict the large transition uploads, etc. to core-dev is to toss all the rest of the packages into Main.
[19:45] <LaserJock> I don't exactly know why we'd want to limit that stuff to core-dev
[19:46] <LaserJock> if it's not in a package set I would think MOTU should be fine
[19:46] <persia> Well, nobody really cares for the packages, so they're just likely to bitrot unless well maintained in a sync source.
[19:46] <persia> If someone cares, the TB can authorise a team, or someone can be a specialist.
[19:47] <LaserJock> well, somebody *should* care about everything
[19:47] <LaserJock> what matters is the level of care
[19:47] <LaserJock> brb
[19:48] <persia> Well, sure.  So, firstly, encourage the development of teams to care for things, and make sure the rest is maintained by those developers we trust the most.
[20:05] <lupine_85> yep, that was it. multiply-claimed inodes right through /var/lib/dpkg
[20:06] <soren> StevenK: Around yet?
[20:10] <soren> I need an archive admin to move eucalyptus to multiverse.
[20:10] <james_w> Keybuk: pm-utils
[20:11] <james_w> Riddell: "bzr bd-do" if you still need it
[20:11] <james_w> Riddell: /usr/share/doc/bzr-builddeb/ has a user manual that mentions this
[20:33] <cjwatson> soren: done
[20:33]  * soren hugs cjwatson
[20:33] <soren> cjwatson: Thanks!
[20:40] <LaserJock> persia: ok, back
[20:41] <persia> OK.  So we left off having granted Ubuntu Developers permission to upload to various package sets, and core-dev to upload to all of Main, and having dumped all the rest of the packages also into main.
[20:42] <LaserJock> right
[20:42] <persia> At this point, universe consists only of those packages that are in package sets with teams given special permissions to upload.
[20:42] <persia> Since the special permissions are special, we may as well toss those in main also: it won't affect anything.
[20:43] <persia> Now we have main, restricted, and multiverse, with complex upload permissions in main.
[20:43] <slangasek> directhex: is anyone working on gmime2.2?  That seems to be the last bit pulling libmono-corlib1.0-cil onto the CDs (via tomboy)
[20:43] <geser> and this won't make any package sets "better" than others
[20:43] <persia> geser, Right.
[20:43] <directhex> slangasek, it's not team maintained is it
[20:43] <slangasek> directhex: nope
[20:43] <LaserJock> persia: ok, I'm seeing some end to the tunnel now
[20:44] <directhex> slangasek, i don't know of any contact with the maintainer
[20:44] <persia> Now we rename "restricted" to "restricted-drivers" and we rename "multiverse" to "restricted-software" just to make the distinction more clear.
[20:44] <slangasek> directhex: transitioning it is just switching to gmcs, right?
[20:44] <persia> So, thats the emerging philosophy, as I understand it.
[20:45] <directhex> slangasek, best-case, switching the build-dep from mono-* to mono-devel and forcing "csc" as a compiler
[20:45] <LaserJock> persia: one thing I'm not certain on is that it would seem we're dramatically lowering the number of generalists
[20:45] <LaserJock> if core-dev is now the "catch-all" team
[20:46] <jetsaredim> is it possible to implement link handling in desktop notifications (meaning the text of a notification has a link in it - convert to a clickable object which opens a window in browser)
[20:46]  * slangasek nods to directhex, and queues up giving that a whack later
[20:46] <persia> Indeed.  So to address that, we look to the other team of generalists we have, MOTU.  Since universe is gone, MOTU doesn't have anything to do.
[20:46] <persia> So those of them that are interested would become core-dev to help out.
[20:47] <LaserJock> ok, but that then moves them into the "can upload anything" group
[20:47] <LaserJock> which affects the package sets
[20:47] <persia> But since there really isn't a core anymore, we rename the core-dev team to "Generalists" or something.
[20:47] <cjwatson> we'll need to go through MOTU case by case in the process
[20:47] <cjwatson> I believe that this is even explicitly recognised in the spec
[20:47]  * ScottK thinks it is.
[20:47] <LaserJock> cjwatson: so like a massive core-dev app process :-)
[20:48] <persia> Also, because we've added so many additional generalists, we reserve some special packages (like the kernel or gcc) to be restricted, so that only specialists can upload them.
[20:48] <cjwatson> sort of, but recognising in the process that many of MOTU in fact already meet the requirements despite not having applied, and many of the rest only care about some particular area
[20:48] <directhex> slangasek, poot, it's not in svn - but the package was RFA'd & meebey can upload
[20:48] <LaserJock> cjwatson: who recognises that?
[20:48] <cjwatson> which leaves us only with the problem of dealing with the people who (a) don't yet meet core-dev requirements and (b) can't be adequately trained in a few months or so
[20:49] <persia> cjwatson, More a) don't meet requirements, b) can't be trained in time, and c) don't fit better into one of the more specialised teams.
[20:49] <cjwatson> LaserJock: I was speaking only for myself, but the decision would be made by the TB. Note that I did not say "all"
[20:49] <cjwatson> persia: I thought I'd covered that in my previous utterance, but if you want to be explicit, certainly
[20:50] <LaserJock> but we're still talking about a pretty significant bump in trust level
[20:50] <LaserJock> I'm think in terms for protecting package sets from the generalists
[20:50] <LaserJock> s/for/of/
[20:50] <persia> Why, if the TB believes that those generalists would be suitable for core-dev did they get around to applying?
[20:51] <meebey> slangasek: plan was to get package maintained in pkg-gnome, but they didn't reply yet (since about 3 weeks)
[20:51] <LaserJock> persia: is that for me?
[20:51] <persia> LaserJock, Yes.  Sorry.
[20:51] <LaserJock> persia: because they're obviously not suitable
[20:52] <cjwatson> LaserJock: are we really? I'm actually not convinced. MOTU is already root on most Ubuntu users' systems; nearly everyone installs something from universe.
[20:52] <persia> LaserJock, Hrm?  If the TB indicates they are suitable, wouldn't they be suitable?
[20:52] <slangasek> meebey: ah
[20:52] <LaserJock> persia: well, not in my opinion
[20:52] <LaserJock> but whatever
[20:52] <cjwatson> and we already have lots of ways to keep track of what people are doing; if people mess with something that other people actually care about, then they will be noticed
[20:52] <LaserJock> I don't think the TB is currently capable of making a sound decision on that
[20:52] <LaserJock> they've already delegated away most of these decisions
[20:53] <LaserJock> I don't see how they're going to be able to go through ~ 100 applications in a timely manner without cutting corners
[20:53] <LaserJock> there will also be a tremendous social pressure to just let people in
[20:53]  * cjwatson feels under no such pressure
[20:53] <persia> Well, sure, but that's a transition pain.
[20:53] <LaserJock> so no, I personally don't think the TB can just find people suitable
[20:53] <meebey> slangasek: as I am no C hacker, I don't want to take full maintainer ship of it
[20:54] <persia> I don't think the TB will just "find people suitable", but rather that they would select those people who they would find suitable if they applied for core-dev.
[20:54] <slangasek> meebey: ah, don't look at me, I'm only interested in getting the transition done :)
[20:54] <ajmitch> persia: is all this written down somewhere so I can catch up?
[20:54] <LaserJock> ok, but why aren't they already core devs?
[20:54] <LaserJock> people generally apply for things they are suitable for
[20:54] <persia> ajmitch, The spec has an outline, but you'll have to check the backlog for the socratic presentation.
[20:55] <meebey> slangasek: hehe too bad, ok :)
[20:55] <directhex> meebey, isn't slomo our pkg-gnome guy?
[20:55] <meebey> directhex: he is? shoot him! :-P
[20:55] <LaserJock> the assumption seems to be that most MOTU are ready for core-dev, they just haven't applied for whatever reason
[20:55] <ajmitch> persia: just trying to grasp what happens to exsiting MOTUs & core devs
[20:55] <LaserJock> which seems to be counter to Ubuntu's history
[20:55] <meebey> directhex: he didn't reply either so...
[20:55] <meebey> directhex: I dont think he has interest
[20:55] <persia> LaserJock, Remember, we pulled in all the flavours, so suddenly all the flavour developers need to be core-dev.  Speaking for myself, none of the flavours on which I work are in main.
[20:56] <geser> ajmitch: it's not really decided yet besides that the groups should get merged somehow
[20:56] <cjwatson> I think the number is 66, not 100, BTW
[20:56] <LaserJock> persia: no, they *shouldn't* be core-devs
[20:56] <cjwatson> LaserJock: I've certainly seen plenty of instances where people needed to be encouraged to apply
[20:56] <LaserJock> cjwatson: right, but you're assuming that thats the case with the majority of current MOTUs, right?
[20:57] <LaserJock> or do you plan on tossing out most?
[20:57] <cjwatson> I'm looking through the names and trying to work out who would scare me if they could upload to everything rather than just to things that lots of Ubuntu users use even though they aren't in main
[20:57] <cjwatson> there seems to be an implicit assumption going on here that universe is somehow safe
[20:57] <cjwatson> it is not
[20:58] <RAOF> Some of this will be dealt with by marking some groups of packages specialist-only, right?  It's not quite the same as a strict MOTU->core-dev transition.
[20:58] <LaserJock> safe?
[20:58] <cjwatson> the ability to upload to directly universe is already a very high trust level
[20:58] <cjwatson> directly to
[20:58] <LaserJock> ah, I see what you mean
[20:58]  * directhex uploads directly to RAOF
[20:58] <cjwatson> and therefore the relevant question is whether I am scared that people will suddenly decide to break glibc or whatever
[20:58] <LaserJock> well, I think it is and frankly I think it's mostly given out all to quicly
[20:58] <persia> RAOF, I believe that will only be a very small set of packages, where even most current core-dev oughtn't be playing randomly.
[20:58] <ajmitch> persia: like the kernel?
[20:58] <cjwatson> in the full knowledge that people will notice (assuming that the package actually matters)
[20:59] <persia> ajmitch, That's my expectation.
[20:59] <cjwatson> persia: I don't think the question of exactly how small has really been explored very much
[20:59] <LaserJock> cjwatson: I'd be seriously afraid of any packages I care about
[20:59] <cjwatson> LaserJock: why wouldn't you notice if somebody broke them?
[20:59] <calc> or randomly firing off OOo builds on cd release week ;-)
[20:59] <LaserJock> cjwatson: I don't want the broke in the first place!
[20:59] <ajmitch> calc: well, if they're brave enough to get that source package uploaded... :)
[20:59] <cjwatson> I care about stuff in universe as well as in main
[20:59] <calc> anyone who wants to fix OOo bugs be my guest, just need to coordinate uploads
[21:00] <cjwatson> I am not scared about MOTU breaking it
[21:00] <LaserJock> you aren't?
[21:00] <cjwatson> nope
[21:00] <LaserJock> I am for sure
[21:00] <cjwatson> I think you're too paranoid, then :)
[21:00] <pitti> with our current TIL practice I'm not really scared either, TBH
[21:00] <cjwatson> occasionally I might have to go and reeducate somebody
[21:00] <cjwatson> but it's pretty rare
[21:00] <LaserJock> ok, so say I'm paranoid
[21:01] <pitti> I don't ever recommend anyone for MOTU whom I don't trust to ask if he encounters something unknown
[21:01] <LaserJock> is there a mechanism in the archive reorg where paranoia will be OK?
[21:01] <cjwatson> we have always said that Ubuntu will be about team-maintainership
[21:01] <pitti> LaserJock: I'm not saying that you are wrong, just my personal feeling
[21:01] <LaserJock> that is, can I lock out "core-dev" from a project?
[21:01] <LaserJock> pitti: sure, I know
[21:01] <cjwatson> if anything, we have gone too far in the direction of individualism
[21:01] <LaserJock> I don't trust probably 50% of MOTU as it is
[21:02] <geser> LaserJock: why didn't you comment on MOTU applications if you think they aren't ready yet?
[21:02] <LaserJock> making them core dev scares me a lot
[21:02] <cjwatson> LaserJock: the technical capability will be there, but we strongly discourage people taking a maintainer lock
[21:02] <LaserJock> geser: because it's largely pointless
[21:02] <cjwatson> LaserJock: if you said that in your own core-dev application, the TB would be thinking quite hard about whether to say yes, frankly
[21:02] <pitti> frankly, I don't believe that the current set of MOTUs just counts down the time when they can jump and upload a new glibc
[21:02] <persia> LaserJock, Why?  We do reject some applications, if there is controversy, or delay them for long enough that we feel comfortable.
[21:02] <LaserJock> pitti: I don't either, for sure
[21:02] <cjwatson> because one of the things we typically test is whether people are willing and able to work as part of a team
[21:03] <LaserJock> cjwatson: teams are great!
[21:03] <pitti> if they were, they had applied already, presumably
[21:03] <cjwatson> ... to work as part of the Ubuntu development team
[21:03] <LaserJock> I just want to be able to trust my team to work as a team and not break things too much
[21:03] <cjwatson> not just the team of people they like
[21:03] <Amaranth> pitti: I dunno, I'm getting excited about uploading a new kernel, glibc, firefox, and OOo
[21:03] <Amaranth> :P
[21:04] <geser> Amaranth: don't forget dash
[21:04] <pitti> Amaranth: deal! you fix it all, become TIL, and receive all the blame/bugs :)
[21:04] <RAOF> Amaranth: I think you missed out gcc there.
[21:04] <cjwatson> LaserJock: I'm very worried by the fact that you say you regard some incoming MOTU as inadequate, but intentionally fail to comment on their applications
[21:04] <Adri2000> slangasek: I think you're the best person to review/ack the samba sru, and review/upload the debdiff. could you do that?
[21:04] <cjwatson> I think it is the responsibility of team members to speak up when they see problems
[21:05] <Amaranth> RAOF: I'll put a virus in gcc that puts it into new gccs compiled with that gcc
[21:05] <LaserJock> cjwatson: well, most of the time these days I've never even heard of the people
[21:05] <LaserJock> cjwatson: but on occasions when people have brought up issues they're generally told to stop being mean
[21:05] <LaserJock> gives much less motivation to say something if you're just gonna get flamed for it
[21:06] <cjwatson> and from what I see the new MOTU approval process seems to be largely consensus-driven; I can't remember the last time I saw a successful application that included negative comments, and I know there are some failed applications, which suggests that there are applications that fail due to negative comments
[21:06] <cjwatson> LaserJock: I'd very much like to see a reference for that remark
[21:06] <cjwatson> examples
[21:06] <cjwatson> because that is a critical failure
[21:06] <LaserJock> cjwatson: it's consensus of those who speak up, yes
[21:07] <cjwatson> those who choose not to speak up have abrogated some of their moral right to criticise the process, IMO
[21:07] <persia> cjwatson, There was actually a recent application that contained a couple semi-negative comments and was approved, but the comments were all addressed to the commentor's satisfaction before approval.
[21:07] <cjwatson> persia: right, I mean unresolved negative comments
[21:08] <LaserJock> cjwatson: I realize that. It's certainly not my desire to just hold my tongue all the time
[21:08] <LaserJock> I'd rather not drag names around
[21:09] <cjwatson> in any case, I did already bring up the "there are some members of MOTU whom I'd rather not see in core-dev" issue with Mark et al
[21:09] <cjwatson> it was acknowledged and we will explicitly address it as part of any implementation of the reorg
[21:09] <LaserJock> I mean, I thought we had the MOTU/Core Dev split for a reason
[21:10] <slangasek> Adri2000: you might ask around whether anyone in the server team could do the upload?  If I do the upload, then another member of the SRU team should approve the SRU itself
[21:10] <cjwatson> we had it for reasons that made sense four years ago
[21:10] <LaserJock> if we're going to abandon that and go more Debian-style then we can talk about that I guess
[21:10] <cjwatson> I honestly do not think that those reasons make direct sense any more
[21:10] <LaserJock> but I haven't seen a lot of discussion on -devel about that
[21:10] <cjwatson> god, I've been discussing this until I'm blue in the face everywhere I can find
[21:10] <cjwatson> I'm not going to take criticism about it being under-discussed :P
[21:11] <cjwatson> I feel like I never stop talking about it
[21:11] <LaserJock> well, no offence, but maybe you've been talking in the wrong direction
[21:11] <Amaranth> Whatever the solution is I just want it to allow me to do compiz uploads
[21:11] <cjwatson> I am stepping back from this conversation because if I do not I will violate the code of conduct
[21:12] <directhex> let's swap recipes instead. how'd you like some bacon cookies, cjwatson?
[21:12] <LaserJock> I haven't seen this specific issue of bumping developer permissions on -devel ever
[21:12] <Amaranth> directhex: I'll trade you for my cheese cookies
[21:12] <LaserJock> perhaps it would mean less repeating if we could hash it on more on -devel
[21:13] <LaserJock> cjwatson: that's fine dude, I've learned a lot about the plan through the conversation, and I *do* trust you
[21:14] <LaserJock> so I'll let you get back to more important work
[21:14] <RAOF> Amaranth, directhex: You should breed those cookies.  Cheese and bacon?  MMmmm.
[21:14] <Adri2000> slangasek: oh ok, needs two different people... then, mathiaz? could you sponsor my debdiff for the samba sru?
[21:14] <directhex> RAOF, i don't know how well the cheese would go with the choc chip
[21:15] <cjwatson> LaserJock: it has at least been mentioned in TB meeting minutes
[21:15] <cjwatson> which received zero (0) comments
[21:18] <Laney> heh
[21:18] <Laney> oops
[21:18] <slangasek> cjwatson: I guess there's no MIR yet for grub2 (for grub-common); shall I go ahead and do that, or do you have some hidden state on that question that I should pull in?
[21:19] <cjwatson> slangasek: no hidden state, no; please do
[21:20] <cjwatson> LaserJock: I'm not fishing for compliments, and I do want to hear about problems. I really think this is something I've already made an effort to take account of, though, and I'm not sure I'm comfortable with the tone of a conversation that seems to essentially be "half my colleagues suck"
[21:21] <LaserJock> cjwatson: right, I see what you're saying for sure
[21:21] <cjwatson> it just seems pretty defeatist, and to fail to recognise that if that is the case then we should be doing something about it entirely independently of the reorg
[21:21] <cjwatson> because if half of MOTU sucks, then those sucky people *already* have a very high privilege level
[21:21] <LaserJock> yep
[21:22] <cjwatson> one thing I have thought of is that maybe a reorg gives us the opportunity/excuse/whatever to reevaluate those people who have been in MOTU for years but aren't core-dev
[21:22] <cjwatson> because originally MOTU was conceived at least in part as an on-ramp
[21:22] <LaserJock> yeah, I thought about that too
[21:22] <jcastro> Come on LaserJock! Half-full bro! half full.
[21:23] <cjwatson> I don't especially want to have a rah-rah don't we all rock conversation either :)
[21:23] <LaserJock> jcastro: well, if there's a big hole in the bottom it's kinda hard ;-)
[21:23] <directhex> jcastro, the glass is not half full. or half-empty. the glass is in need of a top-up
[21:24] <LaserJock> I've been told for the last couple years that we need to lower the barrier to entry and not be "mean" to people by asking tough questions of applicants
[21:24] <cjwatson> if nothing else I suspect that there is at least some expiry that can be done
[21:24] <LaserJock> I guess I let that get the better of me in the conversation, which isn't good
[21:24] <directhex> LaserJock, adopt the debian NM process!
[21:25] <LaserJock> I'd rather not
[21:25] <cjwatson> there is a problem with lots of Ubuntu being in some ways a reaction to problems in Debian
[21:25] <cjwatson> we fail to pick up the good stuff sometimes
[21:25] <cjwatson> Debian NM is an unnecessarily protracted process, and in particular it is slow even for good people
[21:25] <LaserJock> I guess my general feeling is that it's good to have the applicant prove themselves rather than everybody else have to prove why not
[21:25] <directhex> on a related note, where is cjwatson based? i need a key signed to start debian NM process
[21:26] <LaserJock> but I guess I can see where the philosophy isn't exactly the best way to grow a developer community
[21:26] <cjwatson> the questions asked in Debian NM are occasionally way over the top and things that I don't know offhand after eight years of being a Debian developer, so in some ways they just test your ability to look things up
[21:26] <LaserJock> the problem for me is rarely the technical skills
[21:27] <cjwatson> but on the other hand, the fact that the process is seen as difficult means that there is more kudos attached to completing it, and it means that people really try hard
[21:27] <LaserJock> but I've seen people become MOTU who are quite immature and don't seem to understand when to ask and when to "just do it"
[21:28] <LaserJock> we've created quite a bit of "policing" such as motu-release and motu-sru because we don't trust each other
[21:28] <cjwatson> the people who do well in their Debian application processes are those who spend the NM delay time sitting there building up expertise and bombarding people with good patches until other developers are begging for them to be let in
[21:28] <cjwatson> directhex: Cambridge
[21:28] <directhex> oh, that Other place
[21:28] <cjwatson> you should've asked, I drove by Oxford last weekend ;)
[21:28] <directhex> cjwatson, reckon i need more than one signature?
[21:28] <cjwatson> being in the web of trust at all was fine last I checked
[21:29] <Mithrandir> cjwatson: if you manage to get to Cam, getting ten sigs should be a SMOBB
[21:29] <Mithrandir> uhm
[21:29] <ajmitch> directhex: your bias is showing :)
[21:29] <Mithrandir> s/cjwatson/directhex/
[21:30] <directhex> hm, yes, i think i can rustle up a second DD in oxford
[21:30] <cjwatson> LaserJock: I agree regarding policing; excess requiring of signoff for things is something that generally bothers me. OTOH I also have a bias towards actually getting releases out so meh :)
[21:31] <LaserJock> cjwatson: +1 ;-)
[21:31] <directhex> ajmitch, bias?
[21:31] <cjwatson> LaserJock: although speaking of merging things, the members of motu-release and motu-sru are pretty experienced guys. Why do we have separate ubuntu- vs. motu- teams there?
[21:31] <cjwatson> or, maybe more relevantly, why do we need separate teams?
[21:31] <LaserJock> cjwatson: Main, vs Universe
[21:32] <LaserJock> I tried to get them into one at one point
[21:32] <cjwatson> that's an answer for how they arose, but not an answer as to why they're needed
[21:32] <kirkland> so does FF go into effect at midnight UTC ?
[21:32] <persia> kirkland, Yes.  148 minutes.
[21:32] <mvo> ha! plenty of time
[21:32] <cjwatson> the separation there means that motu-release don't get the opportunity to learn from the "main" release team, etc.
[21:33] <LaserJock> cjwatson: because having non-Core Devs approving Core Dev actions seems weird?
[21:33] <pitti> didn't it say "slangasek's morning"?
[21:33] <kirkland> begin haphazard commits now.
[21:33] <kirkland> :-)
[21:33] <kirkland> persia: thanks.
[21:33] <LaserJock> cjwatson: I totally agree
[21:33]  * pitti pedals faster
[21:33] <Amaranth> mvo: Quick, upload gnome-do and enable docky :)
[21:33] <LaserJock> cjwatson: they also have to have different task lists, etc.
[21:33] <cjwatson> LaserJock: motu-release and motu-sru aren't enforced to be core devs, but those are teams of people whom I would expect to be uncontroversial for core-dev if they aren't already
[21:33] <RAOF> Amaranth: Too slow!  It's already in!
[21:33] <cjwatson> LaserJock: and we could deal with different task lists by launchpad's component filtering for bug queries, almost entirely
[21:33] <Amaranth> RAOF: I meant by default :P
[21:34] <RAOF> Amaranth: Now that _would_ be desktop-eXperience :P
[21:34] <LaserJock> cjwatson: well .... I personally don't know that I'd recommend them all for Core Dev, but maybe they'd get through OK
[21:34] <cjwatson> at least I would expect them to be able to learn pretty quickly given incentive
[21:35] <ajmitch> cjwatson: you mentioned expiry - wouldn't the usual LP team expiry work in most cases?
[21:35] <persia> Actually, many if both teams are often also core-dev.
[21:35] <cjwatson> ajmitch: to some extent. It tests that people are reading e-mail, but not that they're actually still doing anything
[21:35] <cjwatson> IOW it's an "are you still on the Internet?" policy
[21:35]  * Amaranth wasn't reading email :(
[21:35] <savvas> mvo: could you take a look at the first draft for the end-of-life page your requested? https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/319146 http://launchpadlibrarian.net/22419716/end-of-life_document.txt
[21:35] <LaserJock> cjwatson: when I was working on the QA team I pushed for essentially making -sru one team
[21:36] <savvas> *you
[21:36] <cjwatson> which is better than nothing, but doesn't deal with people who just haven't uploaded anything for three years
[21:36] <cjwatson> LaserJock: I think I'd like to reopen that discussion
[21:36]  * Amaranth also hasn't uploaded anything in a long time
[21:36] <LaserJock> cjwatson: awesome, I think it makes things so much easier
[21:36] <ajmitch> true, it's only a 1-week window
[21:36] <cjwatson> Amaranth: because compiz is in main, right? :)
[21:36] <Amaranth> cjwatson: Right
[21:37] <Amaranth> Everything I've ever touched moved to main
[21:37] <cjwatson> Amaranth: did you ever apply for core-dev?
[21:37] <cjwatson> I'm curious
[21:37] <Amaranth> No, never had enough package uploads in universe to think I'd get it
[21:37]  * LaserJock feels a "told you so" coming on ;-)
[21:37] <slytherin> Hi, next time someone refreshes ubuntu-meta package, can you please remove libpt-1.10.10-plugins-* packages? They are not used by ekiga anymore.
[21:37] <Amaranth> and now I'm not even MOTU
[21:38] <mvo> Amaranth: you don't have to, you just commit to the compiz bzr and I sposnor it ;)
[21:38] <cjwatson> I don't say I told you so when it's obvious ;-)
[21:38] <cjwatson> slytherin: somebody needs to change the seeds
[21:38] <cjwatson> we don't edit the lists in ubuntu-meta by hand
[21:38] <slytherin> cjwatson: Should I log bug then so that it will be on the record?
[21:38] <cjwatson> slytherin: yeah, stick a bug on ubuntu-meta please
[21:38] <Amaranth> mvo: That doesn't really work when we're going git snapshots though, half the work is making the snapshot
[21:39] <Amaranth> Sometimes almost all the work is making the git snapshots, compiz fails distcheck a lot :P
[21:39] <mvo> Amaranth: oh yes
[21:43] <slytherin> cjwatson: done. bug 331256
[21:44] <cjwatson> ta
[21:46] <slangasek> LaserJock: hrm, motu-sru and motu-release as "policing" - would you argue that ubuntu-sru and ubuntu-release are also bad?
[21:46] <slangasek> cjwatson: ... LP has component filtering for bug queries?  Wherewhere?
[21:46] <cjwatson> slangasek: under advanced
[21:46] <slangasek> huh
[21:46] <LaserJock> slangasek: mostly
[21:46] <cjwatson> comes out as &field.component= etc. I think
[21:46] <LaserJock> I certainly think a release team is important
[21:47] <cjwatson> it's in the "Series-specific" section of the advanced search bit
[21:47] <LaserJock> I'd rather we didn't need SRU policing
[21:47] <cjwatson> SRUs are an example of where we've been screwed by inadequate care taken
[21:47] <cjwatson> specifically and in very very high-profile ways
[21:47] <LaserJock> yep
[21:48] <LaserJock> I would expect a developer to be responsible for it though
[21:48] <cjwatson> and in at least one case, it wasn't even because the uploader did anything obviously wrong
[21:48] <slangasek> slytherin: why does ekiga not need the plugins anymore?  What replaced this functionality?
[21:48] <LaserJock> a developer should be able to  figure out what is and what is not SRU worthy though
[21:49] <cjwatson> we've analysed many of the cases where this went wrong, and I don't think it typically comes out to be that simple
[21:49] <LaserJock> exactly
[21:49] <cjwatson> the particularly difficult bit is that "make this obviously correct one-line change" is actually not safe
[21:49] <cjwatson> because simply rebuilding the package *at all* can create bugs
[21:49] <LaserJock> yep
[21:50] <cjwatson> and I don't think this is something that's intuitive to most developers
[21:50] <LaserJock> but the SRU teams are mostly policing, i.e. "is the developer following the SRU Policy?"
[21:50] <slangasek> LaserJock: I think that too much expects all developers to be interchangeable, which they aren't; having an extra set of eyeballs on SRU changes is valuable per se, and it's also valuable to have someone with an SRU "big picture" perspective nvolved
[21:50] <LaserJock> not necessarily taking responsibility for and checking for complete correctness of SRUs
[21:50] <slangasek> LaserJock: er?
[21:50] <cjwatson> ubuntu-sru generally does code review, IME ...
[21:51] <slangasek> yes, this is why I hate kernel SRUs. :)
[21:51] <LaserJock> at least with MOTU SRU it's generally just been "is this a properly formated SRU request?"
[21:51] <Amaranth> mvo: Hopefully we never do another git snapshot though, just poke the compiz guys to do a release :)
[21:51] <persia> That's not what the team is supposed to do.
[21:51] <cjwatson> I think that's another case for merging the teams, then, provided that we take the opportunity to merge the practices too :)
[21:51] <cjwatson> separate teams do tend to create divergence like that
[21:53] <pochu> LaserJock: really? I'm sure I've done some SRUs without needed to do all the paperwork
[21:53] <pochu> just a debdiff
[21:53] <slangasek> cjwatson: knowing now that I'm able to filter LP bug queries will certainly help; but I don't think we have an equivalent way to filter bug mails
[21:54] <cjwatson> slangasek: we certainly no
[21:54] <cjwatson> do
[21:54] <slangasek> how?
[21:54] <cjwatson> X-Launchpad-Bug:.*component=
[21:54] <slangasek> hmm
[21:54] <slangasek> ok
[21:54] <slangasek> (what does that do if there's more than one Ubuntu bug task, on packages in different components?)
[21:55] <LaserJock> you might also consider just having the non-Core Dev MOTU SRU people just agree to not take on Main SRUs
[21:56] <LaserJock> or are you concerned more about getting Universe SRUs in your mailbox
[21:56] <slangasek> yes
[21:56] <LaserJock> ah
[21:57] <LaserJock> then maybe cjwatson's filtering might work a lot better