[00:04] <asac_> fta: it is your call :)
[00:20] <mohbana> does flash work?
[00:21] <jdong> no. we specifically put in some code to break it because it'd be funny to watch 30 million people install it and scratch their heads.
[00:24] <mohbana> ok bug dound
[00:26] <samtb2> hi there. ant in intrepid seems to depend on gcj even though i have openjdk installed. is this correct? am i supposed to ignore dependencies or something or just install gcj too?
[00:29] <jibel> ScottK: Hi, the bug with pycentral in bug 293208 is the way dist-upgrade of python-modules are handled by pycentral
[00:29] <jibel> ScottK: mvo and pitti have discussed about it in bug 291262
[00:33] <Keybuk> pitti: hmm, seem to be hitting a large number of archive 404s :-/
[00:39] <Keybuk> elmo: around?
[00:41] <elmo> yeah
[00:41]  * cjwatson starts to flush out syncs, at least as far as the autosyncer managed to get before falling over
[00:41] <Keybuk> elmo: is there an internal archive casey should use instead of archive.u.c ?
[00:42] <elmo> Keybuk: what's wrong with archive.u.c ?
[00:42] <Keybuk> elmo: it keeps 404ing
[00:43] <elmo> checking
[00:44] <Keybuk> as if Packages is being updated but not pool
[00:44] <elmo> nah, a couple of machines are out of sync
[00:45] <elmo> due to trigger hoarkage, I'm ficking it
[00:46] <wgrant> cjwatson: Are we expecting queue-builder to collapse again this time, meaning buildds sit idle for hours, or is that fixed?
[00:46] <Keybuk> I'm sure whatever bug we hit last time is fixed
[00:46] <cjwatson> wgrant: I have no idea and am not all that desperately worried
[00:46] <cjwatson> wgrant: we'll find out
[00:46] <Keybuk> and that we'll find all new bugs this time
[00:46] <Keybuk> ;)
[00:47] <wgrant> Heh.
[00:47] <ajmitch> wgrant: have faith
[00:47] <LordMetroid> Alright, lets get on deving 9.04
[00:48] <LordMetroid> But how do a newbie as me go about doing so?
[00:48] <LordMetroid> I mean newbie to Open Source development
[00:48] <cjwatson> http://wiki.ubuntu.com/ContributeToUbuntu
[00:49] <wgrant> ajmitch: Perhaps.
[00:49] <elmo> Keybuk: all in sync, and should be ok going forward
[00:50] <Keybuk> thanks
[00:50] <Keybuk> looks like it ran this time
[00:57] <LordMetroid> cjwatson: thank you
[00:58] <slangasek> tjaalton: have you seen bug #283015 by chance?  I see that you've done a lot of the xkb-data uploads
[01:09] <Thayle> How do I get involved?
[01:09] <directhex> Thayle, #ubuntu-motu is best for you
[01:09] <Thayle> Alright thanks.
[01:09] <directhex> remember that many people are busy with the election though
[01:10] <slangasek> with the election, or with the election parties?
[01:11] <TheMuso> heh
[01:12]  * ajmitch really should go & vote this weekend then
[01:13] <slangasek> so you can get your free coffee at Starbucks?
[01:13] <ajmitch> I doubt they'd do that here :)
[01:14] <jdong> slangasek: isn't that a felony?
[01:15] <ajmitch> we have to endure a few more days of campaigning in NZ still
[01:15] <slangasek> jdong: getting free coffee?
[01:15] <ajmitch> darn, hardy
[01:15] <wgrant> What has Hardy done now?
[01:15] <ajmitch> hardy's debootstrap won't let me create a jaunty pbuilder tarball
[01:16] <wgrant> Hah.
[01:16] <wgrant> Symlinks win there.
[01:16] <ajmitch> haven't upgraded the laptop to intrepid yet :)
[01:16] <slangasek> ajmitch: pass the extra arg to tell it to use the intrepid or hardy script for building
[01:18] <jdong> slangasek: it's offering a monetary incentive to vote, is it not? :)
[01:19] <ajmitch> jdong: I believe they've stopped doing that
[01:19] <jdong> ajmitch: really? is it for that reason?
[01:19] <slangasek> jdong: Starbucks actually already got slapped for trying to offer it as an incentive for voting, so they instead changed it to giving free coffee to everyone
[01:19] <jdong> slangasek: ah, gotcha :)
[01:19] <jdong> slangasek: sadly I don't have any starbucks around here
[01:19] <ajmitch> jdong: from what I heard, yes, a number of companies have changed to just giving free stuff/discounts to all
[01:20] <jdong> ajmitch: haha interesting, I didn't think they'd take that radical reading of election laws so literally :)
[01:20] <slangasek> jdong: well you're not missing much, it's only brewed coffee that they're giving away :)
[01:20] <slangasek> also, it's not that Starbucks took the reading literally, it's that the Washington sec of state smacked them
[01:20] <jdong> slangasek: with that money I can power my car for 0.5 seconds!
[01:21]  * Keybuk tries to remember what the tomerge files are for
[01:21] <Keybuk> DaD maybe?
[01:21] <Keybuk> Adri2000: ?
[01:22] <cjwatson> ajmitch: I haven't backported that debootstrap yet
[01:22] <cjwatson> ajmitch: but yes, the jaunty script is just a symlink to gutsy, let alone hardy/intrepid
[01:22] <ajmitch> yes, I've just put in that symlink for now
[01:25] <Keybuk> ok, mom's brain wiped again *sigh*
[01:25] <wgrant> That sounded very strange.
[01:30] <jdong> wgrant: better than last time we had that mom and dad merging discussion.
[01:30] <jdong> that sounded much worse.
[01:32] <wgrant> jdong: Indeed, indeed.
[01:34] <Keybuk> ERROR:root:dpkg-genchanges for changes/ubuntu/d/dia/dia_0.96.1-7ubuntu1_source.changes failed
[01:34] <Keybuk> kooky
[01:54] <Keybuk> right
[01:54] <Keybuk> let's try a patch publish again
[01:56] <Keybuk> ok, http://patches.ubuntu.com/ now has correct data I think
[01:58] <superm1> hum what happened to mom?  did she die?
[01:58] <Keybuk> she suffered an aneurysm during her move
[02:00] <superm1> is she talking about moving in with dad again?
[02:00] <StevenK> Keybuk: MoM moved?
[02:01] <cody-somerville> Your MoM is so fat... ugh, never mind. :(
[02:04] <Keybuk> StevenK: casey likes to throw disks
[02:04] <Keybuk> and when casey isn't throwing disks, mom is filling 'em
[02:04] <Keybuk> looks like there was more damage from the filled disk than I thought
[02:05] <Adri2000> Keybuk: yes that was for doing a DaD-like front-end to MoM. iirc I started doing something but nothing was actually finished and published
[02:05] <Adri2000> I guess you can keep them though, they might be useful for something else in the future
[02:05] <Keybuk> mathiaz patched them to add more info, so he must be using them for something ;)
[02:11] <Keybuk> comments support:
[02:11] <Keybuk> it would be nice to have that as plain cgi
[02:11] <Keybuk> not being resident in memory would make elmo happier
[02:16] <Keybuk> right
[02:16] <Keybuk> let's spin this again and see whether we get merges with patches this time ;)
[02:19] <Keybuk> ValueError: process failed 17: dpkg-source -x abiword_2.6.4-4.dsc /srv/patches.ubuntu.com/unpacked/a/abiword/2.6.4-4
[02:19] <Keybuk> GnNNAARRGH
[02:19] <ajmitch> that's not a useful error to work with
[02:22] <NCommander> ScottK, hola
[02:59] <lifeless> Keybuk: :13:57 < nhandler> Is MoM being updated? It only goes up to 'm' right now
[02:59] <lifeless> :
[02:59] <lifeless> from -motu
[03:00] <Keybuk> see above
[03:01] <lifeless> Keybuk: ah, I only recalled your saying patches should be ok earlier
[03:01] <lifeless> Keybuk: thanks
[03:47] <NCommander> wgrant, ping
[03:51] <wgrant> NCommander: Hi.
[03:51] <NCommander> wgrant, care to do some upload sponsoring?
[03:52] <wgrant> NCommander: Sorry, lots of homework.
[03:52] <NCommander> np
[04:24] <ScottK> NCommander: Hello.
[04:24] <NCommander> hey ScottK
[05:20] <Keybuk> mom working on universe now
[05:20] <Keybuk> pitti: http://merges.ubuntu.com/a/autogen/ now has both sets of patches ;
[05:23] <Keybuk> oh, I mean multiverse
[05:48] <Keybuk> ...
[05:48] <Keybuk> looks like cjwatson did a sync
[06:15] <pitti> Good morning
[06:15] <Hobbsee> hey pitti!
[06:15] <pitti> Keybuk: I noticed some packages which have both patches
[06:15] <pitti> Keybuk: archive 404> ah, that could be it; I occasionally get that on my box as well, but 5 seconds later it works again
[06:16] <Keybuk> looked like a combination of factors
[06:17] <pitti> yay jaunty
[06:18] <Keybuk> of course, now it has to catch up with the sync
[06:18] <StevenK> Hey pitti
[06:26] <superm1> cjwatson, it looks like that task bug won't actually be resolved until soyuz 2.1.11 on at least 2008-11-19.  at least until then would you anticipate any ramifications in switching it back over to calling upon the meta packages in livecd-rootfs?
[06:28] <superm1> if not, i'll do another upload of livecd-rootfs with that hack in place to do a first alpha, planning to remove it shortly after first alpha
[06:41] <michael__> MoM?
[06:44] <bryce> merge-o-matic
[06:44] <bluefoxicy> damnit
[06:44] <bryce> iz our lil' friend
[06:44] <bluefoxicy> I cannot sing Beautiful Dreamer, and I haven't been able to actually record on Ubuntu for like 6 releases
[06:47] <michael__> cool
[07:25] <tjaalton> slangasek: aww that one.. yes it was mentioned on another bug that got fixed.. should be simple to fix
[07:25] <slangasek> ok, cool :)
[07:47] <pitti> ArneGoetje: intrepid-proposed langpacks copied; however, since the jaunty sync wave is building, too, building the langpacks will take a while
[07:52] <StevenK> i386      1532 builds waiting in queue
[07:52] <StevenK> Daaaaaaaaaaaaaamn
[07:52] <pitti> need more buildds :)
[07:52] <pitti> unifying the ppa and ubuntu buildds would be great in times like that
[07:53] <Hobbsee> whee!
[07:53] <Hobbsee> pitti: does that mean you'll fix your buildd.py script to work for rescores again?  :)
[07:53] <wgrant> pitti: There are bugs about that, filed by almighty people.
[07:53] <pitti> yeah, I talked about that with Adam
[07:54] <liw> pitti, if there was a way to run buildds easily under kvm, perhaps temporary buildds could be arranged for these times
[07:54] <wgrant> Pooling buildds between the big three archs and PPA/primary would indeed be very nice.
[07:55] <pitti> and about 800 of those builds are langpacks, which are currently only built by i386 buildds
[07:55] <wgrant> Hmm, pretty pathetic sync run. Was that incomplete, or are we seeing the effects of the Lenny freeze?
[07:57] <liw> wgrant, I'm pretty sure we are
[07:57] <liw> though I can't be bothered to dig up statistics for how sid has changed in the past several months
[07:58] <pitti> ogasawara: o_O
[07:58] <pitti> ogasawara: I thought we settled for having just one bug for tracking 2.6.27.y patches, to ease bureaucracy?
[07:59] <pitti> ogasawara: so from all those invalid bugs I take it that intrepid final already has 2.6.27.2?
[07:59] <pitti> ogasawara: ah, yeah, that's what the changelog says anyway
[08:45]  * soren makes a note to remember to upload a new vim with syntax highlighting for Jaunty+1 *before* Jaunty releases
[08:46] <lasko> *nod*
[08:46] <Treenaks> soren: current vim doesn't have syntax highlighting?
[08:47] <lasko> current vim should.
[08:47] <Treenaks> lasko: *phew* :)
[08:47] <soren> Not for "Jaunty" in changelogs.
[08:47] <Keybuk> it does highlight jaunty
[08:47] <Keybuk> in that oh-so-attractive yellow-on-OMG-red ;)
[08:48] <soren> Well.. Yes. :)
[08:48] <lasko> Though... if I remember correctly it requires vim-full?
[08:49] <soren> No, it's in vim-runtime.
[08:49] <soren> The syntax definition, that is.
[08:49] <lasko> ahh
[08:51] <soren> cjwatson: Are you doing vim already or should I grab it?
[08:52] <Keybuk> I don't think he's up yet
[08:57] <pitti> soren: just do it :)
[08:57] <NCommander> hey soren
[08:57] <soren> NCommander: ahoy.
[08:57] <soren> pitti: Will do :)
[08:57] <pitti> random throught of the day: using vimplate helps a lot for creating debian bugs with ubuntu patches
[08:57] <NCommander> soren, how goes it this $TIME_OF_DAY
[08:58] <pitti> soren: which remeinds me that I totally forgot to upload mutt as my first merge; damn
[08:58] <pitti> oh, we are current, nevermind
[09:00] <soren> NCommander: I'm not sure, really. I'm rather knackered. I didn't get to sleep much last night.
[09:00] <soren> NCommander: Yourself?
[09:01] <sebner> pitti: mighty pitti. mind moving audacious from proposed to updates? bug #291643
[09:01] <pitti> sebner: hm, I already went through the list today, that wasn't on my radar
[09:01] <pitti> sebner: nack; just 2 days old, needs 7
[09:01] <NCommander> soren, trying to sleep and failing miserably -/
[09:02] <sebner> pitti: also though I have already 4-5 positive comments?
[09:02] <soren> NCommander: 'tis easy. Just stop.
[09:03] <pitti> sebner: it's current policy; we occasionally do exceptions for really grave bugs, where the severity outweighs the risk of regression
[09:03] <sebner> pitti: Ok Í see. anyway, thx
[09:03] <pitti> but it needs explicit justification
[09:09] <pitti> \sh: heck, what *is* wrong in the picture? :-)
[09:09] <StevenK> pitti: You don't see it? :-P
[09:09] <pitti> oh, now I do
[09:10] <pitti> oops :)
[09:10] <StevenK> Haha
[09:10] <Keybuk> that's the australian mirror
[09:10] <StevenK> Haha
[09:10] <pitti> ʎןʇɔɐxǝ
[09:14] <NCommander> wow
[09:14] <NCommander> McCain got slaughter
[09:14] <NCommander> er
[09:14] <NCommander> wrong channel
[09:14] <Keybuk> yay, MoM finished
[09:14]  * Keybuk remembers to unlock her
[09:15] <StevenK> You lock up MoM?
[09:15] <Keybuk> sure
[09:16]  * Keybuk decides that chewing on a permanent CD marker is not such a great idea
[09:20]  * mvo uploads a jaunty update-manager (for the early birds)
[09:22] <Hobbsee> oh dear...
[09:22] <Keybuk> pitti: you leave the Changed-By to be mom?
[09:22] <pitti> Keybuk: whoops; not usually, that was a brainfart
[09:23] <pitti> Keybuk: I usually merge by hand, but that asciidoc thing was so simple that I just took MoM's output
[09:23] <StevenK> pitti: Including "DESCRIBE CHANGES HERE" ?
[09:23]  * sebner hugs mvo for that :P
[09:23] <pitti> StevenK: no, the changelog is fine :)
[09:24] <pitti> but apparently I used "vi", not "dch"
[09:24] <Keybuk> I often wonder if I made MoM secretly add "THIS PACKAGE WAS MERGED BY AN INATTENTIVE PERSON" to the description, how many people would notice :p
[09:24] <StevenK> Hahah
[09:25]  * pitti sighs at the devscripts delta
[09:26] <mvo> soren: do you think we could make "-net nic,model=virtio" default in the kvm in jaunty?
[09:27] <mvo> soren: and maybe a bigger default than -m 128 ?
[09:27] <pitti> mvo: oh, is that the magic incantation to actually get network in kvm?
[09:27] <Keybuk> and -soundhw all
[09:27] <Keybuk> and make it somehow magically work on my XPS
[09:27] <mvo> pitti: for me "-net user -net nic,model=virtio" is the key to get fast networking
[09:27] <pitti> mvo: well, at first I wanted to get networking *at all*
[09:28] <mvo> Keybuk: yeah, good point
[09:28] <mvo> pitti: otherwise its stuck at ~300kb/sec even from a local cache
[09:28] <mvo> pitti: oh? -net user did that for me, but that is the default AFAIK
[09:28]  * Keybuk has the only Intel Core 2 Duo without Virtualization support
[09:28] <pitti> mvo: inside it might work, but at the host I tried to configure pan0 appropriately, and it wouldn't work
[09:29] <pitti> mvo: simply no ping; and that didn't even get to masquerading or so
[09:29] <pitti> I ended up kpartx-mounting the image for copying stuff into the vm
[09:30] <NCommander> Keybuk, nope, I got one too
[09:30] <NCommander> Yay first generation hardware
[09:30] <Keybuk> but since it can run amd64, vmware works
[09:30] <NCommander> Keybuk, wait, if it supports amd64, it should have VTx
[09:30] <Keybuk> NCommander: tell that to Dell
[09:30] <NCommander> THe chip supports it
[09:31] <NCommander> you might need to cox the bios to enable it
[09:31] <soren> mvo: No.
[09:31] <Keybuk> NCommander: no vmx in /proc/cpuinfo
[09:31] <soren> mvo: That would make anything but Hardy and Intrepid fail miserably.
[09:31] <Keybuk> whereas my Intel Core Duo has vmx in /proc/cpuinfo even when disabled in the BIOS
[09:31] <NCommander> Keybuk, d'oh
[09:31] <soren> mvo: (the nic model thing, that is)
[09:32] <NCommander> Keybuk, what model Dell is it?
[09:32] <Keybuk> NCommander: XPS m1330
[09:32] <NCommander> hrm
[09:33] <NCommander> Keybuk, the m1330 is listed as supporting it
[09:33] <NCommander> You need a BIOS greater than A2 however
[09:34] <mvo> soren: oh, ok - that is a good arguement against it ;)
[09:34] <NCommander> Keybuk, to get it to work on mine, I had to apply a hack to my BIOS :-)
[09:35] <Keybuk> a hack?
[09:35] <NCommander> Sony locks out VTx on their chips
[09:35] <NCommander> YOu have to mod the BIOS to enable it
[09:35]  * NCommander LOVES playing find the offset
[09:36] <NCommander> Dell just seems to require a new enough BIOS
[09:36]  * Keybuk has bios A08
[09:36] <NCommander> And no VTx ENABLE in the POST menu?
[09:36] <Keybuk> nope
[09:36] <soren> Keybuk: vmx capabilities show up in cpuinfo even when disabled in the BIOS. That's expected.
[09:37] <NCommander> soren, not always
[09:37] <Keybuk> it's a T5550
[09:37] <NCommander> Ouch
[09:37] <NCommander> Ok
[09:37] <NCommander> Yeah
[09:37] <soren> NCommander: I've never seen it not happen.
[09:37] <NCommander> I can't believe they actually shipped a core without VMX which the T5550 is
[09:38]  * Keybuk has no understanding of Intel product names or numbers
[09:38] <NCommander> soren, I know on this machine I always had it, it was just a matter of hacking the Phoenix BIOS this POS came with
[09:39]  * NCommander notes that he got this machine at prices that are disturbing low
[09:39] <NCommander> Only reason I got a sony
[09:39] <Keybuk> this was the cheapest on-offer pick from the website
[09:39] <Keybuk> it mostly runs iTunes and Lightroom ;)
[09:43] <NCommander> Keybuk, it could be worse
[09:43] <directhex> when does jaunty go EOL?
[09:43] <Keybuk> t'other half got the expensive, top-of-the-range 1550
[09:44] <soren> NCommander: Do you actually have examples of hardware that manages to hide vmx even from cpuinfo when disabled in the bios?
[09:44] <Keybuk> directhex: two years last thursday
[09:44] <directhex> soren, yes! this desktop pc does that!
[09:44] <NCommander> directhex, its a little early for that ;-)
[09:44] <NCommander> directhex, its a little early for that ;-)
[09:44] <NCommander> er
[09:44] <directhex> NCommander, not when warning upstream of which versions of their apps will be shipped
[09:44] <NCommander> Not offhand sommer
[09:45] <NCommander> wow
[09:45] <NCommander> I totally fail Keybuk
[09:45] <NCommander> wait, no, that was soren
[09:45] <soren> directhex: Brand?
[09:45] <NCommander> -ENOSLEEP
[09:45] <directhex> soren, HP
[09:45] <soren> directhex: Can I see your cpuinfo, please?
[09:45] <directhex> soren, i had to actually flash on a replacement BIOS just to get the ability to turn it on
[09:45] <NCommander> directhex, It has an AMD core, right?
[09:45] <directhex> NCommander, intel
[09:45] <NCommander> O_o;
[09:45] <NCommander> I've only seen AMD's do that
[09:45] <soren> NCommander: AMD's don't have vmx.
[09:45]  * Keybuk bestows the Tollef Award for Terseness on mvo
[09:45] <Keybuk> update-manager (1:0.95) jaunty; urgency=low
[09:45] <Keybuk>   * updated for jaunty
[09:46] <NCommander> I meant the equivelent of vmx for AMD
[09:46] <Keybuk> --
[09:46] <Mithrandir> NCommander: svm, then
[09:46]  * soren nods
[09:46] <directhex> soren, i turned it on in the replacement "vpro" bios: flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
[09:46] <directhex> soren, the regular bios doesn't have the functionality, full stop
[09:47] <soren> directhex: So no chance of seeing the full cpuinfo with the regular bios?
[09:48] <NCommander> soren, some processors only report abilities when they are actually active
[09:48] <directhex> soren, not unless i boot XP and re-flash
[09:48] <NCommander> soren, i.e., last time I checked, lm only shows up when my process is actually in long mode
[09:48] <NCommander> s/process/processor
[09:49] <directhex> soren, an HP dc7700, if you care
[09:50]  * mvo happily accepts the award from Keybuk and put it into his trophy glass cabinet
[09:50] <Keybuk> speech!
[09:51] <NCommander> soren, you seem suprised that cpuinfo isn't always static
[09:52] <directhex> soren, http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=3232108&prodTypeId=12454&prodSeriesId=3232029&swLang=13&taskId=135&swEnvOID=1093#120
[09:52] <directhex> soren, the "HP Compaq Business Desktop System BIOS (786E1 BIOS)" download cannot do vmx
[09:52] <directhex> "HP Compaq dc7700p Business Desktop System BIOS for Intel vPro Technology (786E1 BIOS)" can
[09:53] <soren> NCommander: Not really. I'm just puzzled that it's the case for vmx/svm. I never encountered a system where it wasn't reported in cpuinfo, if the CPU had the capabilities.
[09:53] <NCommander> soren, well, I would think its a safety feature
[09:53] <soren> How so?
[09:53] <Chipzz> hrrrrm
[09:53] <Chipzz> Error in /home/chipzz/.mutt/sidebar, line 5: sidebar_width: unknown variable
[09:54] <NCommander> Programs trying to use VTx are supposed to check with the BIOS to make sure it actually would be safe to do so
[09:54] <Chipzz> but the changelog documents the sidebar patch as being applied?
[09:54] <NCommander> Virtualization solutions like Xen run guest OSes in Ring 1, and only fault to -1 (VTx) when needed
[09:55] <NCommander> I would guess that this behavior exists to make sure no instructions are not run in the wrong ring by accident
[09:55] <Chipzz> soren: ^^
[09:55] <Chipzz> since you did the last upload
[09:55] <NCommander> soren, I have absolutely no idea if thats the truth, but its the only plausable explication I can think of (lm is the other mode that sometimes seems to disappear and reappear as well ...)
[09:56] <soren> Chipzz: Do you have mutt-patched installed?
[09:56] <Chipzz> just mutt; but the mutt changelog documents the patch as being applied
[09:56]  * soren is using the sidebar patch quite happily.
[09:56] <soren> Chipzz: Yes. To mutt-patched.
[09:56] <Chipzz> are mutt and mutt-patched build from the same source?
[09:56] <soren> Yes.
[09:56] <Chipzz> ah, that would explain
[09:57] <Chipzz> quite misleading though
[09:57] <soren> What is?
[09:57] <directhex> NCommander, it's true - kvm was what told me i had no vmx flag
[09:57] <Chipzz> that the changelog of mutt documents a feature being applied in mutt-changed
[09:58] <Chipzz> (yes I know packages built from the same source have the same changelog;
[09:58] <NCommander> directhex, wait, kvm told you?
[09:58] <Chipzz> hence my comment about "quite confusing")
[09:58] <directhex> NCommander, well, the init script
[09:58] <NCommander> directhex, that error message usually means the BIOS isn't allowing access to ring -1
[09:58] <Chipzz> anyway problem fixed
[09:59] <directhex> NCommander, the init script just looks for "vmx" or "svm" in cflags, and if you have neither, says "                log_failure_msg "Your system does not have the CPU extensions required to use KVM. Not doing anything.""
[09:59] <directhex> cpuflags, even
[09:59] <NCommander> Oh, I see
[10:00]  * NCommander notes VTx is an amazing hack
[10:00] <Chipzz> soren: maybe make a note in the changelog about mutt-patched?
[10:01] <NCommander> directhex, you know how VTx works?
[10:02] <directhex> NCommander, black magic and voodoo? that's enough for me
[10:02] <NCommander> lol
[10:02] <soren> Chipzz: I'm not going to change earlier changelog entries. I might add a reference to mutt-patched in mutt's long description, though.
[10:04] <pitti> mvo: I just started upgrading my wife's computer to 8.10; u-n told me about the missing nvidia driver
[10:04] <pitti> mvo: however, since version -96 now works again in intrepid-proposed, we should update u-m as well for that; is that already on your radar, or shall I open a tracking bug for this?
[10:04] <pitti> mvo: (or a new task, rather)
[10:06] <mvo> pitti: its on my radar, tseliot mentioned it yesterday
[10:06]  * pitti hugs mvo
[10:07] <mvo> pitti: I just need to add checks so that we ensure we never end up with the non-working version
[10:08] <pitti> mvo: that's similar to the jockey update (bug 293107)
[10:08] <Chipzz> soren: I wasn't suggesting that. but in the next changelog maybe?
[10:08] <pitti> mvo: I think we can safely do it once the new driver is in intrepid-updates, right?
[10:08] <pitti> mvo: btw, version 71 still seems to fail
[10:09] <soren> Chipzz: Like " * Oh, look! There's a package called mutt-patched, too!" ? :)
[10:10] <mvo> pitti: oh, good to know
[10:10] <Chipzz> soren: :) or just mentioning that the patch is only applied to mutt-patched next time updating the patch?
[10:11] <Treenaks> 11:05 <@     _mike_> zo, alle newszilla dreaders zijn nu debian/lenny, met de  laatste diablo code, en een openvz 0-master
[10:11] <Treenaks> 11:05 <@     _mike_> <phew>
[10:11] <Treenaks> OOPS
[10:11] <Treenaks> --------------------------------------------------------------------------------
[10:11] <mvo> pitti: yeah, I think so too. when its in -updates we should be fine
[10:12] <Chipzz> Treenaks: where you from?
[10:12] <Treenaks> so.. on-topic, what about disabling middle-button emulation (left+right=middle) for jaunty?
[10:13] <directhex> Treenaks, it's disabled? :(
[10:13] <Treenaks> directhex: no, it's enabled
[10:13] <directhex> Treenaks, thank god
[10:13] <Treenaks> directhex: that's why I pasted something I didn't want to paste
[10:16] <Keybuk> Treenaks: get a better IRC client?
[10:16] <Keybuk> xchat requires you to press Enter after pasting
[10:17] <directhex> i wonder if smuxi does
[10:17] <Treenaks> Keybuk: so does irssi, but only if you paste more than 3 lines
[10:17] <Treenaks> Keybuk: but good idea, thanks.. I'll see if I can configure that
[10:18] <Keybuk> Treenaks: the real problem there is using an IRC client that is blissfully unaware of the fact you're running in a GUI
[10:18] <Keybuk> there are plenty of real GUI clients available ;)
[10:19] <Treenaks> Keybuk: make a screen for X apps and I'll consider them ;)
[10:19] <Keybuk> it's called vnc :P
[10:19] <Treenaks> s/screen/gnu-screen like program/
[10:19] <liw> for those who use irssi so that they can run it under screen, I note that bip seems to work very well with xchat: you can quit xchat whenever you like, and then re-connect to bip (an irc proxy) when you feel like being flooded again
[10:21] <directhex> really?
[10:21] <directhex> -directhex- VERSION bip-0.7.2
[10:26] <Keybuk> see, I just don't bother
[10:26] <Hobbsee> liw++
[10:26] <Keybuk> and accept that people will talk about me when I'm not here
[10:26] <Keybuk> I don't let it worry me
[10:27] <ion_> Middle button emulation for the win.
[10:27] <liw> Keybuk, I don't care if people talk about me, but I find it practical to know when they talk _to_ me, without my having to monitor irc constantly
[10:27] <liw> Keybuk, there is an unfortunate tendency amongst people to wait for people to get onto irc rather than e-mail them :(
[10:28] <Keybuk> if you're eating dinner, or asleep, why does it matter if they're talking to you?
[10:28] <Keybuk> you can't do anything about it - so there's no real point to being online
[10:28] <Keybuk> and the best bit is
[10:28] <Keybuk> if you're not online
[10:28] <Keybuk> they stop trying
[10:28] <liw> that's certainly a valid point of view, I don't disagree with that at all
[10:29] <liw> but people have expressed annoyance if I*m not on irc throughout my entire work day
[10:32] <Keybuk> why would you disconnect during your working day?
[10:32] <liw> to be able to concentrate for a while, without having xchat interrupt me
[10:33] <soren> Keybuk: But you might miss out on people talking *about* you. :(
[10:33] <Keybuk> liw: I just ignore it
[10:33] <liw> Keybuk, you're a better man than I am (but we knew that)
[10:33] <Keybuk> then again, I have very minimal notification
[10:33] <Keybuk> it just places an icon in the notification area at the top
[10:35] <cjwatson> superm1: it's fine to use the metapackages until then
[10:35] <cjwatson> wgrant: it got stuck at libxcrypt; I fixed that by hand and am rerunning
[10:36] <cjwatson> soren: vim> go ahead if you haven't already
[10:37] <soren> cjwatson: Almost done. Got distracted. :)
[10:43] <cjwatson> mvo: your debconf changelog is bizarre; the remaining changes allegedly include a backport from trunk, but those changes were in the Debian upload you merged
[10:45] <cjwatson> mvo: could you commit your changes to bzr, too?
[10:45] <cjwatson> with a 'bzr merge' there
[10:48] <mvo> cjwatson: my only change to debconf (that I can remember is): 1.5.23ubuntu2 - is that the one?
[10:48] <mvo> and that change is in bzr
[10:48] <cjwatson> oh, it was Scott
[10:48] <cjwatson> Keybuk: ^-
[10:49] <Keybuk> cjwatson: ?
[10:49] <cjwatson> Keybuk: you uploaded debconf, apparently
[10:49] <Keybuk> a merge?
[10:49] <cjwatson> yes
[10:49] <Keybuk> right
[10:49] <cjwatson> Keybuk: you didn't commit the changes to bzr, and the merge changelog entry was wrong
[10:50] <Keybuk> I know
[10:50] <cjwatson> can you please fix that?
[10:50] <Keybuk> I can't retroactively fix the changelog message
[10:50] <cjwatson> MoM should have a warning for packages maintained in bzr
[10:51] <Keybuk> packages maintained in bzr are a pain in the arse
[10:51] <Keybuk> it's impossible to ever get them right
[10:51] <Keybuk> I won't touch it next time
[10:51] <cjwatson> they're trivial to get right if you use bzr ;-)
[10:51] <stefanlsd> Keybuk: i agree with cjwatson. We just need a process
[10:51] <seb128> the issue is that not everybody uses bzr
[10:51] <Keybuk> you have to apt-get the source
[10:51] <Keybuk> then you have to get the branch
[10:51] <cjwatson> not in this case
[10:51] <Keybuk> then you have to figure out what's in the branch that's not in the source
[10:51] <Keybuk> and somehow overlay them over each other
[10:52] <Keybuk> and then figure out where you got to
[10:52] <Keybuk> and then probably do other things to make it build
[10:52] <Keybuk> it's utterly stupid
[10:52] <cjwatson> seb128: no, the issue is when people decide not to use bzr even when the package already does
[10:52] <cjwatson> seb128: I don't mind (well, I do, but :-) ) that not everyone uses bzr right now; it's the clash that's awkward
[10:52] <Keybuk> no
[10:52] <seb128> right
[10:53] <Keybuk> the issue is that bzr is fundamentally incompatible with the way we do source packages
[10:53] <Keybuk> and we're trying to force people to use it
[10:53] <Keybuk> and it doesn't work
[10:53] <seb128> but everybody doesn't want to spend half an hour rather than 5 minutes just to fight bzr
[10:53] <cjwatson> Keybuk: in this case, the bzr branch is sufficient; I don't believe any overlaying is necessary
[10:53] <pitti> Keybuk: apt-get source warns, and you have debcheckout for convenience
[10:53] <seb128> I just stopped touching packages in bzr due to that
[10:53] <cjwatson> Keybuk: I try to make that be the case for all my packages
[10:53] <cjwatson> or at least have it be obvious when it isn't
[10:54] <mvo> Keybuk: I find bzr a huge help for my package maintainance in many ways
[10:54] <cjwatson> Keybuk: so AFAICT you're complaining about something which is true for other packages but not this one
[10:54] <wgrant> I think much of the problem is that bzr usage is very inconsistent.
[10:54] <cjwatson> wgrant: yes, I agree with that
[10:54] <Keybuk> cjwatson: my compaint is the time it takes to figure out what package this one is
[10:54] <Keybuk> whether it's one that's easy, or hard
[10:54] <Keybuk> and that you still have to assume it's hard to find out it's easy
[10:54] <cjwatson> Keybuk: so leave it alone if you don't want to put in that effort
[10:54] <Keybuk> and it's a waste of time
[10:54] <seb128> mvo: that's likely because you have complicated packages, it's just annoying when doing simple changes
[10:54] <Keybuk> cjwatson: like I said, I'll leave it alone next time
[10:54] <cjwatson> don't screw it up for other people
[10:55] <pitti> Keybuk: but I think a MoM warning if a package has Vcs-Bzr:.*launchpad* would be utterly helpful
[10:55] <seb128> mvo: but we already had this discussion ;-)
[10:55] <Keybuk> pitti: I'd rather just have MoM ignore those packages
[10:55] <mvo> seb128: indeed :)
[10:55] <Keybuk> since it clearly will never be the right thing
[10:55] <cjwatson> Keybuk: I use MoM as a to-do list even while ignoring its *output*
[10:55] <pitti> Keybuk: it can point out the need for merge, but not output anything, right
[10:55] <cjwatson> Keybuk: so ... what pitti said
[10:55] <pitti> Keybuk: maybe its report should point out "debcheckout" or so
[10:55] <Keybuk> can't do that with the current design
[10:55] <Keybuk> either it generates a merge, or it doesn't
[10:56] <cjwatson> make it spanner the merge somehow
[10:56] <Keybuk> why?
[10:56] <Keybuk> whatever it does will clearly be wrong
[10:56] <Keybuk> just like whatever anyone does that doesn't know the package will clearly be wrong
[10:56] <Keybuk> this is why I hate bzr packaging
[10:56] <pitti> the need for merging isn't wrong
[10:57] <Keybuk> it, ironically, makes it impossible to maintain packages as a team
[10:57] <pitti> s/impossible/different/
[10:57] <pitti> and that's what we need to improve
[10:58] <Keybuk> yes, we can spend a lot of time working on the procedures
[10:58] <Keybuk> training
[10:58] <Keybuk> getting everybody to do things the right way
[10:58] <Keybuk> and we'll end up with something almost as good as what we had before
[10:58] <Keybuk> only a little extra work
[10:58] <pitti> (wasn't it you who wrote NoMoreSourcePackages? :-) )
[10:58] <cjwatson> I think there should be a rule that every package that's in bzr should either be buildable straight from the branch, or should fail in an obvious way with directions as to what to generate (but preferably the former, and moving towards universally the former)
[10:59] <cjwatson> there are not enough packages in bzr right now to make that terribly hard to enforce
[10:59] <pitti> yeah, if debcheckout+debuild doesn't work, that's a bug
[10:59] <mvo> does that mean we should keep it as it is and abandon the whole maintain-packages-in-bzr idea?
[10:59] <Keybuk> pitti: the whole point of that document was my assertion that the *only* way do to bzr packaging was to *only* do bzr packaging
[10:59] <pitti> Keybuk: I fully agree :)
[10:59] <Keybuk> trying to package both ways simultaneously is just pain for pain's sake
[10:59] <cjwatson> the problem with that assertion is that it's false. I get by just fine otherwise
[10:59] <pitti> yes, I don't argue that
[11:00] <Keybuk> bzr packaging fails the moment you have an .orig.tar.gz
[11:00] <Keybuk> because you can't put that in bzr in a way that works
[11:00] <pitti> no, that's not true
[11:00] <pitti> you are just not using the tools we have for that
[11:00] <Keybuk> the tools we have are hacks
[11:00] <Keybuk> they get one bit from other there, and the other from other *there*
[11:00] <Keybuk> and end up only slightly worse than apt-get source
[11:00] <pitti> well, apt-get source fetches orig.tar.gz and diff.gz and applies that
[11:00] <Keybuk> which is what I find ridiculous
[11:00] <pitti> debcheckout fetches orig.tar.gz and the branch and applies that
[11:00] <pitti> I don't see the fundamental difference
[11:01] <pitti> well, I do appreciate that it could be cleaner
[11:01] <pitti> but it works as well as apt-get source, IMHO
[11:01] <Keybuk> I disagree
[11:01] <cjwatson> fixing this is one of the reasons James has put lots of effort into bzr-builddeb
[11:01] <Keybuk> you can't do a diff.gz with that
[11:01] <seb128> it's just extra steps, slower and a different workflow you need to learn
[11:02] <Keybuk> and none of this actually gives us anything we didn't have before
[11:02] <Keybuk> in fact, it's worse
[11:02] <Keybuk> because in the brave new bzr world you can't use merge-o-matic anymore
[11:02] <Keybuk> so merges become hard work again
[11:02] <pitti> seb128: if someone uploads jockey or apport without committing to bzr, it's much slower and extra steps for me to clean up after him...
[11:02] <cjwatson> Keybuk: merge-o-matic gets things wrong when bzr merge doesn't
[11:02] <Keybuk> unless you're lucky enough to be Colin and only focus on things which are native and in revision control upstream along with their packaging
[11:02] <pitti> Keybuk: merges are a snap of a finger with bzr
[11:02] <seb128> pitti: right, but you just discourage people to fix things on your packages then
[11:02] <cjwatson> your claim that it's worse is based on the theory that merge-o-matic is at least as good
[11:02] <Keybuk> cjwatson: such as?
[11:02] <pitti> seb128: and doing serious upstreamish development work without revision control is insane
[11:03] <Keybuk> you've not filed any bugs
[11:03] <seb128> pitti: we don't discuss upstream work but packaging there
[11:03] <pitti> Keybuk: I don't use MoM  for merging cups or hal -- I just use "bzr merge", and that just works
[11:03] <cjwatson> Keybuk: it has less context for changes; I don't see it as something MoM can fix
[11:03] <Keybuk> cjwatson: it has the same context
[11:03] <pitti> no, MoM doesn't have history
[11:03] <Keybuk> yes it does
[11:03] <Keybuk> it might not be quite as discreet as the commit logs
[11:04] <Keybuk> depending on whether the author releases often or bunches things up
[11:04] <Keybuk> but otherwise it's basically doing the same thing
[11:04] <pitti> but it can't tell that patch A has been applied as modified patch A' upstream and thus is merged
[11:04] <Keybuk> in fact, MoM tries to be a bit smarter about the merge than bzr
[11:04] <cjwatson> Keybuk: lucky enough? ignoring the native thing which I really don't think is as important as you make out, the reason I'm in this position is that I've put effort into it
[11:05] <Keybuk> cjwatson: and that means you're the only person who can really make changes to those packages now
[11:05] <Keybuk> because you're the only person who understands the way you've done it
[11:05] <Keybuk> which is almost certainly different to the way pitti does it
[11:05] <cjwatson> Keybuk: demonstrable bollocks
[11:05] <Keybuk> and probably different to the way mvo does it
[11:05] <cjwatson> you can tell this from the fact that other people change them
[11:05] <pitti> I had no problem so far committing changes to d-i or update-notifier
[11:05] <Keybuk> and get ranted at on IRC for fucking it up
[11:06] <seb128> right, because you put the required efforts to figure how to update those and you are used to bzr so it's likely something easy for you
[11:06] <cjwatson> the people who utterly ignore stuff that's in place will screw it up, sure; in other cases I haven't had many problems actually
[11:06] <cjwatson> people generally get it right
[11:06] <Keybuk> I didn't get it right
[11:06] <Keybuk> and I don't think I'm incompetent
[11:06] <pitti> seb128: that may be true, yes
[11:06] <cjwatson> you ignored the vcs-bzr, which I think tools could have helped you with
[11:07] <cjwatson> if you hadn't, I'm confident that you would have got it right
[11:07] <Keybuk> to see the vcs-bzr, I had to get it from bzr
[11:07] <mvo> asac: could you please check #272314 ? I think you were a bit quick with making it "invalid" ;)
[11:07] <Keybuk> it's a chicken and egg
[11:07] <cjwatson> huh?
[11:07] <pitti> Keybuk: no,apt-get source warns you
[11:07] <cjwatson> the vcs-bzr field is in the package as uploaded, and as pitti says ...
[11:07] <Keybuk> at no point there, did I run apt-get source
[11:07] <seb128> pitti: I don't even know where to push my changes usually, I apt-get source which gaves me a bzr command, which I use and gives me a readonly checkout and there I'm stucked
[11:07] <cjwatson> Keybuk: and, like I say, I think MoM should have warned somehow
[11:07] <pitti> Keybuk: right, you downloaded from MoM, which brings us back to the original problem of MoM not warning about it :)
[11:07] <Keybuk> and as I've frequently filed bugs - apt-get source has never given me a bzr warning
[11:07] <cjwatson> hence "I think tools could have helped you"
[11:08] <Keybuk> cjwatson: patches welcome
[11:08] <soren> Keybuk: You could put the info in REPORT and have grab-merge warn you.
[11:08] <mvo> (asac: and adding a update-manager taks for that matter)
[11:08] <cjwatson> apt-get source often gives me bzr warnings
[11:08] <cjwatson> so "WFM" is unfortunately the best I can say at the moment ...
[11:08] <cjwatson> anyway, midwife visit
[11:08] <pitti> seb128: debcheckout :)
[11:08] <Keybuk> quest tmp% apt-get source debconf
[11:08] <Keybuk> dpkg-source: extracting debconf in debconf-1.5.23ubuntu2
[11:08] <Keybuk> dpkg-source: info: unpacking debconf_1.5.23ubuntu2.tar.gz
[11:08] <seb128> pitti: what is that?
[11:08] <Keybuk> see, no warning
[11:09] <pitti> seb128: convenience script to fetch orig, branch, and set it up correctly
[11:09] <liw> Keybuk, weird: NOTICE: 'debconf' packaging is maintained in the 'Bzr' version control system at:
[11:09] <seb128> pitti: should apt suggest than rather than bzr get on http locations?
[11:10] <Keybuk> if bzr is the correct way to get a package
[11:10] <Keybuk> then apt-get source should *not* bitch at you
[11:10] <pitti> seb128: yes, very much so; in fact, it should use "lp:~/ubuntu-core-dev/debconf/ubuntu", which works for read-only as well as push
[11:10] <Keybuk> apt-get source debconf should automatically use bzr to fetch it properly
[11:10] <pitti> mvo: ^
[11:10] <asac> mvo: sure
[11:10] <asac> let me look
[11:10] <mvo> Keybuk: I can add that (for bzr+lp branches)
[11:10] <pitti> Keybuk: that, or at least a stronger warning if DEBEMAIL =~ /ubuntu/ is a good idea
[11:11] <pitti> mvo: and advocating http:// is really outdated now, I think
[11:11] <Keybuk> pitti: warning is silly
[11:11] <Keybuk> I really never read apt output
[11:11] <pitti> mvo: but I guess it takes that straight from Vcs-Bzr
[11:11] <Keybuk> it's all random crap about package lists and stuff
[11:11] <Keybuk> which is why it's turned off
[11:11] <pitti> Keybuk: it could just fail
[11:11] <Keybuk> pitti: that's not being helpful either
[11:11] <mvo> pitti: yes
[11:11] <Keybuk> "do this" ... FAIL!
[11:12] <Keybuk> if apt knows what you're supposed to have done instead, it should just do that
[11:12] <mvo> Keybuk is right, it should to it automatically, problem is how to ensure the diff gets sent back to lp when its finished?
[11:12] <asac> mvo: well. ia32libs wasnt updated for them
[11:12] <liw> "apt-get source" can work (local mirror) whereas bzr might fail (no Internet access)
[11:12] <pitti> mvo: what about apt-get source just calling debcheckout if it sees Vcs-Bzr:.*launchpad ?
[11:12] <Keybuk> liw: in which case, according to colin, you shouldn't be allowed to fetch the source package
[11:12] <asac> mvo: should be a lower depends bound ... true
[11:12] <mvo> asac: right, that clearly indicates that there is a versionized dependency missing, no?
[11:13] <pitti> Keybuk: fetching is fine, uploading is disallowed (which is why we are currently doing it that way)
[11:13] <asac> mvo: but still those folks claimed that multiverse got disabled ;)
[11:13] <mvo> asac: I asked for the upgrade log, in general, we keep multiverse, but of course there might be a bug (or corner case)
[11:13] <pitti> but yeah, it's a tricky problem
[11:13] <mvo> asac: yeah, that worries me a bit :/
[11:13] <asac> mvo: maybe update manager could do better to see that there are packages from a now-disabled component?
[11:13] <pitti> maybe we should just try to make apt-get source call debcheckout, and see who complains
[11:14] <asac> mvo: lets assume user disabled it ;) ... that could be the case for sure
[11:14] <mvo> pitti: yes
[11:14] <asac> mvo: or maybe apturl :)
[11:14] <pitti> it coudl still download the package with --force, or so
[11:14]  * Keybuk didn't know about debcheckout, btw
[11:14] <Keybuk> where was that announced?
[11:14] <asac> mvo: but update-manager could also know that there are packages from multiverse and do something imo. otherwise the upgrade would fail too i guess
[11:14] <mvo> asac: well, what should it do in this case? I can not embed special knwledge into it for each package, if the dependencies are fine, u-m will install it
[11:15] <pitti> Keybuk: devscripts 2.10.8, Tue, 11 Sep 2007
[11:15] <asac> mvo: how? if multiverse isnt enabled the upgrade will either fail (because the dep cannot be fulfilled) or removed?
[11:15] <mvo> pitti: I think calling debcheckout if fine, but how do we ensure that the change in bzr are then sent back to LP? or does debcheckout do that?
[11:15] <Keybuk> pitti: I can't see any ubuntu-devel posts introducing it?
[11:15] <pitti> Keybuk: but right, that's why apt-get source should point it out/JFDI
[11:15] <mvo> asac: or kept at the same version. but it does something sensible, even if that is removing the package
[11:15] <Keybuk> which is an interesting point
[11:15] <Keybuk> we're getting an increasing number of DTRT tools
[11:15] <Keybuk> yet you can only learn about them by osmosis, since we don't really document them anyway
[11:16] <asac> mvo: true. i think if package comes from a none-ubuntu archive it should be removed if it would cause problems to keep it at same version
[11:16] <pitti> mvo: you mean teaching people how to use "bzr commit"?
[11:16] <mvo> asac: right, but how should u-m know? it can not have special knowledge for each package, if its not encoded in the dependencies, there is little I can do AFAICS
[11:16] <asac> mvo: but cant we do better if people have things from ubuntu archive ? maybe an index of package names mapped to archive section?
[11:16] <mvo> pitti: yes
[11:17] <asac> mvo: hmm ... isnt the info to identify a package as being from multiverse in the cache?
[11:17] <mvo> pitti: it sounds silly, but you did not have to do it with apt-get source / dput
[11:17] <asac> mvo: like in the Pool file name?
[11:17] <Keybuk> pitti: it's a shame that Vcs-Bzr isn't in the changes file :-/
[11:18] <asac> but yeah. lets keep this as a dependency bug
[11:18] <mvo> asac: it is, but why should it tread multiverse differently than say universe?
[11:18] <mvo> or restricted ?
[11:18] <pitti> mvo: well, I don't think we can pretend to not use bzr
[11:18] <asac> mvo: no it should treat all that way
[11:18] <pitti> mvo: if we'd do that, we wouldn't need it in the first place
[11:18] <asac> mvo: if you hav a package for which the section was disabled and that comes from ubuntu archives, we can consider to enable that pool for upgrade
[11:19] <mvo> pitti: I agree - I think i just need to add a message explaining that bzr commit is required or something like this
[11:19] <Keybuk> actually
[11:19] <pitti> mvo: point to https://wiki.ubuntu.com/BzrMaintainerHowto ?
[11:19] <Keybuk> this is damned hard
[11:19] <Keybuk> we end up with three different Vcs-Bzr fields
[11:19] <pitti> (which should get an update...)
[11:19] <Keybuk> one from BASE, one from LEFT and one from RIGHT
[11:19] <mvo> asac: that information is not recorded (yet) if the user commented out his repos
[11:19] <Keybuk> which one do we believe?
[11:19] <Keybuk> and how do we deal with them being different?
[11:19] <mvo> asac: but yeah, having this information "Installed-From" would be *really* useful
[11:19] <pitti> the one from ubuntu
[11:20] <mvo> asac: for liw and his system-cleaner for example
[11:20] <asac> mvo: which information? i can currently look at apt-cache show and see the poolname in the filename
[11:20] <Keybuk> pitti: two of those may be ubuntu ;)
[11:20] <Keybuk> in fact, three of them may be in some circumstances
[11:20] <pitti> Keybuk: well, RIGHT is Debian, and LEFT is what you are just generating, isn't it?
[11:20] <Keybuk> no
[11:20] <mvo> asac: right, now try to comment out multiverse and do that apt-cache policy thing again
[11:20] <asac> mvo: Filename: pool/multiverse/f/flashplugin-nonfree/flashplugin-nonfree_10.0.12.36ubuntu1_amd64.deb
[11:20] <pitti> Keybuk: ah, no, LEFT is current ubuntu, RIGHT is current Debian
[11:20] <mvo> asac: or try it in a version that is no longer downloadable (because there is a new version in jaunty and the old one got removed from the archive)
[11:20] <pitti> Keybuk: so, "LEFT" is the right Vcs- field
[11:21] <Keybuk> pitti: not so much
[11:21] <asac> mvo: ok ... i believe you ;)
[11:21] <Keybuk> all three can come from the same distro
[11:21] <Keybuk> .e.g initramfs-tools
[11:21] <pitti> Keybuk: but as I said, it's not really necessary for MoM to do the merge; it is actively wrong to upload it
[11:21] <Keybuk> BASE might have been in ubuntu first
[11:21] <mvo> asac: we should talk about this at uds, the "record where it comes from" idea is really good
[11:21] <Keybuk> LEFT and RIGHT might also have been in ubuntu
[11:21]  * mvo needs to run for lunch
[11:21] <Keybuk> well, normally not, but it's possible
[11:22] <Keybuk> the problem is that just about every debian/control we're talking about inherently has a conflict
[11:22] <Hobbsee> when is the ETA for moving everything to bzr?
[11:22] <Hobbsee> (is there one?)
[11:22] <Keybuk> since the apparent change made to everything is to change the Vcs-Bzr to point to launchpad
[11:22] <Keybuk> pitti: the problem is that MoM has to do the merge
[11:23] <Keybuk> since the information is in debian/control
[11:23] <Keybuk> which it only has when doing the merge
[11:23] <pitti> Keybuk: it's also in the .dsc
[11:23] <Keybuk> is it?
[11:23] <pitti> well, it's in Sources.gz, so it has to
[11:23] <pitti> It's VCS-Bzr:
[11:24] <asac> mvo: is that fixable in a SRU (for new upgraders) at all? will update-manager look at -updates for updates or do an intermediate step to "plain" first?
[11:24] <Keybuk> interesting
[11:25] <Keybuk> here's a thought
[11:25] <asac> mvo: or do we need a tweak as hardy SRU now?
[11:25] <Keybuk> grab-merge could branch the bzr repository into a temporary directory
[11:25] <Keybuk> and move the .bzr into the directory the merge result is unpacked into
[11:26] <pitti> and auto-add the new files in debian/ ?
[11:26] <Keybuk> not auto-adding would make people manually check a bit more carefully
[11:26] <Keybuk> lifeless: around?  I feel momentarily evil
[11:26] <pitti> sure
[11:26] <Keybuk> I wonder if I can fake a bzr conflict for the conflicted files :p
[11:26] <pitti> well, I don't use grab-merge, but if many people do, that sounds helpful
[11:27] <asac> fake a conflict? for the not added files?
[11:27] <pitti> for the real conflicts in the files, I figure
[11:27] <Keybuk> asac: for the ones with MoM conflict markers in them
[11:28] <soren> Keybuk: .bzr/checkout/conflicts
[11:28] <asac> oh. so we still want to do our own merge logic and not bzr merge?
[11:28] <pitti> Keybuk: but that would still not record the merged revisions from trunk
[11:28] <pitti> Keybuk: so you'd break bzr merge
[11:28] <Keybuk> sure
[11:28] <pitti> so if debian/trunk is in bzr, doing that would be wrong, too
[11:28] <Keybuk> so which header field is that documented? :p
[11:29] <pitti> Keybuk: Debian's Vcs-*? :-)
[11:29] <Keybuk> or does that require personal knowledge of the package
[11:29] <pitti> we only need to consider Vcs-Bzr, I think
[11:29] <Keybuk> pitti: there doesn't seem to be a standard for those
[11:29] <pitti> I do have bzr imports for vcs-svn, too
[11:29] <Keybuk> I've seen people using both XS-Debian-Vcs-Bzr and XC-Original-Vcs-Bzr
[11:29] <pitti> but since svn doesn't really support branches and merges, it doesn't matter
[11:29] <soren> Keybuk: The latter is certainly wrong.
[11:29] <Keybuk> see
[11:29] <Keybuk> this is the problem
[11:29] <pitti> Keybuk: no, scratch that
[11:29] <pitti> look at the debian .dsc
[11:29] <soren> Keybuk: It needs to be XS- at the very least.
[11:29] <Keybuk> soren: I mean XS
[11:30] <Keybuk> pitti: look at it for?
[11:30] <Keybuk> Vcs-Bzr ?
[11:30] <soren> Keybuk: There was some discussion a long time ago about whether to use Debian or Original.
[11:30] <pitti> Keybuk: yes
[11:30] <Keybuk> what do you do in that case?
[11:30] <pitti> Keybuk: I guess that only really affects d-i
[11:30] <soren> Keybuk: I'm quite sure we agreed Debian was correct.
[11:30] <pitti> Keybuk: don't use MoM
[11:30] <Keybuk> debconf uses Original ;)
[11:30] <Keybuk> pitti: so how do we document which packages to use MoM for and which not to?
[11:30] <Keybuk> you see my point here
[11:30] <Keybuk> we've ended up in the situation where no developer can touch anything for fear of getting it wrong
[11:30] <pitti> Keybuk: If Ubuntu has a Vcs-Bzr:, I would discourage MoM
[11:31] <pitti> otherwise use MoM
[11:31] <pitti> and if Debian has a Vcs-Bzr, too, MoM shouldn't output anything, since uploading it breaks bzr merge
[11:31] <pitti> admittedly having just ubuntu in bzr, and not debian/trunk, is utter crack
[11:31] <Keybuk> why would you discourage MoM in the former case?
[11:32] <pitti> and I doubt that many people use that actually
[11:32] <pitti> since it makes merges so much harder
[11:32] <Keybuk> if you're just committing uploads to bzr, the MoM upload is worth committing
[11:32] <Keybuk> I don't agree
[11:32] <Keybuk> I think bzr is making the merges so much harder
[11:32] <pitti> Keybuk: well, discourage, or use your magic grab-merge approach
[11:32] <soren> Keybuk: https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023379.html
[11:32] <pitti> Keybuk: just keeping ubuntu in bzr and not the debian side is, IMHO
[11:32] <pitti> I did it long enough, and it was a PITA
[11:32] <pitti> now I import debian's svn to bzr and merge from that
[11:32] <pitti> so much easlier
[11:33] <Keybuk> see, everyone's doing it differently ;)
[11:33] <pitti> well, "just ubuntu in bzr" -> pain, discourage, not document
[11:33] <ScottK> pitti: I thought I'd gotten that Spamassassin SRU you just accepted rejected.  It's got two problems.
[11:33] <pitti> "import deiban into svn" -> love, and you don't need MoM
[11:33] <ScottK> pitti: 1.  I forgot to add the patch to 00list, so it doesn't get applied.
[11:34] <sebner> pitti: will the "old" way once gets disabled so we are forced to use bzr?
[11:34] <pitti> ScottK: whoops, that slipped my review (argh too many SRU reviews today); sorry
[11:34] <ScottK> pitti: 2.  I uploaded it to dapper-updates, not dapper-proposed (so it's just as well actually the patch wasn't applied).
[11:34] <ScottK> pitti:
[11:34] <ScottK> pitti: No problems.
[11:34] <ScottK> pitti: There's a fixed one I just uploaded.  I'd appreciate it if you'd accept it.
[11:34] <pitti> ScottK: thanks, will do
[11:34] <pitti> sebner: which old way?
[11:34] <ScottK> pitti: Great.  Thanks.
[11:35] <sebner> pitti: the normal way we work on packages now ^^
[11:35] <Keybuk> pitti: can you think of an unmerged package using bzr?
[11:35] <pitti> Keybuk: hal
[11:35] <pitti> Keybuk: but as I said, I have debian in bzr, too, so all I do is "bzr merge", and it's happy
[11:36] <Keybuk> http://merges.ubuntu.com/h/hal/REPORT
[11:36] <Keybuk> that detected that you have ubuntu in bzr \o/
[11:36] <pitti> sebner: maybe once we have everything in bzr, but notuntil that
[11:36] <Keybuk> but you're missing vcs-bzr for the debian version :p
[11:36] <pitti> Keybuk: that's because debian is in svn
[11:36] <pitti> Vcs-Svn: svn://svn.debian.org/svn/pkg-utopia/packages/unstable/hal
[11:37] <Keybuk> and you use bzr-svn?
[11:37] <pitti> yes
[11:37] <Keybuk> see
[11:37] <sebner> pitti: how long will this take? I suppose you are already actively migrating?
[11:37] <Keybuk> how is another developer merging hal when you're away supposed to know this stuff?
[11:37] <pitti> sebner: we have some prototypes, but don't hold your breath
[11:38] <Keybuk> the sheer amount of magic required to merge hal that's only in your brain is worrying to me
[11:38] <Hobbsee> Keybuk: no one's else is insane enough to merge hal.
[11:38] <pitti> Keybuk: as long as he commits it to bzr, I don't mind
[11:38] <pitti> Keybuk: having debian in bzr is making things easier for *me*
[11:38] <Keybuk> pitti: but you've said yourself, you'd rather they didn't because it'd be wrong
[11:38] <pitti> if someone else wants to do it the hard way, and doesn't ask me, *shrug*
[11:39] <Keybuk> the problem is, by making it easier for you, you're making it harder for everyone else
[11:39] <pitti> Keybuk: no, only if debian/trunk is in bzr, too
[11:39] <pitti> Keybuk: why? that I have debian hal in an svn-imported bzr is totally opaque to anyone else?
[11:39] <pitti> and that I have ubuntu hal in bzr is obvious due to vcs-bzr
[11:39] <Keybuk> unless they're trying to merge
[11:40] <pitti> you can just commit a manual merge
[11:40] <pitti> that's just bad if trunk/debian is a real bzr branch, since then you don't record the merged revisions
[11:40] <Keybuk> or they can just upload it as normal, and you can sort it out later? :)
[11:40] <pitti> but for svn that doesn't matter anyway, because svn doesn't know
[11:41] <pitti> Keybuk: "normal" in the sense of committing the changes to bzr without worrying at all about the debian svn, yes
[11:41] <Keybuk> I mean just dupload
[11:41] <pitti> often people just upload without committing, so I just prod them to send me the diff or commit afterwards
[11:41] <mvo> asac: that is fixable, update-manager will use the latest stuff in the archive
[11:42] <sebner> pitti: kk
[11:43] <cjwatson> I don't actually mind when people upload rather than committing, since I can just ask them to commit; it doesn't normally turn into an hour-long argument about life the universe and everything
[11:44] <cjwatson> (and I have committed stuff on other people's behalf before)
[11:47] <cjwatson> pitti: is your Debian hal branch lp:~ubuntu-core-dev/hal/debian ?
[11:47] <cjwatson> code.launchpad.net/hal is where I would naturally look for this stuff
[11:48] <pitti> cjwatson: yes, I push it there; updating now
[11:48] <pitti> it's just a bzr-svn alioth <-> lp gateway
[11:48] <pitti> this is a setup which I don't actually *like* and which should be much easier
[11:49] <pitti> but well, it's a package that I work on a lot, so doing that initial setup is worth it
[11:49] <cjwatson> I agree, it ought to be lp:debian/hal
[11:49] <cjwatson> and automatically imported
[11:49] <pitti> since you lose merge tracking if you do another svn import
[11:50] <pitti> since svn is just so <censored> <beep>
[11:50] <cjwatson> presumably, though, pulling the branch from LP, running 'bzr pull' with bzr-svn installed, and pushing is fine
[11:50] <cjwatson> that should probably be in the branch whiteboard
[11:50] <Mithrandir> pitti: uhm, svn does merge tracking now, you know that?
[11:51] <pitti> Mithrandir: oh? since when?
[11:51] <Mithrandir> 1.5
[11:51] <pitti> wow, that brings it on par with cvs :)
[11:51] <Mithrandir> so intrepid + hardy-backports.
[11:51] <Keybuk> http://pastebin.ubuntu.com/67874/
[11:51] <Keybuk> that turns out to be quite easy
[11:51] <ogra> Mithrandir, dont mix intrepid with hardy-backports :P
[11:52] <Mithrandir> *shrug*; unless bzr it doesn't change the on-disk format twice a week and then proceeds to whine at me.
[11:52] <pitti> Keybuk: I'd use Vcs.*launchpad
[11:52] <Keybuk> pitti: that doesn't work for your packages
[11:52] <Keybuk> this will err on the false positive side
[11:52] <pitti> Keybuk: otherwise we'd catch all the alioth vcs-svn ones which we don't care about
[11:52] <Keybuk> but I think that's ok
[11:52] <pitti> Keybuk: my packages?
[11:52] <Keybuk> ie. hal
[11:52] <Keybuk> it wouldn't show up the debian bit
[11:52] <Keybuk> why would it have launchpad in it anyway?
[11:53] <Keybuk> shouldn't it be Vcs-bzr: lp:~ubuntu-core-dev/hal/ubuntu ?
[11:53] <pitti> Keybuk: suppose package foo is in alioth svn, but not in bzr in ubuntu anywhere
[11:53] <pitti> then a standard non-VCS merge is the right thing
[11:53] <Keybuk> pitti: then they'll get a warning
[11:53] <Keybuk> and can figure out whether its safe to continue
[11:53] <cjwatson> I haven't been using lp: so far, but maybe I should
[11:53] <pitti> Keybuk: yeah, if it's just a warning, that's in fact fine
[11:53] <Keybuk> right, that goes at the bottom of grab-merge
[11:54] <pitti> cjwatson: I don't use it in the Vcs-: fields, because I like them to be clickable
[11:54] <cjwatson> the thing about using lp: is that you can't c'n'p them into a web browser
[11:54] <pitti> but for bzr checkout/pull/push/get they work nicely
[11:54] <cjwatson> so you have to have a separate vcs-browser field which is more fiddly
[11:54] <pitti> cjwatson: but debcheckout is clever enough to translate them, I think
[11:54] <Keybuk> cjwatson: the thing about not using lp is that it doesn't translate nicely into a writable or readonly url automatically
[11:55] <cjwatson> Keybuk: yeah, I don't pretend to have a perfect answer there
[11:55] <cjwatson> pitti: it is
[11:56] <cjwatson> maybe I should just bite the bullet and use vcs-browser
[11:57] <cjwatson> I just don't want to be changing things round every five minutes since that's confusing too
[11:58] <jernst> bryce: ping?
[11:59] <ogra> jernst, likely to early for him
[11:59] <jernst> I thought so too ;-), thanks
[12:05] <pitti> bryce: do you want to do the inkscape merge? it's currently on my plate, since I tossed the recommends: around right before release, but you feel more attached to it :)
[12:06] <pitti> soren: ^ likewise, do you wnat to do virtinst?
[12:07] <soren> pitti: I'll do virtinst, yes.
[12:08] <pitti> soren: thanks
[12:13] <pitti> argh, guys, pretty please forward patches to Debian
[12:16] <kwwii> mvo: could you look at #293482 and confirm that it is not a compiz problem?
[12:19] <asac> TheMuso: your ppa is named here: https://wiki.ubuntu.com/MozillaTeam/Bugs/FlashAnswers :) ... anything else you would like to be asked on NEW sound bugs?
[12:23] <ahasenack> is there a way for apport to report the time of the crash?
[12:23] <ahasenack> I have a bug report saying that when a program called Me-TV was closed, apport reported a crash in landscape-sysinfo, which is clearly wrong
[12:23] <ahasenack> so I'm guessing apport is reporting an old crash
[12:24] <pitti> ahasenack: yes, it's written into the report by default
[12:24] <pitti> ahasenack: "Date:"
[12:25] <ahasenack> pitti: I must be blind then, I don't see it here: https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/271954
[12:25] <pitti> ahasenack: oh, it's not copied to the LP bug report
[12:26] <pitti> ahasenack: in fact it was doing it before, but I was asked to throw out redundant fields
[12:26] <ahasenack> pitti: only that field?
[12:26] <ahasenack> pitti: can you put it back please? :)
[12:27] <pitti> ahasenack: how would it help you with that bug?
[12:27] <pitti> ahasenack: yes, ignore the "me-tv" comment, it's clearly wrong
[12:27] <pitti> ahasenack: you got one of those nice python segfault crashes
[12:27] <ahasenack> pitti: I would compare the date of the crash with the date of the bug
[12:27] <pitti> I'm regularly lost what to do with those, too
[12:28] <pitti> ahasenack: it should be "5 minutes earlier" or so
[12:28] <pitti> ahasenack: it apparently happened while a session was running
[12:28] <ahasenack> pitti: I was assuming that apport was reporting an old crash that was for some reason not reported when it actually happened
[12:28] <pitti> ahasenack: apport pops up and reports straight after the crash happens
[12:28] <pitti> unless you don't have a running session, in which case it asks you when logging in
[12:28] <pitti> but that's not the case here, according to the description
[12:29] <pitti> ahasenack: given that landscape-sysinfo is cron'ed every 10 minutes, I guess me-tv was just a coincidence
[12:29] <ahasenack> pitti: yes, that's what I'm thinking now
[12:30] <ahasenack> pitti: so, if the crash happened outside of a session and the user logged in only the next day into gnome, then we would get very different dates for the crash and the report, right?
[12:30] <mvo> kwwii: "I get the same result with or without Compiz. As I already said, the
[12:30] <mvo> fresh account experiences the same issue too." (last comment) so I doubt its a compiz issue
[12:31] <pitti> ahasenack: yes
[12:32] <kwwii> mvo: yeah, in the meantime I am not sure if this guy is being honest in the report...thanks for checking
[12:33] <ahasenack> pitti: thanks
[12:33] <mvo> kwwii: oh, ok - I double check here on my system
[12:39] <mvo> Riddell: for bug #291115 there is no "TEST CASE" in the description yet, is it sufficient to just use turkish locales to trigger the bug?
[12:48] <mvo> kwwii: works for me on a fresh system with and without compiz (just tested it on a freshly upgraded test system)
[12:54] <Riddell> mvo: yes
[13:05] <mvo> Riddell: thanks, I added a test case now, it would be cool if you could fill in the extact commands that are required (how to run adept to get the --proposed version of hte upgrader, how to switch default language with kde )
[13:12] <mvo> did we release note that evms was removed from the archive?
[13:12] <soren> It was?
[13:13]  * soren lets out a sigh of relief
[13:13] <mvo> rmadison evms tells me its no longer in intrepid
[13:13] <mvo> it just is a pain for people upgrading with evms root
[13:13] <mvo> and update-manager will happily remove evms because its now obsolete
[13:15] <Keybuk> I thought we kicked that out back in edgy or something
[13:17] <Keybuk> ah, universe in gutsy
[13:17] <Keybuk> gone from intrepid
[13:17] <mvo> bad for people with evms roots
[13:17] <Keybuk> sync'd removal from Debian
[13:17] <Keybuk> so we probably never noticed
[13:18] <kwwii> mvo: cool, thanks...I appreciate your help
[13:18] <mvo> aha, thanks
[13:18] <Keybuk> cjwatson: removals.txt isn't updated anymore?
[13:18] <mvo> Keybuk:  I was wondering about that
[13:18]  * mvo prepares a update-manager SRU for the two evms users
[13:19] <Keybuk> mvo: one assumes if they had it installed, it wouldn't be removed?
[13:19] <Keybuk> or does update-manager remove it?
[13:19] <mvo> Keybuk: update-manager removes everything that is obsolete unless its told otherwise
[13:19] <mvo> (obsolete == vanished from the archive)
[13:19] <Keybuk> how does it tell the difference between that and local packages?
[13:20] <mvo> Keybuk: it checks what is local before it updates the sources.list and then calcs the difference
[13:20] <Keybuk> cunning
[13:20] <Keybuk> mvo: who's the *other* evms user?
[13:21] <mvo> heh :)
[13:21] <Keybuk> actually, I can think of two
[13:21] <Keybuk> Tollef and wasabi
[13:23] <cjwatson> Keybuk: https://launchpad.net/ubuntu/+source/evms/2.5.5-26ubuntu2 logs the removal; bug 159585 is for the fact that removal data is spread over two places
[13:24]  * cjwatson nags that bug
[13:27] <tseliot> Riddell: do you know if there's something similar to the gnome-settings-daemon in KDE? For example something which loads the screen settings (resolution,etc.) on login?
[13:36] <pitti> mvo: btw, no need to do a no-change upload of intrepid-proposed to jaunty; we can just copy-package it (which I usually do for SRUs if jaunty and intrepid versions are the same)
[13:36] <pitti> mvo: also, you didn't build with -v, thus the bugs don't get autoclosed
[13:49] <ogasawara> pitti: yah, sorry for the extra noise with those 2.6.27.2 bugs that I had opened and closed.  It was an oversight on my part.
[13:50] <pitti> ogasawara: no problem about the noise; I'm more worried about misunderstandings about the future SRU workflow
[13:50] <ogasawara> pitti:  I believe tim was under the impression people wanted an SRU bug report/patch
[13:50] <pitti> ogasawara: hm, who? I'm fine with just one bug report, with a changelog
[13:50] <pitti> I want the kernel team to read the changelog and check for something fishy
[13:51] <pitti> not to create busywork for themselves and me to create tons of bug reports :)
[13:51] <ogasawara> pitti: agreed, that's why I had scripted opening the bugs for them.
[13:51] <ogasawara> pitti: let me talk with them, just a sec
[13:54] <rtg> pitti: while clumping all of the stable updates into one report makes SRU processing easier, it will make regressions a little more difficult to track.
[13:55] <pitti> rtg: okay
[13:55] <rtg> 'cause there is a pile of them. About 40 committed, another 57 in the pipeline,
[13:55] <pitti> rtg: well, if you actually want to have one SRU bug per commit yourself, I'm fine; I was just under the impression that you didn't
[13:56] <pitti> I think I can easily counterattack ogasawara's script with a script to close SRU bugs when moving things to -updates :)
[13:56] <ogasawara> heh
[13:56] <rtg> pitti: I was just trying to find a way to change policy so we could add stable updates. The mechanics don't matter to me.
[13:57] <pitti> rtg: it seems easier to me to create bug reports about particular regressions when they are found, not in advance, but that might be just me
[13:57] <rtg> pitti: however, that being said, whoever is doing the work really needs to look at each patch.
[13:57] <rtg> pitti: that works for me as well.
[13:57] <pitti> rtg: for a casual tester/reporter, it's not really feasible to find the commit that was responsible for the regresssion anyway
[13:58] <rtg> so, clump the stable updates into one SRU request, then create regression reports as they appear?
[13:58] <mvo> Riddell: is #241314 sru worthy?
[13:58] <pitti> that, or just use that one bug; I think it's a matter of common sense
[13:58] <pitti> rtg: also, if we notice that we get like 5 regressions per stable pull, that's not a sign to change the bug reporting policy, but a sign that we shouldn't do it in the first place :)
[13:59] <pitti> one regression is worse than 10 known bugs usually...
[13:59] <rtg> pitti: I guess experience will tell us if we're doing the right thing.
[13:59] <pitti> (unless they are of the data loss/security kind, of course)
[13:59] <Riddell> mvo: I wouldn't say so
[13:59] <pitti> rtg: exactly
[14:01] <mvo> Riddell: ok, good
[14:03] <tseliot> Riddell: is there no equivalent?
[14:04] <Riddell> tseliot: oh sorry, no there's nothing which sets resolution as far as I know
[14:04] <ogasawara> rtg: I'll open a master bug for 2.6.27.3 and 2.6.27.4 then and clean up those other bugs that got opened.
[14:04] <tseliot> Riddell: ok, thanks
[14:05] <rtg> ogasawara: cool. I think that will constitute enough change that an upload is required.
[14:07] <rtg> pitti: in checking on https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27 I see that it needs building, but I can't find it in any of the Intrepid queues.
[14:07] <rtg> why are the buildd's so backed up anyway?
[14:07] <pitti> rtg: the source is already accepted, so it's not in a particular queue (well, it's in "DONE")
[14:07] <pitti> rtg: we have the initial jaunty sync wave, plus new langpacks
[14:08] <rtg> ah, the DONE queue. 111K entries.
[14:09] <rtg> hrmph. make that Jaunty stuff wait until _my_ builds are done.
[14:26] <ScottK> pitti: If you're still up for doing archiv'ish things, please have a look at intrepid backports for lintian, devscripts, and debootstrap.
[14:27] <pitti> ScottK: seb128's archive day today :)
[14:27] <ScottK> pitti: OK.  Thanks.
[14:27] <ScottK> seb128: ^^^
[14:27] <seb128> oh right, I forgot about that
[14:28] <seb128> will have a look
[14:28] <ScottK> seb128: Thanks.
[14:28] <seb128> pitti: I got used to not touch the archive during the intrepid freeze ;-)
[14:32] <tseliot> Riddell: is it a bug the fact that Konsole doesn't remember its previous size when you launch it?
[14:33] <Riddell> tseliot: yes, fixed in trunk
[14:33] <tseliot> Riddell: ok, thanks god it's not a feature ;)
[14:45] <danimo> hi
[14:45] <danimo> asac: ping?
[14:50] <mvo> pitti: re bug #272199 - the reason this is not in intrepid already is that it breaks the string freeze (that was the reason why its not in gnome too). I can still do a upload if the regression is more imporant than the string freeze (I don't mind either way)
[14:51] <pitti> mvo: not sure, but we did have that string until shortly before RC
[14:51] <nxvl> cjwatson: i'm not getting jaunty-changes's confirmation e-mail, is that list moderated?
[14:51] <asac> danimo: ?
[14:51] <cjwatson> nxvl: err, are you trying to mail it directly?
[14:52] <mvo> pitti: well, we had it for about a week (added 2008-10-21 and removed 2008-10-31
[14:53] <maxb> But the strings were in hardy, weren't they?
[14:53] <tedg> Keybuk: So, if MoM will do a merge automatically will it propose that as a merge in the packaging VCS?  How does that work?
[14:53] <mvo> pitti: I have no strong opinion either way, I'm fine with doinga sru for it
[14:53] <mvo> pitti: it would be nice if we could resurrect the strings from hardy somehow
[14:53] <mvo> (the translations I mean)
[14:54] <pitti> mvo: there's a script which copies them over
[14:54] <cjwatson> nxvl: mails to jaunty-changes are moderated, but subscription is open
[14:54] <cjwatson> nxvl: the moderation queue is also empty
[14:55] <Laney> mvo: Please do it!
[14:55] <mvo> pitti: oh? is that script in the bug somewhere (and I overlooked it?) - if so, I'm happy to do it right away
[14:55] <Laney> :)
[14:55] <nxvl> cjwatson: i mean the subscription
[14:55] <cjwatson> nxvl: nothing to do with us ...
[14:55] <nxvl> cjwatson: mmm, i will check what's happening, thank you
[14:55] <pitti> mvo: it's a Launchpad thingie; I don't know it either, I just know about its existance
[14:56] <mvo> pitti: so it happens automatically?
[14:56] <pitti> mvo: someone has to call it
[15:01] <danimo> hi asac
[15:01] <danimo> asac: Riddell said you could help me with tracing down an issue with network manager
[15:02] <danimo> asac: my provider assigns me an ipv6 address, and I guess nm thinks it thus doesn't need to assign me an ipv4 address via dhcp
[15:02] <danimo> asac: but I need to prove it somehow
[15:02] <ogra> ARGH
[15:03] <ogra> tkamppeter, my cups went on strike after printing once
[15:03] <ogra> i get a "No %%Pages: comment in header" message
[15:03] <ogra> it worked a second ago and now i cant even print a testpage
[15:05] <ogra> not even a reboot and resetting the printer helped
[15:07] <asac> danimo: is that pppoe?
[15:07] <Spads> ogra: a friend of mine got that problem shortly after upgrading to intrepid.
[15:08] <ogra> well, i rinted several times on intrepid already
[15:08] <ogra> and it woked a minute before this job
[15:09]  * ogra goes mad ... why does such a thing only happen if i'm in massive time pressure 
[15:10] <danimo> asac: no, plain ethernet
[15:10] <danimo> asac: (student dorm)
[15:16]  * ogra cries
[15:18] <asac> danimo: then how does your provider assign you ipv6?
[15:18] <danimo> asac: the student dorm is my isp
[15:18] <danimo> asac: ipv4 and ipv6 via one ethernet line
[15:19] <asac> danimo: open a bug, reproduce and attach the complete syslog so i get an initial idea ;)
[15:20] <asac> dont use IPv6 here :/
[15:20] <danimo> asac: I wanted to ask where to look
[15:20] <danimo> asac: the ipv6 address is assigned as the interface is brought up
[15:20] <danimo> asac: ipv6 doesn't require dhcp
[15:24] <superm1> asac, is there any particular reason that libmbca depends on bluez-gnome?
[15:24] <asac> superm1: yes. i think the wizard itself support bluetooth somehow
[15:24] <asac> we cannot use that in NM though for now
[15:25] <superm1> it's pulling in the entire bluetooth stack whenever you install network-manager gnome
[15:25] <asac> hmm
[15:25] <superm1> because network-manager gnome is recommending libmbca0
[15:25] <asac> superm1: could you file a bug about that? is that a big problem? i men in the end we want to support bluetooth by default i think
[15:25] <asac> s/men/mean/
[15:26] <superm1> asac, well it's not a problem for main distro, but for derivatives it is adding a lot of dependencies
[15:26] <superm1> asac, i'll file a bug though
[15:27] <asac> superm1: ok. but assume next release NM supports bluetooth ... fixing this bug wouldnt change much for derivates then i think
[15:27] <asac> (not really sure how NM will do that in the end ... so there might be less depends involved)
[15:28] <superm1> asac, right.  well i guess that also depends on the timeframe of that release
[15:28] <superm1> i guess the better question to pose is why it's asking bluez-gnome rather than libbluetooth3 or similar
[15:29] <asac> superm1: point that out in the bug. libmbca upstrewam has to give a comment then
[15:30] <asac> danimo: ok. first stare at the log and see if it tells you something special about ipv6
[15:32] <asac> danimo: then go and look in code how the nm-setting-ip6-config.h things are used
[15:32] <asac> and if they prevent stage4 from getting the ip
[15:35] <ogra> URGH !
[15:35] <ogra> so as soon as a print job gets sent to /dev/usblp0 the device vanishes
[15:36] <ogra> what a mess
[15:36] <danimo> asac: will  try, bbl
[15:36] <ogra> pitti, ^^^^ any idea ?
[15:37] <pitti> ogra: urgh? no, that's news to me; anything enlightening in dmesg?
[15:37] <ogra> [  847.544312] usb 7-3: USB disconnect, address 8
[15:37] <ogra> [  850.168082] usb 7-3: new high speed USB device using ehci_hcd and address 9
[15:37] <ogra> [  850.321234] usb 7-3: configuration #1 chosen from 1 choice
[15:37] <ogra> [  850.324979] usblp0: USB Bidirectional printer dev 9 if 0 alt 0 proto 2 vid 0x03F0 pid 0x4117
[15:37] <ogra> [  852.301256] usblp0: removed
[15:37] <ogra> thats all
[15:37] <ogra> between 850.324979 and 852.301256 i clicked on "print"
[15:38] <ogra> i can cncel the job, replug the printer and have the device back
[15:38] <ogra> printing again gets me the same result
[15:38] <ogra> the printer ui just shows "No %%Pages: comment in header"
[15:39] <pitti> ogra: sounds like a kernel bug or hw problem
[15:39] <pitti> ogra: device disconnect when you talk to it...
[15:40] <pitti> you talked too loudly, it fell over
[15:40] <ogra> well, the device works/worked in hardy
[15:40] <ogra> i'm cursing here
[15:40] <seb128> and it worked in intrepid you said
[15:40] <seb128> and just before breaking usually things work
[15:40] <ogra> i should be on the autobahn since 30min, but cant print my badge for the conf i'm heading to
[15:41] <ogra> seb128, it worked during the dev cycle
[15:41] <ogra> i probably scared it by loud cursing :)
[15:41] <ogra> and it constantly worked in hardy
[15:41] <ogra> just intrepid final seems not to
[15:41] <seb128> boot an hardy cd and print your badge?
[15:42] <ogra> hrm
[15:42] <seb128> it'll be faster to boot a CD than to debug
[15:43] <pitti> Riddell: good news
[15:43] <wasabi> Keybuk: mvo: I no longer use evms
[15:43] <wasabi> So, 1 left.
[15:43] <wasabi> But, I no longer use it because it's in such a crappily maintained state, not because I think it sucks. I still think it's awesome. ;0
[15:44] <Riddell> pitti: mmm?
[15:44] <pitti> Riddell: I found the msgctxt problem, and band-aided it
[15:44] <Riddell> pitti: ooh?
[15:44] <pitti> Riddell: next langpack build shoudl be good
[15:44] <Riddell> pitti: is it not a launchpad issue?
[15:45] <pitti> Riddell: unfortunately intrepid's gettext-po.h/glibc implementation is too stupid to know about msgctxt
[15:45] <pitti> so I disabled using that
[15:45] <pitti> that will make the packs considerably bigger (the English ones), but at least correct
[15:45] <pitti> and for -updates we don't care so much
[15:46] <Riddell> pitti: why much bigger?  the strings were always in the .po files
[15:46] <pitti> Riddell: it filters out msgid == msgstr ones
[15:47] <Riddell> ah
[15:47] <pitti> Riddell: for those people who have fun earning easy karma by translating C into en_US and en_GB
[15:50]  * liw ponders using Finnish for msgids
[15:53] <sebner> wb nxvl
[16:20] <Keybuk> cjwatson: yeah I saw that the removal records are now in soyuz, that's where I got the "removed from debian" bit from
[16:21] <ogra> no way ...  and suddenly th same hapens with hardy as well, on all three printers in my house
[16:21] <jdong> is there a way with apt_preferences(5) to pin a glob of packages?
[16:21]  * ogra doesnt get whats happening here 
[16:23] <ogra> pitti,
[16:23] <ogra> E [05/Nov/2008:17:13:56 +0100] [Job 36] No %%Pages: comment in header!
[16:23] <ogra> E [05/Nov/2008:17:14:15 +0100] Pause-Printer: Unauthorized
[16:23] <ogra> E [05/Nov/2008:17:14:19 +0100] PID 9919 (/usr/lib/cups/filter/pstopdf) stopped with status 1!
[16:23] <ogra> E [05/Nov/2008:17:18:55 +0100] Resume-Printer: Unauthorized
[16:23] <ogra> i see a lot of that in my cups log
[16:23] <pitti> tkamppeter: ^ any idea?
[16:24]  * ogra wonders where the pause and resume comes from
[16:32] <ogra> sigh
[16:33]  * ogra doesnt get it 
[16:35] <rtg> kees: is CVE-2008-3831 important enough to warrant another -security upload?
[16:36] <mvo> if there is anyone faimilar with evms, I would appreciate if you could help me with writing the sru test case for bug #292179 - I need a recipt how to add a evms parition to the system (for someone with no clue about evms like me)
[16:39] <Keybuk> evms --cause-pain --hurt --ow --ow --make-it-stop --please --illl-do-anything /dev/sda1
[16:41] <pitti> Keybuk: didn't you forget --fsck-drives?
[16:44] <ion_> The idea of evms sounds nice. I hope someone makes an equivalent UI for lvm, md etc.
[16:44] <ogra> pitti, hmm, now i can print but get empty pages
[16:45] <Keybuk> btrfs!
[16:45] <Keybuk> btrfs!
[16:45] <Keybuk> btrfs!
[16:45] <ogra> pitti, and the intresting part is:
[16:45] <ogra> ogra@osiris:~$ ls /dev/usblp0
[16:45] <ogra> ls: Zugriff auf /dev/usblp0 nicht möglich: No such file or directory
[16:45] <ogra> though it prints  ...
[16:46] <Keybuk> my mouse just stopped working
[16:46] <Keybuk> wtf
[16:47] <ion_> btwfs, huh. /me takes a look
[16:47] <ion_> r
[16:48] <jdstrand> rtg (and kees): unless there is more to it than the CVE description, I'd say it can wait til the next round
[16:49] <rtg> jdstrand: works for me. I'm about to upload 40 plus SRU/stable patches
[16:50] <jdstrand> rtg: is it included in there?
[16:50] <rtg> yep
[16:50] <jdstrand> yeah-- that sounds right to me
[16:50] <jdstrand> -updates, and wait on -security
[16:50] <rtg> but this kernel will likely stay in -proposed for quite awhile
[16:51] <Keybuk> silly things to type #143: rmmod usbhid
[16:51] <jdstrand> well, there are a lot of ways for a local DoS besides that ioctl, so IMO, it's low priority (so we'll wait until we have several of them or something bigger)
[16:51] <rtg> jdstrand: np
[16:53] <Keybuk> HMM
[16:53] <Keybuk> things you cannot do without a mouse
[16:53] <Keybuk> LOG OUT!
[16:53] <mvo> ctrl-alt-backspace
[16:53] <mvo> see, it works!
[16:54] <rtg> Keypucnhing the power button doesn't bring up the dialog?
[16:55] <cjwatson> alt-f1 right right up up enter (alt-tab if necessary) alt-l
[16:55] <cjwatson> see, obvious
[16:58] <Keybuk> it's sad that I still blame Linux for problems like that
[16:58] <Keybuk> (the battery had run out)
[16:59] <ion_> :-)
[17:01]  * ogra goes to install a windows pc 
[17:03] <jernst> bryce: ping
[17:06] <kees> rtg, jdstrand: I thought CVE-2008-3831 was fixed already?  (or was intrepid still vulnerable?)
[17:07] <rtg> kees: well, its in the stable series. Did I already get it? checking changelog....
[17:08] <rtg> its not in the Intrepid changelog
[17:11] <bryce> jernst: rather than pinging people, it's better to just ask the question...
[17:11] <kees> rtg: ah, dang, we'll get it in the next round then.
[17:11] <rtg> kees: well, as I pointed out to jdstrand, this kernel is going to cook in -proposed for several week, perhaps longer.
[17:12] <kees> should be fine.
[17:12] <jernst> bryce: sorry, was not sure that you were back. regarding https://bugs.launchpad.net/bugs/286924 could you please review your patch rejection reason in the light of my last comment ?
[17:14] <kees> slangasek: why is "die" more correct than "done" for the PAM regression?
[17:17] <bryce> jernst: sure
[17:18] <tkamppeter> ogra, pitti, the failure of /usr/lib/cups/filter/pstopdf is bug 289759
[17:18] <slangasek> kees: I'm not sure that it is?
[17:19] <tkamppeter> ogra, pitti, the unauthorized resume should not influence the job.
[17:19] <slangasek> kees: it's more correct than 'ok', because using 'ok' will fall through to the next module, which is probably pam_deny
[17:20] <kees> slangasek: right, "ok" clearly fails.  regardless, I'd like to get it SRU'd asap, since it's clearly a regression.
[17:20] <bryce> jernst: the patch isn't rejected, only the intrepid task
[17:21] <tkamppeter> ogra, pitti, bug 289759
[17:21] <jernst> bryce: sure no problem however the reason (breaks translation) doesn't stand as no translations exists
[17:21] <slangasek> kees: yes, by all means.  I would suggest using '=done' then, and SRUing ASAP
[17:21] <bryce> jernst: fair enough
[17:22] <kees> slangasek: will there be any conffile silliness?  (I assume you have just buck-passed the SRU to me)
[17:23] <slangasek> kees: nope, none at all; you should be able to just edit the unix profile and it should work
[17:23] <slangasek> yes, I'm passing it to you so that I can do the SRU approval :)
[17:23] <ogra> tkamppeter, what i dont get that i printed yesterday and the whle morning stuff and it worked, it just suddenly stopped working
[17:24] <kees> slangasek: hah, perfect, I'll jump all over it.
[17:27] <kees> murdok: hola!  :)
[17:27] <murdok> hola :Ð
[17:27] <murdok> it's about bug https://bugs.launchpad.net/ubuntu/+source/procps/+bug/216398
[17:28] <kees> yup, hopefully my comments have described the situation a bit.  have you looked at what wine did to solve this in intrepid?
[17:28] <murdok> You said that is better to include in the package a /etc/sysctl.d/dosemu.conf file to fix it
[17:28] <murdok> yes i have
[17:28] <murdok> is it as simple as including this file or do i miss something? i would like to do it
[17:28] <kees> murdok: well, according to the README in /etc/sysctl.d/, I'd recommend something very late in the process, so naming it 90-dosemu-low-memory.conf or so
[17:29] <murdok> okay
[17:29] <kees> murdok: it should be trivial to add to the dosemu package.  (this is why there was a push for /etc/sysctl.d/, so we could support per-package configurations)
[17:29] <murdok> wine's config is named  wine.sysctl.conf
[17:29] <murdok> maybe it should be also change to 90-*
[17:30] <kees> murdok: yeah, it's an over-sight, since they created the file prior to there being a standard for sysctl.d.  but as it happens, they resolve last anyway, so it works.
[17:30] <kees> murdok: the maintainer-script juggling to rename that file is non-trivial, but if one of the wine maintainters is up for it, I'd like that too.  :)
[17:31] <ogra> tkamppeter, do you have anything about "No %%Pages: comment in header" ?
[17:31] <ogra> tkamppeter, seems thats the issue it started with
[17:32] <murdok> isn't it as easy as cp wine.sysctl.conf 90-wine.sysctl.conf and if it doesn't exists create it?
[17:32] <murdok> oops mv*
[17:32] <ogra> and apparently the printer doesnt work at all anymore on any of the laptops i try it on
[17:32] <murdok> well but it works at the end
[17:32] <murdok> i'll try it with doesmu, should i assign the bug to me?
[17:33] <kees> murdok: no, since it's possible the user has changed the conf file, so an md5 check is needed.
[17:33] <kees> murdok: sure, yeah
[17:33] <murdok> okay, let's see if I have it ready tonight
[17:33] <murdok> now I must go
[17:33] <murdok> thanks :D
[17:34] <kees> Keybuk: is there more currect documentation on conffile removal/renaming than http://wiki.debian.org/DpkgConffileHandling ?
[17:47] <murdok> kees: oops i forgot, should i do the patch for jaunty and intrepid?
[17:47] <murdok> both still have the same versions
[17:49] <kees> murdok: if you want to pursue an SRU, do intrepid, but probably best to start with jaunty so you can test it
[17:50] <murdok> okkie
[17:51] <ogra> ok, at least windows worked :(
[17:51]  * ogra cuses that he has to install windows to get a printout, especially since i wont get any sleep through that 
[17:54] <Keybuk> kees: no idea
[17:55] <kees> Keybuk: okay.  I saw a whole bunch of extra magic added to the procps maintainer scripts when removing the tcp timestamp stuff.
[17:55] <Keybuk> colin did that ;)
[17:56] <Keybuk> I think he took my functions and replaced sed with dpkg-query
[17:56] <Keybuk> so his are probably the most current ;)
[17:56] <kees> I will use procps as the gold standard now.  :)
[18:12] <Keybuk> pitti: pidgin
[18:12] <pitti> Keybuk: mutt
[18:13] <Keybuk> err, disregard
[18:13] <Keybuk> I'm sure pidgin had an NM plugin
[18:23] <pitti> Keybuk: oh? then we should activate it
[18:23] <pitti> or switch to empathy now, maybe
[18:25] <Keybuk> that's the thing
[18:25] <Keybuk> I thought it was on
[18:26] <Keybuk> but I'm clearly hallcuinating
[18:53] <kees> slangasek: do you have docs on how the pam-configs stuff is processed?  I haven't found anything in the PAM debian/ tree yet.  I'm trying to figure out how -Initial differs from the entires without -Initial
[18:56] <kees> slangasek: and under which situations do I need to update the md5sums in local/pam-auth-update ?
[18:57] <kees> (oh, nm, that's just for templates?)
[19:09] <kees> slangasek: okay, 291091 updated and ready for SRU evaluation.
[19:19] <slangasek> kees: documentation is only in the wiki currently, at https://wiki.ubuntu.com/PAMConfigFrameworkSpec; and yes, the md5sums are just for the templates
[19:20] <kees> slangasek: ah! a pointer to that page would be Nice(tm) in the debian/ tree somewhere.  in the meantime, I will read that just to double-check my changes are sane.
[19:21] <slangasek> kees: you've installed this, just to confirm that it does update your configs files correctly? :)
[19:22] <NCommander> hey kees
[19:23] <kees> slangasek: yea, it works for me
[19:23] <kees> NCommander: heya :)
[19:23] <slangasek> kees: ok, please upload
[19:25] <kees> slangasek: okay, done.
[19:26] <slangasek> thanks
[19:35] <superm1> slangasek, can you disable the cron job that would be creating jaunty mythbuntu alternates whenever dailies would be starting?  We've decided not to do alternates any more due to their enormously low take rate and the testing burden of testing both.  I'm working on porting over all the bits and pieces of our hacks in our live cd build script to other packages so that live cds can be built with livecd rootfs.  it'd be more ideal at that poin
[19:35] <superm1> t to have daily live disks generated in the alternate's place
[19:57] <lifeless> Keybuk: has it passed?
[20:06] <vadi2> I was told that my webcam driver is buggy, but how can I find out who to report the bug to in launchpad?
[20:10] <johanbr> vadi2: file a bug against the kernel (package "linux")
[20:10] <vadi2> johanbr: alrighty, thank you
[20:12] <psusi> can anyone remind me how you turn on KERN_DEBUG printks?
[20:13] <vadi2> johanbr: sorry, but I don't see an option to add an affected package: https://bugs.launchpad.net/ubuntu/+source/cheese/+bug/294142
[20:18] <johanbr> vadi2: Should be another way to do it, but try https://bugs.launchpad.net/ubuntu/+source/linux/+bug/294142
[20:19] <vadi2> johanbr: thank you
[20:21] <slangasek> superm1: ok, changed in bzr
[20:22] <kees> slangasek: uhm, is soyuz supposed to auto-submit things from intrepid-proposed into jaunty?  or did you trigger that?
[20:23] <slangasek> I did that
[20:23] <kees> (i.e. https://edge.launchpad.net/ubuntu/+source/pam  -- I was not expecting it to build in jaunty)
[20:23] <kees> okay, whew
[20:23] <slangasek> er, hrm
[20:23] <slangasek> did it get built twice?  that would be a sign that I screwed up.
[20:23] <kees> slangasek: in that case, do you want me to push those changes into bzr?
[20:24] <slangasek> it should all go to bzr anyway, yes
[20:24] <slangasek> but if it built in jaunty, then... oops.
[20:24] <kees> I yelled at me about a build failure, that's how I noticed
[20:25] <ogra> use earplugs :)
[20:27] <lifeless> Keybuk: (that was a pong)
[20:29] <kees> slangasek: do you want it in bzr as 1.0.1-4ubuntu5.1 or as UNRELEASED with 1.0.1-4ubuntu6 ?
[20:29] <slangasek> kees: I'm already taking care of it in bzr
[20:29] <slangasek> (5.1, now 5.2 since I have to do a rebuild
[20:29] <slangasek> )
[20:30] <kees> d'oh, okay, nm
[20:31] <RainCT> anyone knows if it's possible to limit the bandwith pbuilder uses?
[20:49] <tkamppeter> ogra, pitti, I have dound a possible solution for the pstopdf problem in bug 289759. Please try. It should also fix several other bugs, should get SRU.
[20:50] <ogra> tkamppeter, i will do so if i caom back on sat. for now i had to print on windows to get the papers i need tomorrow morning
[21:20] <jdstrand> slangasek: hi! so pitti sent apparmor to intrepid-proposed like 13 hours ago, however all archs show 'needs building'
[21:21] <jdstrand> https://launchpad.net/ubuntu/+source/apparmor/2.3+1289-0ubuntu4.1
[21:21] <jdstrand> slangasek: is this cause for concern or just archive lag?
[21:24] <infinity> jdstrand: jaunty-release is scored higher than intrepid-proposed.
[21:24] <infinity> jdstrand: So, you get to wait until the autosync queue is done.
[21:24] <infinity> jdstrand: Or, if it's urgent and we need it built and tested ASAP, let me know, and I'll score it up.
[21:24] <jdong> infinity: is that a bug or a feature?
[21:25] <infinity> jdong: Feature.
[21:25] <jdstrand> infinity: no, not that urgent-- I made a comment in the bug. we should be good. thanks!
[21:25] <infinity> jdong: With rare exceptions, -proposed is never meant to be "urgent", while bugfixes in the devel release may well be.
[21:26] <jdong> infinity: gotcha
[22:05] <seb128> kees: there?
[22:08] <kees> seb128: yea, but on a conf call
[22:09] <seb128> kees: ok, did you upload a system-tools-backends new version? there is some new bugs about postinst errors
[22:10] <seb128> whoever did the upload might want to have a look to those
[22:11] <james_w> seb128: intrepid or jaunty?
[22:11] <kees> seb128: back.  bug #?
[22:11] <seb128> james_w: intrepid
[22:12] <james_w> odd
[22:12] <seb128> kees: bug #294291
[22:13] <kees> seb128: looks like a problem due to being in the middle of an upgrade?
[22:14] <seb128> ok, I didn't look into details I was just reading my mails before going to bed and there was 2 upgrade errors for the new version so I figured I would let you now to maybe keep an eye on coming bugs there
[22:14] <seb128> bug #294389
[22:15] <kees> geh, I will try to reproduce, but I didn't have any problems with it yesterday
[22:15] <seb128> that's the other one
[22:17] <kees> james_w: any idea how to reproduce this?
[22:17] <seb128> the issue doesn't seem due to the changes
[22:18] <james_w> kees: no clue
[22:18] <seb128> and there was already a similar bug opened before intrepid
[22:18] <james_w> kees: the second one may be that it is already started
[22:18] <seb128> so that's likely not due to the update and just a coincidence
[22:18] <james_w> kees: in the second log it apparently starts fine once, and then it tries to start it again later and fails
[22:19] <seb128> kees: sorry for the noise
[22:19] <kees> seb128: well, it's clearly related to people getting the security update, but I'm not sure in what way they're set up that it's breaking
[22:20] <seb128> kees: right but it doesn't seem specific to security changes, the postinst has just corner cases where it can break apparently
[22:20]  * kees nods
[22:21] <seb128> mvo is right, all those postinst are not robust enough
[22:21] <NCommander> kees, so I have a PIE-built chroot (I need to hand it to Gentoo; when you want to do something completely insane, it works well)
[22:21] <kees> NCommander: kewl
[22:21] <NCommander> kees, do we want to add anything like PaX, or are we just going to stay w/ AppArmour
[22:22] <seb128> anyway enough work for today
[22:22] <seb128> 'night everybody
[22:22] <NCommander> night seb128
[22:23] <kees> NCommander: most of PaX is already in mainline.  beyond that, AppArmor works well enough for a MAC system.
[22:23] <NCommander> kees, MAC?
[22:24] <NCommander> Macs didn't have AppArmour until jaunty
[22:24] <kees> NCommander: heh.  Mandatory Access Control.  (AppArmor, SELinux, SMACK, etc)
[22:25] <NCommander> ah
[22:25] <NCommander> Cool
[22:25] <NCommander> Gentoo has already done quite a bit of the hardwork needed to make this fly, and based with my previous attempt, I think I can successfully get an amd64 PIE built chroot off the ground
[22:55] <jordi> TheMuso: I uploaded alsa-lib & alsa-driver to unstable, with some changes re: what was in svn
[22:55] <TheMuso> jordi: Right I got those already./
[22:55] <jordi> TheMuso: next will be -utils,tools and plugins
[22:56] <TheMuso> jordi: Right.
[22:56] <jordi> TheMuso: -plugins includes a biarch patch that you could somehow ask for testing :)
[22:56] <TheMuso> jordi: Awesome!
[22:56] <jordi> TheMuso: ie, it will generate lib64asound2-plugins and so on
[22:56]  * TheMuso nods.
[22:56] <RAOF> jordi: Oh?  That biarch patch I put up there some time ago has finally hit a package? :)
[22:56] <jordi> TheMuso: still not committed, I'm trying to finish improving the package descriptions
[22:56] <RAOF> Yay!
[22:57] <jordi> RAOF: so it's you
[22:57] <RAOF> Yup.  That was me.
[22:57] <jordi> RAOF: it's taken a while
[22:57] <jordi> but it's the beginning of both Ubuntu and Debian cycles
[22:58] <jordi> so I decided to apply it, look somewhere else and let TheM^WUbuntu fix it if something goes wrong ;)
[22:58] <RAOF> Yeah.  I was too late for pushing that for Intrepid, or for lenny for that matter.
[22:58] <jordi> TheMuso: it's also a perfect time to bring our diffs close to 0. Go ahead and discuss whatever you want (specially alsa-lib I guess) in the list
[22:59] <jordi> or commit whatever is clear we want in both distros
[22:59] <jordi> RAOF: yep
[22:59] <jordi> and the patch is scary :)
[22:59] <jordi>   [ Christopher James Halse Rogers ]
[22:59] <jordi>   * debian/control, debian/rules: import the multi-arch magic from
[22:59] <jordi>     alsa-lib to build a lib32asound2-plugins package wherever
[22:59] <jordi>     lib32asound2 is built, and similarly for lib64asound2 (closes: #436201).
[23:00] <jordi> this is the uncommitted changelog
[23:00] <jordi> many thanks, RAOF!
[23:00] <vadi2> intrepid-security isn't enabled by default for a clean install, but intrepid-updates is. Is there any rationale behind this or is it a bug? https://bugs.launchpad.net/bugs/289197
[23:05] <TheMuso> jordi: Ok.
[23:06] <rulus> Hello, can someone enlighten me on bug 293127? (I'm the reporter) Are there plans to update these images, or am I doing something wrong? :)
[23:13] <bdmurray> TheMuso: Are you familiar with ubuntustudio-menu at all? bug 276503 was brought to my attention
[23:14] <TheMuso> bdmurray: I have touched the package on several occasions, and the studio team is well aware of that bug. Since nobody else has seemed to do anything about it yet, I'll likely take a peak at some point in my own time.
[23:17] <bdmurray> TheMuso: Great, I'll pass it on.
[23:23] <NCommander> hey TheMuso ]
[23:25] <jordi> RAOF: ooh
[23:25] <jordi> +       # We don't necessarily have pulse, dbus, or jack biarch libraries
[23:25] <jordi> +       # and even if we do, we don't have the .so symlink for them
[23:25] <jordi> +       # since ia32-libs-dev doesn't exist.
[23:25] <jordi> +       # SO: we need to detect these libs when they exist, provide .so
[23:25] <jordi> +       # symlinks, and copy the pkg-config files.
[23:25] <jordi> RAOF: I think I didn't like this too much
[23:25] <jordi> why can't we have biarch libs for these?
[23:26]  * slangasek shoots biarch in the forehead
[23:26] <jordi> la la
[23:27] <jordi> there it goes.
[23:27] <jordi> now debian/rules is as ugly as it can get
[23:28] <jordi> slangasek: enjoy
[23:29] <jordi> http://svn.debian.org/wsvn/pkg-alsa?op=comp&compare%5B%5D=%2Ftrunk%2Falsa-plugins@2126&compare%5B%5D=%2Ftrunk%2Falsa-plugins@2140
[23:29] <slangasek> I assume that involves biarch and will therefore pretend it doesn't exist
[23:30] <jordi> you can't escape biarch
[23:30] <slangasek> I can replace it with multiarch
[23:30] <jordi> RAOF: I guess this will create duplicate files with ia32-libs or so
[23:31] <jordi> slangasek: that would be quite cool :)
[23:53] <jordi> RAOF: here?
[23:53] <RAOF> jordi: Briefly.
[23:53] <jordi> RAOF: ia64-libs doesnt exist, but was added to Build-Depnds
[23:54] <jordi> any clue?
[23:54] <RAOF> Um, was it?
[23:54] <TheMuso> ia64-libs sounds... weird.
[23:54] <RAOF> I presumably had some reason to think that ia64-libs existed.
[23:54] <jordi> amd64-libs?
[23:55] <RAOF> Aaah.
[23:55] <RAOF> Brain transcription error :)
[23:55] <jordi> yep ;)
[23:55] <RAOF> I sometimes like to forget IA64 is an ISA distinct from x86-64.
[23:57] <NCommander> You can run x86 binaries on ia64 however
[23:58] <TheMuso> At what performance penalty?
[23:58] <stgraber> not only on part of them ? (I thought the first ones didn't have the x86 compatibility thing)
[23:58] <lifeless> TheMuso: no penalty
[23:58] <lifeless> TheMuso: the penalty is in the fact that the chip is HUGE
[23:59] <lifeless> TheMuso: and its clock rate doesn't scale as high, so its x86 work/sec is less than current x86-64 dedicated chips
[23:59] <RAOF> jordi: The crazy "create symlinks and pkg-config files" madness was there for some reason.  Possibly because ia32-lib-dev exists only on ia64, and that's an uninteresting arch for me.