[12:13] <BenC> tfheen: All uploaded...in your capable hands now
[12:45] <sabdfl> sistpoty: start with Malcolm Yates <malcolm.yates@canonical.com>
[12:46] <sabdfl> he handles new ISV's, and game publishers would fall into that category
[12:46] <sistpoty> sabdfl: ok, thanks, will do
[01:21] <doko> tfheen, infinity: the OOo build did fail again on amd64; please could you retrieve the preprocessed source of the failing file?
[01:26] <alex-weej> what is gparted being replaced with in the ubuntu installer?
[01:32] <givre> alex-weej: a brand new partitionner : https://wiki.ubuntu.com/Ubiquity/AdvancedPartitionerRewrite
[01:32] <alex-weej> is there a post-installation counterpart tool?
[01:35] <Burgwork> alex-weej: with parted directly
[01:35] <alex-weej> i'm just a little bit concerned
[01:36] <alex-weej> that having done all the setup in the nice fancy ubiquity wizard
[01:36] <alex-weej> users won't have a clue how to change any of the stuff they set up
[01:36] <Burgwork> right
[01:36] <Burgwork> most of the time, users have no need to changing any of the formatting they just did
[01:37] <alex-weej> right, but it would be beneficial to have SOME consistency with a general purpose tool
[01:37] <alex-weej> it's also things like choosing locale
[01:37] <alex-weej> the post-installation tool is completely different to the installation tool (last time i checked it was anyway)
[01:37] <alex-weej> or has this changed?
[01:37] <Burgwork> right, that is not parititioning
[01:38] <alex-weej> but it is the same issue
[01:38] <Burgwork> not really
[01:38] <alex-weej> ok
[01:38] <Burgwork> the ability to change stuff after install is done via the control centre
[02:55] <Chipzz> [knap] : the answer to that is really simple I guess: drivers from the nvidia site are not supported. if it break, you get to keep both pieces
[02:55] <Chipzz> and it *is* bound to break
[02:55] <Chipzz> in short: don't do it
[02:58] <Chipzz> which makes me wonder; has anyone bothered to contact nvidia to tell them we have our own drivers, and to ask them to change their instructions to refer to the ubuntu packages?
[02:58] <Chipzz> or would that be the wrong approach?
[03:40] <TheMuso> c
[03:41] <_ion> c++
[03:53] <tsmithe> python?
[03:55] <_ion> No, ruby.
[03:58] <bddebian> VB
[04:16] <LaserJock> Fortran!
[04:17] <_ion> INTERCAL!
[04:20] <jsgotangco> heh
[04:20] <LaserJock> ajmitch: offtopic?!? in here?
[04:21] <ajmitch> it never happens, right?
[04:23] <LaserJock> no way
[05:11] <Kano> hi, what could be the problem when lshal does not show volume and other info with a 2.6.20 kernel but works with 2.6.18? are there specific patches needed which are not in debian?
[05:53] <_ion> Ooo, look what the apt-get brought in: upstart 0.3.5
[05:54] <_ion> Although i've been using 0.3.5+bzr for a while already. :-)
[06:23] <bluefoxicy> hmm damn
[06:24] <bluefoxicy> my feisty generated no initrds
[06:46] <bluefoxicy> holy crap that was ugly.
[08:02] <ajmitch> hi pitti 
[08:02] <pitti> hi ajmitch
[08:05] <dholbach> good morning
[08:05] <dholbach> ogra: new gnome-power-manager for you
[08:06] <dholbach> ogra: new gnome-screensaver for you
[08:06] <dholbach> ogra: (and new dia for you) :-)
[08:06] <jsgotangco> wooo
[08:07] <pitti> dholbach: yay delegation :)
[08:07] <tfheen> BenC: what about the new lrm?  Just needs an ABI bump?
[08:07] <dholbach> pitti: he always did these - I'm just the messenger :)
[08:31] <ajmitch> pitti: doing source NEW today?
[08:31] <pitti> iwj: I filed a bug for this dpkg thing, btw (bug 84850)
[08:31] <Ubugtu> Malone bug 84850 in dpkg "does not interpret X[SBC] -* fields when building binary control files" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84850
[08:31] <pitti> ajmitch: no, not really; on Friday
[08:31] <ajmitch> ok
[08:33] <ajmitch> though ndesk-dbus will also need MIR as well
[08:33] <ajmitch> it's code shipped in main already, just not as a separate package
[08:33] <pitti> ajmitch: if it's a mere split out, it doesn't need a separate MIR
[08:33] <pitti> ajmitch: just add it to the Queue, saying from which package it was split out
[08:34] <ajmitch> heh
[08:34] <ajmitch> 'several'
[08:34] <ajmitch> I'll note that though, thanks
[09:26] <ajmitch> pitti: so I'll need to fix up any packages that have Maintainer: ajmitch@debian.org for it to build in the future?
[09:31] <pitti> ajmitch: don't worry, I just finished a script which will do the mass-upload transition
[09:31] <ajmitch> that's fine, it'll just make maintaining the source package a bit more annoying
[09:32] <pitti> right, we have to care for this delta
[09:41] <seb128> ogra: new gnome-screensaver and gnome-power-manager to package
[09:56] <sivang> morning
[09:58] <sivang> giftnudel: ping
[09:58] <giftnudel> hi sivang
[09:59] <sivang> giftnudel: oh, I see the topic got a bit upgraded since last time I'e been here :)
[09:59] <giftnudel> how are you?
[09:59] <sivang> let's continue in prvmsg since hubackup is not ubuntu development per se
[09:59] <giftnudel> ok
[09:59] <sivang> (e.g. specifically mentions not to talk about application development on ubuntu ;-))
[10:00] <giftnudel> oh, I see, that's also new to me
[10:00] <giftnudel> although hubackup is a spec, so that should still work
[10:00] <_ion> Not that i have anything to say in the matter, but if there's absolutely zero discussion going on about the development of Ubuntu, casual conversation probably doesn't hurt.
[10:01] <giftnudel> it would soon turn out into a discussion about hubackup, but still
[10:42] <tkamppeter> pitti, doko, can you check what happened with the uploads of the last versions of foomatic-db and foomatic-db-hpijs?
[10:43] <pitti> tkamppeter: ok, which version numbers?
[10:45] <ogra> seb128, thanks for the hint
[10:45] <seb128> np
[10:45] <tkamppeter> pitti, foomatic-db-20070207-0ubuntu2, foomatic-db-hpijs-20070207-0ubuntu1
[10:45] <seb128> ogra: would be nice to do them today so we have GNOME 2.17.91 for herd4 ;)
[10:45] <ogra> ok
[10:53] <tfheen> mvo: hiya, can you please do the GnomeAppInstallDesktopDatabaseUpdate process?
[10:58] <mvo> tfheen: I will do this now, thanks
[10:59] <seb128> tfheen: grraaa, main already frozen?!
[10:59] <seb128> tfheen: do we have exception fro GNOME 2.17.91? need like 3 extra hours to get it packaged
[11:00] <tfheen> seb128: yes, but since you're French, I'm fine with you uploading your gnomy bits.
[11:00] <tfheen> :-)
[11:00] <seb128> ah, good
[11:00] <tfheen> I just don't want random other crap in now.
[11:00] <seb128> ok
[11:00] <pitti> tfheen: we certainly want a new l-r-m for the ABI bump?
[11:00] <ajmitch> oh well, f-spot fixes can wait a week
[11:01] <tepsipakki> tfheen: so we shall push the xorg-bits post-herd4?
[11:01] <tfheen> tepsipakki: yes, that was my plan.
[11:01] <tepsipakki> yeah
[11:02] <tfheen> pitti: the one I accepted about an hour or so ago? :-)
[11:02] <ajmitch> tepsipakki: good work on getting them in shape
[11:02] <pitti> tfheen: erm, yes :) thanks
[11:02] <tepsipakki> debian has just uploaded libxcomposite, libxcursor, libxevie, libxdmcp to experimental, so it's getting easier all the time :)
[11:03] <tepsipakki> ajmitch: thanks!
[11:14] <cjwatson> pitti,iwj: and patch for bug 84850 attached
[11:14] <Ubugtu> Malone bug 84850 in dpkg "does not interpret X[SBC] -* fields when building binary control files" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84850
[11:14] <pitti> cjwatson: yay
[11:19] <ogra> pbuilder-satisfydepends is killing me :/
[11:19] <seb128> stop using pbuilder ;)
[11:20] <ajmitch> blame apt :)
[11:25] <fabbione> ogra: use sbuild.. it's much better
[11:27] <ogra> but thanks, i'll look into sbuild
[11:29] <seb128> ogra: I think that debian pkg-gnome guys use cowbuilder and they said it's much faster than pbuilder
[11:30] <ogra> ah, i'll look at that one as well ... even though, given the amount of pbuilder users in ubunt we should probably just fix it :)
[11:32] <ajmitch> ogra: apt-get --simulate takes a *long time* now, I can't recall the bug #
[11:32] <fabbione> ogra: well.. to be hounest.. given that sbuild is used on buildd.. i would prefer it compared to others
[11:32] <fabbione> and to some degrees is faster than pbuilder
[11:32] <ogra> i knoe mvo was working on something to fix that ...
[11:32] <ogra> *know
[11:36] <iwj> cjwatson, pitti: Nice and freaky bug that.  Thanks, Colin.
[11:51] <tkamppeter> pitti, can the packages foomatic-db-20070207-0ubuntu2 and  foomatic-db-hpijs-20070207-0ubuntu1 still go into Herd 4?
[11:52] <tfheen> tkamppeter: do they fix any bugs targetted for herd 4?
[11:52] <pitti> tkamppeter: foomatic-db is not in NEW, and new version does not exist on the archive; are you sure that they have been uploaded?
[11:53] <pitti> tkamppeter: (likewise for hpijs)
[11:54] <tkamppeter> pitti, I have asked you and doko to upload them last week and you told me that you will do so, as it was my intention to get them in before UVF.
[11:55] <pitti> tkamppeter: hm, I remember uploading some packages, but not foomatic-db
[11:55] <tkamppeter> tfheen, the two packages assure that there will be PPDs for all printers which are supported by HPLIP 1.7.1 which is our current HPLIP for Feisty.
[11:56] <Riddell> pitti: could you promote apport-qt to main when you have a free moment
[11:56] <pitti> tkamppeter: oh, in fact I did upload it
[11:56] <tfheen> Riddell: I did that last night.
[11:56] <pitti> tkamppeter: I wonder where that went to...
[11:56] <pitti> Riddell: how does it work under KDE so far?
[11:56] <tkamppeter> tfheen, the foomatic-db fixes also a bug of the 0ubuntu1 version with renaming of binary packages.
[11:56] <tfheen> tkamppeter: what are the bug numbers?
[11:57] <tkamppeter> tfheen, there are no bug numbers as I have found the problems by myself.
[11:57] <pitti> tkamppeter, tfheen: I'm pretty sure I uploaded it, but it has never arrived as it seems; hmm
[11:58] <Riddell> tfheen: oh, excellent, thanks.  can I upload a kubuntu-meta to include it?
[11:58] <tkamppeter> For the foomatic-db and the uploading I made a new package the same day, as soon as I discovered it.
[11:58] <tfheen> Riddell: please.
[11:58] <pitti> tfheen: the diff between ubuntu1 (in the archive) and ubuntu2 (mysteriously lost) is adding transition packages for the renamed packages
[11:58] <tfheen> tkamppeter: in the future, please do file bugs and get them targetted to the relevant milestone or the release if they are important.
[11:58] <tfheen> pitti: please reupload it and I'll review it.
[11:58] <ogra> pitti, no MIR review for my sound parts :/ i'd have loved to have them in herd4 
[11:59] <tfheen> tkamppeter: since I'm terrible at reading other people's thoughts it does not help me or the release that you know about a bug if you do not tell me about it.
[11:59] <Riddell> pitti: it works great, but still lacks the adept-notifier integration
[11:59] <pitti> Riddell: right
[12:00] <tkamppeter> tfheen, so in the future I will create a bug report along with the package submission.
[12:00] <pitti> tfheen, tkamppeter: reuploaded foomatic-db
[12:00] <tfheen> tkamppeter: yes, or rather when you discover the bug.
[12:00] <tfheen> pitti: cheers.
[12:00] <pitti> argh, I take that back; wrong source.changes
[12:02] <pitti> uploaded for real now
[12:02] <tfheen> pitti: heh. :-)
[12:08] <tkamppeter> pitti, thanks. Did you also upload foomatic-db-hpijs
[12:09] <pitti> tkamppeter: no, I never touched it (doko claimed it)
[12:09] <pitti> tkamppeter, tfheen: ^ shall I?
[12:09] <pitti> (I cannot test it at all, mind you)
[12:09] <pitti> but neither can doko, so *shrug*
[12:10] <doko> hm ...
[12:14] <tfheen> seb128: you'll tell me when you have all your new GNOME shiny in?
[12:14] <tfheen> pitti: please do
[12:14] <seb128> tfheen: yep, we are almost there, 3-4 tarballs left
[12:16] <ogra> tfheen, g-p-m woud be ready, ok to upload ? 
[12:16] <ogra> *would
[12:16] <tfheen> ogra: please.
[12:16] <pitti> tfheen, tkamppeter, doko: f-d-hpijs uploaded
[12:17] <ogra> thanks :)
[12:24] <seb128> pitti (and probably other people who asked for it): with the new gnome-menus/gnome-panel/control-center combo just uploaded you have the menus back, you just have to unmask them from the menu editor
[12:24] <seb128> enjoy ;)
[12:25] <pitti> ah, but we won't do that by default?
[12:25] <pitti> seb128: great, thanks!
[12:26] <seb128> pitti: not decided yet, but looks like it'll be shell by default which is better for standard users and the menus which are better for power user are a few click away to the menu editor
[12:26] <seb128> pitti: feel free to start a discussion on ubuntu-devel(-discuss) list if you think we should use menus by default
[12:28] <pitti> seb128: 'k
[12:28] <pitti> hi carlos 
[12:28] <jwendell> seb128, is there any way to use menus (a gconf key, for example)?
[12:28] <carlos> pitti: hey
[12:28] <seb128> jwendell: did you read what I wrote 10 lines ago?
[12:28] <jwendell> seb128, no hehe
[12:28] <seb128> jwendell: the "you just have to unmask them from the menu editor"
[12:29] <jwendell> seb128, so, i guess it should be like it's right now...
[12:30] <jwendell> seb128, advanced users who want menu back can do this step
[12:30] <seb128> right
[12:31] <tfheen> cjwatson: could I have a d-i upload synced with the -8 kernel ABI?
[12:32] <tkamppeter> pitti, thanks.
[12:35] <ogra> tfheen, gnome-screensaver ready as well ...
[12:36] <zakame> hmm did anyone experience their swapspace double due to devmapper readding to swapon?
[12:36] <ogra> tfheen, ok to upload ? 
[12:36] <tfheen> ogra: yes, please.
[12:37] <ogra> there we go
[12:46] <seb128> tfheen: if I want to sync libsoup on Debian (they packaged the new version for the new GNOME yesterday) should I open a bug first for the record or just syncing is fine?
[12:47] <tfheen> seb128: I've just synced such packages as myself in the past.
[12:48] <seb128> tfheen: ok, thanks
[12:50] <tfheen> fabbione: your ltp upload ftbfs.
[12:51] <fabbione> tfheen: doh!... 
[12:51] <fabbione> tfheen: ok.. i will look into it, but it's not fatal for herd4
[12:51] <tfheen> fabbione: no, not fatal, I just noticed it off the top of my mailbox
[12:51] <Chipzz> mvo_: ping?
[12:52] <StevenK> Directory debian/ltp-commands-test does not exist, aborting
[12:52] <StevenK> Hrrm
[12:53] <cjwatson> tfheen: sure
[12:54] <mvo> Chipzz: hello
[12:55] <tfheen> Riddell: adept seems to ftbfs.
[12:56] <fabbione> StevenK: strange because nothing did change what's built or installed..
[12:57] <cjwatson> tfheen: done
[12:57] <tfheen> doko: you're aware sun-java5 ftbfs on ppc and sparc?
[12:57] <tfheen> cjwatson: thanks
[12:58] <Riddell> how peculiar
[12:59] <doko> tfheen: yes =)
[01:00] <tfheen> doko: could you get it PaS-ed?
[01:00] <doko> tfheen: just don't try to build it
[01:01] <tfheen> doko: same build failure for ooo, btw.
[01:01] <tfheen> Hobbsee: tired?
[01:01] <Hobbsee> yup
[01:01] <Hobbsee> its' 11pm - dinner time
[01:02] <tfheen> Hobbsee: whenever you have the time, you touched kxgenerator last.  It fails to build now.
[01:03] <Hobbsee> tfheen: yes, i saw that, i think :(
[01:03] <Hobbsee> something else failed, too...
[01:03] <doko> tfheen, infinity: seen, and I asked for the preprocessed source file; the package just builds fine for me on two machines
[01:04] <tfheen> doko: hm, true.  You need infinity for that, I don't have access to it.
[01:04] <seb128> tfheen: I'm done with my GNOME updates, dholbach is still working on gnome-terminal and gnome-netstatus and slomo on tomboy and seahorse
[01:04] <dholbach> seb128: both uploaded
[01:04] <seb128> after that we should be set for herd4
[01:04] <seb128> ok
[01:04] <dholbach> i'll upload a new usplash-theme-ubuntu next
[01:04] <tfheen> seb128: ok, cheers.
[01:04] <tfheen> dholbach: woo.
[01:05] <seb128> ok, lunch time for me, bbl
[01:05] <slomo> seb128: seahorse is universe anyway, tomboy will be uploaded in < 10 minutes :)
[01:05] <tfheen> slomo: excellent! :-)
[01:07] <tfheen> seb128: I presume you're aware, but your beagle upload fails to build.
[01:08] <slomo> tfheen: i'll look at the beagle build failure after tomboy/seahorse
[01:08] <tfheen> slomo: cheers.
[01:09] <mjg59> pitti: Any chance you can enable macbookpro support in hal?
[01:09] <StevenK> tfheen: Anything you can throw at me?
[01:09] <pitti> mjg59: is that a patch from git head?
[01:09] <StevenK> Hrm, maybe I should re-phrase that... :-P
[01:09] <StevenK> Hobbsee: He's not my type. :-P
[01:10] <tfheen> StevenK: you want some build failures to grab?
[01:10] <slomo> pitti: while at it... https://bugs.freedesktop.org/show_bug.cgi?id=9343 might be of interest for you too :)
[01:10] <Ubugtu> Freedesktop bug 9343 in misc "hal-device-manager: [patch]  cosmetic issues with dbus-python 0.80" [Trivial,New]  
[01:10] <StevenK> tfheen: Yup
[01:10] <tfheen> StevenK: amarok.
[01:10] <Hobbsee> StevenK: apt-cache unmet.  get fixing :)
[01:10] <Hobbsee> eep, amarok ftbfs?
[01:11] <tfheen> yup, across all arches.
[01:12] <ogra> oh, CC meeting in the UTC afternoon ... thats new :)
[01:13] <Hobbsee> ogra: means the aussies can attend every once in a while
[01:13] <StevenK> tfheen: Aye
[01:13] <dholbach> tfheen, kwwii: uploaded
[01:13] <ogra> Hobbsee, :)
[01:14] <mjg59> pitti: No, it just needs enable-macbookpro rather than disable-macbookpro in rules
[01:14] <mjg59> Oh, and a build-dep on pciutils-dev
[01:14] <pitti> mjg59: ah, I see
[01:15] <pitti> mjg59: no problem; I leave convincing tfheen to you :)
[01:16] <ogra> mjg59, apparently the hal fdi change fixed the brightness key issue for a lot of people ... but it doesnt feel right somehow that we need this many overrides in hal 
[01:17] <ogra> mjg59, do you have any idea how we could avoid it more from the ground up than adding tons of matches to fdi files ? 
[01:17] <mjg59> ogra: Hardware behaves differently. fdi files exist to tell hal how the hardware behaves.
[01:17] <mjg59> It should only be two matches for the Thinkpads.
[01:18] <ogra> well, in the bug people with asus and toshiba laptops showed up with the same prob
[01:19] <slomo> tfheen: tomboy and seahorse uploaded
[01:19] <tfheen> slomo: tomboy already accepted.
[01:19] <mjg59> ogra: No, that's a different problem
[01:20] <ogra> ah, k
[01:20] <ogra> what about the thinkpads that dont know they are thinkpads ? 
[01:20] <mjg59> They lose
[01:20] <raphink> anybody aware of kernel panic with 2.6.15-28.51 on dapper?
[01:20] <ogra> heh
[01:20] <raphink> I guess I'll go tell that on #ubuntu-kernel rather
[01:20] <pitti> raphink: since latest security update? no
[01:21] <raphink> since 2 days ago pitti
[01:21] <raphink> my mom just got a kernel panic with it
[01:21] <pitti> raphink: ugh, regression
[01:21] <raphink> which blah
[01:21] <pitti> raphink: please file a bug and mark it security
[01:21] <raphink> so I'll go shout on #ubuntu-kernel
[01:21] <raphink> I don't have trace though
[01:21] <pitti> raphink: or that, thanks!
[01:21] <raphink> she's 1000km away
[01:21] <ogra> mjg59, well, there seem to be some with
[01:21] <ogra>  smbios.system.product = '236697U' (string)
[01:21] <ogra>   smbios.system.manufacturer = 'IBM' (string)
[01:21] <raphink> so I can't have her note everything she sees
[01:21] <ogra> or other numbers as the product name
[01:24] <ogra> tfheen, i have an updated edubuntu-artwork as well, ok to upload ? 
[01:25] <tfheen> ogra: sure
[01:25] <ogra> thanks :)
[01:37] <fabbione> pitti: ping?
[01:37] <pitti> hey fabbione 
[01:37] <fabbione> hey dude
[01:38] <fabbione> pitti: the ltp FTBFS is caused by pkg-create-dbgsym
[01:38] <fabbione> pitti: mind to take a look at it?
[01:38] <pitti> fabbione: of course not
[01:38] <tfheen> Riddell: do you want the new adept in for herd 4?
[01:38] <fabbione> you also want /bin/sh pointing to bash to build.. i am uploading a fix for that doesn't show up in the buildd
[01:38] <Riddell> tfheen: yeah, that would be nice
[01:40] <fabbione> tfheen: fixed ltp uploaded (universe).. it will still need pitti's love to build
[01:42] <tfheen> fabbione: cheers
[01:42] <slomo> tfheen: ok to upload beagle fix in some minutes?
[01:43] <tfheen> slomo: please.
[01:44] <ogra> tfheen, there is on fuse fix i'd like in herd4, ok to upload ? 
[01:45] <ogra> http://flomertens.keo.in/merge/debdiff_ubuntu1-ubuntu2 in case you want to look at it ...
[01:49] <tfheen> ogra: what's the reasoning for changing the udev priority?
[01:50] <ogra> tfheen, it was a leftover from a former version ... 80 is usersetup already, 45 is the system 
[01:51] <ogra> (in a former version te fusectl filesystem was also mounted from the udev rule, we now do that from a modprobe.d script)
[01:51] <tfheen> ogra: hm, ok.  Upload away.
[01:52] <ogra> somehow the 80-fuse file didnt get deleted ...
[01:52] <ogra> thanks
[02:13] <Riddell> StevenK: did you look into amarok fail to build?
[02:14] <StevenK> Riddell: Looking at it now
[02:14] <Riddell> StevenK: that .desktop file installed on my local build, I'm not sure what governs when it gets installed and when it doesn't
[02:15] <StevenK> Riddell: The last ten lines of debian/amarok.install don't start with debian/tmp
[02:15] <Riddell> ah, that would be it then
[02:16] <StevenK> I'll throw you a debdiff?
[02:16] <Riddell> please
[02:19] <ogra> tfheen, one last upload (apart from possible ltsp or edubuntu-meta changes for the CD), i needed to add a transitional package for student-control-panel to thin-client-manager ... ok to upload ? 
[02:19] <tfheen> ogra: go ahead.
[02:20] <ogra> thanks :) 
[02:20] <giftnudel> I now spent 2 hours trying to get some patch to configure and it always complained about AC_PROG_LIBTOOL being undefined - the solution was to actually install libtool ...
[02:29] <pitti> fabbione: 'k, I think I fixed ltp hard enough now
[02:30] <fabbione> pitti: ok thanks... you rock dude
[02:30] <pitti> fabbione: interesting package, btw
[02:35] <pitti> tkamppeter: do you think that you can get a basic source package for printerdriver-autodownload working for feisty?
[02:40] <cjwatson> pitti: (see my mails on the subject)
[02:41] <pitti> cjwatson: weird, I just have Till's reply
[02:41] <pitti> 08.02.07 20:42 Till Kamppeter    Printer driver autodownload - how to proceed?
[02:41] <pitti> cjwatson: ^ this thread?
[02:42] <cjwatson> yeah, I only sent it recently
[02:43] <pitti> ah, got them now
[02:44] <cjwatson> mvo: we were to talk about dist-upgrader autobuilding. When would be a good time?
[02:44] <cjwatson> mvo: and where can I check out the code you use to produce your dist-upgrader uploads at the moment?
[02:45] <mvo> cjwatson: whenever it is most convinient for you
[02:47] <Kagou> hi
[02:49] <ogra> givr1, the upload was overdue :)
[02:49] <ogra> thanks for the patch :)
[02:51] <cjwatson> mvo: is it in http://bazaar.launchpad.net/~mvo/update-manager/main ?
[02:52] <mvo> cjwatson: yes, under DistUpgrade/build-dist.sh
[02:52] <cjwatson> rather s/mvo/ubuntu-core-dev/
[02:53] <mvo>  sftp://mvo@bazaar.launchpad.net/%7Eubuntu-core-dev/update-manager/main/
[02:53] <mvo> yes
[02:53] <cjwatson> mvo: is there any reason not to just build it on every update-manager upload?
[02:55] <mvo> cjwatson: sure, we could do that. but its not a source-deb and it does not produce a binary deb but a tarball. if we can make soyuz to deal with that, that would be good
[02:55] <pitti> tfheen, fabbione: new ltp uploaded (fixes FTBFS, universe)
[02:56] <mvo> cjwatson: have you read my proposal about the special upgrader deb packages? it would be a alternative approch to the problem
[02:56] <cjwatson> mvo: so what I'm thinking is that the dist-upgrader tarball could just be another one of the objects spat out by the update-manager source package, along with its .deb(s)
[02:56] <cjwatson> mvo: there's a perfectly standard process for doing that kind of thing, which shouldn't need soyuz modifications
[02:56] <cjwatson> mvo: haven't read your proposal, no. Where is it?
[02:57] <mvo> cjwatson: https://wiki.ubuntu.com/UpdateManagerArchDependent
[02:59] <mvo> cjwatson: about building the tarbal on each update-manager source upload, that could certainly be done. the disadvantage is (AFAICS) that for selected backports (like a new apt) we would have to include it into that build-process as well. the alternative approach with using packages is more modual because we could update individal packages independantly for the upgrdaer
[03:01] <ogra> cjwatson, i stopped getting daily CD health check mails on saturday, is that intentional ? 
[03:03] <StevenK> Riddell: Right. Test build sucessful.
[03:03] <StevenK> Riddell: Debdiff is at http://wedontsleep.org/~steven/test/amarok_1.4.5-0ubuntu4.debdiff
[03:04] <Riddell> thanks
[03:08] <BenC> tfheen: I uploaded new lrm and linux-meta
[03:09] <BenC> tfheen: Everything looks built and ready
[03:11] <pitti> BenC: morning
[03:11] <tfheen> BenC: the "linux" package looks uninstallable on sparc, as does the linux-backports-modules packages.
[03:11] <BenC> pitti: Hey...-8 kernel should fix apport
[03:12] <BenC> tfheen: Let me check that real quick...at worst, I'll do another linux-meta upload
[03:12] <mvo> iwj: could you please have a look at bug #84894 when you have a bit of time? 
[03:12] <Ubugtu> Malone bug 84894 in devmapper "File overwrite problem" [High,Confirmed]  https://launchpad.net/bugs/84894
[03:12] <pitti> BenC: right, see my hugging and cheering from this morning
[03:12] <pitti> BenC: you rock, thanks!
[03:13] <BenC> pitti: Hehe, np..so you've tested it and it passes?
[03:13] <pitti> BenC: yep, and I uploaded another apport to reenable it again
[03:13] <pitti> BenC: I tested with several small and large core dumps
[03:13] <BenC> excellent
[03:13] <doko> tfheen: please allow python2.4 and python2.5 into the archive; the changes are in the -dbg packages only. allows us to continue with our work on the other -dbg packages
[03:13] <BenC> pitti: I'll push these changes upstream soon then
[03:13] <pitti> BenC: cool!
[03:18] <BenC> tfheen: I don't see what about linux should be uninstallable on sparc
[03:19] <tfheen> BenC: http://people.ubuntu.com/~cjwatson/testing/feisty_probs.html claims it is
[03:19] <tfheen> doko: doesn't look relevant for herd 4, so no, I won't let them in.
[03:19] <tfheen> Keybuk: did you notice upstart ftbfs on sparc?
[03:20] <Keybuk> tfheen: yeah, I got the spam about that
[03:20] <Keybuk> bloody toy architectures
[03:20] <ogra> its ftbfs as well ...
[03:20] <ogra> likewise on ia64
[03:20] <Keybuk> is just some signal names missing on sparc used in a table so it can say "killed by TERM signal" ... just needs an ifdef or two
[03:21] <tfheen> ogra: fix it? :-)
[03:21] <ogra> tfheen, well
[03:21] <ogra> gpm-light-sensor.c: In function 'gpm_light_sensor_get_hw':
[03:21] <ogra> gpm-light-sensor.c:114: warning: cast increases required alignment of target type
[03:21] <ogra> isnt really informative
[03:22] <tfheen> ogra: yes, and?  Force alignment, then?
[03:22] <ogra> grmbl, i was so happy that our gpm package is patch free now ...
[03:22] <BenC> tfheen: sparc lrm isn't NEW'd yet or something
[03:23] <BenC> it's built, but not available
[03:24] <tfheen> BenC: they ended up in failed-to-move; I'll rescue them
[03:25] <BenC> tfheen: And linux-backports-modules uploaded as well
[03:25] <BenC> should be instant builds
[03:27] <cjwatson> ogra: no, it's certainly still supposed to be sending them to you
[03:27] <tfheen> BenC: isn't l-b-m built from the regular source now?
[03:27] <ogra> cjwatson, hmm
[03:27] <BenC> tfheen: "regular source"?
[03:27] <cjwatson> mvo: would it be possible to split the dist-upgrader source out entirely from update-manager, then?
[03:28] <tfheen> BenC: l-s-2.6.20
[03:28] <BenC> tfheen: No, separate package
[03:28] <BenC> Need to add it to the list of ABI bump uploads
[03:31] <cjwatson> mvo: I think UpdateManagerArchDependent is kind of separate, really; in any case isn't it too late for that sort of major redesign for feisty now?
[03:31] <cjwatson> mvo: whereas a simple reorganisation of the source package to allow autobuilding would be quite easy and can certainly happen after feature freeze
[03:37] <seb128> ogra: any reason for hwdb-client to be a native Debian package?
[03:38] <ogra> seb128, not any particular oe apart from it not being used anywhere else than ubuntu systems
[03:38] <ogra> *one
[03:38] <seb128> ogra: usually when a package is Debian native the version has no revision though
[03:38] <seb128> hwdb-client_0.6-0ubuntu23.tar.gz is weird ;)
[03:39] <ogra> hmm
[03:39] <pitti> Keybuk: if you have a minute, could you please look at bug 76077 and my explanation in comment 5 and tell me whether this weird behaviour is actually a feature and not a bug?
[03:39] <Ubugtu> Malone bug 76077 in udev "Permissions on /dev/usblp* don't agree with cupsys" [High,Confirmed]  https://launchpad.net/bugs/76077
[03:39] <mvo> cjwatson: I agree that it is too late for feisty now for the UpdateManagerArchDependent spec. how would the re-orga work? is it enough if the source package spits out a .changes file and .tar.gz for the release-upgrader? is that enough to make it work? 
[03:40] <ogra> seb128, i guess its because my packaging skill were not really great when i started it ... its been like that since the beginning ...
[03:40] <Keybuk> (random: how do I tell dch now that I just want -1 to become -2 ?)
[03:41] <Keybuk> pitti: yeah, permissions don't seem right across the board in feisty
[03:41] <Keybuk> cdroms aren't showing up in the right group, etc.
[03:41] <pitti> Keybuk: also due to this rule?
[03:41] <ogra> seb128, i'll fix it after herd4, thanks for the pointer, i didnt even recognize
[03:42] <pitti> indeed, my CD-ROM is group 'floppy'
[03:42] <seb128> ogra: no hurry, I'm looking at it because hwdb has a menu item to applications, system tools and we are supposed to have that category not used by default for menu simplication
[03:42] <seb128> I'm looking on where to move it
[03:42] <Keybuk> pitti: I think it has something to do with the new toplogical sysfs model
[03:42] <Keybuk> some rule which never previously applied now applies
[03:43] <seb128> ogra: looks like pitti did that
[03:43] <ogra> seb128, yep
[03:43] <pitti> Keybuk: I meant, is it really right that ATTRS{idVendor}=="0000" matches *any* vendor ID?
[03:43] <pitti> seb128: hm?
[03:43] <ogra> seb128, i'm not keen to have it in control-center .... but thats my personal disliking of it sinc ethe change ...
[03:43] <pitti> ah, read scrollback now
[03:43] <seb128> pitti: could we put the hwdb menu item somewhere else that System Tools? you unmask the menu category we try to not use for MenuSimplication
[03:44] <Keybuk> pitti: define "any" -- that will match every idVendor from the device and all of its parents
[03:44] <ogra> so if it belongs there put it there ...
[03:44] <pitti> ogra, seb128: right, I wondered about hwdb-client being native as well, but I didn't change it when I touched it
[03:44] <ogra> well, native is fine ... just not with a -XubuntuX version :)
[03:44] <seb128> yeah, that was just a side note
[03:44] <pitti> Keybuk: ah, so something in the chain has idVendor=0000
[03:45] <Keybuk> pitti: perhaps
[03:45] <Keybuk> you probably want ATTR{} in those rules anyway
[03:45] <Keybuk> not ATTRS
[03:45] <pitti> Keybuk: thanks; seems we might actually want ATTR
[03:45] <pitti> heh
[03:45] <Keybuk> the "floppy" problem, I don't know about
[03:45] <pitti> seb128: I don't mind much where to put it
[03:45] <Keybuk> that might be a similar bug with the scsi checking bit
[03:46] <pitti> seb128: however, synaptic is also in that menu (apart from vmware)
[03:46] <seb128> ogra, pitti: is that something we want to run several time or once only?
[03:46] <seb128> pitti: yeah, I'm going to make mvo fix synaptic next :p
[03:46] <pitti> seb128: more or less just once, except if your hw changes
[03:46] <pitti> seb128: ah, I see :)
[03:46] <seb128> bah
[03:46] <seb128> that sucks to have a menu item for something that we run once
[03:47] <mvo> seb128: hu?
[03:47] <seb128> can't we have a notification area icon or something?
[03:47] <seb128> mvo: we try to get Applications, System Tools not listed by default for menu simplication
[03:47] <seb128> mvo: and you changing synaptic to be there apparently
[03:47] <seb128> changed
[03:47] <ogra> seb128, we hav a notification
[03:47] <ogra> telling you to click on the menu entry
[03:47] <seb128> ogra: why do we need a menu item then?
[03:47] <seb128> bah
[03:48] <seb128> any problem with having a notification area icon to click on?
[03:48] <mvo> seb128: erh, so some apps will not be displayed anymore at all?
[03:48] <ogra> it was specced like that 
[03:48] <seb128> mvo: ?
[03:48] <pitti> seb128: it's not what notifications are meant for
[03:48] <seb128> mvo: we used to have synaptic to system, administration
[03:48] <pitti> seb128: and the user might not want to go through this hassle as the very first thing he does with the computer
[03:48] <seb128> pitti: menu items are not meant for things that need to be runned once neither ;)
[03:48] <mvo> seb128: right and there is now this control-center that makes everything very hard to find IMHO
[03:49] <pitti> seb128: I have no problem with moving it to control-center, hardware section
[03:49] <seb128> mvo: could be try to adress that rather than having people doing random changes to workaround the problem?
[03:49] <seb128> pitti: that feel wrong if that's something you are likely to run once
[03:49] <seb128> it's going to be "in the way" and create extra confusion all the time
[03:49] <cjwatson> mvo: it would just be like the debian-installer binary .changes
[03:49] <mvo> seb128: fair enough, I was not aware that system tools should go away
[03:50] <seb128> mvo: we did that for dapper ;)
[03:50] <pitti> seb128: most of the settings in that control-center aren't run more often either
[03:50] <seb128> pitti: I disagree, most are config tools
[03:50] <pitti> right :)
[03:50] <cjwatson> mvo: you just do 'dpkg-distaddfile whatever.tar.gz dist-upgrader -' in debian/rules
[03:51] <pitti> how often do people change their screen resolution, language, or prefered fonts?
[03:51] <seb128> still, those are config dialog you might want to use
[03:51] <seb128> hwdb is of no use for an user
[03:51] <pitti> seb128: well, if that would be the case, then we should not install it at all
[03:51] <seb128> we install it because we want users to submit their config once
[03:52] <pitti> people who buy new hardware or plug in another USB devices might even want to submit it again, etc.
[03:52] <seb128> not because they need the tool to do something
[03:52] <mvo> cjwatson: interessting, thanks! I check this out next. what would be the scope? we certainly want to not include all the backports for kde in there? 
[03:52] <Riddell> mvo: oh, it doesn't need backports any more, I managed to get it to work with just a patch
[03:52] <Riddell> or 4
[03:52] <pitti> seb128: as I said, I don't mind moving it somewhere else or redesigning the notification etc. I just want a clear and signed-off instruction document that tells me what to do :)
[03:53] <mvo> Riddell: right, and those will go into -proposed?
[03:53] <Riddell> mvo: that's my plan
[03:53] <mvo> Riddell: cool! thanks
[03:53] <seb128> pitti: I'm going to move it to the hardware control-center category for now, I'm not happy with it though, I'll think about it
[03:53] <seb128> imho that should not be a menu item
[03:53] <pitti> seb128: btw, it's already there for me
[03:53] <seb128> maybe an option somewhere like popcon
[03:53] <seb128> pitti: weird, it's to applications, system tools on my box
[03:54] <pitti> oh, no, that thing is hal-device-manager
[03:54] <pitti> seb128: right, I thought it was *also* in c-c, but that's only h-d-m (which allows you to run hwdb-client)
[03:54] <mvo> I'm not very happy with the way the control-center looks currently. its just overwelming how many icons are in there
[03:54] <seb128> ah ah
[03:54] <seb128> h-d-m allow you to run it
[03:54] <seb128> -> NoDisplay=true for hwdb-client ;)
[03:54] <seb128> no need several way to do the same thing
[03:55] <seb128> and it's not used often enough to justify a separate menu item
[03:55] <pitti> seb128: right, we just need people to find it somehow
[03:56] <seb128> h-d-m looks good enoguh if you have a notify popup pointing users there
[03:58] <cjwatson> mvo: well, I was just thinking of reorganising the build process to be more like everything else in the archive, not a scope change at all
[03:59] <mvo> ok
[03:59] <ogra> seb128, eeek
[03:59] <seb128> ogra: what?
[04:00] <ogra> seb128, thats five clicks then instead of three
[04:00] <seb128> well
[04:00] <seb128> do you really things it makes sense to clutter the menu or shell all the time for something most users will run never or once?
[04:00] <ogra> you have to open control center (takes about a minute for me with a 4200 disk and lots of applets)
[04:00] <ogra> then you have to find h-d-m and click and wait another 15-20 secs 
[04:00] <Riddell> tfheen: new amarok upload which fixes fail to build, I'm good for herd with that in
[04:01] <seb128> we are trying to simply menus and shell to make them usable
[04:01] <ogra> *then* you can click hwdb and wait again
[04:01] <seb128> adding random item for things user need to run once is not the way to do that
[04:01] <ogra> latest at the second click you would hae lost me if i were a new user
[04:01] <seb128> yeah
[04:02] <mvo> c-c has (in the default install) ~50 entries
[04:02] <seb128> and as an user you would like to have that extra item in the way making your menu or shell longer and things harder to use?
[04:02] <ogra> i agree that it would be fine to have a start button for it in the popup
[04:02] <ogra> additionally with a hint where to find it in h-d-m 
[04:02] <ogra> in case i dont want to do it now 
[04:02] <seb128> ok, guys, stop focusing on the shell please
[04:03] <seb128> we have menus back with uploads from today (just unmask them with alacarte)
[04:03] <seb128> and we are likely to have menus by default for feisty
[04:03] <ogra> YAY 
[04:03] <seb128> so the question is not how slow the shell is to start
[04:03] <ogra> great decision
[04:03] <bddebian> Heya
[04:03] <seb128> try focusing on "do you think having that menu item is useful for an user"?
[04:04] <seb128> or is it going to make the menu longer and harder to use
[04:04] <seb128> for something users are likely to never look for out of the first time they are pointed to it?
[04:04] <ogra> well, without the shell the most slowing down factor is gone ...
[04:04] <seb128> (the shell remains available for those who want to use it BTW :p)
[04:04] <ogra> but a shortcut from the popup would still be nice though ... even if it breaks policy
[04:05] <ogra> does it have an extra menu entry ? 
[04:05] <seb128> what has an extra menu entry? the shell? it has a menu item yes
[04:05] <ogra> ah
[04:06] <seb128> pitti: do you have some notification atm the moment indication to use applications, system tools?
[04:07] <ogra> i think so ... there was a bug about it 
[04:07] <seb128> s/indication/or indication
[04:07] <seb128> ok
[04:07] <ogra> pitti fixed it to say the right path ...
[04:07] <seb128> so changing the menu item category would be wrong
[04:07] <seb128> something else needs to be updated according to that
[04:07] <ogra> not if we fix hwdb alongside
[04:07] <ogra> right
[04:08] <seb128> let's fix that after herd4 then
[04:08] <pitti> seb128: yes, in update-notifier
[04:08] <ogra> yep, i'll make a note to change it with the versioning scheme 
[04:08] <ogra> pitti, not in hwdb ? 
[04:08] <pitti> seb128: if we move the menu entry (or remove it), then we need to update the notification text; that's trivial, though
[04:09] <pitti> ogra: no, the notification is in update-notifier
[04:09] <seb128> pitti: that can wait after herd4
[04:09] <pitti> seb128: *nod*
[04:09] <ogra> ah
[04:09] <seb128> I'll probably note the hwdb item on the topics list for the meeting
[04:10] <pitti> seb128: right, thanks; it's changing a spec, so we should sign that off
[04:10] <seb128> np
[04:10] <seb128> mvo: the synaptic menu change can wait after herd4 as well probably ;)
[04:12] <mvo> seb128: ok
[04:17] <seb128> tfheen: could you approve the libxfont and control-center uploads for herd4?
[04:20] <mvo> tfheen: could you please approve update-manager? its a bugfix only upload
[04:21] <seb128> mvo: looks like the vte update fixed gnome-terminal ;)
[04:25] <mvo> seb128: ha! great
[04:44] <ogra> woah, is that still the CC meeting going on in -meeting ? O_o thats nearly 4h now ....
[04:45] <Keybuk> 4h?
[04:45] <Keybuk> wow
[04:45] <Keybuk> they're almost half way already
[04:46] <kylem> jeez.
[04:47] <ogra> heh
[04:49] <Keybuk> does anybody know what a type-punned pointer is?
[04:49] <Keybuk> or why dereferencing one would break strict-aliasing rules?
[04:50] <cjwatson> info gcc-4.1, ctrl-s type-pun
[04:51] <Keybuk> cjwatson: the thing I can't figure out, is that neither pointer is a union
[04:52] <dholbach> kwwii: uploaded
[04:55] <cjwatson> Keybuk: and there lies the problem
[04:55] <kwwii> dholbach: killer, thanks :-)
[04:56] <cjwatson> Keybuk: with -fstrict-aliasing you aren't allowed to access the same bit of memory through two differently-typed variables
[04:57] <Keybuk> not even if you cast them? :p
[04:57] <cjwatson> Keybuk: see C99 6.5(7)
[04:57] <cjwatson> no
[04:57] <cjwatson> it's not about type-checking, it's about optimisations, AIUI
[04:57] <Keybuk> pointer to struct, and pointer-to-first-member-of-struct are always supposed to be equivalent
[04:57] <Keybuk> in fact, they're required to be
[04:58] <Keybuk> isn't that important, since the warnings only coming up in test cases where I'm just stealing a random pointer and stuffing it in, on the basis that I know it's not used for anything :p
[04:59] <cjwatson> I'd need to do more reading to work that out, and I need to conduct an interview in one minute ;-)
[05:00] <Keybuk> heh, I have a copy of C99 here I can hit myself with if I feel so inclined
[05:02] <iwj> mvo: re bug 84894> oh how annoying.  Fixing it.
[05:02] <Ubugtu> Malone bug 84894 in devmapper "File overwrite problem" [High,Confirmed]  https://launchpad.net/bugs/84894
[05:04] <mvo> iwj: great, thanks!
[05:05] <Keybuk> tfheen: may I upload new upstart to correct sparc ftbfs
[05:11] <janimo> gpocentek: hi
[05:13] <janimo> could any of the source NEW reviewers take a look at hal-cups-utils please? thanks
[05:13] <pitti> janimo: next archive day is tomorrow
[05:14] <janimo> pitti: ok thanks. I wasn;t aware of the new schedule
[05:14] <janimo> at least to me it's new :)
[05:15] <pitti> tfheen: ok to upload http://pastebin.ca/353789? It fixes two easy, but very important bugs in libgphoto
[05:15] <pitti> tfheen: one ruins device permissions of *all* usb devices
[05:20] <iwj> mvo: Fix uploaded I think.
[05:25] <mvo> iwj: nice, thanks. I will verify by re-runing the test tonight or tomorrrow
[05:27] <tkamppeter_> pitti, a small detail is still needed for the renamed packages of foomatic-db to work: ubuntu-desktop needs now to depend on openprinting-ppds instead of linuxprinting.org-ppds. Can you (or someone with appropriate rights) change this? Thanks.
[05:31] <pitti> tkamppeter_: can do
[05:37] <pitti> ogra: I merged above change (and some previous ubuntu seed changes which look ok) into the edubuntu seeds, no conflicts; ok for me to commit or do you want to merge yourself?
[05:38] <pitti> ogra: the only questionable thing IMHO is the addition of espeak
[05:41] <pitti> gpocentek: here?
[05:43] <ogra> pitti, if there were no conflicts its fine ...
[05:43] <ogra> just go ahead
[05:43] <pitti> ogra: thanks; done
[05:44] <pitti> gpocentek: can you please merge the Ubuntu seed changes to xubuntu? it's nontrivial, so I didn't want to screw up
[05:46] <pitti> tkamppeter_: seeds changed (except for xubuntu); this requires another -meta upload, but I think that's not important for herd-4
[05:48] <pitti> tfheen: libgphoto2 tentatively uploaded, since I really recommend those fixes; please feel free to lart me and reject the upload if necessary
[05:50] <pitti> mjg59: do you think we need to push the hal change for macbook into herd-4?
[05:51] <tfheen> Keybuk: how invasive?
[05:52] <tfheen> pitti: ok, looks relativetly sane to me.
[05:52] <pitti> tfheen: justification for the patch is in the bug, if you are interested
[05:53] <Keybuk> tfheen: http://rafb.net/p/xGvxOh87.html
[05:55] <tfheen> Keybuk: go ahead.
[05:55] <tfheen> pitti: ok, accepted.
[05:55] <pitti> tfheen: merci
[05:55] <pitti> mjg59: hal FTBFSes with --with-macbookpro ((.text+0x4c3): undefined reference to `gzopen')
[05:56] <Keybuk> tfheen: thanks, done
[05:56] <pitti> mjg59: looks like a bug in pcutils-dev (since a function from that lib wants gzopen())
[06:05] <Keybuk> wow, if I reboot my mail server, I can't keep reading the mailbox
[06:05] <Keybuk> who'd've thought?
[06:10] <ivoks> strange strage MTA :)
[06:40] <geser> pitti: if you are interested I've modified pkgmaintainermangler to work on source packages. The modified script is at http://members.ping.de/~mb/srcmaintainermangler/
[06:43] <Keybuk> seb128: so, err
[06:43] <Keybuk> I updated my laptop
[06:43] <Keybuk> and rebooted
[06:43] <Keybuk> and have no GNOME session
[06:44] <BenC> cjwatson: There's no eject command in the CD's initrd...is there some other way to eject CD's that I don't know about?
[06:44] <BenC> cjwatson: This is the desktop CD
[06:45] <Keybuk> seb128: might not be your fault, hang on
[06:49] <mvo> tfheen: if you could approve update-manager 0.57.2 that would rock. its a one-line fix
[06:57] <tkamppeter__> pitti, thanks for updating the seeds, but I have still a little problem:
[06:58] <cjwatson> BenC: you can't really eject the desktop CD except from break=top :-)
[06:58] <tkamppeter__> If I do a general update also the update of linuxprinting.org-ppds-extra is held back though it does not have a dependency in ubuntu-desktop
[06:58] <cjwatson> BenC: powerpc?
[06:58] <BenC> cjwatson: No, I need to eject the CD so people can load the driver CD :)
[06:58] <cjwatson> oh
[06:58] <BenC> from casper-premount
[06:59] <cjwatson> BenC: depend on eject and have casper's hook script copy it in
[06:59] <BenC> Ok
[07:00] <tkamppeter__> pitti, I have Replaces:, Provides:, and Conflicts: lporg... in the openprinting packages and in addition the transient lporg packages, is this correct?
[07:01] <BenC> cjwatson: Should I do any sanity checks after they re-insert the install media to make sure it's the right CD?
[07:01] <BenC> and if so, what's the best check
[07:02] <cjwatson> BenC: hmm, maybe remember the contents of /cdrom/.disk/info
[07:03] <cjwatson> it's not exactly a UUID but it should be a pretty good signature for this purpose
[07:03] <BenC> cjwatson: Is /dev/cdrom valid at this point?
[07:04] <BenC> or should I check mtab to see what the cdrom device is
[07:04] <tsmithe> PriceChild, mmhmm?
[07:04] <cjwatson> BenC: casper doesn't use /dev/cdrom
[07:04] <tsmithe> he wants a mailing list and doesn't know where to ask
[07:04] <cjwatson> BenC: see find_livefs in scripts/casper
[07:05] <cjwatson> it iterates through devices and tries to guess which one to use
[07:05] <cjwatson> maybe make it remember which one it used and use the same one again
[07:06] <pitti> tkamppeter__: that should be fine
[07:08] <BenC> cjwatson: So what device would I use for ejecting, mounting, and checking for driver-updates?
[07:08] <BenC> cjwatson: I'll look around in there...maybe it does store the sys2dev
[07:09] <cjwatson> shouldn't be too hard to make it store it
[07:09] <sladen> it's an optical drive, there are the ioctl()s for the disk-id
[07:10] <sladen> however that might make testing harder if you're using a disk-image to test
[07:10] <cjwatson> which casper already does. no need to reinvent the wheel
[07:10] <cjwatson> (it uses /lib/udev/cdrom_id)
[07:10] <PriceChild> I'm sorry I haven't a clue where else to ask this, but how would I go about requesting the creation of a mailing list?
[07:11] <BenC> cjwatson: cdrom_id might be a good way to check for the install media being re-inserted
[07:11] <cjwatson> PriceChild: rt@admin.canonical.com
[07:11] <PriceChild> Thanks cjwatson :)
[07:11] <cjwatson> BenC: cdrom_id just gives you the capabilities of the drive
[07:11] <alex-weej> does anyone have any idea how i can debug/get more info on this? https://bugs.launchpad.net/ubuntu/+source/hal/+bug/83842
[07:11] <Ubugtu> Malone bug 83842 in hal "Sound devices not detected by HAL after upgrade to Feisty" [Undecided,Unconfirmed]  
[07:12] <cjwatson> doesn't tell you anything useful about the disk
[07:12] <BenC> ah, thought it was some if for the media
[07:12] <BenC> *id
[07:16] <seb128> Keybuk: GNOME b0rkage?
[07:17] <Keybuk> seb128: no
[07:17] <Keybuk> iwj's udev update restored the udev init script which I'd deleted
[07:17] <tkamppeter__> pitti, can you test then whether your system updates smoothly, as soon as the new ubuntu-desktop is on your mirror?
[07:17] <Keybuk> so I had udev being run twice => bad /dev/null permissions
[07:17] <seb128> Keybuk: ok, cool
[07:18] <BenC> cjwatson: livefs_root isn't run before casper-premount
[07:19] <BenC> Guess I'll have to reimplement find_livefs() as a find_driver_updates()
[07:21] <iwj> Keybuk: Err, did I do something wrong ?
[07:22] <iwj> Also,
[07:22] <iwj> python--
[07:22] <iwj> Why does  x += 3  count as a binding of x and make the function fail with an UnboundLocalVariable error ?
[07:22] <Keybuk> iwj: not at all, update-rc.d did something wrong as usual
[07:22] <iwj> OIC
[07:23] <iwj> And why is there no way of saying `I want "x" to refer to the "x" in the enclosing scope' ?
[07:24] <iwj> You can only say `global' which is not the same thing at all.
[07:43] <BenC> cjwatson: I have a question about the ubiquity-driver-updates spec. It mentions search for drivers in ubuntu/, but that seems to conflict with our own CD's
[07:43] <BenC> cjwatson: Should I change that to ubuntu-drivers/ ?
[07:54] <cjwatson> BenC: oh, right, maybe livefs_root needs to be refactored yes
[07:54] <cjwatson> BenC: hmm, I'd forgotten about the ubuntu symlink on our CDs. Yes, pick something reasonable and short that doesn't clash
[07:56] <BenC> cjwatson: I'm actually thinking about expanding it a little, so that the script only checkes ubuntu-drivers/<kver-abi>/
[07:56] <BenC> no reason to load what might be a ton of the same package for different versions of the kernel
[07:57] <BenC> cjwatson: How safe is it to assume that the installer kernel version (not flavour) is the same as the installed kernel?
[07:58] <BenC> Then I also need to account for architecture
[08:00] <cjwatson> BenC: in the desktop CD, you can assume that they're the same
[08:00] <BenC> Is there an easy way to get the dpkg arch from initrd?
[08:01] <BenC> cjwatson: I'll have to assume it everywhere or copy all of ubuntu-drivers/*/*_<arch>.deb
[08:08] <cjwatson> BenC: yeah, just assume it I think
[08:09] <cjwatson> BenC: oh, hmm, what if they provide multiple versions and expect those to be used on upgrade?
[08:09] <cjwatson> BenC: maybe *_<arch>.deb *should* be copied to the installed system ...
[08:10] <cjwatson> BenC: the architecture is DPKG_ARCH in the environment, within the initramfs
[08:17] <BenC> cjwatson: Ok, thanks
[08:18] <BenC> cjwatson: Would make sense, since the new packages might be needed for known security update
[08:18] <cjwatson> right
[08:19] <BenC> cjwatson: how about ubuntu-drivers/<kver>/*_<arch>.deb, where kver would be something like 2.6.20 (no ABI or flavour)?
[08:21] <gpocentek> pitti: xubuntu seeds updated, but not shown on LP yet
[08:21] <gpocentek> gpocentek: sorry for the delay
[08:21] <gpocentek> err
[08:21] <gpocentek> pitti: sorry for the delay ^^
[08:22] <pitti> gpocentek: thank you! no need to excuse :)
[08:22] <cjwatson> BenC: while you mentioned security updates, I was actually thinking of feisty -> feisty+1 upgrades ...
[08:23] <cjwatson> BenC: the other option would be to save a Packages file and arrange for an apt-cdrom-style entry to appear in sources.list, but I'm a bit worried about designing that on the fly
[08:24] <cjwatson> BenC: are the drivers really going to be all that huge?
[08:24] <BenC> cjwatson: I'm a little worried about the potential size that ubuntu-drivers/*/*_<arch>.deb might become
[08:29] <cjwatson> BenC: if you think <kver> is the best compromise, that's OK by me
[08:40] <chezz99> hello
[08:43] <cjwatson> tfheen: you might want to give-back debian-installer where it failed
[08:44] <cjwatson> tfheen: hmm, or not, possibly
[08:46] <cjwatson> BenC: could you please make storage-core-modules Provides: loop-modules?
[08:46] <BenC> cjwatson: Sure thing
[08:47] <cjwatson> no idea why this only just started breaking now
[08:47] <BenC> cjwatson: In git
[08:48] <cjwatson> thanks
[08:53] <Kano> hi, where is  splitconf.pl ?
[08:54] <BenC> Kano: The script for the kernel configs?
[08:55] <Kano> yes
[08:55] <Kano> i want another config, but how to split
[08:55] <BenC> It's in the tarball for linux-source-*
[08:55] <BenC> or in git
[08:55] <Kano> no it is not
[08:55] <Kano> pulled git
[08:56] <BenC> Yes, it is
[08:56] <BenC> debian/bin/splitconfig.pl
[08:56] <Kano> but not under ubuntu-2.6
[08:56] <BenC> yes, it is
[08:56] <cjwatson> it really is, I pulled the git tree a couple of hours ago and I see it
[08:56] <Kano> hmm then find must be stupid..
[08:56] <cjwatson> what find invocation did you use?
[08:56] <BenC> you mispelled it :)
[08:56] <Kano> ubuntu-2.6# find -name splitconf.pl
[08:56] <BenC> it's splitconfig.pl not splitconf.pl
[08:56] <cjwatson> splitconf != splitconfig
[08:57] <Kano> # Common config options automatically generated by splitconf.pl
[08:57] <Kano> so who is stupid...
[08:57] <cjwatson> nobody used the word "stupid" except you. kindly stop.
[08:58] <BenC> Kano: Direct further questions to the ubuntu wiki, KernelTeam entry
[08:59] <cjwatson> tfheen: please accept iso-scan 1.18ubuntu1 and give-back debian-installer once that's built and in the archive
[09:02] <Kano> BenC: splitconf(ig).pl search has no result
[09:02] <BenC> Kano: ls -l debian/bin/splitconfig.pl
[09:02] <Kano> yes but how to use it
[09:02] <BenC> you don't use it directly
[09:02] <BenC> if you really want to, read debian/rules
[09:02] <BenC> that's where it gets used
[09:02] <Kano> but i have a new generic full config
[09:03] <Kano> i want to try all pata drivers and no old ide code
[09:03] <BenC> actually it gets used in debian/bin/oldconfig
[09:03] <Kano> as even a pure sata system got a hdx device
[09:04] <BenC> Kano: pure sata wont have a hdX device...it's not possible
[09:04] <BenC> Kano: Most likely you have your sata controller in legacy/compatible mode
[09:05] <Kano> i think the currect selection of drivers is really suboptimal
[09:05] <BenC> that's a nice baseless statement
[09:06] <BenC> considering we've tuned that driver list based on past releases and suggestions by upstream kernel, I wonder where you come up with that
[09:06] <Kano> when cdroms stop working and even normal boot required irqpool cheat then it is not really optimal
[09:07] <BenC> that has nothing to do with drivers
[09:07] <BenC> well, the irqpoll option doesn't
[09:07] <BenC> that's most likely a broken driver, a broken BIOS on your system, or a crappy device
[09:08] <wasabi> Or a wonderful combination of all three. =)
[09:08] <BenC> Kano: Either way, file bug reports...compiling your own kernel for PATA vs. IDE wont help you with those issues, nor will it allow us to fix the problem
[09:10] <Kano> BenC: well i have to compile the kernel because i want to use it with etch
[09:10] <BenC> Kano: Uh, you're compiling an Ubuntu kernel to use on Debian?
[09:11] <Kano> yes, and i found out that that required a patch to hal, maybe because of some different config or so
[09:11] <BenC> No, it required a patch to hal because upstream changed things
[09:11] <BenC> it's Not ubuntu specific
[09:11] <Kano> i added patch 58 or so
[09:11] <wasabi> Debian's HAL/Kernel is just older.
[09:11] <zakame> did anyone experience something similar to bug #84668?
[09:11] <Ubugtu> Malone bug 84668 in devmapper "adds misleading double entry to swapon" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84668
[09:11] <Kano> sysfs something
[09:12] <Kano> 2.6.20 with differnet config settings does not require that change but have no idea what option it is
[09:12] <BenC> Kano: well, if you're mixing your system with ubuntu source + self compiled kernels + debian userspace with self compiled binaries, then I'm afraid I can't help you much anymore
[09:13] <BenC> you're creating way more problems than I intend to help overcome
[09:13] <wasabi> Yes, what part of this is Ubuntu anymore, anyways?
[09:13] <Kano> BenC: to make me work with ubuntu let mc work correctly, but this tool is not always able to change dirs there
[09:14] <BenC> Kano: I suggest you rm -rf debian/ in the ubuntu-2.6 git and just use make-kpkg
[09:14] <Kano> hmm would be possible
[09:15] <Kano> btw. ubuntu -6 kernel was not able to build with pbuilder/etch
[09:20] <siretart> iwj: I'm currently trying to follow your instructions, but with the massive debug output, I'm unable to reproduce the behavior :(
[09:21] <iwj> siretart: Hmmm.
[09:21] <siretart> iwj: I do notice however that it becomes quite likely that one or more raid devices become degraded, so I have to add the 'missing' disc by hand
[09:21] <iwj> The degraded thing is fixed in ubuntu4.
[09:21] <siretart> currently I need to wait ~20min to get the device synced
[09:21] <siretart> iwj: this IS with ubuntu4
[09:21] <iwj> Really ?  That's odd.
[09:21] <iwj> Very odd.
[09:22] <iwj> Because I added --no-degraded so it oughtn't to do that at all.
[09:22] <siretart> currently fscking, will recheck soon
[09:22] <siretart> iwj: the funny thing is: I returned home earlier, and I did succeed to but with ubuntu3 that very one time
[09:23] <siretart> without interaction that is
[09:23] <Kano> BenC: btw. i do not use any ubuntu entry in debian. i look for specific patches only
[09:23] <ajmitch> siretart: what behaviour were you trying to reproduce?
[09:24] <siretart> ajmitch: bug 75681
[09:24] <iwj> ajmitch: Failure to start md devices properly.
[09:24] <Ubugtu> Malone bug 75681 in lvm2 "initramfs script: race condition between sata and md" [Undecided,Unconfirmed]  https://launchpad.net/bugs/75681
[09:24] <ajmitch> hm, looks familiar
[09:24] <iwj> siretart: You have something different because with yours some of them aren't arriving at all.
[09:24] <siretart> ajmitch: yeah, actually you pointed me to that one ;)
[09:25] <iwj> succeed that very one time> It's a race, so you're not guaranteed to lose.
[09:25] <siretart> iwj: as said before, I have both stripes and mirrors, and lvm on top of the stripe
[09:25] <iwj> Urrr.
[09:25] <siretart> actually, 2 vgs, with the root lv on the vg on the stripe
[09:25] <iwj> I haven't done anything that would cause that, I think.
[09:25] <iwj> And I don't understand how your lvm things aren't working either.
[09:28] <iwj> Without the udev debug output it's very hard to debug these races.
[09:28] <iwj> And I'm really perplexed as to what's calling mdadm without --no-degraded or whether it's starting them degraded anyway.
[09:28] <siretart> I'd love to give you the debug output, and I'd love to give it another try, but I need to wait ~20min for the raid device to be resynced right now :/
[09:28] <iwj> Right.
[09:29] <iwj> I'm afraid it's about time for my dinner here; if you manage to get some useful info I'll be around again tomorrow.
[09:29] <siretart> k, have a nice evening!
[09:29] <cjwatson> tfheen: targeted https://launchpad.net/ubuntu/+source/ubiquity/+bug/84597 at herd-4, FYI; I'll sort it out tomorrow
[09:29] <Ubugtu> Malone bug 84597 in ubiquity "[apport]  ubiquity crashed with AssertionError in subst()" [Undecided,Confirmed]  
[09:29] <iwj> siretart: Goodnight and good luck ...
[09:42] <tfheen> cjwatson: thanks; looking at iso-scan now, will give-back d-i afterwards.
[10:22] <seb128> evince used to Depends on "gs-esp | gs"
[10:22] <seb128> now it needs gs-esp-x
[10:22] <seb128> "gs-esp-x | gs" doesn't work because "gs-esp" provides "gs" by example
[10:23] <tfheen> seb128: gs-esp-x | gs (>= 0)
[10:23] <seb128> would you consider that as a gs-esp bug that should not provide gs? or a new "gs-x" should be used?
[10:23] <seb128> or evince Depends gs-esp-x?
[10:23] <seb128> tfheen: gs (>=0) ?
[10:24] <seb128> Provides are not versionned and gs-esp (non-x) Provides gs ...
[10:24] <tfheen> seb128: correct, but if you have a versioned depends, you depend on the real gs.
[10:25] <seb128> well, "gs-esp | gs" was gs-esp or anything else providing "gs" no?
[10:25] <seb128> like gs-gpl
[10:25] <tfheen> ah, ok
[10:26] <tfheen> make something like gs-x, then
[10:26] <seb128> right
[10:26] <seb128> I'll make evince Depends on "gs-esp-x" without the "|gs" for herd4
[10:27] <seb128> or we will have no gs-esp-x since it's not seeded and nothing else depends on it
[10:27] <seb128> tfheen: looks fine to you?
[10:28] <tfheen> hn
[10:28] <tfheen> hm
[10:28] <tfheen> so you need a main promotion too?
[10:28] <seb128> hum?
[10:28] <seb128> gs-esp-x is a new binary split for gs-esp
[10:28] <seb128> and kubuntu-desktop seeded it
[10:28] <seb128> so it should be fine
[10:28] <tfheen> ahkay
[10:31] <visik7> hi
[10:31] <BenC> tfheen: Did you do the herd4 release notes?
[10:32] <BenC> tfheen: If not, who could I forward an email to in order to get something added to it?
[10:32] <tfheen> BenC: no, ubuntu-marketing traditionally does them.
[10:32] <visik7> which memory subdivision use ubuntu kernel generic 1/3 3/1 2/2 or 4/4 ?
[10:32] <tfheen> BenC: you can just edit the wiki page; /FeistyFawn/Herd4
[10:32] <BenC> visik7: stock
[10:32] <BenC> tfheen: what about http://www.ubuntu.com/testing/herd4 ?
[10:32] <visik7> stock means 3/1 ?
[10:32] <kylem> none of the above.
[10:32] <kylem> we use HIGHMEM_4G...
[10:33] <tfheen> BenC: it'll be moved there eventually.
[10:33] <kylem> well, i guess 4/4 is what you mean.
[10:42] <Nafallo> tfheen: hi! have anyone asked for a gnome-terminal give-back on amd64, ppc, ia64 and sparc?
[10:44] <tfheen> Nafallo: given-back
[10:45] <Nafallo> tfheen: thanks
[11:02] <visik7> mmm seems 1/3
[11:05] <cyberix> Aaargh. Feisty has a "Control Center".
[11:06] <cyberix> It hurts me so much, I feel my soul burn
[11:06] <kylem> haha.
[11:07] <cyberix> Using a menu is soooo much easier than using a separate window that looks complicated.
[11:07] <cyberix> Is this an upstream evil from gnome?
[11:07] <kylem> indeed.
[11:07] <ogra> cyberix, the menu should be back with the most recent version
[11:08] <cyberix> Thank god
[11:08] <ogra> yeah
[11:08] <ogra> there will be a control center menuitem though ... 
[11:08] <ogra> so people can still have it
[11:09] <cyberix> I feel having the items in two places may be confusing.
[11:09] <cyberix> But it is a _LOT_ better than having just a control center
[11:09] <ogra> yep
[11:10] <ogra> its a compromise
[11:10] <seb128> it's all about choice
[11:10] <seb128> the fact that you don't like something doesn't make it bad
[11:10] <seb128> some other people like it
[11:10] <ogra> rigth
[11:10] <ogra> its a totally personal preference
[11:10] <seb128> having the choice between menus or shell is a quite good solution
[11:11] <ogra> yup
[11:11] <cyberix> "I like _____ a lot because Microsoft made me like it!"
[11:12] <seb128> cyberix: those users exist and there is no reason to denigrate them
[11:21] <elmo> lamont: ping
[11:21] <lamont> elmo: ack
[11:21] <elmo> lamont: could/why doesn't bind do the ssh style stop+restart in postinst?
[11:22] <elmo> bind being down for long  periods of time over a dist-upgrade makes me cry
[11:22] <lamont> sigh.  it used to do that.  /me checks yet again to rationalize things one more time
[11:22] <lamont> elmo: 9.3?
[11:22] <elmo> lamont: whatever's in edgy
[11:23] <lamont> 9.3 then
[11:24] <lamont> elmo: ah.. 'twas dropped in going from bind 8 to bind 9
[11:24] <lamont> sigh
[11:24] <lamont> for the moment, I won't upload that to etch, though
[11:25] <kylem> god. beep-media-player is horribly broken.
[11:26] <elmo> lamont: fair enough, feisty/unstable would be nice tho ;-)
[11:26] <Guardian> hello
[11:26] <Guardian> i tried to boot the feisty herd3 cd
[11:26] <Guardian> check for cd defects reports no error
[11:26] <Guardian> right after keyboard detection, it loads modules then hangs
[11:26] <Guardian> is there anything useful i can report and how ?
[11:27] <lamont> elmo: bind 9.3.4 is waiting a few more days to snap from unstable to etch, is the reason
[11:32] <elmo> does evince have horrific kerning for everyone or am I special?
[11:32] <elmo> actually, specifically, anything exported as a PDF from abiword or OO in ubuntu, has horrific kerning when viewed in evince
[11:39] <lamont> elmo: I switched back to xpdf about 2 seconds into evince-hell.  I'll consider switching back in a year or 2
[11:39] <elmo> yeah, but dude, you're still using whatever the precursor to twm was :-P
[11:52] <tormod> tepsipakki: I am running xorg 7.2 now, on a laptop with ATI Radeon X700. Great, all seems to run fine!