[12:11] <elmo> LaserJock: always has?
[12:11] <elmo> for Ubuntu members anyway
[12:11] <LaserJock> elmo: hmm, for some time I've had to do a RT if I change my preferred address
[12:12] <LaserJock> so I thought they were independent of each other for some reason
[12:12] <elmo> LaserJock: well, it's not 100% automated, because I don't trust LP and/or my scripts not to break ubuntu.com for everyone, so the diff gets mailed to us, and we have to ack it before it's applied
[12:12] <elmo> LaserJock: so an RT ticket is a good way of poking people if it's taken more than a couple of days
[12:13] <LaserJock> elmo: ahh
[12:21] <Riddell> sistpoty: hmm?
[12:23] <tsmithe> Mithrandir, well, i'm off to sleep. i'd just like to ask about a couple of packages in NEW. UbuntuStudio would like wired and enblend to get in (and they've been there since at least, if not before FF). seb128 said he'd had a look, but would like another ack or someone else to upload it entirely. could you take a peek? thanks :)
[12:28] <sistpoty> Riddell: sorry, was afk for a moment... just sent a mail to -motu... what do you think of it?
[12:32] <Riddell> sistpoty: luka has replied already
[12:33] <sistpoty> Riddell: just read it...
[12:33] <sistpoty> Riddell: however by removing the binaries (shortly before feisty releases), you could still make use of the build infrastructure until that point
[12:34] <sistpoty> Riddell: and afterwards we could have binaries for feisty +1
[12:34] <sistpoty> Riddell: the big difference would be that nobody would *need* to support the packages in feisty, once it's released
[12:35] <sistpoty> Riddell: do you think that would totally defeat the purpose or would this be an option you could live with?
[12:37] <Riddell> nobody has to support them anyway, they're just a useful platform to build upon
[12:37] <Riddell> yes, it would be pointless to remove the binaries
[12:37] <sistpoty> hm... ok
[01:04] <krawek> hi
[01:05] <krawek> I have a problem loading shared libraries on dapper, I get: undefined symbol: __gxx_personality_v0
[01:05] <krawek> any idea?
[01:05] <krawek> I'm compiling a ruby extension
[01:06] <danohuiginn> anybody here want to review a simple patch? bug 91695
[01:06] <Ubugtu> Malone bug 91695 in gtkgo "Missing a .desktop file" [Undecided,Confirmed]  https://launchpad.net/bugs/91695
[01:10] <jwendell> krawek, try asking on #ubuntu
[01:10] <krawek> ok
[01:13] <jwendell> danohuiginn, i cannot try it right now, but you could add a changelog entry
[01:15] <danohuiginn> thanks jwendell. Over on #ubuntu-bugs, I was just told to leave the changelog for a maintainer to update, but OK
[01:21] <khermans__> ok, new ubiquity is *REALLY* broken
[01:29] <danohuiginn> if I edit the changelog,I need to change the version number, right?
[01:31] <LaserJock> danohuiginn: yeah
[01:32] <danohuiginn> are there docs on that somewhere?
[01:34] <LaserJock> well, the Ubuntu Packaging Guide
[01:34] <LaserJock> !packagingguide > danohuiginn 
[01:35] <jdong> what is this orange and red thing and what has it done to my login splash?
[01:35] <danohuiginn> got it. thanks
[02:53] <wick2o> anyone know what is wrong with this line? append debian-installer/locale=en_US kbd-chooser/method=us preseed/file=/cdrom/custom.seed initrd=install/initrd.gz ramdisk_size=16384 root=/dev/ram rw quiet --
[02:53] <wick2o> anyoen see an error in this?
[02:54] <wick2o> it still prompts me for the locale and kbd-chooser when i try and do my install
[03:27] <wick2o> anyone know what is wrong with this line? append debian-installer/locale=en_US kbd-chooser/method=us preseed/file=/cdrom/custom.seed initrd=install/initrd.gz ramdisk_size=16384 root=/dev/ram rw quiet --
[03:28] <wick2o> im having a hard time getting those first few questions preseeded
[04:47] <supervillain> hello, is there a way to check each .deb file locally from the internet? I want to check it's md5, and signature validity, if it's not tampered by someone else.
[04:51] <LaserJock> supervillain: if you create a mirror it should work
[04:58] <supervillain> for example, I have /var/cache/apt/archives/lynx_2.8.5-1ubuntu2_i386.deb downloaded from ubuntu repository, is there a way I can get the MD5 of this file from the ubuntu repository?
[04:58] <Fujitsu> supervillain, apt-get, aptitude, or synaptic will automatically check it.
[05:00] <LaserJock> supervillain: I think that the Packages.gz file has the md5sum
[05:55] <kronoman> there is a need for a Norton Utilities-like thing for Linux ?
[05:55] <kronoman> I could code one, inspired on my yesterday hard disk crash
[06:05] <TheMuso> kronoman: If you are referring to something like ghost, there are already several solutions for Linux
[06:05] <TheMuso> As far as I know anyway.
[06:06] <TheMuso> Partimage is one that comes to mind.
[06:08] <kronoman> I was meaning something that come up when the system fails to boot
[06:08] <kronoman> i.e my system crashed /
[06:08] <kronoman> so I was dumped to a root terminal
[06:08] <kronoman> if I were a grandma, I would have been in trouble to recover my data
[06:09] <kronoman> would have been cool instead of the "run fsck manually" a menu with "try to backup data" "check hard disk for errors" etc
[06:09] <kronoman> a text menu, I mean
[06:09] <kronoman> that would make ubuntu more user friendly , I think
[06:12] <kronoman> what I mean is, instead of dumping you to a root console in case of a boot failure, should try to provide with some options to recover, and a "go to root terminal" too
[06:23] <kronoman> more like a integrator, for partimage, badblocks, fsck, etc
[06:23] <kronoman> all-in-one place to call the tools to save your system
[07:29] <pitti> Good morning
[07:29] <Hobbsee> hey pitti!
[07:30] <ajmitch> hey pitti 
[07:31] <Hobbsee> :)
[07:37] <Seveas> elkbuntu, he's ill already, better give him something good instead of your soup
[07:37] <elkbuntu> rofl
[07:38] <elkbuntu> shhh.. you'll ruin my plan!
[08:14] <Mithrandir> tsmithe: I can poke at them.
[08:14] <pitti> Mithrandir: can you please give-back workrave on ppc?
[08:15] <Mithrandir> given-back
[08:16] <Hobbsee> :)
[08:16] <dholbach> good morning
[08:16] <pitti> Mithrandir: thanks
[08:17] <Mithrandir> Hobbsee: you need a proper hackergotchi with just your head and not any background. :-)
[08:17] <dholbach> hey Hobbsee
[08:18] <Hobbsee> Mithrandir: people keep saying that, but imbrandon tried, did a shocking job, because i tend to wear my hair down, which means that if you remove my hair, there's not much of my face left.
[08:18] <Hobbsee> heya dholbach!
[08:18] <ajmitch> morning Mithrandir 
[08:18] <Mithrandir> morning, Andrew
[08:19] <Mithrandir> Hobbsee: we could do something like http://planet.tut.no/heads/lene2.png (a friend of mine) ?
[08:19] <Hobbsee> hrm, maybe
[08:21] <Mithrandir> I could give it a shot if you give me a picture where your head is slightly bigger than 20x20 pixels. :-)
[08:21] <giftnudel> good morning all
[08:29] <Hobbsee> Mithrandir: ahh.  could be aranged, if you really want
[08:30] <Mithrandir> Hobbsee: I could at least give it a shot.
[09:07] <pitti> _ion: hm, I figured out some required packages for the nvidia_supported script, but it still fails with a NoMethodError
[09:11] <pitti> mvo: can you confirm bug 91315?
[09:12] <Ubugtu> Malone bug 91315 in restricted-manager "fglrx needs to be modprobed in /etc/modules" [Undecided,Unconfirmed]  https://launchpad.net/bugs/91315
[09:24] <mvo_> pitti: I give it a go now, but I'm not fully up-to-date
[09:27] <mvo_> pitti: I don't have fglrx in my /etc/modules but it still works fine for me 
[09:28] <pitti> mvo_: including DRI?
[09:29] <mvo_> pitti: yes. let me add a comment to the bugreport
[09:29] <pitti> mvo_: i. e. if X is loaded, it modprobes the module automaticallY?
[09:29] <pitti> mvo_: hmm, anyway, if it doesn't work for some people, I better have r-m add it to /e/modules
[09:29] <mvo_> pitti: right, it will not hurt
[09:30] <lifeless> iwj: hi
[09:30] <lifeless> iwj: sorry I haven't replied to your mail about protocols, got myself into a month long series of sprints
[09:30] <lifeless> iwj: I'm doing so now
[10:09] <_ion> pitti: Could you /msg me the whole error, please?
[10:15] <pitti> _ion: done
[10:15] <pitti> _ion: I merged your changes to trunk; the new hw detection rocks!
[10:15] <pitti> _ion: there seems to be a race somewhere, though; sometimes I only see 'nvidia', and sometimes I also see the legacy driver
[10:16] <_ion> Ouch... That shouldn't happen. :-\ What does lspci -n say about your card?
[10:17] <pitti> _ion: 01:00.0 0300: 10de:0322 (rev a1)
[10:17] <pitti> _ion: as I said, sometimes it works correctly
[10:17] <pitti> I didn't figure out a pattern yet; maybe iff the driver is enabled
[10:19] <_StefanS_> does the current feisty kernel support more than 2gigs of memory ?
[10:20] <_ion> CONFIG_HIGHMEM4G=y
[10:20] <_StefanS_> yes that is great... but does the STOCK ubuntu kernel support it ?
[10:20] <mjg59> Yes
[10:21] <_StefanS_> ok super !
[10:21] <_ion> I pasted it from the stock kernel's config. :-)
[10:21] <_StefanS_> _ion: oh, i'm sorry .. I thought you were trying to get smart with me, so meaning I should compile it by myself ;)
[10:22] <_StefanS_> (to get the support I wanted)
[10:22] <_StefanS_> great, then i'll go out and buy those extra 2gigs for for my lappie :)
[10:27] <_ion> pitti: All right, the version of hpricot in feisty doesn't support the page / 'td[text() ^= "0x"] ' syntax for XPath searches yet. I had installed mechanize with rubygems. I'll modify the script to support the older API.
[10:28] <pitti> _ion: there's no way to replace this with a simple shell/wget script?
[10:28] <pitti> (or urllib)
[10:28] <_ion> pitti: Oh. It *does* support the / syntax, but not the XPath expression i'm using.
[10:28] <_ion> pitti: Of course it's possible, but it would be 5x longer without the mechanize magic. :-)
[10:29] <pitti> ok :)
[10:29] <pitti> _ion: I'll upload 0.5 now for more widespread testing; we'll need another upload tomorrow anyway I guess (after I got a reply to bug 91315 and maybe fixes for the hw detection)
[10:29] <Ubugtu> Malone bug 91315 in restricted-manager "fglrx needs to be modprobed in /etc/modules" [Medium,Needs info]  https://launchpad.net/bugs/91315
[10:30] <_ion> pitti: Screen-scraping doesn't get much easier than this: get 'http://www.nvidia.com/object/linux_display_archive.html'; click page.links.with.href(link_re); click page.links.with.text(/Supported Products List/); (page / 'td[text() ^= "0x"] ').map {|td| td.inner_html.strip.hex }
[10:31] <_ion> That returns a list like [0x0112, 0x01A0, ...]  from a page like http://www.nvidia.com/object/IO_18897.html
[10:31] <pitti> _ion: sweet ;)
[10:32] <pitti> _ion: I still wonder why they maintain such detailed web pages instead of putting those lists into the modules themselves
[10:32] <_ion> pitti: Indeed.
[10:33] <pitti> _ion: uploaded and pushed; can you please merge?
[10:43] <Lutin> mvo_: could you have a look at bug #83139 ? it seems that this program uses files that were in update-manager in edgy, but no longer in feisty
[10:43] <Ubugtu> Malone bug 83139 in gapti "[apport]  gapti crashed with ImportError in <module>()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83139
[10:44] <mvo_> Lutin: yes, I can fix that
[10:46] <Lutin> mvo_: okay, thanks 
[10:57] <_ion> pitti: Pushed the workaround for the version of hpricot in feisty.
[10:57] <pitti> _ion: cool, thank you
[11:01] <TheMuso> pitti: In your email re php4, are you referring to my UVF for drupal when you say its fixed in feisty?
[11:03] <pitti> TheMuso: no idea, I just checked drupal's current dependencies, and it has php5 alternatives
[11:03] <TheMuso> pitti: Oh ok. I was wondering that.
[11:04] <_ion> pitti: Btw, is the problem with nvidia_legacy being listed still there after removing /var/cache/restricted-manager/*.restricted?
[11:05] <slomo_> hm, half of gnome failed to build on ppc it seems
[11:06] <seb128> slomo_: yeah, not only on ppc, there is quite some build errors on amd64 and ia64 also
[11:06] <seb128> slomo_: I'll ask for retries when we are done with uploads
[11:08] <slomo_> seb128: ok, thanks :)
[11:08] <seb128> Mithrandir: gtkhtml upstream changed the lib name, any objection to upload a new source package, etc?
[11:09] <seb128> Mithrandir: there is just new evolution to build with it, should be straigthforward
[11:10] <dholbach> could it be that the libwnck for amd64 disappeared somewhere?
[11:10] <pitti> libwnck18 | 2.17.92-0ubuntu2 | http://de.archive.ubuntu.com feisty/main Packages
[11:11] <dholbach> should be 2.18.0-0ubuntu1
[11:11] <seb128> dholbach: there is a bunch of things which didn't build on amd64
[11:11] <dholbach> seb128: libwnck did build
[11:11] <dholbach> and other stuff ftbfs because the binary is missing
[11:11] <Mithrandir> seb128: go ahead
[11:12] <seb128> Mithrandir: I'm running reprocess-failed-to-move
[11:12] <seb128> that might fix libwnck and other builds
[11:12] <seb128> 47 items there
[11:12] <Mithrandir> ew
[11:12] <Mithrandir> thanks
[11:12] <Lutin> mvo_: btw, can I mark #86574 and #83563 as fixed ?
[11:12] <seb128> np
[11:12] <mvo_> bug  #86574  bug  #83563
[11:12] <Ubugtu> Malone bug 86574 in software-properties "[apport]  software-properties-gtk crashed with NameError in add_source()" [Undecided,Fix committed]  https://launchpad.net/bugs/86574
[11:12] <Ubugtu> Malone bug 83563 in update-manager "[apport]  update-manager crashed with NameError in init_proxy()" [Undecided,Fix committed]  https://launchpad.net/bugs/83563
[11:13] <mvo_> Lutin: let me check
[11:13] <mvo_> Lutin: yes
[11:13] <Lutin> ok
[11:15] <mvo_> Lutin: thanks!
[11:20] <Lutin> mvo_: np
[11:26] <Lutin> mvo_: I guess bug #84915 has been fixed as well
[11:26] <Ubugtu> Malone bug 84915 in update-manager "exec error in DistUpgradeControler" [High,Fix committed]  https://launchpad.net/bugs/84915
[11:27] <mvo_> Lutin: yes
[11:27] <mvo_> Lutin: thanks
[12:05] <bhale> Mithrandir: would you mind closing out uvf bug 88751 before beta hits us?
[12:05] <Ubugtu> Malone bug 88751 in beagle "UVF - Beagle 0.2.16.2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/88751
[12:05] <bhale> Mithrandir: please and thank you.
[12:25] <dholbach> oooooh a new workrave version - finally finally finally
[12:27] <bhale> dholbach: dose it have new dances?
[12:27] <dholbach> it fixes a bunch of bugs i forwarded upstream ages ago - it took them quite a while until they rolled a new tarball
[12:35] <pitti> dholbach: oh, so I can stop asking for give-backs on powerpc :) the current one failed two times due to some gnome library inconsistency
[12:50] <Keybuk> fabbione: (switching to here since it's a bug)
[12:50] <Keybuk> your ide device took 30s to show up, that's a little strance
[12:50] <Keybuk> strange too
[12:51] <Keybuk> could you mail me "lspci -vnn" output as well?
[12:51] <fabbione> Keybuk: no it's not.. there are 4 scsi controllers on that machine that takes a long time to scan
[12:51] <fabbione> Keybuk: 3 of them are Fc-HBA
[12:51] <Keybuk> fabbione: yeah, but the ide device taking the time -> odd
[12:51] <fabbione> sure  i can...
[12:51] <fabbione> it's the last one to be scanned.. and it's a cdrom
[12:52] <Keybuk> this is the time udev takes to process the rule, not the kernel find it
[12:52] <fabbione> uh
[12:52] <fabbione> on the way
[12:55] <Keybuk> that's a hell of a machine
[12:55] <fabbione> Keybuk: it's the T2000 Niagara + 3 FC-HBA controllers.. nothing more
[12:57] <Keybuk> PHYSDEVPATH=/devices/pci0001:02/0001:02:00.0/0001:03:01.0/0001:04:00.2/0001:06:0
[12:57] <Keybuk> 2.0/host1/port-1:1/end_device-1:1/target1:0:1/1:0:1:0
[12:57] <fabbione> Keybuk: lucky that i didn't plug 2 of the controllers or you would see N times the same disks
[12:57] <Keybuk> that's like Eurler's Koningsberg's Bridges Problem, but in PCI!
[12:58] <fabbione> Keybuk: want ssh access? :)
[12:58] <fabbione> but yeah.. there are 3.. kind of weird
[12:58] <Keybuk> I'd be afraid it'd try and takeover my mind over the connection
[12:58] <Keybuk> I'd expect a PCI/E to PCI bridge
[12:58] <fabbione> there are PCI-X and PCI-E slots only
[12:58] <Keybuk> and then maybe I guess a bridge between pluggable boards or something
[12:59] <fabbione> 3 PCI-E (the 3 Fc-HBA)
[12:59] <StevenK> Keybuk: Euler Konigsberg, surely?
[12:59] <Keybuk> sure, but you always have a PCI/E to PCI bridge so you can talk PCI at your PCI/E cards
[12:59] <Keybuk> StevenK: I may be confusing the spelling with the car :p
[12:59] <fabbione> 2 PCI-X one used for the internal scsi disks
[12:59] <StevenK> Keybuk: Haha
[12:59] <fabbione> Keybuk: + all the PCI integrated boards
[12:59] <fabbione> yeah
[12:59] <cjwatson> Keybuk: heh, I've been rereading "A Fire Upon The Deep" recently. If fabbione's computer is a deep-cover instance of the Blight then RUN AWAY
[12:59] <Keybuk> ID_FS_USAGE=filesystem
[01:00] <Keybuk> ID_FS_UUID=5dcafd4e-bbce-4d0e-a746-1d0221accc10
[01:00] <Keybuk> DEVLINKS=/dev/disk/by-id/scsi-3500000e011554ee0-part1 /dev/disk/by-path/pci-0001
[01:00] <Keybuk> :06:02.0-sas-0x500062b00000ad25:1:1-0x500000e011554ee2:1-part1 /dev/disk/by-uuid
[01:00] <Keybuk> /5dcafd4e-bbce-4d0e-a746-1d0221accc10
[01:00] <Keybuk> so it *should* be showing up
[01:00] <Keybuk> oh, weird, that's for /dev/sdb not /dev/sdb1
[01:01] <fabbione> yeah sdb2 is not there
[01:01] <fabbione> not even as multipath entry
[01:01] <fabbione> 0 lrwxrwxrwx 1 root root  30 2007-03-13 12:07 5dcafd4e-bbce-4d0e-a746-1d0221accc10 -> ../../mapper/3500000e011554ee0
[01:01] <Keybuk> odd, you have a uuid for a dm-1 device as well
[01:01] <fabbione> but this is the usual "added last takes over" situation
[01:01] <fabbione> problem is sdb2 is just not there at all
[01:02] <Keybuk> sdb2 is showing up as an LVM2 member
[01:02] <fabbione>  /dev/sdb2 on / type ext3 (rw,errors=remount-ro)
[01:02] <fabbione> for once i am really sure it's not LVM
[01:02] <Keybuk> do vol_id /dev/sdb2 for me
[01:03] <fabbione> vol_id /dev/sdb2
[01:03] <fabbione> ID_FS_USAGE=raid
[01:03] <fabbione> ID_FS_TYPE=LVM2_member
[01:03] <Keybuk> was it an lvm2 member once, that you've quick formatted a new filesystem onto?
[01:03] <fabbione> might be
[01:03] <fabbione> it's a test disk/install
[01:04] <Keybuk> oh, I see why you have a uuid for the dm-1 ... ian broke it
[01:05] <Keybuk> (by-uuid is pointless for dm devices since they have fixed names anyway)
[01:05] <fabbione> Keybuk: do you have a patch on the fly i can test?
[01:05] <Keybuk> fabbione: not right now, give me a few hours
[01:05] <fabbione> just because this thing is.. N O I S Y
[01:05] <fabbione> Keybuk: ok
[01:05] <fabbione> i can test it tomorrow then
[01:06] <Keybuk> will look into it after lunch/ken
[01:06] <fabbione> yeps that's ok
[01:06] <fabbione> i am gonna power it off
[01:06] <fabbione> you REMEMBER the noise, don't you? :)
[01:06] <Keybuk> I remember the noise
[01:21] <kwwii> dholbach: I am pushing a gdm branch with a list enabled theme (although not as default)
[01:21] <kwwii> dholbach: can you check that I did the setup.py and .cfg correctly?
[01:24] <iwj> OK, I give up.  How do you install a system with root-on-raid ?
[01:25] <iwj> I've tried: today's feisty daily ubiquity (no apparent support for raid); edgy d-i (likewise) and dapper d-i.
[01:25] <iwj> dapper is closest but I can't seem to get it to let me designate my new md device as the root fs.
[01:25] <ogra> since when does ubiquity do raid ? 
[01:25] <ogra> i thought only alternate does
[01:25] <iwj> ogra: Apparently never but I didn't know that when I started :-).
[01:25] <ogra> heh, ah ... 
[01:26] <StevenK> edgy's d-i should do it
[01:28] <iwj> OMG `Rebuild status : 16% complete'  but I only just created it!
[01:30] <iwj> Let me check this edgy d-i again.  Maybe I made some silly mistake.
[01:30] <fabbione> iwj: i used the manual partitioner in d-i
[01:30] <fabbione> iwj: first create the partitions, tell d-i to use them as raid
[01:30] <fabbione> go to the raid configuration menu
[01:30] <fabbione> create the raid
[01:30] <fabbione> go back to the partitioner, select the raid and format it/mount it.. etc
[01:31] <robertj_> is it too late for items in universe to go to main for feisty if a main inclusion requests is filled out & approved? libpam-keyring is the greatest thing since sliced bread :)
[01:31] <iwj> Perhaps part of the problem was that I was trying to use an LV as one of my raid components and that doesn't seem to work.
[01:32] <fabbione> no d-i only supports raid on real partitions
[01:32] <fabbione> best you can do is FS over LV over RAID
[01:32] <iwj> fabbione: Right.  That's fine, I've cleared way for that now.
[01:33] <iwj> Why does it need to rebuild it right after I've created it ??
[01:33] <StevenK> Oh drat, openoffice.org-voikko got promoted.
[01:34] <fabbione> iwj: it depends from the raid I think.. raid1 will just wait for that...
[01:34] <StevenK> Would someone mind uploading openoffice.org-voikko  1.1-4build2 to fix #90485
[01:34] <iwj> Aha!  The raid md device shows up in this list _this time_.
[01:36] <Mez> anyone have any idea why my crontabs arent running (using dapper_)
[01:36] <pitti> robertj_: it's not too late in general
[01:36] <pitti> robertj_: you just need to convince iwj or me hard enough to approve it
[01:37] <xerxas> how do i update to from edgy to herd5 ? 
[01:37] <xerxas> without update-manager -c -d 
[01:37] <iwj> OH FFS.  The two things I made the raid1 md out of are different sizes and the raid has chosen to make the md the _larger_ !
[01:37] <xerxas> (I'm remotely connected)  
[01:37] <pitti> xerxas: man apt-get, and #ubuntu, please
[01:38] <xerxas> pitti,  sorry 
[01:38] <xerxas> OT , I know apt-get / /etc/apt/sources.list 
[01:38] <apokryphos> xeros: see the FAQ in #ubuntu topic
[01:38] <xerxas> but that was a simple question ,  I want to update to do some bug triaging 
[01:39] <Hobbsee> xerxas: it's nto development related, and either #ubuntu or #ubuntu+1 would have told you
[01:41] <xerxas> ok , running update-manager -d remotely , too lazy to change /etc/apt/sources.list :)
[01:41] <xerxas> sorry for OT 
[01:43] <iwj> ... but only if you don't wait for it to resync.
[02:10] <dholbach> kwwii: ok
[02:31] <geser> ogra: are you going to upload the debdiffs for rebuilding ltspfs and linux-ntfs? or should I open bugs for it?
[02:42] <bddebian> Heya
[02:45] <_ion> last black
[02:46] <_ion> Whoops. Should be more careful with /foreach window; forgot the / from '/last black'
[02:47] <PhinnFort> ping jdong
[02:47] <jdong> yes
[02:48] <PhinnFort> n/m
[02:48] <PhinnFort> just had some trouble setting up prevu, but suddenly it works...
[02:48] <PhinnFort> got "W: Failure trying to run: chroot /var/cache/prevu/builds/21062/. mount -t proc proc /proc", but now everything is nice
[02:49] <PhinnFort> it's darn nice, btw
[02:50] <jdong> hmm, that would be a pbuilder failure of some sort
[02:50] <jdong> don't know what would be causing it though
[02:50] <PhinnFort> it seems to be running smoothly now, though
[02:50] <jdong> (prevu hands over the actual build task to pbuilder, it just sets up the source code to build)
[02:50] <PhinnFort> aha
[02:50] <jdong> most builds don't need /proc anyway ;-?)
[02:51] <PhinnFort> well, i thought the whole /proc subsystem was deprecated in Linux
[02:51] <PhinnFort> ;)
[02:52] <jdong> lol, no, far from that :)
[02:52] <jdong> /proc is deprecated for interacting with drivers, hardware, etc
[02:53] <jdong> but it is still the way of interacting with PROCcess information
[02:53] <jdong> like it was meant to.
[02:53] <PhinnFort> aha
[02:53] <PhinnFort> that clears up some stuff;)
[02:53] <PhinnFort> i always wondered what "proc" had to do with driver interfaces
[02:55] <jdong> it really doesn't have anything to do
[02:55] <jdong> but /proc was a nice virtual filesystem that kernel drivers can use to interact with userland
[02:56] <jdong> and with nothing else available for the job, /proc got abused
[02:57] <robertj_> what happened to the 2007-02-11 MainInclusionReportPamKeyring?
[02:57] <PhinnFort> isn't /sys getting deprecated too, now?
[02:58] <jdong> PhinnFort: really? haven't heard that.
[02:58] <PhinnFort> i might have dreamt that up
[02:58] <jdong> :)
[02:58] <PhinnFort> ;)
[02:58] <mjg59> /sys is here to stay
[02:59] <bddebian>  /usr needs to die :)
[02:59] <elmo> mjg59: are you using feisty on your macbook pro?
[02:59] <PhinnFort> not die, just disappear
[02:59] <PhinnFort> and maybe /opt
[03:00] <bddebian> mjg59: Can I ask one more time about laptop-mode? :-)
[03:00] <mjg59> elmo: Yes
[03:00] <mjg59> Also, grub
[03:00] <PhinnFort> bddebian: have you tried gobolinux?
[03:00] <elmo> mjg59: meh
[03:00] <mjg59> I've no idea what's up with that initrd.img stuff
[03:00] <elmo> mjg59: can I install grub and have it work?
[03:01] <mjg59> On xfs? Erm.
[03:01] <mjg59> Probably nowadays, to be honest
[03:01] <elmo> mjg59: feisty is killing me with lilo
[03:01] <bddebian> PhinnFort: No, I play on GNU/Hurd though :-)
[03:01] <mjg59> The only issue I'm hitting is that the keyboard doesn't always work
[03:01] <mjg59> But I get the same with isolinux
[03:01] <ogra> geser, i'm doing ltspfs now ...
[03:01] <mjg59> bddebian: Bit busy with real work right now, I'm afraid
[03:02] <sabdfl> elmo: sheesh, what's next, dropping dselect from the seeds?
[03:02] <elmo> sabdfl: huh?
[03:02] <sabdfl> lilo => grub...
[03:02] <elmo> sabdfl: I detest lilo, I never use it unless I'm forced to
[03:02] <elmo> sabdfl: always have
[03:02] <sabdfl> ok
[03:03] <bddebian> mjg59: All I really needed to know is if it's viable to 'fix' it in Feisty.  There are a couple LP bugs on it.
[03:03] <mjg59> Probably
[03:03] <bddebian> That's an autoritative answer ;-P
[03:04] <danohuiginn> if I want a package to use dpatch I have to change debian/rules, right?
[03:04] <mjg59> bddebian: I'm trying to finish my PhD - available time to look at LP is pretty tiny
[03:04] <thom> danohuiginn: yes
[03:04] <mjg59> Sorry about that
[03:05] <mjg59> danohuiginn: Changing the build system can make it harder to get stuff back into Debian, though conversely using dpatch can make it easier - you need to balance the two to a certain extent
[03:05] <danohuiginn> Thanks, thom. That means somebody should update http://doc.ubuntu.com/ubuntu/packagingguide/C/updating-chap.html
[03:05] <bddebian> mjg59: No worries, I'm just giving you a hard time.
[03:06] <elmo> mjg59: so, sorry, just to confirm, grub-install should DTRT in feisty?
[03:06] <mjg59> elmo: Assuming your partition table is fine, yeah. As far as I know, it can deal with xfs now.
[03:06] <mjg59> There's certainly no Mac-specific reason to use lilo
[03:06] <elmo> mjg59: XFS is a red herring
[03:06] <mjg59> Ok
[03:06] <elmo> or at least it is for me, I'm not using it
[03:07] <kylem> elmo, want to build with the patch for me?
[03:07] <mjg59> In that case, yeah, go for it
[03:07] <elmo> kylem: which patch is that, sorry?
[03:07] <kylem> #88219
[03:07] <elmo> oh, I forgot to subscribe to that
[03:07] <cjwatson> elmo: yes, I'm with mjg59, grub (a) should work and (b) works for me on an iMac
[03:08] <cjwatson> elmo: might need to gptsync (refit package) if you haven't done so before)
[03:08] <danohuiginn> mjg59: OK, thanks. I was just trying to find the simplest way to submit a patch, and seem to have failed ;)
[03:08] <mjg59> danohuiginn: If you can't upload, then debdiff is probably the easiest
[03:09] <mjg59> cjwatson: If lilo's working, then the partition table is good enough (I believe)
[03:09] <elmo> cjwatson: ok, I'll try that on the vein hope it may help with my assploding initramfs problems
[03:09] <elmo> gptsync is happy
[03:09] <elmo> already reran it
[03:09] <geser> ogra: thanks
[03:09] <danohuiginn> OK, mjg59. I'll do it that way
[03:13] <ogra> geser, linux-ntfs done as well
[03:14] <geser> thanks again
[03:14] <goliath23> hi
[03:15] <goliath23> does anyone know what color-palette is used in the (edgy) usplash when the text-colors are specified?
[03:16] <Riddell> goliath23: #ubuntu-art (or whatever it's called) might
[03:16] <goliath23> hm ok
[03:19] <elmo> kylem: I think it's generating 0 byte initrd's because they're for 2.6.17 btw
[03:19] <kylem> argh.
[03:20] <goliath23> Riddell: do you think, you could send me the source code where I could read what palette is used in the end? on ubuntu-artwork everyone seems to be asleep
[03:21] <Riddell> goliath23: https://beta.launchpad.net/ubuntu/+source/usplash-theme-ubuntu/0.12
[03:21] <Riddell> without the "beta"
[03:21] <elmo> kylem: also, no go on your patch
[03:23] <goliath23> thanks, but thats the theme. I'd need the source of the usplash library
[03:23] <kylem> elmo, no go in which sense
[03:23] <elmo> kylem: still get the Fatal: empty map, and exit code of 1
[03:23] <goliath23> Riddell: the one that provides usplash_backend.h I guess
[03:23] <kylem> sigh.
[03:23] <kylem> elmo, does the Warning: print?
[03:24] <elmo> nope
[03:24] <kylem> i bet the problem is that it's stat() the symlink
[03:24] <goliath23> Riddell: got it
[03:28] <elmo> man, feisty hates this macbook pro with a passion that I can only respect and admire
[03:32] <highvoltage> elmo: hehe
[03:33] <elmo> kylem: 2.6.20-10 really really hates this macbook pro
[03:33] <elmo> 2.6.20-9 is a lot happier
[03:33] <elmo> in fact, it's booting
[03:34] <kylem> whack.
[03:35] <_ion> summon pitti
[03:47] <bddebian> Can someone explain to me where the hell tutos2 came from?
[03:50] <elmo> so, umm, who would 'feisty doesn't work with lilo' go against?  the initramfs works fine with grub, but explodes on lilo.  not sure if that's an initramfs, linux-source or lilo bug
[03:51] <elmo> Mithrandir: 91940 is another one I think that should probably be milestoned, FWIW
[03:51] <Mithrandir> I'd guess at it being a lilo bug with lilo not managing to load the whole initramfs or something like that
[03:51] <elmo> Mithrandir: ok, thanks, will report that in a sec
[03:51] <Mithrandir> thanks, looking
[03:53] <kylem> elmo, can you try passing in libata.display_hpa=0 to 2.6.20-10?
[04:11] <hunger> cpu frequency scaling seems to be broken on my thinkpad. is that a known issue with the feisty -9-generic kernel?
[04:12] <Seiya> Scaling appears to be working normally on my thinkpad
[04:14] <hunger> Hmmm... setting it to powersave throttles my cpu.
[04:15] <hunger> Dynamic always runs at max speed, even is the box is 98% idle.
[04:15] <Seiya> Definitely not the behavior I'm seeing on my T40
[04:15] <Ng> -9-generic seems ok on my thinkpad atm
[04:16] <Ng> of course I've completely forgotten how to find out which scaler I'm using
[04:18] <Seiya> I'm actually using KDE at the moment, but that really shouldn't make that big a difference
[04:19] <hunger> powersave works as expected...
[04:19] <hunger> Seiya: So do I.
[04:19] <iwj> I'm amazed anyone is using root-on-raid at all, seeing how flakey this all is.
[04:19] <hunger> performance is fine as well, but dynamic seems to be identical to performance:-)
[04:20] <Seiya> Got me, then
[04:20] <Seiya> What model thinkpad?
[04:20] <hunger> Seiya: T43p.
[04:20] <geser> Ng: look in /sys/devices/system/cpu/cpu0/cpufreq/
[04:20] <siretart> iwj: it was quite stable and reliable in dapper and edgy, it sucks in feisty :/
[04:21] <iwj> siretart: Well, the edgy installer hasn't impressed me with it so far.
[04:21] <Ng> geser: ta
[04:21] <iwj> And now my upgrade has bombed out in a crazy way.
[04:21] <siretart> iwj: TBH, I've used the dapper live cd and created the raid volumes and volume groups manually, then rsync'ed an existing rootfs over
[04:22] <iwj> siretart: Yers.
[04:22] <siretart> iwj: I made much better experiences with the debian installer
[04:22] <hunger> Seiya: You are right... after switching back and forth for a while it works for me as well.
[04:22] <iwj> I might well take that approach myself.
[04:22] <hunger> Seiya: Strange... I'll have to keep an eye on this.
[04:22] <iwj> I mean I've spent most of the day so far just trying to get to a point where I can reproduce your bug ...
[04:23] <siretart> :(
[04:26] <iwj> The thing that makes /initrd.img.old empty is particularly annoying.  Why oh why etc. etc. ??
[04:27] <iwj> Are usage messages from modprobe expected ?
[04:27] <iwj> In the initramfs.
[04:31] <iwj> Yay!  I have reproduced your bug!
[04:32] <mjg59> elmo: ^
[04:32] <elmo> the one I haven't even filed yet?  neato
[04:33] <mjg59> So b0rked initramfs seems reproducible
[04:33] <iwj> elmo: ... ?
[04:33] <iwj> I'm talking about bug 75681.
[04:33] <Ubugtu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
[04:34] <mjg59> iwj: elmo had broken initramfs images earler, which then in turn broke lilo
[04:34] <iwj> I'm not sure that's the same thing.
[04:34] <iwj> elmo: You mean the `empty map file' thing ?
[04:34] <elmo> iwj: no, I mean the usage message from modprobe
[04:34] <elmo> that sounds like the breakage I had, when I tried to use lilo on feisty
[04:34] <iwj> elmo: Oh, I think they're a red herring.
[04:35] <elmo> ok
[04:35] <elmo> well we may be talking about very different things
[04:35] <iwj> But you have a machine that doesn't boot I taken it then ?
[04:35] <elmo> iwj: yes, a Macbook Pro, using lilo
[04:35] <elmo> it boots fine with grub though
[04:35] <iwj> Mmmhmm.
[04:35] <elmo> no root-on-raid or lvm or any other of that jazz
[04:35] <iwj> Oh.
[04:35] <elmo> it's a simple ext3 fs
[04:35] <iwj> Dunno what that is.
[04:35] <cjwatson> it's not fallout from hda->sda migration is it?
[04:35] <iwj> I don't think it's related to modprobe and my lilo systems boot fine except for the fact that they're all root-on-weirdshit.
[04:36] <cjwatson> i.e. device major number now being wrong?
[04:36] <iwj> cjwatson: Sounds like a good bet to me.
[04:36] <iwj> elmo: Can you do me a favour and try an experiment ?
[04:36] <kylem> that doesn't explain why it works alright with grub...
[04:36] <elmo> iwj: not right now, no - it's not my laptop and the person who owns it is using it to work :)
[04:36] <iwj> Oh :-).
[04:36] <cjwatson> kylem: grub has UUID handling ...
[04:36] <kylem> hmm, true.
[04:37] <cjwatson> could be lilo.conf just wasn't munged appropriately, whereas grub munges its own menu.lst
[04:37] <kylem> elmo, could they run 'rdev /vmlinuz'? :)
[04:37] <iwj> I had a bug here where lilo looks up the devino of the root fs and then encodes those numbers into your boot setup.
[04:37] <iwj> This is nowadays wrong.
[04:37] <kylem> everything lilo does is wrong nowadays...
[04:37] <iwj> The answer is to move root=... from being a lilo directive to a kernel command line arg in append=.  Ie,  append="root=/dev/something rest of append thing goes here"
[04:43] <iwj> The only trouble with this setup for reproducing this md bug is that I've used a usb stick as one of the raid components to make sure I always lose the race.  Which is fine but usb sticks are damn slow.
[04:45] <Riddell> cjwatson: is the ubiquity warning page being kept for beta?
[04:45] <cjwatson> Riddell: the intro?
[04:45] <Riddell> cjwatson: the warning this is not a final release.  I can't remember if it gets removed before or after the beta
[04:46] <cjwatson> Riddell: no, I'll remove it; thanks for reminding me
[04:50] <Riddell> cjwatson: hmm, if I don't format the partition for / I don't get any warning, but there's an error part way into the install
[04:53] <cjwatson> Riddell: version of ubiquity? I fixed that recently
[04:53] <Riddell> cjwatson: today's daily CD, Kubuntu
[04:54] <Riddell> 1.3.26
[04:54] <cjwatson> ubiquity (1.3.27) feisty; urgency=low
[04:54] <elmo> kylem: oh, the person with the laptop snuck off :-( I'll have to finish testing tomorrow
[04:54] <cjwatson>   * New partitioner: Add validation for system partitions being formatted
[04:54] <cjwatson>     (LP: #89461).
[04:54] <cjwatson> your livefs is out of date
[04:56] <kylem> ok
[05:05] <ogra> does anybody else see weird behavior with the latest firefox ? 
[05:05] <ogra> seems it cant open any non local page here ... 
[05:06] <ogra> oh, i lied, it just takes 5min to open a webpage
[05:06] <ogra> hmm
[05:09] <pitti> carlos: oh, fresh langpacks from today :)
[05:09] <carlos> pitti: we do them every day ;-)
[05:13] <pitti> seb128: I started building current langpacks and will upload tonight; did you see any problem with yesterday's? the German ones worked great
[05:14] <pitti> ogra, mvo, seb128: thoroughly testing restricted-manager again would be appreciated; a lot of code improvements in 0.5 and 0.6
[05:14] <_ion> pitti: I think i fixed the problem with nvidia_legacy still being visible some times. I had erroneously put the parsing of modalias.overwrite *after* the module cache was saved.
[05:15] <pitti> ah :)
[05:15] <ogra> BenC, did anything change wrt networking in the recent kernel ? i cant get pings with a 128 byte packetsize and above through ... 
[05:15] <_ion> pitti: I've pushed the change to my branch.
[05:15] <BenC> ogra: bcm43xx?
[05:15] <pkern> Do you produce installer images for USB sticks somewhere?
[05:15] <ogra> pitti, i'd love to, but currrently i can be happy to have an IRC connection it seems ...
[05:16] <ogra> BenC, yep
[05:16] <ogra> i saw nothing in the changelog
[05:16] <pitti> ogra: ah, alright :/
[05:16] <ogra> but it looks like a driver prob
[05:17] <BenC> ogra: None that I'm aware of
[05:19] <pkern> Hm yes... http://de.archive.ubuntu.com/ubuntu/dists/feisty/main/installer-i386/current/images/netboot/ ... Ok, not really hidden.
[05:24] <bluefoxicy> In case anyone hasn't noticed, Dell's Linux survey asks what kind of commercially supported distro you would like to see installed on Dell systems
[05:24] <pitti> carlos: will the feisty tarballs continue to be generated in the afternoon, or will you move them to the mornings again? and back to a weekly cycle?
[05:24] <bluefoxicy> One choice is Ubuntu.  So everyone clap for yourselves, because you did a good enough job to get on Dell's radar without being a multi-million dollar publicly traded stock.
[05:25] <iwj> siretart: AYT?  Could you email me (iwj@ubuntu.com) your initramfs ?  Unless it has a password or something in it ...
[05:26] <seb128> pitti: will try the language pack now, I've been swamped with GNOME 2.18 since yesterday
[05:26] <pitti> seb128: oh, don't worry
[05:26] <carlos> pitti: well, I don't understand how's that it takes so long to be generated...
[05:26] <pitti> seb128: if you wait for another hour or so, you can test the new ones right away
[05:26] <carlos> pitti: and didn't have time to see what's going on
[05:27] <seb128> pitti: k, will do that then, I still have to fix libgnomeui and gtk updates for GNOME 2.18
[05:27] <pitti> carlos: ok, no problem
[05:27] <pitti> carlos: after those, I'll just generate them together with the stable ones in the morning and stop worrying about them
[05:27] <pitti> seb128: sorry for bothering you then, I'll find other guys to hassle :)
[05:28] <carlos> pitti: ok
[05:28] <Lure> pitti: can you review https://wiki.ubuntu.com/MainInclusionReportDigikamImagePlugins when you find some time?
[05:28] <pitti> Mithrandir: I'd like to upload the feisty langpack flood this evening; just want to confirm that's ok with you?
[05:28] <Mithrandir> pitti: go for it.
[05:29] <siretart> iwj: as soon as I return home (ETA ~2h)
[05:29] <pitti> Lure: what's the urgency? "OMG, we need it yesterday for the beta freeze" or slightly lower?
[05:29] <iwj> siretart: OK.
[05:29] <Lure> pitti: lower, it is just in supported now, but may get on cd after beta
[05:29] <iwj> siretart: When you do you might like to try removing /usr/share/initramfs-tools/scripts/local-top/mdrun and updating your initramfs.
[05:29] <Lure> pitti: if space allows it
[05:30] <pitti> Lure: ok, non-CD packags can be promoted later still
[05:30] <siretart> iwj: sounds scary, because I need that script to boot my system..
[05:30] <pitti> Lure: then I'll do my OMGbetafreeze tasks first, if that's ok with you
[05:30] <siretart> (by manually calling it)
[05:30] <iwj> siretart: Oh.
[05:30] <iwj> You do have a spare initramfs though don't you ?
[05:31] <iwj> I suppose you probably don't.
[05:31] <Lure> pitti: no problem, was just told that it is best to ping you when we have MIR ready ;-)
[05:31] <pitti> Lure: right, and please continue nagging me if I forget
[05:31] <siretart> iwj: that can be arranged.. ;)
[05:31] <Lure> pitti: will do after beta, thanks ;-)
[05:31] <iwj> This whole wobbly pile is far to fragile and the thing has no proper plan B setup.
[05:31] <iwj> So err sorry if I break your system with my crazy requests.
[05:32] <iwj> Unfortunately my copy of your symptoms seems to have gone away.
[05:32] <siretart> oh
[05:32] <iwj> But I have a different set of symptoms which I think are due to lilo and perhaps when I've investigated and fixed those it will be better.
[05:32] <siretart> the system is already broken for weeks, but that's it with development versions :/
[05:35] <iwj> Quite.
[05:35] <siretart> ok, driving home now
[05:35] <iwj> You should have, I think, /usr/share/initramfs-tools/scripts/local-top/mdadm too.  That's the correct script which should DTRT.
[05:35] <siretart> cu later!
[05:35] <iwj> ttfn
[05:44] <pitti> carlos: https://translations.beta.launchpad.net/ubuntu/feisty/+source/restricted-manager/+translations -> no templates available; how come? I thought universe was imported as well?
[05:46] <bddebian> pitti: phpmymoney has been orphaned in Debian and hasn't seen an upstream update since 2003 afaics.  Do you think we should drop it?
[05:46] <pitti> bddebian: I'm all for decruftification :)
[05:48] <carlos> pitti: no, universe is not yet imported
[05:48] <pitti> carlos: ah, ok; doing the good old vi po/de.po then :)
[05:48] <bddebian> pitti: Well if it stays in Debian, will it just get re-synced again?
[05:48] <carlos> pitti: ;-)
[05:49] <pitti> bddebian: I don't know yet; I wasn't yet introduced to the technical side of blacklisting
[05:49] <bddebian> Ahh :-)
[05:50] <pitti> Keybuk, Mithrandir: is there a blacklist on drescher where I should add removed packages which should not be resynced?
[05:50] <Keybuk> pitti: /srv/launchpad.net/dak/sync-blacklist.txt
[05:50] <pitti> Keybuk: thanks; I'll add that to ArchiveAdmin
[05:52] <PhinnFort> jdong: ping, again
[05:52] <cjwatson> pitti: (note that that's in bzr)
[05:52] <pitti> Keybuk: hmm, the 'Be sure to "bzr commit" after any changes.' is not to be taken too seriously? :)
[05:52] <pitti> cjwatson: right, with lots of uncommitted changes
[05:53] <alex-weej> does anybody feel like upping the importance of this? https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/78288
[05:53] <Ubugtu> Malone bug 78288 in linux-source-2.6.20 "kernel 2.6.20-10 doesn't boot with sata-hd" [Medium,Confirmed]  
[05:53] <bddebian> pitti: I guess my question is more:  Do I attempt it with PHP5 or not bother? :-)
[05:53] <Keybuk> pitti: bad people
[05:53] <pitti> bddebian: *shrug* I don't know; Personally I couldn't care less about that php stuff
[05:53] <pitti> Keybuk: I'll commit it now
[05:54] <bddebian> pitti: Know anyone that does? :-)
[05:56] <pitti> bddebian: I'll just kill it; really noone should use 4 years old php software; it's got more holes in it than Swiss cheese, probably
[05:56] <iwj> elmo: If I were to feed you a sh fragment that I was going to try putting in the lilo postinst to fix up this root= problem, would you be able to test it ?
[05:57] <iwj> siretart: Now I've fixed my lilo problem the md race has gone away for me but I do think it's still there lurking in that mdrun script.
[05:58] <elmo> iwj: the laptop has left the building - but I can test it tomorrow for you
[05:59] <pitti> bddebian: there it goes  /me makes a flushing noise
[06:00] <bddebian> pitti: :)
[06:02] <mvo> iwj: can you give me a hint when dpkg throws this error: "dpkg: error processing wpasupplicant (--remove):
[06:02] <mvo>  Package is in a very bad inconsistent state - you should reinstall it before attempting a removal." ? is there anything that the user can do if he does not have the original package anymore?
[06:07] <iwj> mvo: Best thing is to dpkg -i as similar a .deb as can be found.
[06:07] <iwj> Err on the side of an earlier one.
[06:08] <iwj> This state can only arise if dpkg's unpack is interrupted eg by the system crashing or dpkg crashing or some such.
[06:08] <mvo> iwj: ok, thanks
[06:12] <cjwatson> Mithrandir: could you give-back gnome-panel/amd64?
[06:12] <cjwatson> at least the reported problem should be fixed now
[06:14] <seb128> there is probably a lot of other packages to build retry on amd64 and ppc
[06:15] <seb128> cjwatson: do you know if other builds have been retried yet?
[06:15] <cjwatson> yes, but that's the one that's obviously blocking my feisty upgrade ... :)
[06:15] <cjwatson> I don't know
[06:15] <seb128> ah ok ;)
[06:15] <seb128> I'll have a look and make a list
[06:15] <cjwatson> quite impressively too, there's a Breaks/Depends loop and apt-get just refuses to do anything
[06:17] <cjwatson> I'll try just upgrading the kernel and related stuff, which is what I actually need
[06:31] <mdz> mvo: around?
[06:31] <mdz> mvo_: how about you?
[06:33] <mvo_> mdz: hello!
[06:33] <mdz> mvo_: I'm attempting an upgrade test from 6.10 to feisty, and update-manager failed. I've pasted you the output in /ms
[06:33] <mdz>  /msg, even
[06:33] <mvo_> mdz: please update your update-manager to the version in edgy-proposed
[06:33] <mvo_> mdz: that should fix the problem
[06:34] <mdz> mvo_: eek. who is affected?
[06:34] <mdz> this is a bone stock 6.10 install in vmware
[06:34] <mvo_> mdz: the update is uploaded to edgy-updates as well, but not yet approved
[06:34] <mvo_> mdz: everyone without a .gnupg dir :(
[06:35] <mdz> I'll create a .gnupg dir for now
[06:35] <mvo_> mdz: that will fix it as well
[06:35] <mdz> mvo_: have you already spoken to an archive admin about accepting it?  this is fairly critical for upgrade testing
[06:36] <pitti> mvo_, mdz: we talked about it yesterday; if mvo_ uploaded the fix now, I'll accept it
[06:36] <mvo_> mdz: I haven't pushed for it yet, its only recently sru-verified (it was in the queue for sru-verification for some time, but the queue was processed slowly)
[06:37] <mvo_> pitti: its uploaded
[06:37] <mdz> mvo_: at what point will 6.10 start to recognize feisty CDs as an upgrade opportunity?
[06:38] <pitti> mvo_: eek, config.{guess,sub} changes
[06:39] <pitti> mvo_: after getting bitten by 30 bug duplicates about a broken hal because of autotools changes, I have to refuse this
[06:39] <mvo_> pitti: ok, I will reupload
[06:39] <pitti> mvo_: ok, rejected, you are free to upload again
[06:39] <pitti> mvo_: sorry for the hassle
[06:40] <mdz> pitti: if that's to be standard policy, please document it on StableReleaseUpdates as it will be a common error
[06:40] <pitti> mdz: it is actually; 'please make sure that there are no changes except the changelog' or sth. similar
[06:41] <pitti> "The package difference must be a minimal change to fix the bug. Spurious changes to build systems, documentation, functionality will be rejected."
[06:41] <pitti> and "Make no other changes relative to the version in -proposed."
[06:41] <pitti> (relative to 'add a changelog entry')
[06:42] <mdz> pitti: oh, the version in -proposed didn't update those files?
[06:42] <mdz> pitti: if they can cause problems, we probably shouldn't change them in -proposed either
[06:42] <pitti> mdz: I'm not sure; but I'm anal about the -proposed vs. -updates diff being only the changelog
[06:42] <pitti> i. e. release exactly what has been tested in -proposed
[06:43] <mdz> agreed; once LP supports it that will be an exact copy, binaries and all
[06:43] <pitti> mdz: I agree, and I usually complain about them
[06:43] <crimsun> sabdfl: Ben informed me that Feisty's 2.6.20-10.17 regressed your audio. When you have a moment, please attach separately the requested info from the "Reporting Sound Bugs" section on https://help.ubuntu.com/community/DebuggingSoundProblems to bug 69529  (if that X60 is in fact the affected one)
[06:43] <Ubugtu> Malone bug 69529 in linux-source-2.6.17 "Sound intermittently not working on ThinkPad X60" [Medium,In progress]  https://launchpad.net/bugs/69529
[06:43] <pitti> mdz: I'm strict for main, and less strict for universe (e. g. config.guess/sub should usually be harmless)
[06:43] <mdz> pitti: I think that's appropriate
[06:44] <mvo_> mdz: cd detection should work, I will test that now in vmware
[06:45] <pitti> mvo_: it worked for me, but it doesn't offer upgrading; just 'start synaptic' and 'ignore'
[06:45] <pitti> mvo_: (or something similar to 'ignore')
[06:46] <mvo_> mdz, pitti: it has the same .gnupg dir problem  :/
[06:46] <pitti> mvo_: hm, that worked for me with just edgy-proposed; I tested that carefullyh
[06:46] <mdz> mvo_: I just tried it; it was only detected as a CD with packages on it
[06:47] <pitti> mdz: likewise; I had to do 'sudo sh /cdrom/cdromupgrade', that worked without the -proposed fix
[06:47] <mvo_> mdz: after you added .gnupg ? did it detect it correctly then?
[06:48] <mdz> mvo_: oh, I did not attempt that
[06:48] <mdz> I will try that now
[06:49] <mvo_> mdz: sorry for. its the same bug as before, gnupg insists in creating a $GNUPGHOME/trustedb file whatever option you give it
[06:49] <mdz> mvo_: yes, I remember this from apt-key. it is not very cooperative
[06:49] <mdz> I tried everything to suppress that
[06:50] <mdz> in the end I had to use --trustdb-name
[06:50] <mdz> mvo_: is that how you fixed this one as well?
[06:50] <wick2o> afternoon
[06:51] <elmo> mvo_: are you using gpgv?
[06:51] <elmo> + yet - those kind of issues go away when you do
[06:51] <mvo_> mdz: I set --homedir to the tempdir that is used for the extraction
[06:51] <elmo> obviously I realise it's too late for edgy, I mean for feisty onwards
[06:51] <mdz> mvo_: ok, after creating .gnupg, I get Cancel/Start Package Manager/Run Upgrade
[06:51] <mdz> mvo_: it would be nice if we could improve that dialog
[06:52] <mvo_> elmo: currently I use the python GnuPGInterface 
[06:52] <mvo_> mdz: improve in what way exactly?
[06:52] <mdz> it's not very clear what it means; it should say that it's a new version of Ubuntu and ask if they want to upgrade
[06:52] <mdz> It says "A distribution volume with software packages has been detected"
[06:53] <mdz> it should say something like "This volume contains a new release of Ubuntu.  Would you like to upgrade to it?  Don't upgrade/Upgrade"
[06:53] <wick2o> APPEND debian-installer/locale=en_US kbd-chooser/method=us preseed/file=/cdrom/preseed/ubuntu-custom.seed initrd=/install/initrd.gz ramdisk_size=16384 root=/dev/ram rw quiet --
[06:53] <mdz> and preferably state the version
[06:53] <wick2o> anything in there jump out at anyone as being wrong?
[06:53] <wick2o> the debain-installer and kbd-chooser doesnt seem to work
[06:53] <mvo_> mdz: ok, I will do that
[06:53] <wick2o> the preseeded stuff works great
[06:53] <mdz> mvo_: the dialog about whether to use the network could be tweaked as well, while you're there
[06:55] <mvo_> mdz: I'm happy to do that, what bits are unclear?
[06:56] <mdz> "Include latest updates from the Internet?"  "The upgrade process can automatically download the latest updates and install them during the upgrade.  The upgrade will take longer, but when it is complete, your system will be fully up to date.  You can choose not to do this, but you should install the latest updates soon after upgrading."  "Install updates/Skip updates"
[06:57] <mvo_> mdz: thanks, that sounds much better indeed
[06:57] <mdz> (install updates should be the default option of course, I reversed the button order)
[06:58] <mdz> mvo_: what happens if the user has packages from universe installed and they attempt a CD upgrade?
[06:59] <mvo_> mdz: a lot of packages will be kept back, but otherwise it should work. when he runs a apt-get update with network next time u-m will prompt to finish the upgrade
[07:00] <mdz> mvo_: that's pretty good
[07:00] <mdz> mvo_: I wonder how many universe packages tolerate it, though
[07:00] <mdz> partial upgrades won't be well tested
[07:00] <mvo_> mdz: its only as good as the apt problem resolver
[07:00] <cjwatson> wick2o: what release of Ubuntu?
[07:01] <mvo_> mdz: I can do some testing on this though
[07:01] <mdz> pitti: what does it do?
[07:01] <pitti> mdz: restores the most recently closed tab
[07:01] <mdz> mvo_: I was also thinking that because downloading and installing the updates are separate progress bars, they should be separate steps in the dialog too.  what do you think?
[07:01] <pitti> the 'whoops, ctrl+w' undo
[07:01] <mdz> mvo_: so instead of preparing/modifying/downloading+installing/..., preparing/modifying/downloading/installing/...
[07:02] <mdz> mvo_: does the API support that?
[07:02] <mvo_> mdz: that should be straightforward to add
[07:03] <mdz> mvo_: ok, I'll file a bug
[07:03] <mvo_> mdz: thanks
[07:03] <mdz> pitti: oh, how nice
[07:04] <pitti> mdz: one of those small and nice things you discover when releasing shift too late :)
[07:04] <_ion> pitti: I got rid of "whoops, ^W" problems by making Gtk use Emacs key bindings. :-)
[07:05] <mdz> pitti: I usually "discover" my xchat closing
[07:05] <_ion> pitti: Now ^W does the right thing in text fields, even in Firefox.
[07:05] <mdz> because I remapped close to shift+ctrl+w to be able to use it for kill-word
[07:05] <mdz> _ion: that used to DTRT, but no longer
[07:05] <Keybuk> pitti: what does that one do?
[07:06] <pitti> Keybuk: <pitti> mdz: restores the most recently closed tab
[07:06] <dneary> Hi
[07:07] <dneary> jono: About?
[07:07] <mdz> mvo_: does update-manager attempt to check whether it is out of date with -updates before doing an upgrade?
[07:07] <jono> dneary: two ticks, phone
[07:07] <dneary> jono: No rush, I'm between raindrops and was looking for a chinwag
[07:08] <mdz> mvo_: do you think that would be a good idea?
[07:08] <mvo_> mdz: currently not, but it is on the list of things to implement. its a good idea for sure, lack of time was the problem so far 
[07:08] <mdz> since anyone who has not installed updates for 10 days at beta will not be able to upgrade
[07:09] <mdz> mvo_: understood
[07:09] <mdz> I guess the thing to do would be to provide a simple way to upgrade only update-manager and nothing else
[07:09] <mdz> to avoid having to install 6 months of updates just to upgrade to the next release
[07:13] <mvo_> mdz: the way the system is designed (downloading the special upgrade tarball) we come close already. I was thinking of adding a dependency mechanism to this as well so that it can check if it has e.g. the version of adept apt it needs etc. this should be straightfoward to implement and will avoid problems. it espcially important for the kde-part of u-m as this needs a updated konsole otherwise it will not work at all
[07:14] <mdz> mvo_: hmm, you're right. it would be better to make them dependencies of the upgrader than of update-manager
[07:14] <mdz> pseudo-dependencies, anyway
[07:15] <mvo_> mdz: yes, that was what I was thinking. it could even update the required packages before it starts etc
[07:17] <mdz> mvo_: hmm, I suppose we would need to include (N-1)-updates on the (N) CDs
[07:17] <mdz> to fully support upgrades without internet access
[07:18] <mvo_> mdz: yes, we are not very good at this currently. it works for ubuntu CD->CD upgrades on systems that haven't used the net. but for e.g. kubuntu it will not work as it is right now
[07:19] <mdz> mvo_: right, i mean that to implement the pre-dependency feature for the upgrader, we would need to start doing that
[07:19] <mvo_> mdz: right
[07:19] <mdz> mvo_: do you think it is likely that we will encounter this situation again, so that it is worthwhile to implement this feature proactively?
[07:20] <mdz> implementing it in the upgrader itself has the nice property that we don't need to do it in advance; we can wait and do it only if needed
[07:20] <mvo_> mdz: I think its likely - the chances to have a anoying bug that needs to be fixed prior the upgrade are there
[07:31] <wick2o> cjwatson: dapper
[07:31] <wick2o> 6.06.1 -server
[07:31] <wick2o> sorry for the late response, computer went down at work
[07:31] <pitti> seb128: there, new langpacks!
[07:31] <pitti> Riddell: are you interested in giving the French KDE feisty langpacks a quick test?
[07:31] <seb128> pitti: same place as usual?
[07:31] <pitti> seb128: yup
[07:32] <pitti> deb http://people.ubuntu.com/~pitti/langpacks/daily/feisty/ ./
[07:32] <pitti> seb128, Riddell: ^
[07:33] <mdz> mvo_: ok, I'll put it on the agenda for UDS then
[07:34] <Riddell> pitti: sure
[07:36] <pitti> ^ new testing bait for the ATI-owning folks (Nvidia testing appreciated as well)
[07:37] <pitti> mvo_: FYI, nothing yet in the edgy-updates queue; did the upload fail or didn't you do it yet?
[07:38] <mvo_> pitti: in 2 minutes, building it in a chroot now
[07:38] <pitti> mvo_: ah, ok; no hurry, just checking
[07:40] <cjwatson> wick2o: looks fine; check /proc/cmdline after booting to make sure that those options are really being used
[07:40] <mvo_> pitti: uploaded now
[07:41] <wick2o> cjwatson: cjwatson checkin it out now..
[07:49] <pitti> mvo_: accepted, thanks
[07:50] <mvo_> pitti: cool, thanks
[07:52] <wick2o> cjwatson: i think i found my error, for some reason when id copy the iso to my usb key and then unmount it wouldnt override the copy that was already there, so when i tried it in vmware it didnt work because it was an older image that didnt have the changes :\...at leasat this is my theory since it works with qemu
[07:52] <wick2o> ill give it another go after an rm of the iso and i recopy to my usbkey
[07:54] <wick2o> if this was my problem, i swear i should be stabbed
[07:54] <wick2o> :)
[07:56] <iwj> siretart: Any progress with(out) .../mdrun ?
[08:06] <jwendell> keescook, around?
[08:06] <keescook> jwendell: howdy, yup.  what's up?
[08:07] <jwendell> keescook, there is a new upstream version (security fix) for vnc4 (4.1.2). Did you know or should i fill a bug about it?
[08:08] <keescook> jwendell: does it have a CVE associated with it?
[08:08] <jwendell> keescook, no, but this version is from may,2006 !!
[08:09] <jwendell> keescook, http://www.realvnc.com/
[08:09] <keescook> Hm, I suspect that's already been taken care of: https://launchpad.net/ubuntu/edgy/+source/vnc4/+changelog
[08:09] <keescook> unfortunately, edgy and feisty's vnc4 aren't stable and no one has figured out why.  :(
[08:10] <jwendell> keescook, ah, right. why ubuntu's version number is different from upstream?
[08:10] <keescook> jwendell: because when doing security fixes, only the fixes are back-ported.
[08:10] <keescook> i.e. the version number stays the same.
[08:10] <iwj> This modem wasn't working because of a _faulty telephone cable_ between the laptop and the wall socket!  Honestly.
[08:10] <jwendell> keescook, that's not the feisty case, right?
[08:11] <keescook> jwendell: in feisty's case, no one has packaged 4.1.2, so the fixes were just backported to the existing package.
[08:11] <keescook> jwendell: if you wanted to figure out why edgy/feisty doesn't work, I (and maybe people) would be very grateful
[08:11] <keescook> https://launchpad.net/bugs/78282
[08:11] <Ubugtu> Malone bug 78282 in vnc4 "vnc4server does not start Desktop environment after security update" [High,Confirmed]  
[08:11] <jwendell> keescook, it works for me
[08:12] <jwendell> keescook, as client. as server i use vino :)
[08:12] <keescook> jwendell: heh.  okay, fair enough.  The security issue was only on the server side, IIRC.
[08:13] <_MMA_> Hi guys. How do I find out if something in Main will get updated? Mainly (hehe) wacom-tools and xserver-xorg-input-wacom.
[08:13] <_MMA_> I was helping a user on the forums with a HOW-TO I maintain. http://ubuntuforums.org/showthread.php?t=25151 I realized that the version of wacom-tools he needed was  0.7.6-4 and Ubuntu (Feisty) uses 0.7.2.
[08:15] <Mithrandir> cjwatson: given-back
[08:16] <cjwatson> thanks
[08:29] <kronoman> I think Ubuntu needs a better crash-in-boot handling
[08:29] <kronoman> to make easier for novice users to recover after a crash (i.e hard disk crash)
[08:30] <wick2o> kronoman: i think there are way too many varables for that to happen
[08:30] <wick2o> its not like windows has very good crash-in-boot handling either
[08:30] <kronoman> maybe just a menu with options to call fsck, badblocks, etc
[08:30] <kronoman> instead of dumping to a root terminal
[08:32] <wick2o> honestly, if it happends that often that you would need a menu, id think it would be time to replace the harddrive ;)
[08:33] <wick2o> i guess they COULD setup a bit or a 0/1 somewhere in /proc for "did my system crash"
[08:33] <wick2o> and run fsck or its true
[08:33] <wick2o> i wouldnt that it would be that hard for you to create your own bash script with these functions
[08:34] <kronoman> really, I just crashed once and replaced the disk after data recovery, but I thought, if this happens to a normal user.... 
[08:34] <kronoman> I mean, the concept of dumping to a root terminal if the system crashes goes against the "for human beings" thingy
[08:37] <sabdfl> crimsun: ok, am filing bug with all that data
[08:37] <crimsun> sabdfl: thanks
[08:37] <wick2o> kronoman: true i guess
[08:38] <wick2o> i mostly use ubuntu-server...i a huge fan of the LTS build
[08:38] <wick2o> if that continues ( a realse every 5 or so years with full sec. updates) im going to switch all my servers over the ubunut
[08:45] <sabdfl> crimsun: https://beta.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/92005
[08:45] <Ubugtu> Malone bug 92005 in linux-source-2.6.20 "Sound not working on x60 with 2.6.20-10 in feisty beta" [Undecided,Unconfirmed]  
[08:45] <crimsun> sabdfl: looking.
[08:53] <siretart> iwj: puh. returned from lunch, sitting at my workstation now
[08:54] <crimsun> sabdfl: it actually should work fine presently, but likely you'll need to try [echo options snd-hda-intel model=thinkpad |sudo tee -a /etc/modprobe.d/alsa-base]  if it's still inaudible in the next kernel
[08:56] <shawarma> siretart: Lunch?!? Arent' you in Germany?
[08:56] <siretart> iwj: surprisingly, the system bootet without intervention after an system upgrade. let's see if it was only luck
[08:56] <siretart> shawarma: s/lunch/dinner/
[08:56] <siretart> ;)
[08:56] <shawarma> siretart: Oh.
[08:56] <shawarma> siretart: :-)
[08:57] <Treenaks> hacking so hard, you forget time ;)
[08:58] <siretart> Treenaks: I was on a buisness trip to munich for two days, and have just returned home
[08:58] <Treenaks> siretart: blame it on jet lag -- germany is so big 8)
[09:00] <siretart> Treenaks: ;)
[09:00] <siretart> iwj: ok, reboot failed then :(
[09:00] <pitti> Riddell, seb128: good to upload the current langpacks?
[09:01] <mdz> wick2o: we do need a simple way to force a check; that's on the discussion agenda for the next summit
[09:02] <mdz> as for doing something intelligent if the root filesystem is corrupted, that's a tough one
[09:02] <mdz> it's not safe to bring the system up far enough to behave in a friendly way
[09:03] <Riddell> pitti: works fine for me
[09:04] <pitti> Riddell: great, thanks for testing
[09:13] <siretart> iwj: okay, I now removed the local-top/mdadm script, with the behavior, that NONE md volumes appear in /proc/mdstat. Before I had one of four devices listed
[09:13] <siretart> iwj: another difference is that udevtrigger doesn't help anymore
[09:18] <_ion> Ooo, cool. I don't know whether it's a new feature in libvte or xfce4-terminal, but now the background colors of the bottom line and the rightmost column are spread to the window boundary if the window size isn't a multiple of the font size.
[09:23] <Adri2000> http://librarian.launchpad.net/6335769/buildlog_ubuntu-feisty-i386.avidemux_1%3A2.3.0-0.0ubuntu2_FAILEDTOBUILD.txt.gz < any idea how to fix that is welcome... Mithrandir maybe?
[09:23] <siretart> iwj: initramfs is underway
[09:30] <juliux> hi, it is possible to copy the ubuntu desktop cd image to an usb stick and to start the live system from the usb stick? i don't want to install ubuntu on the usb stick
[09:48] <iwj> siretart: No, I wanted you to remove the _mdrun_ script.  You should have an _mdadm_ script too which is the one I think is correct.
[09:49] <iwj> But thanks for the initramfs.  Must go now but I'll look at it tomorrow.
[10:14] <lando> what version of gnome will feisty ship with?
[10:15] <pochu> lando: 2.18
[10:16] <lando> ah thanks 
[10:16] <lando> um u sure? the gnome site states that 2.16 is the latest
[10:16] <seb128> lando: it already has 2.18
[10:17] <seb128> lando: 2.18 official date is tomorrow
[10:17] <lando> nice thanks 
[10:17] <seb128> np
[10:49] <Mithrandir> seb128: I'm doing a bunch of give-backs on gnome stuff, so if you get duplicated ftbfs messages, you know why.
[10:51] <seb128> Mithrandir: yeah, thank you, I was going to make a list but if you can do massive retry that's better
[10:51] <seb128> Mithrandir: probably due to the packages which have not been moved correctly and were not installable on amd64 and ppc
[10:51] <Mithrandir> seb128: nah, I go through the list of out-of-dates, that's easy enough.
[10:51] <seb128> ok
[10:51] <Mithrandir> seb128: yeah, that's what I think too
[11:02] <sabdfl> tepsipakki: ping, #ubuntu-meeting
[11:13] <sabdfl> mjg59: we have two -core-dev applications in #ubuntu-meeting if you have a sec
[11:34] <danohuiginn> anyone here got time to review two simple patches? bug 91694 and bug 91695
[11:34] <Ubugtu> Malone bug 91694 in cgoban "No .desktop file" [Undecided,In progress]  https://launchpad.net/bugs/91694
[11:34] <Ubugtu> Malone bug 91695 in gtkgo "Missing a .desktop file" [Undecided,Confirmed]  https://launchpad.net/bugs/91695
[11:34] <danohuiginn> both just adding in application menu items
[11:36] <pochu> danohuiginn: are both packages in main?
[11:36] <danohuiginn> no, both in universe
[11:36] <pochu> danohuiginn: then it's better that you ask in #ubuntu-motu ;)
[11:37] <danohuiginn> OK. Thanks, pochu. One day I'll work out what channel is for what
[11:37] <pochu> danohuiginn: yw