[00:12]  * ogra_cmpc sighs about fedora
[00:33] <ogra_cmpc> hrm
[00:36] <soren> ogra_cmpc: hm?
[00:37] <ogra_cmpc> soren, ach ... endless discussions with the fedora people about the --arch option in ltsp
[00:37] <ogra_cmpc> they never heard about amd64 :P
[00:39] <ogra_cmpc> and somethimes the attitude between the lines "there is no linux apart from fedora" is a bit well ...
[00:40] <ogra_cmpc> ... tiring ?
[00:42] <slangasek> maddening?  exasperating?  pity-inspiring? :)
[00:43] <ogra_cmpc> :)
[00:43] <soren> Gah... Is that really the time?
[00:43] <soren> *headdesk* I have work tomorrow you know!
[00:43] <slangasek> no, you're reading it upside-down
[00:44] <Hobbsee> geser: ah good, i'm not going mad (w.r.t dpkg-gencontrol: failure: cannot read -)
[00:44] <ogra_cmpc> soren, lol
[00:44] <slangasek> it's actually hh:01
[00:44] <slangasek> sorry, hh:10
[00:45] <soren> Oh... good?
[00:45] <slangasek> it's always good when it's the hour of the hardy heron
[00:45] <soren> \o/
[00:49] <Hobbsee> soren: oh dear.  i told you that you broke it :)
[00:52] <soren> Hobbsee: You did.
[00:52] <soren> You actually did.
[00:52] <soren> I was bound to happen sooner or later.
[00:52]  * jdong reads scrollback
[00:52] <StevenK> Bwahaha
[00:52] <jdong> sounds like fun, folks
[00:52] <jdong> :)
[00:53] <jdong> anyone else notice stuff FTBFSing on Hardy? (kidding :D)
[00:53] <StevenK> "I was bound to happen sooner or later." <- sounds like the sage words of someone crazy enough to merge dpkg
[00:53] <soren> Impossible!
[00:53] <slangasek> StevenK: he is inevitable
[00:54] <soren> That's me. Inevitable.
[00:56] <soren> The best part about uploading dpkg? Knowing that your crack will be built *right* *now*.
[00:56] <jdong> soren: and your crack seeds all other crack too :)
[00:57] <soren> Yeah, that's the not so best part of it.
[00:58]  * soren goes to bed
[00:58] <soren> LS:10 is way too late for me to still be up.
[00:59] <soren> I completely stopped making sense at hE:10.
[01:03] <Hobbsee> soren: do try not to break it again, OK? :)
[01:04] <Hobbsee> soren: Knowing that your crack will be built *right* *now*. <-- sounds like you should apply to be a buildd admin.
[01:04] <Hobbsee> there are priorities for a reason!
[01:04] <soren> Hobbsee: It's ironic, really. I was trying to be a good boy and even added a new test case to dpkg with this upload. Did it help? Nooooo..
[01:04] <Hobbsee> soren: your upload is done and built and didn't break the world now, i tkae it?
[01:05] <soren> https://edge.launchpad.net/ubuntu/+source/dpkg/1.14.16.6ubuntu2
[01:05] <soren> I guess it needs to be published before the buildd's pick it up.
[01:05] <soren> After that, it's give-back galore.
[01:06]  * Hobbsee looks
[01:06] <infinity> soren: No, it's built already.
[01:06] <Hobbsee> yeah, just as i'm going on VAC.  great.
[01:06] <Chipzz> soren: http://imgs.xkcd.com/comics/insomnia.png ;)
[01:06] <infinity> soren: I'll do mass-give-backs once it's published.
[01:06] <Hobbsee> infinity: who really cares about ia64 anyway
[01:06]  * cjwatson hopes he didn't just break all the seeds
[01:07] <Hobbsee> cjwatson: it's the day for breakage. why not?
[01:07]  * cjwatson HIGHLY recommends not merging the seeds any more
[01:07] <soren> cjwatson: Just fix them before FF, otherwise we'll have to live with broken seeds. :(
[01:07] <cjwatson> unless you feel like a really fun resolution pass
[01:07] <Hobbsee> cjwatson: so, uh, how does one merge seeds, or do that equivalent, now?
[01:07]  * soren decides to stop trying to be funny and *really* goes to bed.
[01:07] <Hobbsee> or am i missing something obvious?
[01:08] <Chipzz> cjwatson: btw, are you responsible for consolekit integration?
[01:08] <cjwatson> Hobbsee: largely, the idea is that we should stop needing to, because common things are in a single common place
[01:08] <Hobbsee> soren: you'll probably break dpkg between now and then anyway, so the seed point will be moot.  *g*
[01:08] <cjwatson> Chipzz: no
[01:08] <cjwatson> Hobbsee: we're not quite at that ideal yet, but a lot closer than we were
[01:08] <Hobbsee> cjwatson: oh good!  i'd wondered why they weren't previously
[01:08] <Chipzz> hrrrm then I must be mistaken; nevermind then. who is though?
[01:08] <cjwatson> Chipzz: pitti
[01:09] <cjwatson> err, and if you just updated your seed branches, you might have to force it a bit - I just made a mistake and uncommitted
[01:09] <Chipzz> cjwatson: is it possible that I recall you having a discussion about sudo and ck integration a couple of weeks ago?
[01:10] <cjwatson> Chipzz: yes
[01:10] <cjwatson> Chipzz: doesn't mean I'm responsible for it though, I was just playing with it and trying to improve a few things
[01:10] <Chipzz> cjwatson: ah, because that actually was a reason for concern for me
[01:11] <Chipzz> haven't played with ck yet, so I may be totally mistaken
[01:12] <Chipzz> but integrating ck with sudo and/or login rang a couple of very loud alarmbells here
[01:12] <cjwatson> do you mean ssh rather than sudo?
[01:12] <Chipzz> no, sudo
[01:12] <cjwatson> I wasn't integrating it with sudo
[01:13] <cjwatson> all I was trying to do was make policykit applications not break hopelessly when invoked via sudo
[01:13] <Chipzz> anyway, I'll be better off voicing my concerns with pitti maybe?
[01:13] <cjwatson> sure
[01:13] <Chipzz> but your input would be nicetoo I guess ;)
[01:14] <cjwatson> well, I don't know what your concerns are
[01:14] <cjwatson> but it's also 1:15am
[01:14] <Chipzz> basically my concern is that adding ck as a dependency may complicate recovering a broken system
[01:14] <Chipzz> (ie booting in rescue mode)
[01:14] <Hobbsee> death to all evil keyboard bugs111
[01:15] <cjwatson> Chipzz: well, nobody AFAIK was talking about making sudo register a CK session
[01:16] <cjwatson> Chipzz: and rescue mode uses sulogin, not login, and therefore does not create a PAM session, so that would not involve CK either
[01:16] <cjwatson> any sane implementation of CK integration lets the login manager continue if CK isn't available, anyway
[01:16] <cjwatson> for instance if you use the PAM module you make it optional
[01:17] <Chipzz> that's what I figured
[01:17] <cjwatson> I think there's an argument (though it's still debatable) that sudo should forward CK credentials, but having it pretend to be a new console session seems rather a stretch
[01:19] <Chipzz> but I shall ask pitti about it tomorrow. imho care should be taken not to complicate such scenarios (though one might argue that when your system is broken, well, it's broken...)
[01:19] <cjwatson> I don't really think it would
[01:21] <Chipzz> cjwatson: anyway, since this is pitti's stuff anyway, I'll bother you no more and let you get some sleep ;)
[01:21] <cjwatson> thanks ;)
[01:22] <Chipzz> good night (in case you're hitting the sack ;))
[01:27]  * infinity manually shoves dpkg through the publisher...
[01:31]  * lamont waves
[01:33] <Hobbsee> hi lamont
[05:11] <Seq> Does anybody know how to create their own kernel derivitive using the binary-custom folder? Mine seems to continually fail
[06:05] <warp10> Good morning!
[06:22] <pwnguin> im assuming the answer's no, but if I trigger a kernel panic, that stack trace wont be present anywhere on disk, right?
[07:22] <pitti> Good morning
[07:23] <stgraber> hi pitti
[07:23] <pitti> geser: ugh; due to the new dpkg, I assume? I'll have a look soon
[07:24] <pitti> LaserJock: I just accepted the packs in -proposed
[07:24] <pitti> LaserJock: today I'll care for getting dapper to feisty langpacks synced, and then do an announcement on -translators@; if all goes well, I'll move them in a week
[07:26] <pitti> soren: compat level 1 in pkg-create-dbgsym> yes, unfortunately we have packages which are *that* old and crappy :/
[07:28] <pitti> soren: that sounded like fun; thanks for fixing it, is there anything I still need to do?
[07:29] <LaserJock> pitti: k, awesome
[07:30] <pitti> Chipzz: so, what exactly are your concerns with sudo and CK?
[07:31] <Hobbsee> morning pitti!
[07:32] <Chipzz> pitti: more like login and CK
[07:33] <Chipzz> hrrrm wait :P sudo too actually
[07:34] <Chipzz> my concern is that in case something breaks, that having CK in the mix would make it harder to fix things
[07:36] <Chipzz> basically the way it is now, recovering a broken system (or rather: getting to a state where you can attempt to recover it) is not too complex
[07:36] <Chipzz> FSVO "not too complex"
[07:36] <Chipzz> ie
[07:37] <Chipzz> booting with init=/bin/bash
[07:37] <Chipzz> lets say the sudo <-> CK integration breaks
[07:38] <Chipzz> atm sudo setup is not too complex, and little is required to say, reboot, log in as user, and use sudo to gain root
[07:38] <Chipzz> little is required -> from a technical pov
[07:40] <Chipzz> my concern (and I don't know if it's a valid concern) is that complicating sudo (and login) config may make it more error-prone, and increase the chances of you being unable to for example gain root access at all when stuff goes haywire
[08:04] <dholbach> good morning
[08:04] <simira> dholbach: the "good" part still is missing. But I hope you are having one. :)
[08:05] <dholbach> thanks simira
[08:05]  * dholbach hugs simira
[08:06] <simira> :)
[08:12] <Hobbsee> simira!
[08:13] <emgent> moin
[08:13] <simira> hi Hobbsee
[08:14]  * simira is at school, with a terribly bad teacher.... (he is french, and not totally comfortable with Norwegian...)
[08:15] <Hobbsee> erk!
[08:23] <soren> pitti: I think it's under control. infinity said he'd be giving back all the stuff that broke because of it.
[08:24] <pitti> good
[08:25] <pitti> soren: you didn't disable NO_PKG_MANGLE yet, right?
[08:25] <soren> pitti: Right. I'll do that later today.
[08:25] <pitti> cool
[08:25] <pitti> soren: the joys of dpkg :)
[08:26]  * pitti hugs soren
[08:26] <pitti> StevenK: oooh, promising changelog on libosso! :)
[08:27] <slytherin> Why is latest daily alternate CD for i386 so small (491MB)?
[08:28] <Hobbsee> seeds are probably botched
[08:29] <slytherin> Hobbsee: looks like that is the case. Many important packages are missing
[08:30] <seb128> hey Hobbsee pitti soren
[08:30] <seb128> hello mvo
[08:30] <seb128> soren: so the fixed dpkg has built?
[08:30] <mvo> hey seb128
[08:30] <soren> seb128: Yes, around 2AM last night.
[08:30] <pitti> good morning mvo, seb128
[08:30]  * soren is sleepy eyed.
[08:30] <Hobbsee> hey seb128
[08:31] <Hobbsee> soren: 2am is a great bedtime!
[08:31]  * soren hugs pitti back
[08:31] <soren> Hobbsee: It would have been, yes.
[08:31]  * mvo hugs Hobbsee
[08:31] <mvo> hey pitti
[08:31] <seb128> around the time I stopped working then
[08:31]  * Hobbsee hugs mvo.  morning!
[08:31]  * seb128 is tired still and need coffee
[08:31]  * Hobbsee inserts the caffeine drip
[08:32]  * mvo needs tea
[08:32] <seb128> hum, tea?
[08:32] <seb128> no, need coffee first this morning
[08:33] <seb128> ah, and builds have been retried during the night
[08:34] <simira> mvo: hmm... good suggestion
[08:34] <slytherin> Hobbsee: by the way, it is not i386 problem. All the CDs are very small
[08:35] <Hobbsee> slytherin: it wouldnt' surprise me.  cjwatson should know why
[08:49] <gaspa> pitti: i saw usplash... hm. there really was some dumb mistakes...
[08:51] <StevenK> pitti: Do you think my libosso hack is too gruesome?
[08:52] <pitti> gaspa: working fine now :) ; however, it's still not quite what I need, so I added another command (INPUTCHAR); will upload today
[08:52] <pitti> StevenK: haven't looked at it yet (will do in a few), but it sounds like a great hack :)
[08:53] <pitti> (in the *sniff* "good crack" sense)
[08:53] <gaspa> pitti: ok... so you're not angry with me, isn't it ? :D :D
[08:53] <pitti> gaspa: no, why should I? :)
[08:53] <soren> wtf...
[08:53] <gaspa> :P
[08:53] <soren> It's *Tuesday*?!?
[08:53] <gaspa> pitti: there's something other that should be done in usplash?
[08:53] <pitti> soren: does that come as a big surprise for you?
[08:54] <soren> pitti: Yes!
[08:54] <pitti> gaspa: there are tons of bug reports...
[08:54] <gaspa> ( someone's going to fosdem, this month? )
[08:54] <soren> pitti: This is awesome! I just got an extra day until FF!
[08:54] <pitti> good morning macd
[08:54] <pitti> good morning MacSlow
[08:54] <pitti> good morning Pi"I'm a lazy tab key user"tti
[08:54] <gaspa> pitti: yes, but much of them seems arch-dependent...
[08:54] <MacSlow> hi pitti
[08:55] <MacSlow> odd... I thought I shut down xchat yesterday
[08:55] <gaspa> so i wasn't able to reproduce them.
[08:55] <soren> MacSlow: Shut down xchat? But that would log you off irc, wouldn't it?
[08:55] <pitti> znc FTW!
[08:56] <soren> znc?
[08:56] <MacSlow> soren, yes... in the evening before going to bed this makes sense :)
[08:56] <pitti> soren: apt-cache show znc (I have used this for some weeks now, it works great)
[08:57] <soren> MacSlow: But, but... You'd be logged off irc!!!11!!!one!
[08:57] <pitti> seb128: I'm about to look at MacSlow's sponsor request, or did you already?
[08:57] <seb128> pitti: feel free, there is new upstream versions
[08:58] <seb128> pitti: so if you want to do the update in the same time you are welcome
[08:58] <Mithrandir> soren: you'd take IRC through a drip feed directly into your brain if you could. :-P
[08:58] <seb128> pitti: the libwnck one should be easy
[08:58] <pitti> soren: still better than wasting power over the night :) (but with a proxy you can have both)
[08:58] <pitti> seb128: erm, I was just going to upload them
[08:58] <pitti> seb128: *sigh*, ok, will do
[08:58] <seb128> pitti: ok, do it, I'll pick those when I do the update
[08:58] <seb128> pitti: no, don't bother, I'm fast at doing those updates ;-)
[08:59] <soren> pitti: You turn off your computer too?!
[08:59] <pitti> heh
[08:59] <soren> Good thing I'm sitting down already..
[08:59] <pitti> soren: sure, whenever I don't need it for at least an hour
[09:01] <pitti> MacSlow: just a nitpick for the future: can you please use patch tags (https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines) for future patches, to record upstream bugs and descriptions, etc.?
[09:03] <pitti> MacSlow: and please put the source.changes there, too (rebuilding locally now, so don't worry for now)
[09:04] <MacSlow> pitti, oh... sorry didn't knew about the comments
[09:04] <MacSlow> pitti, I only knew about stating the LP-bug entry in the changelog
[09:05] <seb128> hate cupsys and apparmor
[09:05] <pitti> MacSlow: no need to be sorry, it's a relatively new thing
[09:05] <pitti> MacSlow: that's why I'm pointing it out, we want to try to establish it a bit
[09:05] <pitti> seb128: --verbose?
[09:05] <seb128> pitti: still the broken update for a week, I didn't take time to investigate but it's getting annoying
[09:05] <seb128> Loading AppArmor module: Failed.
[09:05] <seb128> invoke-rc.d: initscript apparmor, action "force-reload" failed.
[09:06] <seb128> so cupsys can't be configured
[09:06] <MacSlow> pitti, so the suggested comments in the patch itself is newer than the (LP: #12346)-thing?
[09:06] <pitti> ugh, I thought apparmor was working again on current kernels?
[09:06] <pitti> MacSlow: yes, much newer
[09:07] <pitti> MacSlow: in the desktop team we want to add some metadata to patches to record description, whether it's ubuntu specific, and various bug tracker links
[09:08] <pitti> MacSlow: g-c-c> any particular reason why you hcanged the function names?
[09:09] <pitti> MacSlow: wouldn't it be enough to just change the called programs?
[09:11] <MacSlow> pitti, I like consistency and predictability
[09:11] <pitti> ok
[09:12] <MacSlow> pitti, and since it's not a public API-call I felt save changing it
[09:13] <MacSlow> pitti, thanks for the uploads!
[09:28] <geser> good morning
[09:34] <lool> persia: I tried to clarify the "situation" with UME-handled packages in #188130; I'm around to chat about them if you need further clarifications
[09:34] <pitti> MacSlow: you're welcome *hug*
[09:34] <pitti> hi geser
[09:35] <pitti> StevenK: hah, nice patch!
[09:36] <pitti> StevenK: I take it you verified that using the same pointer doesn't lead to double-free() or other crashes when the session terminates?
[09:37] <pitti> StevenK: I wait with the promotion until it gets built everywhere
[09:46] <geser> Hi pitti
[09:53] <seb128> StevenK: could you look at the gimp update sponsor request? getting the new version before the freeze would be nice
[09:53] <StevenK> pitti: I've found where it disconnects. It doesn't free them, it calls dbus_bus_release_name() -- as long as that copes, I think it should be fine.
[09:53] <StevenK> seb128: Yeah, in a little while.
[09:53] <seb128> thanks
[09:53]  * StevenK runs off to buy part of dinner.
[10:06] <simira> can someone fix the locobot?
[10:06] <cjwatson> slytherin: ok, I'm sure it's my fault, I'll look at it shortly
[10:14] <Hobbsee> soren: no, it's really monday.
[10:15] <Hobbsee> Mithrandir: do they do those drips now?  that'd be nice!
[10:16] <simira> Hobbsee: he's in transit I believe
[10:17] <Hobbsee> oh.
[10:17] <Hobbsee> yay for backscroll, and irc proxies
[10:17] <simira> he's on in a few mins
[10:17] <simira> :)
[10:17] <Hobbsee> just demand he comes on now :P
[10:18] <simira> I don't need him, I'm in class :)
[10:20] <Hobbsee> simira: i thought you were supposed to listen in class?
[10:20] <Hobbsee> and not be on irc?  :)
[10:20] <Hobbsee> that being said, i've been on irc during uni too.
[10:20] <simira> Hobbsee: yes, when my french lecturer learns Norwegian properly, maybe...
[10:21] <Hobbsee> oh, this is *still* the french lecturer?
[10:21] <Hobbsee> sheesh, how long is he giving a lecture for?
[10:21] <simira> yes, we mostly got only him :p
[10:21] <simira> four hours today
[10:21] <simira> five yesterday, and three tomorrow, I believe
[10:22] <Hobbsee> ew.
[10:22] <simira> mm
[10:22] <Hobbsee> what's he attempting to teach?
[10:22] <simira> a norwegian standardization system for archive management for official purposes
[10:24] <simira> pretty much like ISO 15489, just made and adjusted to Norwegian standards
[10:25] <simira> lucky for me, it's very easy to understand from an IT/developer perspective
[10:25]  * mpt orders a copy of ISO 15489 to keep on his bedside table
[10:26] <simira> mpt: you'd need a bad French lecturer to have any use of it. The standardization itself is somewhat interesting
[10:26] <simira> (if you are interested in archive managment, that is)
[10:28] <pitti> yay, seems I sufficiently convinced usplash to do what I want it to do \o/
[10:28] <pitti> sane fsck integration into usplash!
[10:28] <TheMuso> pitti: DO those recent usplash changes affect themes at all?
[10:28] <pitti> with pressing Esc to skip routine checks
[10:28] <TheMuso> pitti: ooooo shiny!
[10:29] <mpt> pitti, cool
[10:29] <pitti> TheMuso: no, they don't; I just fixed the input handling
[10:29] <mpt> !
[10:29] <TheMuso> pitti: Right.
[10:29] <pitti> I currently hijack the progress bar to show the fsck progress
[10:29] <pitti> which means that it'll jump around a little
[10:29] <pitti> (i. e. used for init script progress, then fsck progress, then again init script progress
[10:30] <pitti> I'd like to use a different colour for fsck, but usplash currently doesn't allow that
[10:30] <TheMuso> Better than nothing.
[10:30] <pitti> it's probably good enough for a first upload
[10:30] <mpt> hrm
[10:30] <pitti> mpt: WDYT? should I use the progress bar or output some text
[10:30] <cjwatson> pitti: ooh, congratulations
[10:30] <pitti> (like percentage)
[10:30] <cjwatson> pitti: which fsck backends does it support?
[10:30] <pitti> cjwatson: only ext3 actually provides progress reading
[10:30] <mpt> pitti, how soon in the progress bar do/can you find out that you need to do fsck?
[10:31] <pitti> I'll check it in a bit how it looks with reiser and xfs
[10:31] <pitti> rcS.d/S30checkfs.sh
[10:31] <pitti> should be fairly early
[10:31] <pitti> I didn't run a complete boot yet
[10:31] <cjwatson> but only when fsck actually starts
[10:31] <mpt> pitti, I mean, do you know that you'll have to do a fsck before the progress bar begins?
[10:31] <pitti> I just start usplash and checkfs. manually
[10:32] <pitti> right, what cjwatson said
[10:32] <pitti> mpt: let me test this with a real boot and come back to describe how it looks like in the entire boot sequence
[10:32] <mpt> ok
[10:35] <slytherin> cjwatson: thanks for looking into it. :-)
[10:39] <gaspa> pitti: next step is a kernel ooops... i want to see it in a usplash screen... :D :D
[10:39] <pitti> heh
[10:39] <Mithrandir> Hobbsee: I'm sure you could get one if you paid enough..
[10:40] <pitti> mpt: so, it actually looks a bit ugly
[10:40] <mpt> pitti, my usual suggestion is to retain one progress bar for overall progress of the task (in this case, starting up), and using text for subtasks
[10:40] <pitti> init script progress starts from 0 to 30%, then checkfs kicks in and does 0 to 100, then init script continues from 30 to 100
[10:40] <mpt> So it's ok if the progress bar gets stuck for a few minutes, as long as there's a line of text changing regularly underneath
[10:40] <pitti> mpt: ok, I I should rather output the percentage?
[10:40] <mpt> where "regularly" > 1/second
[10:41] <mpt> pitti, is there anything more fine-grained you can report than the percentage?
[10:41] <Hobbsee> simira: fun
[10:41] <mpt> For a large disk, a single percentage could take many seconds
[10:41] <pitti> mpt: fsck has 5 stages, and reports a percentage for each of the stages
[10:41] <pitti> but they are fairly meaningless
[10:41] <mpt> Is there a MB measurement, for example?
[10:42] <mpt> or disk blocks, or something?
[10:42] <pitti> no
[10:42] <pitti> well, blocks maybe
[10:42] <pitti> it outputs some numbers 'cur' and 'max'
[10:42] <Hobbsee> Mithrandir: heh
[10:42] <mpt> pitti, do they represent a fraction?
[10:42] <mpt> i.e. progress = cur/max?
[10:42] <pitti> I can output the numbers (stage X/5, cur, max) directly instead of percentages
[10:42] <pitti> mpt: yes
[10:42] <pitti> mpt: that's the percentage withing a stage
[10:42] <mpt> and max > 100?
[10:43] <pitti> for a small disk, max < 100
[10:43] <mpt> hrm
[10:43] <pitti> for a large one I suppose it's much bigger
[10:43] <pitti> I have a 6 GB test partition, where it's 94
[10:43] <mpt> How long does it take overall?
[10:43] <mpt> actually, sorry, wrong question
[10:44] <mpt> How long does the slowest stage take?
[10:44] <mpt> for that 6 GB
[10:44] <pitti> oh, stage 1: 46 (70% of time), stage 2: 473 (20% of time), stages 3 to 5 are very quick
[10:44] <mpt> 473 seconds?
[10:44] <pitti> no, that's the 'max' number reported
[10:44] <mpt> oh
[10:44] <pitti> an absolute number of files or blocks to check, or so
[10:44] <mpt> a different number for each stage
[10:45] <pitti> I have a conversion function which accumulates stage, cur, and max to a single percentage
[10:45] <pitti> (adapted from fsck.ext3)
[10:45] <mpt> The reason I'm asking this, is that it's good for the text to update at least every couple of seconds
[10:45] <mpt> so that it never looks frozen
[10:45] <mpt> As a (very) last resort we could include the time elapsed, I'm just trying to work out whether that's necessary
[10:46] <pitti> mpt: what about including all?
[10:46] <Mithrandir> mpt: you don't have any meaningful output that changes every couple of seconds by default, at least.
[10:46] <pitti> Checking disc..... 23% (stage 1, 234/437)
[10:46] <Mithrandir> well, maybe on a 6G disk, but not on a 1TB disk or thereabouts.
[10:46] <mpt> Mithrandir, "by default" as in the existing text display?
[10:46] <Mithrandir> mpt: yes.  You have a text throbber and a progress bar.
[10:47] <mpt> yes, I'm familiar with it
[10:47] <mpt> but not familiar with how bad it gets on huge disks
[10:47] <mpt> s/bad/sullen/
[10:47] <pitti> (I currently mimic that text mode progress bar behaviour in usplash)
[10:47] <Mithrandir> it just throbs slower.
[10:47] <pitti> I think the numbers (cur/max) will get higher, so I could output those
[10:48] <pitti> fsck seems to update progress several times a second
[10:48] <mpt> What makes it spin the throbber?
[10:48] <pitti> mpt: the text mode has a certain threshold for the percentage
[10:48] <mpt> I mean, what has it finished when it rotates one segment
[10:48] <pitti> e. g. if one "=" represents 2.3%, it updates the progress bar every 2.3%
[10:49] <pitti> oh, it has that rotating thingy, too
[10:49] <Mithrandir> pitti: "throbber". :-)
[10:50] <pitti> Mithrandir: I think I just learned a new word :)
[10:50] <mpt> So, if we can assume that (a) fsck will usually take more than a couple of minutes, and (b) for most disks max > 100, then I think it's better to show cur & max
[10:50] <pitti> mpt: maybe the percentage in addition, to give a feeling for an ETA?
[10:50] <mpt> throbber, I think comes from Netscape 1.1, where it actually throbbed
[10:50] <pitti> since stage 1 takes 70% and stages 2 to 5 together 30%, it would look less intimidating
[10:51] <mpt> pitti, you're right
[10:51] <pitti> mpt: WDYT about "23% (stage 1/5, block 234/437)"
[10:51] <mpt> Your suggestion above is perfect
[10:51] <mpt> except three dots, not five :-)
[10:51] <Mithrandir> pitti: where do you get the cur and max numbers from?
[10:51] <pitti> sure :)
[10:52] <pitti> Mithrandir: fsck -C
[10:52] <pitti> Mithrandir: rather, -C3
[10:52] <pitti> (output progress to fd 3)
[10:52] <pitti> -C == -C0 is magic, it uses the text mode progress bar
[10:52] <pitti> but for an fd you get three numbers (stage cur max) per line
[10:52] <pitti> one line for each cur
[10:53] <Mithrandir> ah
[10:53] <mpt> http://en.wikipedia.org/wiki/Throbber
[10:53] <Mithrandir> max for a 2.6T volume is ~21k, so a percentage would be good
[11:02] <persia> lool: Thanks for the clarification on MIC.  Sounds like a bit of a mess.  I'd like to wait to hear back from smagaoun about it, but will push pre-FF if nobody else hits it.
[11:03] <Hobbsee> persia: see my comment in -motu
[11:04] <persia> Longer term, I'd think setting maintainer to UME, and granting UME access to the VCS might be a sensible solution, to avoid tracking multiple debian/ directories.  Alternately, one of the two repos can be the master, and the other can merge/sync as Ubuntu does with Debian.
[11:04] <cjwatson> slytherin: OK, I see the problem - the code that generates the "master task" for cdimage doesn't cope with following more than one level of seed dependencies
[11:04] <persia> Hobbsee: I refuse to accept anything as "crack" that can be fixed.  Mortar is cheap :p
[11:04] <cjwatson> slytherin: the upshot being that required, minimal, standard, and desktop-common go missing
[11:07] <slytherin> cjwatson: That is almost everything one would need to use Ubuntu. ;-)
[11:07] <slytherin> desktop I mean.
[11:07] <lool> persia: Thanks
[11:09] <persia> lool: On an extended note, aside from other things, doesn't it make sense for someone in UME to be sponsoring UME stuff, rather that UUS?  My comfort level for uploads when wearing a UUS hat goes down significantly when the resulting maintainer is not MOTU.
[11:11] <lool> persia: There are little uploaders for UME at the moment; most people aren't MOTU and we only have a couple of core dev while the packages are being promoted to main
[11:12] <persia> lool: Makes sense.  I remember when myth was that way.  UUS works until it gets resolved (although it may soon require UMS)
[11:12] <lool> persia: While folks started the MOTU process and will probably be core dev in the next weeks or months when they will have demoed some experience, I fear it would be too hard to sponsor everything internally ATM
[11:15] <Hobbsee> persia: sure, but sanity is not.
[11:51] <TheMuso> Hrm. Is it known that one doesn't get a /dev/cdrom symlink in /dev?
[11:52] <TheMuso> Running latest updates, from my local mirror.
[11:54] <sucotronic> hello everybody
[11:54] <sucotronic> one question
[11:54] <sucotronic> How often the maintainers checks the original projects for new releases?
[11:55] <cjwatson> sucotronic: "from time to time"
[11:55] <sucotronic> mmm
[11:55] <cjwatson> some maintainers are subscribed to announcement lists and see them immediately; some just check every so often; some only update when prodded
[11:56] <sucotronic> there isn't any mechanism to notify maintainers?
[11:58] <sucotronic> or is more easy to become a maintainer?
[11:59] <cjwatson> sucotronic: subscribing to upstream announcement lists is the preferred mechanism for diligent maintainers, though they can also create a debian/watch file and use uscan --report --verbose regularly
[12:00] <sucotronic> then, I've to contact with the maintainer to ask him?
[12:08] <cjwatson> sucotronic: filing a bug would be the usual method
[12:10] <sucotronic> cjwatson: sorry, I'm new. How I can do it?
[12:12] <cjwatson> sucotronic: https://bugs.launchpad.net/ubuntu/+filebug; also read https://wiki.ubuntu.com/ContributeToUbuntu
[12:12] <cjwatson> sucotronic: please ask further support questions in #ubuntu
[12:14] <sucotronic> cjwatson: thank you a lot
[12:14] <Mez> hmm, does anyone know anyone here who works for yahoo ?
[12:17] <sucotronic> cjwatson: I think you are wrong. I don't want to report a bug. I'm a maintanier of a project, and I only want to know how to notificate the ubuntu maintainer the new releases
[12:18] <persia> sucotronic: A bug of the form "Please upgrade to new upstream release X.Y" is the preferred format if you want to push changes, rather than waiting for a pull.
[12:20] <sucotronic> persia: ok, that's what I want to know. Thanks
[12:28] <DarkSun88> Hi all
[12:33] <cjwatson> slytherin: Ubuntu daily CD builds fixed now
[12:33] <slytherin> cjwatson: Thanks. Does that mean that new images will be generated again?
[12:36] <cjwatson> slytherin: I just generated Ubuntu ones
[12:36] <cjwatson> and am building Kubuntu now
[12:37] <slytherin> cjwatson: kudos to you. :-)
[12:37] <slytherin> Any of the buildd admins present here? I have a debconf preseed request.
[12:37] <cjwatson> I thought that particular preseed had been done
[12:38] <slytherin> cjwatson: which one? I am referring to batik build, it uses older j2sdk because Sun JDK is too new for it.
[12:40] <cjwatson> slytherin: the RT ticket was marked resolved on 12 Dec; I'll see if I can dig up exactly what was preseeded
[12:41] <slytherin> cjwatson: AFAIK, only Sun java packages have been preseeded.
[12:41] <geser> cjwatson: sun-java-* works on the buildds after the preseeding was done (at least in hardy)
[12:43] <slytherin> and what we need is preseeding for j2sdk/j2re package (Blackdown JDK/JRE). This is needed for some packages.
[12:47] <cjwatson> shared/accepted-sun-dlj-v1-1 is preseeded, but nothing else seems to be
[12:47] <cjwatson> slytherin: mail rt@admin.canonical.com with your request
[12:48] <pitti> cjwatson: do you know if there will be any problems if I add a "Breaks: usplash (<< 0.5.12)" to initscripts? (which is a required package)
[12:48] <pitti> cjwatson: I need the new usplash features for the fsck integration
[12:48] <cjwatson> pitti: don't think so
[12:49] <pitti> ok, thanks
[12:49] <slytherin> cjwatson: Difficult task if you ask me. Access to my primary mail account (gmail) is blocked for me. I will see what I can do. :-)
[12:50] <cjwatson> slytherin: (or ask somebody else to do so) and say exactly which debconf question you need preseeded
[12:50] <slytherin> cjwatson: How do I identify debconf question?
[12:54] <cjwatson> slytherin: you'll need to read the maintainer scripts and figure out what they're doing
[12:54] <slytherin> ok
[13:03] <slytherin> cjwatson: Looks like there are two different debconf questions, one for sdk and one for runtime. 'j2re1.4/license: true' and 'j2sdk1.4/license: true'
[13:07] <StevenK> pitti: libosso built everywhere - do you need to wait for the publisher to finish, or can you promote it while it's running?
[13:11] <pitti> StevenK: if it's uploaded, I can promote it
[13:11] <Hobbsee> pitti: bad idea.
[13:11] <pitti> ?
[13:12] <Hobbsee> pitti: you need to wait for it to finish building, else it gets a "failed to upload" status.  iz YALPB.
[13:12] <Mithrandir> Hobbsee: but it's shiny!
[13:12]  * Hobbsee takes the shiny away from Mithrandir
[13:12] <pitti> Hobbsee: "if it's uploaded..."
[13:12] <Hobbsee> NO MORE SHINY FOR YOU!  NOT YOURS!
[13:12] <Hobbsee> pitti: i thought you meant source uploaded
[13:12] <Mithrandir> :'-(
[13:12] <pitti> no, I meant the binary builds were uploaded
[13:13] <Hobbsee> oh right.   go ahead, then :)
[13:13]  * Hobbsee hugs Mithrandir
[13:13] <pitti> anyway, I'm finally off for lunch for a bit; I'll review/promote it once I'm back
[13:14]  * Hobbsee blinks
[13:15] <Hobbsee> so, uh...
[13:15] <Hobbsee> either iv'e forgotten how to use powerpoints, or thsi cable has just died on me.
[13:20] <Hobbsee> or only works sometimes
[13:22] <Mithrandir> Hobbsee: it's probably to wear down your nerves.
[13:23] <Hobbsee> Mithrandir: it was working fine prior to this.  but now that i'm going on holidays, where it'll be my only phone, it does this.  grrr.
[14:19] <saispo> BenC: ping ?
[14:20] <BenC> saispo: ?
[14:21] <saispo> BenC: hi :) i have a little question about git kernel ubuntu, i see on list *changes that kernel 2.6.20 and 2.6.22 are fixed but nothing in gitweb, it's normal ?
[14:22] <BenC> saispo: what do you mean "fixed"?
[14:22] <saispo> about CVE-2008-0600.
[14:22] <ubotu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0600)
[14:25]  * pitti promotes libosso and osso-gwconnect to main and waves to StevenK
[14:34] <Riddell> DarkSun88: are you going to rebulid all the libglew rdepends?
[14:34] <DarkSun88> Yes. Are there problems?
[14:34] <Riddell> DarkSun88: no, just confirming it's in your sights, I've let it through New
[14:35] <Riddell> DarkSun88: also I've uploaded a new koffice2 so you can ignore krita-kde4
[14:35] <DarkSun88> Well, thanks. :)
[14:38] <saispo> BenC: changes haven't been commited in git ?
[14:40] <BenC> saispo: I'm sure they have, but maybe they weren't pushed...I can check
[14:40] <saispo> ok, thanks :) because i must rebuild them
[14:40] <saispo> and i use git for doing this
[14:46] <saispo> BenC: thanks, good for gutsy :)
[14:47] <saispo> waiting feisty :)
[14:57] <dramen> hello
[14:59] <dramen> how can i install a manpage when i build a (debian)package by using dpkg-buildpackage
[15:00] <ion_> See dh_installman(1)
[15:00] <persia> dramen: You likely want to ask that question in #ubuntu-motu, and read the dh_installman manual page
[15:03] <dramen> in debian/rules there is a call dh_installman
[15:04] <dramen> normally, it should install the manual page automatically on the right location
[15:06] <cjwatson> as dh_installman's own manual page says, you have to tell it which manual pages to install, either with debian/manpages (or debian/PACKAGENAME.manpages) or with command-line arguments
[15:16] <dramen> ok, i just put the deprecated dh_installmanpages into my debian/rules-file and now it works
[15:17] <dramen> although, the output is as followed: "dh_installmanpages: This program is deprecated, switch to dh_installman."
[15:19] <pitti> cjwatson: ooh! ubuntu-meta with reorganized seeds?
[15:25] <cjwatson> dramen: dh_installmanpages has a different interface, which includes automatically searching for manual pages. In practice this turned out to be more trouble than it was worth.
[15:25] <cjwatson> pitti: yes
[15:39] <seb128> ogra: will you look at ted's gnome-screensaver updates, the bug is assigned to you, or should I do it?
[15:41] <seb128> soren: could you look at the gtk-vnc update sponsor request? it should be easy and required by the new GNOME
[15:42] <soren> seb128: It's on my list.
[15:42] <soren> :)
[15:43] <lool> Hmm today's Tech Board meeting doesn't appear on the fridge which is the official place to list tech board meetings (says the wiki); who should I ping to get this fixed?  Tech board folks to ask fridge people or fridge people directly?
[15:44] <xivulon> hi heno
[15:44] <persia> lool: Mail to fridge-devel@
[15:45] <heno> hey xivulon!
[15:45] <persia> More generally, TB should send such a mail when a meeting date is decided.
[15:45] <heno> xivulon: that last version looks nice :)
[15:46] <Keybuk> lool: fridge *still* can't do recurring meetings
[15:46] <Keybuk> so they have to add them one by one by hand
[15:46] <saispo> seb128: \o/
[15:46] <seb128> saispo: what?
[15:46]  * lool mailed fridge-devel
[15:46] <Keybuk> and occasionally we hit the horizon of Corey's boredom of typing the same meeting in
[15:47] <saispo> seb128: nothing, just say "hello" :)
[15:47] <seb128> hey saispo ;-)
[15:48] <xivulon> heno: glad to hear that
[15:49] <xivulon> heno re skinning, I should be made the labels and buttons solid color and/or transparent
[15:49] <xivulon> at the moment the image is 314x164
[15:49] <xivulon> assumes white background
[15:49] <xivulon> 164x314
[15:49] <heno> xivulon: can the buttons be made transparent?
[15:50] <xivulon> heno: never tried that
[15:50] <ogra> seb128, hmm, i'm pretty packed atm if you have a spare cycle for that it would be great
[15:50] <xivulon> should be possible though
[15:50] <seb128> ogra: ok, will look at it, thanks
[15:50] <heno> xivulon: ok, grey will be fine as well
[15:51] <ogra> thanks a lot
[15:51] <heno> having a pixmap on the entire background would be great
[15:52] <xivulon> that should be possible too, but haven't played with that either, requires overriding default nsis behaviour (164x314) expected
[15:52] <xivulon> that said when the image goes below text readibility is affected
[15:53] <xivulon> I think that a 3Dish logo with shadow on white background might be good enough
[15:53] <heno> I agree
[15:54] <xivulon> if they can keep it within the above size much easier for me
[15:54] <heno> It's just useful to know what the technical constraints are when talking to the art team
[15:54] <xivulon> that can be branded (at compile time though)
[15:54] <heno> let's start with that then
[15:55] <xivulon> I mean I can always override the nsis behaviour here and there, but I have the schedule quite busy before friday already
[15:55] <xivulon> translation I think is a more urgent issue
[15:56] <xivulon> I can reuse wubi scripts (po <-> nsh) or win32loader approach (c dll + gettext)
[15:59] <xivulon> the transparency by the way depends on mfc api, if it is supported by standard flags or via sendmessage then it can be done
[15:59] <heno> xivulon: NSIS gets the locale from Windows?
[15:59] <xivulon> if not it requires a separate dll which is not worth it IMO
[15:59] <xivulon> yes
[16:00] <xivulon> uses the default windows language
[16:00] <heno> cool
[16:00] <xivulon> but at the moment I only have english in there anyway
[16:01] <heno> I think the text is ok for translation now (though I'd like to see even less of it :) )
[16:01] <xivulon> if there are mfc gui experts here, tips are welcome :P
[16:01] <xivulon> easiest way for me is if you change the text in the wiki
[16:01] <xivulon> I'll grab it from there
[16:02] <heno> OK, I'll try condensing it some more if possible
[16:03] <xivulon> I'll upload the code tonight, building it should be quite straightforward, you need wine+nsis2.34
[16:09] <xivulon> heno: quick googling shows that transparent buttons are not obvious, transparent labels should be ok
[16:10] <heno> that would be great
[16:10] <xivulon> eh did not look at what is required to enlarge the image though
[16:21] <xivulon> heno: http://img444.imageshack.us/img444/9167/umenu1wy6.jpg
[16:21] <xivulon> this is to show transparency capabilities
[16:22] <xivulon> I think it looks better on the side though
[16:25] <heno> xivulon: right, but we wouldn't use that image in that case. most likely the image would have the logo on the left and a faint texture on the right
[16:25] <heno> xivulon: what's the image dimension on that one?
[16:25] <xivulon> I appreciate that, note that the same image would probably also go in the reboot page
[16:26] <heno> right
[16:34] <xivulon> heno that is a bit tricky, since the size changes slightly with font sizes (the image can be stretched or we can end off into a background color)
[16:36] <\sh> soren, ping dpkg-dev...as I don't like to fight with dpkg, would you like to bring the "Description" tag back to _source.changes files, as described here: http://git.debian.org/?p=dpkg/dpkg.git;a=blobdiff;f=scripts/dpkg-genchanges.pl;h=0fcd529b847c5f51f7f4c5e3ea8c51e186d3730d;hp=7dada21a531c568298764c76dbe9a44b56471101;hb=15fa75bd7143d6ec54f0a77c482ff0cfb72bf440;hpb=1f6feb233d4e7088cb920f386292f8d31d694d3a ?
[16:36] <soren> \sh: File a bug.
[16:36] <\sh> soren, right now, this field is policy and MIA in last dpkg from debian/ubuntu :)
[16:37] <\sh> soren, ah well, I'll provide a debdiff
[16:37] <soren> Cool, thanks.
[16:39] <\sh> soren, np
[16:48] <xivulon> heno the nsis recommended size for a vertical image is 164x314, for a full image 496x314
[16:56] <xivulon> heno: checkboxes are like buttons, so cannot be transparent
[16:57] <xivulon> that basically rules out a full size image
[16:58] <heno> xivulon: ok (you mean for the radio buttons on the reboot page?)
[16:58] <xivulon> yes
[16:58] <xivulon> they will have a solid background
[16:59] <heno> btw, is there any limitation on colour depth?
[16:59] <xivulon> It has to be a bitmap not sure what depth is supported, but I that depends on windows defaults
[17:02] <xivulon> heno: http://img166.imageshack.us/img166/1228/umenu2zo3.jpg
[17:02] <xivulon> IMO Simplest option is to have a vertical image (164x314) with 3Dish logo + shadow, all with a white background.
[17:04] <heno> xivulon: agree. I'll look at making one (and ask for some art help if I fail)
[17:04] <heno> thanks for investigating
[17:04] <xivulon> np
[17:42] <neighborlee> so is hardy close'ish to average user ready , from what I read about current status it would seem so  :)
[17:43] <jpatrick> neighborlee: feature freeze soon
[17:43] <neighborlee> ohhhhh btw
[17:43] <neighborlee> what was the decision on mono
[17:43] <neighborlee> jpatrick, sounds nice :)
[17:43] <persia> neighborlee: The (nearly) final set of upstreams should be determined this week, but there are still lots of bugs that need closing.  Testing appreciated, but know that you're testing.
[17:43] <neighborlee> persia, yes
[17:44] <neighborlee> persia, current issues seemed doable ;)
[17:45] <neighborlee> persia, what is the status of mono in hardy or is it already gone ;)
[17:45] <neighborlee>  I saw wiki and  was wondering
[17:46] <persia> neighborlee: You'll get a better answer from the daily CDs or the metapackages than from me (I don't know, except that there are at least mono packages in universe)
[17:46] <neighborlee> yes that wont change from what I read
[17:46] <neighborlee> just  wont be installed out of box or on install CD
[17:46] <neighborlee> persia, daily cd ??
[17:47] <LaserJock> I can't imagine mono being gone, we have f-spot and tomboy using it
[17:47] <neighborlee> persia, surely someone knows
[17:47] <neighborlee> :))
[17:47] <neighborlee> LaserJock, you dont know about the  wiki do you ;)
[17:47] <persia> neighborlee: Check the hardy ubuntu-desktop package
[17:47] <LaserJock> neighborlee: I know there is a lot of stuff on the wiki, much of it has no baring on what's actually done
[17:47] <neighborlee> persia, ok fine I was hoping someone would just know what status was ;))
[17:47] <neighborlee> LaserJock, ok, odd.
[17:47] <LaserJock> *bearing, methinks
[17:48] <LaserJock> neighborlee: why is that odd? The wiki is open to editing by anyone
[17:48] <neighborlee> well the idea is the remove mono entirely, but leave on repo at least
[17:48] <neighborlee> LaserJock, I assumed it was a serious issue r aised by a developer, but maybe not.
[17:48] <mjg59> No
[17:48] <neighborlee> LaserJock, it looked very serious to me.
[17:48] <mjg59> Mono's not being removed
[17:48] <neighborlee> mjg59, ok ..as I say the wiki looked done very professsionally so I had zero reason to think anything less
[17:49] <LaserJock> neighborlee: well, I'm sure the person who wrote it  was serious, but if it's the wiki page I'm thinking of it was not by a developer
[17:49] <mjg59> Someone's written a spec about it. The spec hasn't been approved.
[17:49] <neighborlee> ic alright
[17:49] <mjg59> You can see that by following the link from the spec to the status page on Launchpad
[17:49] <neighborlee> ic
[17:50] <neighborlee> well it did makes alot of sense though if you think about it
[17:50] <neighborlee> MUCH less MB footprint  ,  memory too ?..and there are valid  replacements to all apps according to the wiki author anyway
[17:50] <neighborlee> anyway I was curious, as on the outset it sounded very logical.
[17:51] <neighborlee> and now with winforms being deprecated for avalon it does beg the question possibly ;)
[17:51] <mjg59> There's no decent replacement for Tomboy
[17:52] <neighborlee> yes actually there is, at least according to the wiki author
[17:52] <neighborlee> offhand I dont recall.
[17:52] <mjg59> He's wrong
[17:52] <neighborlee> but I think there was some feature the repalcement didn't have.
[17:52] <neighborlee> but I now he mentioned something
[17:52] <neighborlee> ..know
[17:52] <neighborlee> checking
[17:53] <neighborlee> and what about tracker..it replaced beagle :)..makes you wonder at least it does me.
[17:53] <neighborlee> hm lets see
[17:54] <neighborlee> found it
[17:54] <neighborlee> ok this is on forum however
[17:55]  * persia notes bug #190862 may be interesting in any discussion of tomboy
[17:55] <ubotu> Launchpad bug 190862 in tomboy "License headers missing" [High,Confirmed] https://launchpad.net/bugs/190862
[17:55] <neighborlee> oh gawd clealry this is a HUGE issue for those involved in the discussions..a sorta 'heated' debate it looks like.
[17:55] <neighborlee> persia, hmm
[17:55] <neighborlee> license headers oh thats inntersting ;)
[17:55] <LaserJock> neighborlee: yes, because almost are all arguments are a technical "smoke and mirrors" around "we don't want it"
[17:56] <neighborlee> hm
[17:57] <mjg59> persia: Unless there's any reason to think otherwise, the presence of a global copyright file is generally sufficient
[17:57]  * mjg59 heads out
[18:12] <xivulon> heno: once you get the artwork for umenu could you please also produce a set of images of size 150x57 to be used in wubi header?
[18:12] <xivulon> ideally there should be one for each flavor covered by wubi
[18:16] <xivulon> mjg59, there used to be some code in powermanagement-interface/pmi.acpi to disable suspend (ram/disk) for loopinstallations
[18:16] <xivulon> that for some reason did not go through to pm-utils
[18:16] <xivulon> would it be possible to add it back? grep host in pmi.acpi
[18:18] <xivulon> ah missed the heads out part...
[18:41] <pranith> is there any update for the vmsplice exploit for ubuntu yet?
[18:41] <sistpoty|work> pranith: yes
[18:42] <pranith> i did apt-get upgrade today, and no new kernel...
[18:42] <sistpoty|work> pranith: at least I've seen a new kernel from security today
[18:42] <pranith> hmm
[18:42] <pranith> ok
[18:42] <sistpoty|work> pranith: arrived not too long ago
[18:42] <jdong> it was put in git like 23hrs ago
[18:42] <jdong> http://www.ubuntu.com/usn/usn-577-1
[18:42] <pranith> ok, thanks
[18:43] <jdong> update released on all supported versions of Ubuntu :)
[18:52] <geser> slangasek: the last comment in bug #187890 says that the package got synced but the archive has still the old version. A bug in a script not catching an error?
[18:52] <ubotu> Launchpad bug 187890 in onscripter "Please sync onscripter 0.0.20080121-1 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/187890
[18:52] <\sh> soren, would you like to take a look at bug #191324 and upload please, so linda and everyone else is satisfied again using dpkg-genchanges.pl ? :)
[18:52] <ubotu> Launchpad bug 191324 in dpkg "dpkg-genchanges.pl missing the "Description" field in *_source.changes files" [Undecided,New] https://launchpad.net/bugs/191324
[18:53] <\sh> soren, I just tested it , and everything is fine again and following debian policy
[18:53] <sistpoty|work> \sh: revu is already fixed *g*, and sparky's linda as well *g*
[18:53] <slangasek> geser: mmm, could be.  the sync-source script apparently exits with success when you fail to ask it to override the Ubuntu changes, and so pitti's most recent wrapper script sends some false-acks :/
[18:54] <\sh> sistpoty|work, well, if dpkg is fixed, you can drop the workaround ,-)
[18:54] <slangasek> Riddell: I guess you have the sync lock right now, could you add 187890 to your queue?
[18:54] <persia> geser: There's an issue with package versions that small.  I had to manually force a couple packages earlier in the cycle
[18:55] <\sh> sistpoty|work, but I'm uploading my package again, ok?
[18:55] <persia> infon 0~r144-1 and infon-devel 0=r198-2.1
[18:55] <sistpoty|work> \sh: I'd rather not drop the workaround... revu shouldn't throw backtraces because of a missing entry in the changes file (of course I should really fix much more for that *g*)
[18:55] <Riddell> slangasek: ok
[18:55] <sistpoty|work> \sh: sure (btw.: I put back your last upload)
[18:55] <sistpoty|work> \sh: so that's up there already
[18:55] <\sh> sistpoty|work, so it's already on the list, cool :)
[19:01] <Riddell> slangasek: that can't be synced, it has a smaller version number than the current version we have
[19:02] <slangasek> Riddell: oh, that's also a good reason for not syncing then
[19:03] <geser> slangasek: so we need to add an epoch to onscripter?
[19:03] <slangasek> geser: to be syncable again, yes
[19:03] <jaalto> Where can I find step by step instructions how to make a release and upload files to it in launcpad. I have forgotten the details
[19:03] <slangasek> geser: or else drop the leading zeroes, and worry about epoching later?
[19:04] <ScottK> Debian would need to add the epoch, right?
[19:04] <slangasek> epoch, or drop the leading zeroes
[19:04] <geser> ScottK: if we don't want to carry it forever, yes
[19:05] <geser> slangasek: wouldn't dropping the zeroes also require to rename the orig.tar.gz?
[19:05]  * ScottK was thinking if we wanted to be able to sync it.  Once you add an epoch for Ubuntu, you aren't syncing any more.
[19:05] <slangasek> geser: well, yes - why would that hurt anything?
[19:06] <geser> slangasek: not really
[19:06] <slangasek> ScottK: we already can't sync it because the current Ubuntu versioning sorts greater than the Debian versioning
[19:06] <ScottK> Right, but us adding an epoch doesn't help that.
[19:07] <geser> ScottK: how does dropping the zeros help us?
[19:07]  * ScottK didn't say it does.
[19:08] <slangasek> ScottK: sorry, I read "we need to add an epoch to onscripter" as "we need to get the Debian maintainer to add an epoch to onscripter" :)
[19:09] <ScottK> Ah.  Maybe that's what he meant and I'm to much of a literalist.  Dunno.
[19:12]  * geser will upload onscripter without the leading zeroes
[19:12] <slangasek> geser: upload it to Debian?
[19:14] <geser> slangasek: to Ubuntu :)
[19:14] <geser> as a fake-sync
[19:14] <slangasek> oh, gotcha
[19:15] <geser> what's the correct version in this case? -1build1 as there is no real change or is it -1ubuntu1 due to the changed versioning?
[19:15] <xivulon> slangasek, is it possible to agree on metalink urls, even without dealing with generating the metalinks? I need to hardcode those in wubi.
[19:16] <xivulon> otherwise I will need to make amendments post feature freeze
[19:16] <persia> geser: Maybe -0ubuntu1 because of the changed versioning?
[19:17] <geser> that's also an option
[19:22] <xivulon> only need to know where the metalinks will be, and convention for filename therein (relevant before final release), we can use static metalinks for the time being pointing at daily-builds
[19:25] <xivulon> slangsek: something like: ubuntu.com/metalinks/ubuntu-8.04-desktop.metalink -> ubuntu-8.04-desktop.iso (filename)
[19:30] <slangasek> xivulon: let me see about working through that over the next few hours.  Any new URLs under ubuntu.com need to be discussed with the webmaster first
[19:34] <xivulon> slangasek, keep in mind that 1: the metalink url should not change over time within a release cycle, 2: the filename within it may or may not change
[19:35] <xivulon> to make clear the second point, assume the metalink is called ubuntu-8.04-desktop.metalink, that will now point to urls that will retrieve the file hardy-desktop.iso
[19:36] <xivulon> on top it contains a filename property (which most downloaders use to rename the downloaded file). That can be hardy-desktop.iso or ubuntu-8.04-desktop.iso
[19:36] <ScottK> Riddell: Could I please have a give back on testresources.  I believe it'll build this time.
[19:36] <xivulon> I'd opt for the second option
[19:37] <Riddell> ScottK: not from me
[19:37] <Riddell> ScottK: try slangasek
[19:37] <ScottK> OK.  Riddell: who from then?
[19:37] <ScottK> K
[19:38] <ScottK> slangasek: Would you please give back testresources.  I'm reasonably certain it will build.
[19:38] <geser> ScottK: ask pitti, Mithrandir or lamont for a give-back
[19:39] <geser> ScottK: you need an build admin not an archive admin
[19:39] <ScottK> Ah.
[19:39] <ScottK> Thanks.
[19:39] <lamont> geser: s/lamont/infinity/
[19:39]  * ScottK hopes one of them see that then.
[19:39] <slangasek> ScottK: not me either, I'm not a buildd admin
[19:39] <ScottK> Right.
[19:40] <geser> lamont: aren't you a buildd admin anymore or do you simple don't handel give-back requests?
[19:40] <lamont> geser: well.....
[19:40] <geser> ScottK: Hobbsee can also do give-backs, but that doesn't help you right now
[19:41] <lamont> I'm an lp-admin now, so I can certainly do it.
[19:41]  * ScottK would need her long stick to reach out and wake her up.
[19:41] <lamont> I prefer to not abuse the duck that way
[19:42] <geser> lamont: I looked at https://edge.launchpad.net/~launchpad-buildd-admins/+members and you're still listed so I guessed you could do it
[19:43] <lamont> yeah.  I should really fire myself from that group, to be proper
[19:44] <ScottK> lamont: Please give back testresources first.
[19:44] <lamont> ScottK: dropping myself from the group won't make it so I can't give it back..
[19:45] <ScottK> True, but if you did it first, it would actually be done.
[19:47] <lamont> both done
[19:50] <ScottK> lamont: Thanks.
[20:07] <slangasek> xivulon: ok, I've given the ubuntu.com webmaster food for thought; there are various concerns about how much of a difference this will make to www.ubuntu.com load at release time and so forth, but we'll work through those and I'll let you know what conclusions we reach.  If this is just a matter of adding the metalink URLs to wubi, though, I wouldn't worry about not having the decision before FF
[20:08] <bddebian> Oh, who is doing give-backs?  Can someone do lordsawar?
[20:10] <pitti> bddebian: can do
[20:10] <pitti> bddebian: people in the ~launchpad-buildd-admin team can
[20:11] <bddebian> Thx
[20:11] <pitti> bddebian: nothing to give back, it's built everywhere but hppa (and it's needsbuild there)
[20:11] <LaserJock> bah
[20:11] <pitti> hi LaserJock
[20:12] <LaserJock> pitti: you gotta a sec for a NEW consultation?
[20:12] <newz2000> xivulon: Hi, I'm the webmaster. I have some questions but I need to do a little investigation in order to speak intelligibly on the matter. Can I e-mail your or /msg you later on this week?
[20:12] <pitti> actually not, trying to concentrate to get this usplash thing fixed and then go to bed
[20:12] <LaserJock> pitti: fine
[20:12] <pitti> LaserJock: but just ask your question,
[20:12] <bddebian> pitti: Ah, someone must have done it, thanks
[20:13] <LaserJock> I'm totally switching the packaging for squeak (multiverse smalltalk stuff) so that we're syncing to the official unofficial packages
[20:13] <pitti> 'official unofficial'? :)
[20:13] <LaserJock> the source package names are completely different
[20:13] <pitti> I see
[20:13] <pitti> so that requires some removals/NEWs
[20:13] <LaserJock> pitti: Debian won't take it officially, but squeak maintains official packages
[20:13] <LaserJock> but there is some binary package overlap
[20:14] <pitti> LaserJock: that's not a problem; just make sure that the versions are higher
[20:14] <LaserJock> yes, the versions will all be higher
[20:14] <pitti> and that the packages with the same names have the same purpose :)
[20:14] <pitti> and keep transitional empty packages until after hardy for upgrades
[20:14] <LaserJock> ok, so I shouldn't ask for removals?
[20:15] <pitti> the old source packages should be removed
[20:15] <pitti> and old libraries, etc.
[20:15] <LaserJock> k, and have the new packages do the transitionals
[20:15] <pitti> old application packages should become transitional packages
[20:16] <LaserJock> ok, how hard would it be to get somebody to remove squeak-image, squeak-sources, and squeak-vm for me? :-)
[20:16] <pitti> LaserJock: let's first get the new packages in, then remove the old onese
[20:16] <pitti> LaserJock: it's not hard, just file a bug against them asking for removal and sub ~ubuntu-archive
[20:17] <LaserJock> sure
[20:18]  * pitti sighs and goes for another round of reboot/usplash testing; brb
[20:18] <pitti> 4 usplash uploads in two days...
[20:19] <LaserJock> fun :/
[20:20] <ScottK> pitti: If you're going to be around for a bit, you might idle in #ubuntu-meeting and 'fanboy' my core-dev application in person when the time comes (meeting in progress now).
[20:21] <Mez> Question: with all the idiots trying to get people to sudo rm -rf / - why not create a patch that gives you an "are you sure - are you really sure - are you REALLY REALLY sure" kind of warning?
[20:22] <persia> Mez: Fails the silent-on-success guideline
[20:22] <LjL> Mez: as in, putting an alias by default in ~/.bashrc for --preserve-root?
[20:22] <ScottK> bddebian: Testresources FTBFS again.  It's your fix, so have fun.
[20:24] <ScottK> ;-)
[20:24] <Mez> LjL, something like that
[20:25] <Mez> LjL, actually, thats not a half bad idea
[20:26] <Mez> Anyone willing to sponsor a patch for that
[20:26] <LjL> Mez: not sure. guidelines aside, people would probably starting to give "alternative commands" to bypass that check
[20:26] <Mez> LjL, it's built into rm, so wouldnt fail the guidelines
[20:26] <infinity> Mez: Preventing users from shooting themselves in the foot with cute aliases and such never works.
[20:27] <Mez> infinity, wow - havent seen you in ages
[20:27] <Mez> how're things
[20:27] <infinity> Decent, I just don't speak up in -devel much anymore
[20:28] <Mez> I've actually looked for you specifically on a couple of occasions infinity ;)
[20:28] <Mez> cant remember why now
[20:28] <Mez> prob something to do with Debian and NM
[20:28] <slangasek> or turtles
[20:28] <infinity> Mez: (Note that we could just change it to "rm -rf /*" etc... If people will run random commands like that, they'll always get what's coming to them)
[20:28] <infinity> slangasek: *glare*
[20:28] <slangasek> :-)
[20:29] <Mez> infinity, ;)
[20:29] <Mez> slangasek, do I want to know
[20:30] <slangasek> yes, but I won't tell you
[20:30] <Mez> ?@
[20:42] <xivulon> slangasek: thanks, yes for the time being it's mostly a matter of URL only I can point to my website for the time being and repoint later.
[20:42] <xivulon> Note that if the "filename" attribute within the metalink is not constant throughout a release cycle, I will also need to recode a bit.
[20:43] <slangasek> xivulon: right.  I'm not sure what the best solution is for that side of things; everywhere else, we make a point to distinguish between pre-release codenames, and release versions
[20:44] <xivulon> slangsek, if you keep the metalink url fixed, either way is wrong
[20:44] <xivulon> slangasek: ^
[20:45] <slangasek> precisely
[20:45] <xivulon> i.e. you either have a ubuntu-8.04-desktop.metalink pointing at hardy-8.04-destop.iso or you have ubuntu-8.04-desktop.metalink which downloads hardy-desktop-iso and calls it ubuntu-8.04-desktop.iso
[20:47] <slangasek> xivulon: yes, it's also wrong because we don't want to have /metalink/ files labelled "hardy" after release, or labelled "8.04" before release
[20:48] <xivulon> an alternive is to use server side redirection
[20:48] <xivulon> so I can point to ubuntu-8.04-desktop.metalink.latest
[20:49] <xivulon> which will redirect me to either ubuntu-8.04-desktop.metalink or ubuntu-8.04-alpha3-desktop.metalink
[20:50] <xivulon> the metalink file itself by the way should be lighter than an average webpage if you are concerned about bandwidth
[20:50] <slangasek> xivulon: what about if the installer were to look for a file under the release number, and fall back to the codename if it's not available?
[20:51] <xivulon> I can do that but will hardcode some ubuntu specific practices
[20:51] <slangasek> that would also give us the option of hosting them in two different places (i.e., releases.u.c, cdimage.u.c, which is how the images are split as well)
[20:51] <xivulon> I was thinking somthing like:
[20:52] <xivulon> ubuntu.com/metalinks/8.04 with subdirs: final, beta, alph3, current
[20:53] <xivulon> current contains "fixed" urls which are redirected
[20:53] <slangasek> the subdirs seem unnecessary, since we don't generally keep previous milestone images around after the next one has been released
[20:54] <xivulon> agree, on top of that server side redirection do not require files visible to the user
[20:55] <xivulon> so it would be ubuntu.com/metalinks/8.04 containing ubuntu-8.04-desktop.metalink OR ubuntu-8.04beta-desktop.metalink + ubuntu-8.04-desktop.current.metalink redirection
[20:55] <xivulon> the last one being "invisible"
[20:56] <xivulon> the filenames therein should match whatever a user would grab manually from the mirrors
[20:57] <xivulon> would the above seem reasonable?
[20:57] <slangasek> it still has the flaw that it implies using the "8.04" designation before 8.04 is released
[20:58] <slangasek> I expect newz2000 will have some opinions on the layout
[20:58] <Mithrandir> we could use metalinks/NOT-YET-RELEASED/8.04/ or something like that.
[20:58] <xivulon> could be called hardy-desktop, the issue is that all distros share the same codename so can't have that...
[20:59] <infinity> We should definitely not use numbers before release.
[20:59] <xivulon> ubuntu-beta-desktop.metalink ubuntu-finall-desktop.metalink ...?
[20:59] <xivulon> all in 8.04
[20:59] <infinity> I still remember the s/6.04/6.06/ pain.
[20:59] <xivulon> I mean either one or the other
[20:59] <slangasek> xivulon: I would probably do ubuntu-hardy-desktop-i386.metalink or such; prefixing the distro name to the image name
[21:00] <slangasek> or else mirroring the per-flavor heirarchy currently present on releases.u.c/cdimage.u.c
[21:00] <xivulon> slangasek: I really only care about having redirections (.htaccess) which are fixed across a cycle and gets updated
[21:01] <xivulon> The rest is for "real users" more than programmatic access
[21:01] <xivulon> provided the redirections get me to the right metalink, I do not really mind what is called
[21:01] <infinity> What's the actual goal here?
[21:01] <infinity> A static URL that's always correct?
[21:01] <xivulon> yes
[21:02] <slangasek> infinity: giving wubi a static url that can be embedded, yes
[21:02] <infinity> It's my opinion that having the current alpha turn into the release is very much incorrect.
[21:02] <infinity> This is one reason why we do the rename on release.
[21:03] <infinity> ubuntu-hardy-desktop.iso != ubuntu-8.04-desktop.iso, and never should we promote anything that claims otherwise.
[21:03] <xivulon> don't think there is much confusion there
[21:04] <slangasek> there isn't *today*, because we make the distinction
[21:04] <infinity> There would be with a static URL that tracks through to release.
[21:04] <Mithrandir> any reason wubi can't try two URLs and fall back to the not-yet-released one if the released one doesn't exist?
[21:04] <Mithrandir> so it'd be embedding two URLs, not just one
[21:04] <infinity> Having different locations and filenames is a big, blinking warning that you're using unreleased code.
[21:05] <infinity> Anything that obscures that without warning the user is a no-no to me. :/
[21:05] <infinity> s/unreleased/unsupported/, if you prefer.
[21:05] <infinity> (It's obviously all "released")
[21:05] <xivulon> That is of course not an issue for the stand-alone version, but it is problematic for the version bundled with the CD
[21:06] <infinity> Why is it an issue?
[21:06] <slangasek> for the version bundled with the CD, it could read metadata from the CD image itself telling it which url to check...?
[21:06] <xivulon> I will have to change the embedded urls just before release
[21:07] <infinity> if (download release.iso) { continue; } else { download beta.iso; warn user that it's beta; }
[21:07] <xivulon> slangasek: I do parse .disk/info anyway...
[21:07] <slangasek> xivulon: in that case, you already have the metadata that tells you whether it's released
[21:07] <xivulon> sorry infinity misunderstood you above, yes I can do 2 urls
[21:08] <xivulon> slangasek: true.
[21:09] <xivulon> but...
[21:09] <xivulon> if a user gets a copy of wubi.exe and pass it to a friend, that becomes stand-alone, and will not "know" what to download
[21:10] <slangasek> are there identifying version numbers in wubi itself?
[21:10] <Mithrandir> xivulon: make it look at http://releases.ubuntu.com/.manifest or something then?
[21:11] <xivulon> Now I use 8.04+bzr revision
[21:11] <xivulon> But can of course change that
[21:11] <xivulon> Mithrandir: you mean the wubi name?
[21:12] <xivulon> ah no
[21:12] <Mithrandir> xivulon: if you have a standalone .exe, what information does wubi want to collect before it can install?
[21:12] <xivulon> it needs to know the metalink url
[21:13] <Mithrandir> it needs to be able to construct the right metalink URL, right?
[21:13] <xivulon> if the standalone is produced after the ISO ships, that is trivial, but if the standalone is on the CD that is less so
[21:13] <xivulon> yes
[21:13] <Mithrandir> it's not needed for wubi from 8.04 to be able to install 8.10?
[21:14] <xivulon> nope
[21:14] <slangasek> huh? why does it make a difference when the .exe is built?
[21:14] <xivulon> slangasek: if I release an exe on my website after ISO release I can embedded the right urls
[21:14] <slangasek> we will know, a priori, what the urls are for "pre-release" and "release" metalink files, whether these are the same or different
[21:14] <slangasek> I think we're all agreed that the urls should be *defined* well in advance
[21:15] <slangasek> it's just that the "release" url shouldn't be *populated* prior to the release
[21:15] <Mithrandir> they'll just 404 until we actually have released.
[21:15] <xivulon> slangasek: correct
[21:15] <slangasek> xivulon: ok, so where's the problem then?
[21:15] <xivulon> not really a problem, so far there seem to be 2 solutions: I try 2 different urls or we use redirection
[21:16] <slangasek> ok
[21:16] <xivulon> just need to knwo which route you guys prefer, for me redirection is less work :P
[21:17] <cody-somerville> Would someone be so kind to summarize what the problem is? :)
[21:17] <slangasek> well, yes, but I think the above 800 lines of scrollback make it clear that there's resistance to using a single, user-visible url for pre- and post-release files :)
[21:17] <xivulon> ah but that will not be user-visible
[21:17] <cody-somerville> Why would you want that anyhow?
[21:18] <slangasek> cody-somerville: the subject at hand is wubi using metalink files; I don't know that there is a problem currently
[21:18] <slangasek> xivulon: uh, it'll be on a website, users can access websites, therefore it's user-visible :-)
[21:19] <xivulon> in the sense the redirection is serer side (.htaccess) so if you look in the metalinks directory you do not see redirecting urls
[21:19] <xivulon> of course you can also opt for visible redirections
[21:20] <slangasek> mm, ok
[21:21] <xivulon> http://en.wikipedia.org/wiki/Server-side_redirect
[21:23] <slangasek> eh, "server-side redirect" is a very vague term without any implications of .htaccess or any other mechanism; that was my confusion, citing wikipedia doesn't really help :)
[21:25] <xivulon> What I mean is that I can type "http://ubuntu.com/metalinks/hidden_latest.metalink" and get "http://ubuntu.com/metalinks/ubuntu-8.04-desktop.metalink"
[21:25] <xivulon> but if you look in "http://ubuntu.com/metalinks" you only see "ubuntu-8.04-desktop.metalink"
[21:26] <slangasek> yes.  "server-side redirect" implies the former, it didn't imply the latter.  But I'm on the same page now.
[21:28] <xivulon> in any case the downloaded metalink (and hence iso filename) would reflect the actual status
[21:29] <xivulon> so do we use (hidden) redirection or do I test for 2 URLs?
[21:29] <slangasek> not our decision to make yet, still needs the webmaster's buy-in :)
[21:30] <slangasek> (and if the webmaster nack's hosting it on www.ubuntu.com, then it'll have to be two urls since pre-release images are hosted on a completely different server from releases)
[21:31] <xivulon> I would assume that in any case, the filename within the metalink will match the underlying iso file URL (i.e. now it would be hardy-desktop-i386.iso)
[21:31] <slangasek> right
[21:32] <xivulon> slangsek thanks a lot for bearing with me
[21:32] <xivulon> aaaaa^
[21:33] <slangasek> no problem at all; sorry for having deferred this so long
[21:33] <xivulon> not strictly a problem for me, I simply wanted to avoid post feature-freeze changes
[21:51] <soren> pitti: debian bug 465340
[21:51] <ubotu> Debian bug 465340 in dpkg "dpkg: Broken call to open in Dpkg/Control.pm" [Important,Open] http://bugs.debian.org/465340
[21:57] <soren> pitti: Short version: Please use dpkg-gencontrol differently :)
[22:10]  * soren gives doko "the eye"
[22:11]  * ion_ has two.
[22:13] <doko_> siren: ?
[22:13] <doko_> soren: ?
[22:14] <soren> doko: Hm.... I'm having odd problems with grub and right now, my prime suspect is your dpkg patch :)
[22:17] <soren> doko: Yup, it seems to be accurate.
[22:17] <soren> doko: It checks:
[22:17] <soren> if test "x$CFLAGS" = x; then default_CFLAGS=yes
[22:17] <soren> fi
[22:18] <soren> And if $default_CFLAGS isn't "yes", it doesn't check for e.g. -fno-stack-protector and then it blows up.
[22:21] <doko> soren: ohh great, it does the CFLAGS settings stuff in debian/rules, but then it doesn't pass it to the upstream make
[22:21] <soren> doko: What would you suggest? Adding -fno-stack-protector to CFLAGS? unset CFLAGS before calling configure?
[22:21] <doko> or configure
[22:22] <soren> doko: No, it *does* get passed to configure. That's the problem. configure behaves differently depending on whether or not CFLAGS is unset(/empty) or not.
[22:25] <doko> soren: this is insane. the conservative thing would be to unexport CFLAGS, and mention it in debian/rules
[22:27] <soren> doko: That's your recommendation?
[22:27] <soren> doko: I just tested it, and it does indeed fix it. Not surprising, I'm just saying.
[22:28] <doko> soren: unexport CFLAGS, and maybe remove the setting of CLAGS in the rules file, it's just misleading
[22:30] <soren> doko: Hm... I'm not sure I remember this correctly..
[22:30] <soren> If a makefile specifies CFLAGS, but there's also a CFLAGS environment variable, what happens?
[22:31] <soren> The environment variable takes precedence, right?
[22:32] <doko> soren: in debian/rules, CFLAGS is not passed to configure, so CFLAGS from debian/files is ignored, configure takes it from the env. in the generated Makefile, it's available and taken, unless you call make with the -e option
[22:33] <soren> doko: Ah.. Ok.
[22:39] <emgent> debian #462984
[22:39] <ubotu> Debian bug 462984 in python-moinmoin "python-moinmoin: MOIN_ID cookie bug" [Serious,Open] http://bugs.debian.org/462984