#ubuntu-devel 2005-04-18
<whiprush> we'll take pics. And the person who packaged the most stuff for hoary gets to do shots. Poor metallikop. :(
<mdz> hmm, no edit or login button with that fancy wiki skin
<ogra> whiprush, lucky dholbach 
<mako> mdz: they're overrated
<ogra> ;)
<whiprush> well, he won't be near me so he gets off this time.
<dholbach> ogra: gm?
* Kamion goes to add sabdfl's party
<T-Bone> hmm, so it's either north america or germany? ;^P
<ogra> dholbach, <whiprush> we'll take pics. And the person who packaged the most stuff for hoary gets to do shots. Poor metallikop. :( <ogra> whiprush, lucky dholbach 
<dholbach> ha... will be seb128 ;-)
<ogra> dholbach, i guess youre getting near that :)
<mvo> how long does it roughly take for the cdimages? I wonder if I should wait and test or go to bed :)
<mdz> Kamion: just don't clobber my change :-P
<dholbach> if anyone has a package he likes to be fixed (in universe) please head to wiki/UniverseLastMinuteFixes
* mako puts his picture on his wiki page
<mako> hmm.. luis isn't around.. i used his picture
<Kamion> mdz: avoided, I think
<azeem_> dholbach: hmm, sbuild 0.35 didn't get merged?
<Kamion> dholbach: NRW == Nordrheinwestfalen?
<ogra> Kamion, yup
<mvo> Kamion: yes
<dholbach> Kamion: yes!
<Kamion> just curious, wondering if my obsolete German geography memory still worked
<dholbach> Kamion: i'm impressed
<dholbach> *arg* why doesnt the wiki like me... :-/
* T-Bone pesters against kde
<Kamion> lamont_r: are new live rootfses ready?
<mvo> dholbach: it just don't like anyone
<lamont_r> doh. yes
<lamont_r> last check ppc was compressing, but it's done new
<Kamion> lamont_r: building, then
<lamont_r> now even
<lamont_r> kde-i18n, otoh, is _NOT_ done _YET_
<mvo> is the hoary-install-i386 ready? it looks like there is a new 20050406.2 dir?
<lamont_r> mvo: there's something new there in the last 20 min or so
<Kamion> mvo: yes
<Kamion> sorry, yeah, install CDs done, please sync/test
<mvo> doing that now
<Kamion> lamont_r: it's gonna be a long night here in UTC+0100
<lamont_r> Kamion: yeah, but this way we get 20050407 CD's.. :-)
<Kamion> oh, that reminds me, better disable the cron jobs
<lamont_r> you want livecd's turned off too?
<azeem_> mako: "vicotory"?
<Kamion> lamont_r: yeah, let's make it all manual-only from now on
<Kamion> all CD cron jobs disabled
<Amaranth> yay for a buggy PyXDG!
<Amaranth> submenus come out all fscked up :/
<mako> azeem_: hmm. good point
<mkedwards> lamont_r: would now be a good time to ask again about the livecd construction script?  :)
<mdz> rsyncing
<mkedwards> livecd ready to rsync?
<mdz> not yet
<lamont_r> mdz: it's working it's way through process, I believe.... 
<mdz> only install at this time
<mdz> lamont_r: kde-i18n?
* lamont_r points mdz at his email from monday ish, once he's bored
<lamont_r> mdz: up to kfilereplace
<mdz> lamont_r: that'll be next week
<lamont_r> mdz: yeah, I figured as much
<mdz> lamont_r: please trigger kubuntu cloop builds once it's ready
<mdz> x3
<lamont_r> yeah
<lamont_r> we're past where we died last time, I keep checking it...
<lamont_r> is actually tail'ing in the other window
<mako> alright.. i'll be back in a little bit.. that list of parties better be good to go ;)
* azeem_ adds a proposal for Munich
<azeem_> (btw I head Arrogance will attend a party in .ca)
<azeem_> heard, even
<CarlK> If I don't get to say so later, Good Job to you all
<azeem_> CarlK: are you going to update? :)
<CarlK> azeem_, I wold love to, but my ISP  went bonkers a few hours ago
<Arrogance> azeem_, but it won't be the same without you
<CarlK> azeem_, I am sitting at Champs Bar-n-grill ;)
<CarlK> so if anyone wants to pop over, Beers on me
<CarlK> but the bat is low.. so off I go
<Kamion> live CD builds done
<mvo> Kamion: install is runing and according to fdisk I have a partition marked as "bootable"
<Kamion> mdz: want DVD builds? I imagine Kubuntu will be a while yet
<mdz> Kamion: sure
<mdz> Kamion: I talked with sabdfl about DVD; I think we have enough time to do a test cycle, but if something is wrong with them, I don't think we'll have time for a second
<mdz> they're just too bloody big
<Kamion> yeah :( I've started builds
<jdub> morning
<dholbach> hey jdub 
<ogra> hi jdub 
<tseng> hi jdub
<mvo> hey jdub 
<seb128> hey hey jdub :)
<mdz> amd64 booting stage 2
<mdz> Kamion: confirmed it has an active partition this time
<lamont_r> jdub: where's my april calendar>?
<jdub> lamont_r: i'm waiting for the disappearing artist trick to finish, and it may just have
<lamont_r> I see
<mdz> jdub: cliff returned my call earlier today, said he hadn't any messages from you
<jdub> he's on IM atm
<lamont_r> jdub: what's this I hear about thirsty camels in australia terrorizing toilets?
<jdub> but i've mailed numerous times recently
<mdz> install-amd64 success
<Kamion> still waiting for freaking *last* round of live CDs to rsync so I can grab this round of install/live. sigh.
<mkedwards> ouch.  ipw2100 blew up on me.  didn't realize hoary's ipw2100 is from December.
<mdz> live-amd64 successful
<mkedwards> mdz: does that mean livecds are ready to rsync?
<mdz> mkedwards: <Kamion> live CD builds done
<mdz> (yes)
<mkedwards> mdz: must have been while I was disconnected due to dead ipw2100.
<mkedwards> mdz: thx
<mdz> lamont_r: kde-i18n status?
<Kamion> mdz: see #kubuntu-devel
<Kamion> haggai is reverting
<mdz> that thing doesn't even have any code in it; why does it take ages to build?
<mdz> GAH
<Kamion> because it has a gazillion files
<Kamion> last time I built it (years ago, for a Debian NMU) it took three hours just to clean
<Kamion> slow machine admittedly ...
<haggai> but the number of langs has gone up since then..
<mdz> Kamion: is it too late to ask for the released filenames to be ubuntu-5.04 rather than ubuntu-hoary?
<mkedwards> regenerates all locales after every language pack addition/removal?  ouch!
<ska> "Ubuntu CD detected - [Automatically upgrade] " - cool!
<Kamion> mdz: you mean 5.04-* rather than hoary-*?
<mdz> Kamion: well, ubuntu-5.04-* rather than hoary-*
<Kamion> meh
<mdz> and kubuntu-5.04-* rather than kubuntu-hoary-*
<Kamion> no, not too late
<Kamion> that's a publish-release thing
<mdz> I know, I just meant in terms of your state of mind and time availability ;-)
<mdz> apparently you have some time to kill waiting for rsync :-/
<Kamion> it doesn't have to be done until tomorrow anyway :)
<haggai> lamont_r: reverted kde-i18n uploaded
<Kamion> mdz: done (basically, pending baz commit etc.)
<mdz> haggai: this one comes with a money-back guarantee, right?
<mdz> live-i386 is good
<haggai> mdz: well if this one breaks it proves it must be an SEP
<haggai> ..somebody..elses..problem..
<lamont_r> mdz: anything before I take the 10 minute drive home?
<mkedwards> what flags should I be using on rsync again?
<mkedwards> just -avP?
<mdz> that'll do
<mkedwards> mdz: thx
* lamont_r heads home with isos to test.
<Kamion> mkedwards: -avP's what I use too
<mkedwards> more than a little bit faster this time.  :)
<ogra_live> mdz, amd64 live is fine here
<mdz> install-powerpc success
<milli> ...lamont_r really leaves milli's house
<diego> i don't mind trying out the current daily livecd if someone is willing to tell me where to get it
<mdz> diego: http://cdimage.ubuntu.com/daily-live/current/
<diego> mdz: ty
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | No more uploads to hoary/main without approval AND a damn good reason (ask mdz or Kamion) | Test the current daily live+install CDs - THIS MEANS YOU: http://cdimage.ubuntu.com/daily/current/ http://cdimage.ubuntu.com/daily-live/current/
<Keybuk> meh
<doko> copying the packages from the installer CD to the disk makes the CD seek all the time, just slow ... defect CD?
<Keybuk> I hate it when you step back and admire some fantastically elegant code
<Keybuk> and trip over the huge flaw in it :'(
<smurfix> Keybuk: your own code? ;-)
<Keybuk> smurfix: of course
<mdz> dholbach is a build-depends machine
<ogra_live> yeah
<mdz> lamont: is kde-i18n building, or do I need to kick something?
<Kamion> doko: archive-copier already tries to get all the directory entries into cache first; I've got to the point of ignoring complaints about it unless they come with a full analysis, I'm afraid :(
<Kamion> DVD builds done
<dholbach> mdz: are those easiest to fix in the 246972469246246 broken packages :-)
<Kamion> should anyone have bandwidth
<dholbach> mdz: and for hoary we have to act FAST :-)
<mdz> I will grab them as soon as my i386 install is finished
<mdz> dholbach: indeed we do
<mdz> Kamion: are the bandwidth gods still frowning on you?
<Kamion> ./hoary-install-amd64.iso
<Kamion>    123925512  19%    9.11MB/s    0:00:54
<jdub> bizarre, i'm still getting this bad header stuff
<mdz> Kamion: so you got the first set and are updating now?
<Kamion> mdz: yes
<mdz> oh, good
<Kamion> rsync is now chewing all my disk bandwidth rather than all my network bandwidth ;)
<jdub> although now it's happening intermittently
<mdz> jdub: use FTP
<jdub> serious bongtasm
<seb128_> Kamion, mdz: the i386 install works fine now :)
<Kamion> seb128_: *phew*
<jdub> mdz: mmm
<mdz> Kamion++
<Kamion> as I said to mdz, I know how to fix that both ways round for breezy
<Kamion> it's just a non-trivial grub-installer patch => not hoary
<seb128_> does reverting this change break other configs ?
<Kamion> seb128_: yes
<seb128_> :(
<Kamion> seb128_: but the same bug existed in warty
<seb128> k
<Kamion> so I'm relatively unbothered about keeping it
<mdz> ubuntu boots fine, and windows boot is easily recoverable
<Kamion> and it can be fixed by a simple fdisk procedure, which we can document
<mdz> (when that bug exhibits itself)
* lamont arrives home
<jdub> haggai: (nice xine change :)
<seb128> yeah, much better than the bootloader not starting :)
<diego> (yay for ipw2200)
<Kamion> seb128: I'm not sure why I didn't immediately twig that your boot problem was due to that - I should've done :(
<mdz> new driver versions will flow like water after the release, worry not
<lamont> mdz: source needs to make it into w-b (and probably the archive) before it will start building...
<mdz> lamont: which bit triggers that?
<lamont> cron.daily'
<mdz> lamont: kicked
* lamont hopes it finishes before :33 or that there's locking there...
<seb128> Kamion: bah, don't worry, that's fixed now which is what matter :)
<Kamion> lamont: doesn't seem to be locking, but it should finish before :33 I think ...
<mdz> lamont: elmo lockified it
<mdz> install-i386 success
<mdz> that's 6/6 for me
<mdz> time to fetch DVDs
<Kamion> lamont: btw, any chance you could kill /usr/doc/util-linux and /usr/doc/util-linux-locales at some point?
<lamont> kill?
<Kamion> the symlinks aren't needed any more
<Kamion> per most other packages
<Kamion> hmm, except the package doesn't seem to create them any more, odd
<Kamion> maybe some old prerm forgot to remove them
<lamont> could be
<lamont> will deal with it sometime soonish
<lamont> you want it for sarge, or just sometime>?
<Kamion> no hurry, I just happened to be looking at the junk still in /usr/doc
<Kamion> it's not essential for sarge; the transition is loose in that respect
<lamont> ok.  I'll at least wait for 2.12p-4 to make it into sarge, or not.  then do the change
<diego> what's all this talk about sarge?
<lamont> diego: kamion wants a bug fix, I was trying to figure out timing...
<Kamion> in a channel with developers who happen to work on multiple projects, sometimes there is crossover talk
<lamont> clearly OT for this channel, of course.
<diego> ah ok
* Kamion sets the craptop's clock back to 1990 to test the apt-cdrom fix
<Kamion> is the OOo web composer thingy not meant to be in the menus any more?
<lamont> gah fire call
<jdub> Kamion: yeha
<seb128> 'night guys
<ogra> night seb128 
<jdub> night seb128 
* mvo goes to sleep now too, i386 is finally finished here too
<mdz> Kamion: with luck, I will be able to complete a DVD test cycle before I go to sleep
<Kamion> w00t
<Kamion> jdub: was that "yes, it's not" or "yes, it is"? :)
<Kamion> go English, it's your birthday
<jdub> heh
<jdub> "yes/no, it is intended to not be in the menu"
<jdub> ;)
<Kamion> ok :-)
<jdub> (you can use the 'from template' dialogue to start new documents with the weird OOo sub-bits)
* Kamion does an amd64 server install in Romanian for the sheer hell of it
<ogra> heh
<doko> 12 english locales created on a non-english install.
<diego> is OOo2 going to stay in hoary?
<Kamion> yes, English locales are always created by request of mdz
<jdub> diego: it's in universe as a TECHNOLOGY PREVIEW
<jdub> ;-)
<diego> jdub: cool :)
<jdub> i had hoped we'd get beagle in universe as a TECHNOLOGY PREVIEW too, but the mono/beagle dudes keep moving the goalposts
<diego> yeah i was hoping that too...why does mono require so much work?
<dholbach> jdub: and hula as TECHNOLOGY PREVIEW
<dholbach> if someone would review it
<thom> hula as MAIL LOSS PREVIEW ;-)
<jdub> dholbach: it's not in yet is it-- oh
<jdub> thom: hey hey!
<jdub> thom: so dcamp was just talking about mod_hula instead of their own internal one
<ogra> dholbach, i'll do...together with fast-user and kreciepes
<dholbach> we have so many GOOD packages awaiting reviews *cry*
<jdub> thom: for the web site
<jdub> thom: which sounds like a great move
<dholbach> ogra: tritium will be delighted to hear
<jdub> thom: but prefork will bite them
<Kamion> mdz: installation on a clock-warped machine works fine, apart from warnings from gpg and tar about stuff happening in the future
<tritium> dholbach, ogra :)
<ogra> dholbach, i promised i'll do before release
<Kamion> it's unpacking the second stage now
<thom> mod_hula would be cool; i take it there's lots of thready madness if prefork would bite them?
<Kamion> the stem of "boot" in Romanian is apparently "porn"
<jdub> diego: beagle doesn't work with our current 1.0.5 version, mono 1.0.6 has some problems that would affect other mono programs, we can't feasibly upgrade to 1.1.x (which would be ideal) just yet
<Kamion> or similar
<thom> jdub: more useful would be lmtp support :-)
<jdub> thom: connection pooling to hula server, etc.
<jdub> thom: yes!
<jdub> thom: that is what i am going to love campd with soon
<jdub> thom: unfort, he is like ba baracus, so he won't be coming to the wedding
<diego> jdub: yay for incompatibility i suppose
<jdub> thom: so we can't get him drunk and convince him that easily
<thom> jdub: hahaha
<Lathiat> haha
<jdub> but man
<jdub> hula with postfix and apache doing the rough stuff
<jdub> mmm-mmm~
<jdub> !
* doko imagines dholbach doing a hulu dance in udu instead of hoary
<thom> jdub: this is the way it should be
<dholbach> doko: i'll do both dances :-)
<thom> fabio jeff and mdz doing the warty dance in hula costume!
<dholbach> doko: with you on the table and jdub will take pictures - how does that sound?
<jdub> thom: mm, 'cos then it's only about as unattractive as, say, cyrus
<thom> pluggable imap servers would be nice too; all i really want is non-sucky webmail and calendaring
<jdub> then you'd have to have standardised mail storage -> :o
<jdub> i wonder how abstract the storage stuff is, whether it's modularised at all
<thom> MailStorageProposal!
<jdub> ...
<doko> hmm, anyone else sees english texts in the gnome panel, when a german locale is selected?
<thom> uh, or whatever that wiki page is called
<jdub> scott and i have already resolved to bridge the divide between our MTA disagreement and nuke that as heavily as possible
<doko> the menu entries are german, but I still see "Applications", "Places", "System"
<Keybuk> jdub: indeed, you suck; I'm right :)
<jdub> Keybuk: stfu :-)
<ogra> doko, its fine here....and was fine on my livecd test 1/2 h ago
<Keybuk> <g>
<thom> the divide between useful MTAs and qmail!
<jdub> Keybuk: how do we begin without saying, "my major objection to this proposal is that it creates a lot of work without having any benefit to anyone or any use case"?
<haggai> looks like kde-i18n made it at last
<Riddell> jdub: you much of a fan of "Wolverhampton based extreme nu wave metal bands"?
<Kamion> *splutter*
<Kamion> anything that starts "Wolverhampton based" cannot be that good
<Clint> not even the curry?
<thom> anything that mentions nu wave metal is on a hiding to nothing too, really :-)
<thom> the combination is just doomed :-)
<jdub> Riddell: this doesn't have anything to do with jono bacon does it?
<Keybuk> yeah, shame the Luftwaffe only got as far as Coventry, really
<jdub> haha
<doko> Keybuk: don't mention the war ;-)
<mdz> Kamion: good news, thanks
<mdz> anyone here who is not doing installation+live testing, please begin, kthx
<mdz> those of you with DVD burners and some hope of being able to download a DVD ISO in less than 24 hours, please do
* jdub writes of himself and his countrymen :|
* doko should stop testing greek installations
<Kamion> I will attempt to grab a DVD once the machine with the DVD burner has stopped doing installation testing
<diego> how big are the dvd isos? my livecd is just finished as i was typing this
<jdub> kamion laughed last month when i asked about rsyncing against the linux magazine dvd ;)
<doko> mdz: grabbed 61%
<milli> lamont: is there a current DVD ISO on mirror.mmjgroup.com?
<Kamion> clock-warped German i386 install finished successfully
<dholbach> mdz: downloading
* Keybuk wonders whether the cd writer will play nice today
* milli notices lamont went on a fire call
<doko> mdz, kamion: are the xhosa strings a good reason for another OOo upload? as an alternative I can put them in a separate source package and just copy the generated files to the binary image.
<Kamion> doko: another OOo upload requires another set of CD builds; I'd rather not do that if not absolutely necessary
<doko> Kamion: ok
<doko> Kamion: so a separate oo-l10n-xh source package is approved?
<Riddell> anyone get an e-mail from Manning Publications Co?
<ogra> Riddell, yup
<Kamion> doko: it's ok by me but it's enough of a hack that I'd like mdz to ok it too
<Kamion> it does mean that two source packages build the same binary, which kind of sucks
<mdz> Kamion: that requires elmo approval
<Kamion> 'k
<mdz> I expect it would need to be versioned to supersede any oo.o security  updates
<doko> yes, but wouldn't that need require that OOo doesn't build the xh package for security updates anymore?
<Kamion> live startup: cardmgr complains "cat: /var/lib/misc/pcmcia-scheme: No such file or directory"
<Kamion> apparently cosmetic
<Riddell> kde-i18n is in the archive now
<Riddell> should the ISOs be generated?
<Kamion> will do
<diego|food> i'll test out that livecd when i get back
<ska-fan> Kamion: now os-prober didnt detect my fedora installs at all
<Kamion> ska-fan: bummer. please mail /var/log/installer/*, menu.lst from Fedora, and menu.lst from new Ubuntu install to cjwatson@ubuntu.com
<mdz> lamont: kubuntu cloops?
<Kamion> mdz: they're building
<mdz> ok
<elmo> eww
<elmo> god damn all this last minuteness sucks
<ska-fan> Kamion: are you cjwatson?
<Kamion> ska-fan: yes
<ska-fan> ok
<Kamion> ska-fan: I cannot promise to fix anything before Breezy now
<Kamion> live-i386, live-amd64 ok
<mdz> doko: for breezy we should split all l10n away from the oo.o source
<ska-fan> how many hours are still left? :)
<Kamion> ska-fan: about 30
<mdz> ska-fan: yeah, about 30
<doko> mdz: nice "exercise" :-(
<Kamion> but the fewer of those used up by rebuilding images, the better
<Kamion> dholbach: doesn't libmysqlclient12 have a different licence from libmysqlclient10?
<elmo> doko/mdz/kamion: you can do the two binaries thing if you want; it doesn't break anything except when oo.o gets uploaded for security without being fixed not to build the duplicated package
<Kamion> dholbach: I thought I remembered the older libmysqlclient being used quite deliberately in Debian
<elmo> it's horrible tho
<mdz> elmo,doko: let's worry about it after the release
<doko> mdz: let's worry about what?
<mdz> doko: oo.o-l10n-xh
<mdz> doko: it's a hoary-updates candidate
<dholbach> Kamion: erm... license? erm 
<doko> mdz: ok, that sounds fine, and I can merge more translations from Adi.
<dholbach> Kamion: 50 use mysqlclient12, 60 use mysqlclient10
<mdz> Kamion: yes, I remember the same
<Kamion> dholbach: as in, much of libmysqlclient12 is GPL, whereas libmysqlclient10 is (AFAICT) just LGPL; thus libmysqlclient12 is more restrictive
<mdz> it was a licensing thing
<Kamion> dholbach: you guys have already transitioned a lot of stuff to libmysqlclient12
<dholbach> Kamion: we do?
<Kamion> I'm wondering if anyone actually checked the legality of that, or if it was just "hey, newer version"
<elmo> hmm the X keyboard mappings are wrong on my powerbook
<dholbach> Kamion: don't remember that much mysql-stuff
<crimsun> I never touched libmysqlclient12
<crimsun> I left stuff with 10
<Kamion> hm, maybe not
<dholbach> Kamion: i'll revert qtstalker then
<Kamion> ok, sorry, I think I'm misremembering, phew
<Kamion> well, check its licence, I haven't :)
<dholbach> Kamion: thanks for the "heads up"
<Kamion> GPL might be ok
<mdz> elmo: that is such a week ago sort of bug
<Kamion> I believe that libmysqlclient12 now has an OpenSSL licence exception, which was most of the problem
<elmo> mdz: dude, I didn't _have_ my powerbook a week ago
<mdz> elmo: details
<elmo> little exploding logic board issue sort of renders my testing schedule beyond my control
<Kamion> elmo: wuss
<jdub> elmo: it's all sorted now?
<mdz> doesn't someone else here have a powerbook?
<jdub> mdz: all gone
<Kamion> yeah, and I don't remember noticing a problem ...
<doko> mdz: I do, but the german keyboard layout in X is consistently broken
<elmo> kamion: \ | is in the wrong place
<mdz> doko: ...
<Kamion> elmo: hmm. wrong with respect to what's on the keys, or wrong with respect to what PC keymap <-> brain mapping expects?
<doko> elmo: even for UK keyboard?
<elmo> kamion: former
<elmo> kamion: key marked tilde and back tick is giving me | and \
<Kamion> elmo: in that case that's probably the uk vs. mac-usb-uk thing which I reported to smurfix multiple times
<elmo> and key marked |\ gives me ~#
<ska-fan> Kamion: It's out
<Kamion> but I configure my own keymap to be more like PC British anyway, so I tend not to notice :)
<ska-fan> Kamion: do you need fdisk -l?
<elmo> jdub: yep, all good, and they didn't try to charge me in the end
<Kamion> ska-fan: shouldn't think so
<Kamion> ska-fan: thanks, will check tomorrow
<elmo> kamion: I tend to xmodmap-ize to hell too, I only noticed 'cos this is an hours old install
<ska-fan> ok. good night then, and good luck :)
<mdz> Kamion: 1:13:40 for hoary-dvd-amd64.iso from concatenated install+live, not too bad
<lamont> mdz: back from fire call
<lamont> did you burn kubuntu cloops, or still need those?
<mdz> they're on the way
<lamont> ok
<lamont> sorry - was stupid call.  Well, minor anwya
<elmo> what's our default dselect-a-like?  and does it do dselect-style install-standard-by-default too?
<milli> lamont: is there a current DVD ISO on mirror.mmjgroup.com?
<lamont> milli: no
<lamont> ENOSPC
<lamont> milli: wanna download one for us?
<Kamion> elmo: aptitude, and I don't think so
<milli> lamont: not a problem... I can put kids in bed while I wait
<Kamion> elmo: though depends what you mean by "default", dselect's still there and does install-standard-by-default still
<milli> lamont:  on CDimage?
<milli> no...  URI please?
<lamont> milli: it won't fit on mirror...
<lamont> ah.
<elmo> kamion: I should fix our priorities then
<milli> lamont:  I have space elsewhere
<lamont> cdimage.ubuntu.com::cdimage/weekly-dvd/current/hoary.....
* lamont can't remember the last component
<Kamion> that's out of date
<lamont> are there torrents for the dvds?
<lamont> Kamion: figures
<lamont> Kamion: ubuntu?
<milli> lamont: torrents, yes, I see them
<Kamion> there are torrents, but autotorrenting doesn't seem to be working, unless thom/elmo fixed that
<lamont> (yet another since the apt/ubunt-docs burn?)
<Kamion> so they may not actually be usable
<Kamion> http://cdimage.ubuntu.com/dvd/current/hoary-dvd-i386.iso
<lamont> or just the dvd's aren't current
<Kamion> they should be current, I built them after that rebuild
<lamont> ah, yes.  http better
<mdz> dvd-amd64 live successful
<adobbie> why not assemble images using jigdo?
<lamont> Kamion: so there hasn't been yet another rebuild since 0200 or so your time?
<Kamion> lamont: no
<lamont> woot
<lamont> and the md5sums match too :-)
<zul> heylo
<mdz> Kamion: according to thom, elmo can get torrents going at any time by triggering it manually
<mdz> it's apparently just the restart which isn't working properly
<Kamion> adobbie: DVDs aren't jigdoed at the moment - it takes too damn long
<adobbie> I made the two DVD sarge set in 70min :)
<adobbie> doesn't take very long imho
<elmo> mdz: uh?
<adobbie> but jigdo didn't use multiple mirrors for me
<adobbie> that would have doubled the speed had it done concurrent across several sources
<Kamion> adobbie: I suspect you mean to reconstruct at your end, not to generate on the server
<milli> lamont:  Good to go with  http://cdimage.ubuntu.com/dvd/current/hoary-dvd-i386.iso then?
<adobbie> yes that's what I meant
<Kamion> adobbie: I'm talking about the latter, and it takes too damn long
<mdz> adobbie: it takes too long to generate the .jigdo files
<Kamion> adobbie: unless you're using JTE, which we aren't yet
<adobbie> Kamion: too long is how long?
<lamont> milli: I think so
<Kamion> adobbie: it takes an hour just for our four CDs
<milli> lamont:  It would be a 2.7Gig mistake if not
<adobbie> Kamion: yeah, that's a pretty long time
<lamont> Kamion said he rebuild them.. I think that means they're good
<Kamion> adobbie: I haven't even dared to try for DVDs
<Kamion> adobbie: hopefully for Breezy we'll switch to JTE, but until then, no
<milli> lamont: or a 4.5 hour mistake taken another way
<lamont> milli: and a $1 coaster
<Kamion> milli: yes, that's the right URL
<milli> lamont: k, starting
<adobbie> $0.25 coaster :)
<lamont> btw, everyone, milli is the neighbor with the bandwidth...
* milli enjoys a T1-sized pipe all to himself
<Kamion> milli: you're providing a valuable service to our development team, indirectly :)
* milli except when Lamont is over here
<milli> :)
<mdz> GAH
<mdz> hoary-dvd-amd64 install failed
<mdz> package-cache-names segfault
<Kamion> uh?
<Kamion> I guess I'll grab that one first, then :(
<Kamion> you sure you're current? check archive-copier version please
<mdz> Kamion: doing so
<lamont> so how do I boot with 8-bit color?
<mdz> Kamion: 0.1.4
<mdz> (current)
<Kamion> mdz: sigh
<daniels> lamont: why do you want to?
<lamont> really need a new monitor for the test box
<lamont> daniels: because the poor thing can only do 680x400 or whatever the last one is, at 24-bit
<ogra> hey, hwdb.ubuntu.com just got its 5000th submission ...
<daniels> wow
<lamont> daniels: it claims to be a "Video Graphics Color Display" :-)
<daniels> lamont: yes, and I've seen many video cards that claim to be 'good'
<mdz> ogra: nice
<lamont> yeah
<ogra> :-D
* Kamion extracts the Packages files
<mdz> Kamion: can we pad the Packages file with a newline or something to work around the bug? ;-)
<lamont> daniels: curiosity aroused, I see that it was manufactured in June of 1990.  were you even born yet? :-)
<daniels> lamont: hah, watch it (for the record, yes)
<lamont> heh
<elmo> Kamion: did you move files around in the torrent view of cdimage ata ll?
<lamont> daniels: I think I bought that with the 386 that I got right after I got married...
<Kamion> elmo: yes, separated install and live out to make it easier to avoid clobbering in publish-release
<Kamion> in some places anyway
<elmo> Kamion: when was this?
<Kamion> Disconnecting: Timeout, server not responding.
<Kamion> royal finished at Thu Apr  7 02:24:03 BST 2005
<Kamion> lamont: ?
<Kamion> elmo: around RC
<lamont> Kamion: yes?
* lamont checks royal
<mdz> Kamion: the last package-cache-names bug only exhibited itself on amd64, right?
<lamont> Kamion: Fontconfig error: Cannot load default config file
<Kamion> mdz: by pure chance
<lamont> that's the closest thing to any error, and it's in all of them.
<Kamion> mdz: I can reproduce this one on powerpc by copying the Packages files
<mdz> I suppose it's worth finishing the download anyway
<Kamion> mdz: and I'm currently debugging
<lamont> Kamion: anything more before I see what my wife wants me to do now?
<mdz> Kamion: DVD for i386-only, if it happens to work, would not be an unreasonable strategy at this point
<Kamion> lamont: so is royal's cloop up to date?
<Kamion> lamont: oh, crap, I switched from wireless to wired on the laptop; that'd do it
<milli> lamont: no luck getting transfer of hoary-dvd-i386.iso to start.. it hangs
<infinity> lamont : That's purely cosmetic.  If Debian's fontconfig maintainer doesn't do it, I'll shut up fontconfig's "my postinst hasn't run yet, help!" whining for breezy.
<lamont> Kamion: royal's kubuntu cloop is current
<lamont> ubuntu is also current, albeit from hours ago
<milli> infinity:  beware of fontconfig 2.3.1, it turned my fonts ugly on me (sid box) because of <dir> changes in /etc/fonts/fonts.conf
<diego> well i'm testing the livecd. everything looks pretty good except the scroll buttons on my synaptics touchpad are not working (they are acting like left-clicks)
<Robot101> milli: see my blog :)
<Robot101> milli: I fixed that shizzle
<diego> would anyone care about this issue at this point?
<milli> Robot101: It had me in a tizzy for half a day.  It was a MAJOR annoyance.
<milli> diego: I have synaptics on this Stinkpad T40, so I would care.  ;-)
<diego> milli: who should i be talking to about this?
<diego> good thing i can "install" packages on the livecd. what would i do without cowsay? :)
<milli> diego: per 'apt-cache show'...Maintainer: Mattia Dongili (ma.d.) <dongili@supereva.it>
<diego> milli, should i e-mail him or is he here?
<Kamion> mdz: looks like sticking two extra newlines on the end of restricted/binary-*/Packages* would do it - but God, how ugly. and if anyone ever produces an image with main,restricted,universe on, that "fix" would break them.
<Kamion> or would it ... perhaps not
<mdz> Kamion: it would definitely break them, or only if their packages file is an unlucky multiple of bytes long?
<milli> diego: no idea if he's here.  I would say file a bug in bugs.debian.org, but Xorg stuff isn't even there yet, so bugzilla.ubuntu.com would be the place to file a bug.  But this is really an #ubuntu question.
<diego> milli, heh
<diego> mdz, any suggestions as to who i need to talk to?
<mdz> diego: search bugzilla; it's a known issue that we can't fix without breaking other things
<mdz> iirc
<diego> also another question: the screen saver just came on the livecd but i couldn't unlock the screen without knowing the password (i had to set it first in tty1). what is supposed to happen?
<mdz> different pointing devices assign their buttons differently
<Kamion> mdz: would definitely break them
<milli> diego:  Looks like bug #6361 is what you found
<mdz> diego: what did you expect to happen?
<Kamion> I'm currently trying to understand why it only breaks in this situation
<diego> ah ok regarding the mouse
<milli> diego:  https://bugzilla.ubuntu.com/show_bug.cgi?id=6361
<diego> mdz, i was hoping to be able to unlock the screen with an empty password
<mdz> the only reasonable consensus we had about locking on the live CD was that it should be disabled entirely, if anything
<mdz> diego: then it wouldn't be locked
<diego> mdz, well it just locked the screen...
<diego> the screen saver came on and it locked the screen automatically
<mdz> diego: I know exactly what it does; it's a bug, a minor one, already reported in bugzilla
<lamont> diego: didn't lock here when it went to screensaver
<diego> uh..i'll refrain from using the computer for a couple minutes and see if it does it again
<mdz> it definitely puts you in a bad situation if you select 'lock screen' from the menu
<mdz> or close the lid
<diego> ohh yeah..i closed the lid :P
* diego runs off like a little girl
<lamont> diego: and (of course?) the work around is ctl-alt-f2; sudo passwd ubuntu; ... ctl-alt-f7
<mdz> "then don't do that" is the only answer for now
<diego> lamont, right, just did that :)
<mdz> I acknowledge that it's wrong behaviour, but it wasn't straightforward to do anything about it in the time available
<cartel_> hey all
<cartel_> quick word to the wise.. reportbug appears to be sending reports to debian bts
<cartel_> someone may want to patch it to go to ubuntu bts
<Kamion> we patched it not to go to Debian ages ago ...
<lamont> cartel_: taht'd be bug #1080
<mdz> lamont: no, that's about bug-buddy
<mdz> cartel_: as Kamion says, it is already patched to do that
<diego> well this computer seems to be working fine other than those 2 known issues. going to try the other one now
<lamont> oh
* lamont burns a little of his home-bandwidth quota
<mdz> are the kubuntu cloops done?
<cartel_> hmm
<Kamion> yes, I just started kubuntu-daily-live
<mdz> ok, thanks
* lamont heads off to give all the unbuilt universe stuff back for one last pass through the chompers
<dholbach> lamont: yeah!
<milli> lamont:  Ok, no worky on the DVD ISO download, are there CD ISOs on mirror.mmjgroup.com?
<dholbach> ok pals, i'm off to bed - see you for the countdown
<ogra> mdz, whats the deadline for universe ? release announcement ?
<mdz> ogra: what did your team decide?
<mdz> ogra: anytime before we close the archive should be OK
<mdz> dholbach: night
<ogra> mdz, thats what i meant, when do you close ?
<mdz> ogra: when we bless the ISOs and announce, I guess
<mdz> I hadn't thought about it much since elmo implemented the approval system
<ogra> ok, so announcement will be our deadline then... dholbach, ok with you ?
<milli> lamont:  nevermind, found them
<dholbach> ok
<dholbach> any ETA already?
<ogra> 24-30h ?
<ogra> mdz ? ^
<dholbach> alright
<mdz> dholbach: sometime around 0800 UTC 2005-04-08
<mdz> perhaps up to a few hours earlier
<dholbach> ok
<ogra> night dholbach :)
<dholbach> ogra: then we should get a move on with krecipes and hula
<dholbach> so elmo can push them in
<ogra> tomorrow i'll go through the review list top to bottom ...
<dholbach> sounds good
<dholbach> ok... see you all, bye mdz 
<ogra> night all
<diego> livecd worked fine on my desktop (nforce2 mobo w/ athlon xp processor and geforce4 video card)
<mdz> thanks
<diego> my usb stick takes like 1-2 minutes to be mounted...known issue?
<jdub> install+live fine on my i386 and powerpc test machines, though i still can't figure out the keyboard selector ;)
<Kamion> sigh. ok, archive-copier fix in baz.
<Kamion> one-liner
<lamont> Kamion: so we document how to turn off archive-copier on the dvd in the errata sheet?
<Kamion> http://people.ubuntu.com/~cjwatson/archive-copier.segfault.diff
<Kamion> let me check which images are affected
<lamont> damn asterisks
<Kamion> if we need to rebuild for some other reason, we *must* include that fix; if I'm correct, it affects images where the combined size of the uncompressed main+restricted Packages files == 3 mod 4
<lamont> weee hoooo!!!!!   IT"S ROULETTE TIME!!
<mpt> That's better odds than the Russian version
<lamont> mpt: the idea is to _MISS_
<Kamion> which now leaves me confused as to why hoary-install-powerpc worked for mdz
<mpt> oh, details
<Kamion> 996287
* Lathiat wonders if theres an up-to-date cdimage.ubuntu.com mirror on internet2 somewhere
<mdz> Kamion: confirm 996287 on my powerpc iso
<mdz> but it did in fact install successfully
<Kamion> hm, maybe I mean == 1 mod 4
<Kamion> or maybe not; sod it, it's an overflow, anything could happen
<mdz> Kamion: if you've got another test cycle in you during the next 12 hours, we can roll another set
<Kamion> I've run the fixed archive-copier through valgrind
<Kamion> it's happy (much happier than before, certainly)
<mdz> since everything should be identical except archive-copier, we should be able to retrieve everything (including DVDs) quickly
<Kamion> alright, I have coffee
<jsgotangco> greetings
<mdz> Kamion: sleep might be a better option than coffee; I can drive a round of tests and have an image waiting for you in your morning
<Kamion> mdz: I'm not going to sleep when stuff is this broken anyway
<Kamion> as in I won't sleep usefully if I try
<Kamion> archive-copier 0.1.5 uploaded
<mdz> did you sneak it in before cron.daily? I suppose not
<Kamion> sadly not
<Kamion> well, not the cron.unchecked before cron.daily
<mdz> elmo: if you're around, mind kicking cron.daily?
<Kamion> mdz: it'll need approval anyway ...
<mdz> you're doing that already, no?
<lamont> Kamion: this means new di yes?
<lamont> but not new livecd?
<Kamion> mdz: yeah, will do
<Kamion> lamont: neither
<lamont> woot
<Kamion> archive-copier is not in the initrd
<mdz> yay for modularity
* Kamion wonders if he can safely approve stuff while cron.daily is running?
<mdz> the lowest setting on this fan is not low enough
<lamont> Kamion: on the down side, there are boatloads of universe packages queued on the buildds, and they're taken 5 at a time.  On the good side, 90% of the packages build in < 1 minute
<lamont> and if we really lose, I'll kill whatever's in theway
<lamont> Kamion: cron.hourly runs at :35
<lamont> so I think that's a yes.
<Kamion> installed, kicked cron.daily again
<lamont> amd64:Total 214 package(s) in state Needs-Build.
<lamont> i386:Total 105 package(s) in state Needs-Build.
<lamont> powerpc:Total 172 package(s) in state Needs-Build.
<lamont> and all the non-universe stuff is really PaS
<lamont> (3,2,6)
<mdz> elmo: awake?
<mdz> elmo: it doesn't look like you uploaded moin1.3 to hoary
<blahrus> just wondering guys, is there going to be a way to upgrade from warty to hoary?
<diego> blahrus: yes.
<Kamion> blahrus: same way as people have been upgrading from one Debian release to the next for years
<blahrus> sorry :( moved from fedora to ubuntu
<elmo> mdz: fuck.  sorry.   is it too late?
<lamont> archive-copier uploaded
<Kamion> moin isn't on the CD, so I shouldn't think so
<mdz> elmo: we're doing one more build cycle to fix archive-copier, so no
<mdz> it'd be on the DVD though
<lamont> x3
<elmo> mdz: what seed should it be in?
<Kamion> blahrus: http://www.ubuntulinux.org/wiki/HoaryUpgradeNotes
<mdz> elmo: supported
<mdz> speaking of upgrade notes, we should publish the release notes on the website someplace
<blahrus> Kamion, so this is doable now . . . 
<Kamion> should be
<daniels> blahrus: yes, but probably more of a #ubuntu topic of discussion
<diego> mdz: "We are in fact planning a simplified upgrade tool for the Ubuntu 5.10 release" --you. did this ever get made?
<CarlK> so is it "Release To Manufacturing" or still  RC?
<mdz> diego: the Ubuntu 5.10 release will be in October 2005
<blahrus> Kamion, i am running hoary on my laptop now, but my desktop (amd64) I am not becuase there was a issue with the kernel and my sound card
<mdz> I wrote that comment a few hours ago
<diego> mdz: oh my bad. read too fast for my own good
<diego> i'm so worthless heh
<Kamion> CarlK: still RC
<Kamion> although, I should pre-publish the images for releases.ubuntu.com rsyncability
<CarlK> ok - http://www.ubuntulinux.org/download/ is still right 
<mdz> Kamion: i386 DVD survived archive-copier, fwiw
<mdz> doing a test install with it now
<Kamion> CarlK: yeah, release proper won't be until Friday morning
<Kamion> mdz: my amd64 DVD's at 31% ...
<mdz> I should be less than an hour away from the powerpc dvd iso, to complete the set
<diego> why is https://www.ubuntulinux.org/support/documentation/faq/upgrade-sarge on the wiki not publicly viewable?
<mdz> there is no sarge from which to upgrade, as yet
<mdz> so its contents wouldn't be relevant anyway
<mdz> but to answer your question, I don't know
<diego> heh, granted
<CarlK> so there may be a new .torrent between now and Fri?
<mdz> CarlK: there definitely will be
<mdz> unless something goes horribly wrong
<CarlK> k - I was going to setup a few seeds... I'll stand by
<CarlK> lol
<mdz> Kamion: i386 dvd install was successful
<mdz> powerpc isn't here yet, but so far archive-copier is our only outstanding issue
<Kamion> ok, pre-publishing ubuntu-5.04-release-*-*.* to releases.ubuntu.com/.pool/
<Kamion> did sabdfl say he was happy with those filenames BTW?
<mdz> Kamion: haven't discussed them with him
<mdz> any reason to have -release- since we'll only be publishing one set of ubuntu-5.04-* ?
<Kamion> well, it's what we did for warty (warty-release-*)
<mdz> that's because we wanted to differentiate from warty-foo-bar.iso, of which we produced many
<Kamion> and it will make the script even more unreasonably complicated to special-case that out :)
<Kamion> in future I expect we'll have ubuntu-5.10-preview-*, ubuntu-5.10-rc-*, ubuntu-5.10-release-*
<mdz> I don't think I would mind ubuntu-5.10-preview, ubuntu-5.10-rc and "ubuntu-5.10"
<mdz> but if it's unnecessarily complicated, I can live with ubuntu-5.04-release-*
<Kamion> although I guess I can take it out actually, there is some provision for an empty status
<Kamion> let me try
<CarlK> I would recomend -release- because it is definitive, as where ubuntu-5.10 is open to confusion 
<fabbione> morning
<Kamion> CarlK: that was my original reasoning, certainly
<Kamion> we have had confusion before
<Kamion> mdz: I can do either
<CarlK> where in the world is it morning?
<diego> i agree with CarlK on this...i'd like some quick way of distinguishing release from preview, daily, and rc builds
<CarlK> Romania? 
<Kamion> CarlK: that would be Denmark; fabbione gets up early
<CarlK> or really late... ;)
<fabbione> CarlK: no.. really early :)
* fabbione rsyncs
<fabbione> Kamion: i guess you did build another set of CD since 8 hours ago
<Kamion> fabbione: yeah
* diego shrieks! my debian menu is gone :|
<Kamion> there's another one coming, but very small diff
<fabbione> Kamion: ok.
<fabbione> i will get ready to brun in the meantime
<Kamion> fabbione: grab this one, there's more of it
<Kamion> diff-wise
<Kamion> Ubuntu install CD builds running
<daniels> it's morning-ish in Western Australia
<fabbione> Kamion: i already have install here.. 
<fabbione> DVD is rsyincing
<mdz> Kamion: ubuntu-5.04-<arch>.iso is preferable, then
<mdz> fabbione: rsyncing from an old DVD, or from concatenated live+install?  I think the latter may be faster
<mdz> fabbione: we are going to have to build one more set of images btw
<Kamion> mdz: ubuntu-5.04-{install,live}-<arch>.iso rather
<mdz> Kamion: er, right
<Kamion> mdz: I have to say I agree with CarlK too, but ok, will do
<fabbione> mdz: just from the old one...
<mdz> Kamion: I'm not unshakably opposed to -release-, especially if sabdfl prefers it
<lamont> fire call
<mdz> Kamion: the s/hoary/ubuntu-5.04/ is what I'm interested in
<jnc> friendly reminder,  OpenOffice is still broken for printing on amd64 
<mdz> jnc: http://bugzilla.ubuntu.com/
<Kamion> mdz: did you concatenate live+install or install+live?
<mdz> we're in the final stages of release preparation here; bugs which are only mentioned on IRC will probably be forgotten
<Kamion> install+live is going pretty slowly here
<mdz> Kamion: live+install
<mdz> mkisofs sorts the directories
<mdz> and /casper comes before /pool
<Kamion> meh, ok
<jnc> mdz: already filed
<Kamion> mdz: I'll check with Mark later
<infinity> jnc : Bug#?
<Kamion> jnc: sorry, but it's unlikely that anything more is going to get fixed
<Kamion> for hoary
<jnc> infinity: 6762
<mdz> Kamion: archive-copier is in, for release architectures
<|QuaD-> when is development on breezy starting (or has it already)?
<jnc> i figure printing, would be a pretty important thing to have working.
<Kamion> mdz: 04:16 < Kamion> Ubuntu install CD builds running
<mdz> |QuaD-: it'll start after hoary is out; we're all busy with hoary right now
<mdz> Kamion: ok
<mdz> Kamion: I think install+live should work as well, fwiw
<mdz> but live+install gives pretty immediate feedback of the savings
<elmo> Kamion: your scripts are already ignoring ia64, right?
<Kamion> elmo: yes
<mdz> I get about 23% very quickly
<elmo> ok, good
<daniels> elmo: so, what's the process for inter-source-package migration of binary packages?
<mdz> Kamion: hmm, would have been better to do live first, since they're faster
<elmo> daniels: inter-what-now?
<daniels> elmo: (assuming, hypothetically, that xfonts-*, xspecs, and xterm get kicked the fuck out of xorg into their own source packages)
<Kamion> mdz: live doesn't need to be rebuilt for this
<elmo> daniels: just do it?
<Kamion> it does not use archive-copier
<mdz> Kamion: er, right, heh
<daniels> elmo: cool
<fabbione> daniels: i will tell you later.. i did for apache once already
<daniels> fabbione: there aren't any strict version deps or anything, they don't need to all go in in the same katieday
<daniels> just wondering if elmo needed to do anything with overrides or whatever
<mdz> Kamion: so {ubuntu,kubuntu}-{install,dvd}
<Kamion> mdz: right
<mdz> it looks like kubuntu has gone home, though
<jnc> Kamion: if i thought it could wait, i wouldn't mention it outside of bugzilla.  openoffice not being able to pick up cups printers and print, that says to me "oh, yeah you should let the devs know about that"  for amd64 :)
<mdz> hopefully they won't discover any new problems tomorrow
<Kamion> none of those are particularly faster than the others; I'll do Ubuntu first since, as you say, few Kubuntu people are awake
<infinity> jnc : Are you the same jnc who owns the problematic LJ1012? :)
<jnc> infinity: aye
<Kamion> jnc: time-based releases mean that sometimes, some bugs just have to stay there, unfortunately
<Kamion> jnc: it might be a candidate for hoary-updates if the fix is sufficiently simple and obvious
<infinity> jnc : As Kamion stated, we're just too short on time to fix it before hoary comes out, but I do feel your pain, having worked with your other printer issues too (have you considered just throwing away the printer entirely and going paperless? :))
<jnc> infinity: well, the 1012 is working okay now thanks to the gs-esp patch
<jnc> infinity: but the OpenOffice print problem applies to _all_ amd64 users
<infinity> jnc ; Yeah, I see that.  Hence Kamion's coment about hoary-updates.  That's about the best anyone can do this late in the game.
<Lathiat> whens the next i386 rebuild goign to finish? (or has it?)
<Lathiat> (install)
<jnc> infinity: whenever it gets released, that's fine.   whom should i work with to resolve the problem?
<Kamion> Lathiat: guessing ~40 minutes
<Lathiat> Kamion: thanks
<jnc> i understand y'all are very busy. do i wait for more words on that bugzilla report, or work with someone actively now
<infinity> jnc : Well, the bug log claims Mithrandir may know the cause (and it's also assigned to him).  I wouldn't bug him until after we release, though.
<jnc> roger that. :)
<jnc> thanks for your feedback, folks
<infinity> jnc : Glad to see the gs-esp patch worked for you.  I'll see if someone feels the patch is worthy of inclusion in a later update.  Otherwise, switching to the other gs is a reasonable workaround to suggest to other owners of the same printer.
<jnc> it stuck out in my mind if i was releasing something that was going to be pressed onto CDs, i'd want the big applications installed by default to work 
<jnc> for the most part they do, it's amd64 where many hoary experimenters have seen nonfunctional printing
<jnc> just for OpenOffice, everything else works great
<Kamion> we have a tradeoff here between releasing stuff with some known breakage, and ... not releasing :)
<jnc> i see
<jnc> it is time to shoot the engineers and release the product?
<Kamion> since apparently nobody's understood this bug well enough to post a patch, it's not something we can really delay for
<fabbione> Kamion: let's stop the release! :P
<Kamion> whether the bug is understood in that sense has considerable bearing on what we do
<jsgotangco> *grin*
<diego> wouldn't it have been better to be where it is right now but a month away from the release date? mmm...QA++
<jnc> Kamion: where i'm confused is that it used to work.  rolling back to a previous version is not a suitable solution?
<diego> did the release schedule work as planned or did it fall behind?
<Kamion> diego: you can never have too much QA ... but we do have to draw the line somewhere
<Kamion> jnc: that would also roll back all other bugfixes made in the interim; no
<jnc> Kamion: i agree, i do not understand this problem enough to diagnose it.  OO is huge and complicated
<jsgotangco> take it to the limit!
<Kamion> and doing that for one architecture is an ugly can of worms
<Kamion> diego: we delayed by two days (announced some time back) to allow extra testing of GNOME 2.10.1, but otherwise we're pretty much on track
<Kamion> although we are kind of burning through our slack time at the moment :-/
<diego> Kamion: i see :/
<Kamion> but nothing to worry about yet
<diego> Kamion: it seems like i got pretty shafted but overall it looks good
<jnc> with everyone so busy, are you short on help?
<jsgotangco> i want to ask a dumb question and it may have been answered in the list but why are we targetting 2.10.1?
<mdz> any non-trivial piece of software contains at least one bug
<mdz> Ubuntu, being a collection of a large number of non-trivial pieces of software, is guaranteed to contain a large number of bugs :-)
<jsgotangco> *grin*
<diego> mdz: and how is ubuntu not trivial?
* diego hides
<mdz> the best we can do is to fix the truly severe ones before release
<jsgotangco> fix the ones that affect the most number of users aye
<Kamion> diego: in what way did you get shafted?
<Kamion> jsgotangco: because 2.10.1 is a bug-fix release, and much of the stuff in it is stuff we've already had reported between preview and release
<jnc> mdz: so i can get a prespective, what is more severe than OpenOffice not printing on the amd64 arch?  just curious, i am sure there is a more serious bug and i would like to know
<mdz> Kamion: iirc, diego has a bad time with ipw2200
<Kamion> jsgotangco: we've chosen to tie ourselves quite closely to the GNOME release schedule, so it makes sense to take their bug-fix releases
<jsgotangco> ahh
<mdz> jnc: you cannot think of a more serious bug than that, really?
<diego> Kamion: as i've previously discussed OT-ily (mdz, this means close your ears), the intel ipw2200 wifi bug that makes me drop my connection every now and then, and my thumb drive only sometimes works and even then with a long delay
<Kamion> jnc: for example, Ubuntu not installing is more severe
<Kamion> diego: ah, OK
<jnc> Kamion: ah, dig it.
<Kamion> jnc: the re-spin we're doing right now is for exactly such a problem
<jnc> mdz: earlier i observed a few devs plotting out with graphs and charts or something, maybe i misread into it.   it was the purpose of shaving off a few seconds from boot up time
* mdz mutters under his breath about source ISOs\
<Kamion> jnc: somebody asked about boot time, and folks responded
<Kamion> jnc: all the actual work there was done months ago; people haven't been working on it today or anything
<jnc> you are all doing a wonderful part in this project which end users benefit from
<jnc> thank you
<lamont> back
<Kamion> you're welcome
<mdz> Kamion: my heart skips a beat when I see "CD2" scroll by in the log ;-)
<jnc> i am used to Gentoo developers, it is good for me to ask questions and understand how Ubuntu development works during a release cycle, thanks again :)
* jnc tears down the spotlight and scrambles out
<diego> what jnc is saying goes for me too, i'm just too big of an ass to type it :)
<lamont> nacl
<lamont> back, even
<Kamion> mdz: yes :)
<fabbione> Kamion: sorry.. i got lost in the noise.. are the new CD ready for rsync?
<Kamion> fabbione: not yet
<fabbione> ok thanks
<Kamion> building powerpc
<mdz> Kamion: eek, jigdo imploded
<Kamion> mdz: it always does that on powerpc :-/
<Kamion> I've been meaning to report it
<Kamion> and/or check whether the result works
<mdz> hmm, neither thom nor elmo are around to kick the torrents
<SuperLag> Gentoo has rc-status to see which services are running... is there something equivalent in Ubuntu?
<daniels> ps auxww
<SuperLag> it's weird... my hard drive light is solid
<SuperLag> and has been for this entire install
<diego> hdd party?
<Kamion> new Ubuntu install CDs up, DVDs building
<lamont> ubuntu hits 2x #2 on the 1-month stats from distrowatch
<lamont> and it's not even next week yet
<SuperLag> lamont: I thought it was #1
<lamont> SuperLag: it is
<lamont> on 1-, 3-, and 6- month lists
<lamont> but #2 now has 1/2 the average-daily-hits as Ubuntu
<lamont> although rank 2-4 have more combined hits than #1. :-)
<diego> lamont: got a colorful graph?
<lamont> http://distrowatch.com/stats.php?section=popularity
<lamont> not really a graph, mind you
<diego> i'm disappointed then
<lamont> not my site, either
<lamont> http://distrowatch.com/weekly.php?issue=current#1
<diego> i did not know mandrake was so popular...weird
<lamont> it's skewed stats
<jsgotangco> its about hits right?
* Lathiat wonders what stats aren't skewed :)
<blahrus> Mithrandir: you around?
<mdz> rsyncing
<lamont> jsgotangco: yes
<Lathiat> bleh to 30K/s rsync
<lamont> mdz: new install CD, or dvd?
<Lathiat> 0406.1-0406.2 seems to be rsncing alot slower than 0405-0406.1 did
<milli> I have tried to wget, lftp and bt the hoary-dvd-i386.iso, I get no bit flow.  Is there a problem?
<mdz> lamont: 3xinstall, 3xDVD
<lamont> woot
<Kamion> mdz: I'm now basically just waiting for stuff to download, so I'm going to bed for a bit; back, er, at some point
<Kamion> lamont: DVDs not done yet
<Lathiat> milli: its usually a file size issue
<mdz> I was up to date before this build, so it should be relatively quick
<lamont> Kamion: ok
<milli> wget --ignore-size gives same results
<mdz> Kamion: ok, night
<Kamion> mdz: you might want to kick off cron.kubuntu-daily followed by cron.kubuntu-dvd once the current build is finished
<milli> lamont: Can I rsync it?
<mdz> milli: bittorrent is a bit flaky, http works fine, rsync works fine
* fabbione hits himslef with a cluebat
* Lathiat removes fabbione's cluebat
<Lathiat> more work less bashing :)
<fabbione> hitting ctrl+c in the wrong xterm is stupid
<lamont> milli: I turned back on the bwlimit on the m.m.c's cronjob, too :-)
<daniels> fabbione: d'oh :\
<lamont> fabbione: and painful
<fabbione> daniels: i killed the DVD rsync right at the end of it :)
<daniels> heh
<fabbione> and 2.6.12_2.6.10.90-1 is finally building
<milli> lamont:  thanks, I need my bandwidth back to play first-person shooter games after today (at my work) :-)
<fabbione> hopefully this is the last one that stops due to insane debian/rules
<Lathiat> ww
<daniels> lamont: the Binary part of the xorg .changes is now a mere 1790 characters
<lamont> daniels: wow, only 1.8* bigger than the mailer likes... :-)
<daniels> lamont: oh, I'm not done yet
<lamont> woot
<fabbione> when are we going to open breezy uploads?
<lamont> not this week...
<fabbione> of course
<lamont> but dunno
<lamont> plans are to play with gcc-4.0 first, but I haven't been dragged into that yet...
<lamont> will pester folks tomorrow after they've slept, I figure.
<lamont> doh.  this channel... thought we were in #u-k for a sec
* lamont gets ready to sleep, unless he's needed.
<fabbione> ehehe
<fabbione> good night lamont
<lamont> g'night
<daniels> night lamont
<diego> gn all
<mdz> amd64 CD install successful
<mdz> powerpc and i386 in progress
<blahrus> mdz: still having issues with current amd64 kernel and my sound card.
<mdz> blahrus: have you opened a bug in bugzilla?
<mdz> that is all there is to be done about it at this point
<blahrus> mdz: yea
<blahrus> 8696
<blahrus> the kernel from warty works fine, then I upgraded to hoary
<fabbione> blahrus: you have been asked to do another test.. did you do it?
<fabbione> if so please add the info to the bug
<fabbione> today this chan is very busy for release
<jsgotangco> wee
<Lathiat> i386-install finished yet?
<fabbione> i386 install running here now
<Lathiat> the new build?
<fabbione> yes
<Lathiat> cheers
<blahrus> fabbione: I assume he means like the cable on the back of the speaker, or is there some program he is talking about
<fabbione> blahrus: the mixer
<fabbione> plus it's not a mortal sin to ask info back if you are not sure how to do something, just do it in the bug please
<blahrus> the mixer is fine, if i boot the warty kernel, sound works, if i boot the hoary kernel sound doesn't work
<blahrus> k, no problem
<mdz> DVD images are up
<blahrus> sorry to bug you guys
<mdz> powerpc CD install successful
<fabbione> i386 is in phase2 now here
<mdz> i386 just logged in here
<mdz> hwdb-gui makes a good test of the system :-)
<mdz> i386 CD install successful
<mdz> 3/3 CD installs successful, doing DVDs next
<fabbione> mdz: i386 normal install is GO here
* fabbione tests multiarse
<daniels> mdz: is powerpc back on to one CD?
<mvirkkil> What nick does Ross Burton go by?
<jdub> ross or rburton
<whiprush> oy jdub, know if gman is making the flight over for UDU?
<jdub> i don't think he can stay
<mvirkkil> jdub: Thanks. Too bad he isn't here.
<jdub> he's going to be at lca
<whiprush> :-/
<jdub> mvirkkil: uk time
<whiprush> It's like, loonix australia month or something.
<mvirkkil> jdub: Well, I'm in uk time +2 ,'
<jdub> whiprush: we don't want him pooing on our roof anyway!
<daniels> whiprush: he's not staying for UDU
<daniels> jdub: haha
<daniels> hm: http://www.pccasegear.com.au/prod2144.htm
<whiprush> daniels: we're not cool anymore, ibm announced the X41. :(
<daniels> whiprush: yeah, I saw, but it's just more of the same
<daniels> it still doesn't have any sort of ati chipset
<whiprush> oh. well, that's why I like it. (heh)
<Lathiat> whats new in it?
<whiprush> updated processor and chipset
<Lathiat> any cheaper?
<whiprush> no, more expensive, starts at $1999 US now
<jdub> they've added more of the same chemicals found in cigarettes
<Lathiat> whiprush: damn
<whiprush> and a fingerprint thinger too
<Lathiat> ha ha
<Keybuk> daniels: you like the ati?
<whiprush> jdub: you have an X300 right? you see dell's new X1? it's their "x40 killer"
<jdub> X1 eh?
* jdub peeks
<whiprush> http://www.engadget.com/entry/1234000913038231/
<whiprush> widescreen even.
<daniels> Keybuk: i like the idea of a chipset that has open specs
<jsgotangco> NICE
<Lathiat> the 700m is pretty nice
<jsgotangco> compared to my crappy ECS laptop
<jdub> i mean, the X300 already kills the X40 ;)
<Lathiat> i want one 
<jsgotangco> which reminds me
<daniels> Keybuk: i8xx is discounted because of it's world's-shittiest-mode-setting stuff
<Lathiat> but i got a big chunky 8600 in stead :)
<jsgotangco> i need a backpack for UDE
<jsgotangco> UDU
<daniels> Keybuk: relying on vbe -> cock
<Lathiat> i wish i could get to UDU
<Lathiat> daniels: hehe
<Lathiat> does the i915 stuff fix that?
<Keybuk> icky :(
<daniels> Lathiat: no
<Lathiat> so its intel ixxx :)
<daniels> well, yeah; i9xx is just i8xx on pcie, really
<Lathiat> ah right
* whiprush just thought of a trivial bug on his x40 that he can close
<jdub> http://img.dell.com/images/global/products/latit/x1_and_coffeecup_314x314.jpg
<jdub> that's just some massive american coffee cup, innit?
<Lathiat> wheh
<jdub> screen sounds wide but small
<daniels> of the four still doing current chipsets (ati, nvidia, intel, via), via are discounted because they don't give out full specs, the driver is arse, the chipset is arse, and they lie rampantly.  nvidia is discounted for no specs and no open driver.  intel is discounted for vbe.  that only leaves one standing, and that one has an open and very, very well-written driver, and i have the specs for it.
<daniels> jdub: heh yeah
<daniels> jdub: it's actually jblack's coffee bucket
<Lathiat> daniels: does it do 3d in te open driver?
<jdub> heh
<daniels> Lathiat: for r2xx, yes
<Lathiat> (on *new* cards)
<daniels> no
<Lathiat> spec problem or no ones bothered problem?
<jsgotangco> i wouldnt touch anything by via at all i used to have a laptop with their c3 processor and it just blows
<daniels> Lathiat: kind of a political problem
* Lathiat wahs
<Lathiat> is it explainable in 30 seconds? :)
<jdub> *cough* http://node.waugh.id.au:8800/
<daniels> Lathiat: not really
<jdub> that was quick
<whiprush> Is marking a dup a specific permission? I don't seem to have that option available.
<Lathiat> what was quick?
<daniels> jdub: particularly jesusesque these days
<Lathiat> indeed
<Burgundavia> jdub: omg, ahhh my eyes
<mvo> morning
<whiprush> nm, found it
<daniels> scorchio!
<jdub> some crankage for you, daniels 
<jsgotangco> is that an ogg stream?
<jdub> ogg theora+vorbis, yes
<daniels> word
<snaggen> I'm I the only one that thinks the new update-manager notification icon looks like a warning sign? First time I saw it I had to look at the tooltip to realize what it was.
<mvirkkil> I've made som changes to gnome-app-install, is there anyone else besides ross I should mail it to?
<jdub> mvirkkil: mail mvo too
<mvo> mvirkkil: I would be interessted too
<mvirkkil> Addresses?
<Lathiat> snaggen: yeh i thought that, then again i guess it kind of is a warning
<SuperLag> dammit
<SuperLag> who would have thought that current still travels through an IDE cable when the Molex power connector to the hard drive is disconnected?? :)
<snaggen> Lathiat, Yes, on a stable system with only security updates it might make sence to resemble a warningsign.
<fabbione> mdz, daniels: multiarse on i386 is GO
<Lathiat> fabbione: multiseat crap?
<Burgundavia> snaggen: if it doesn't grab users attention, they won't update
<fabbione> Lathiat: s/crap// yes
<Lathiat> crap is a generalized grouping word :)
<daniels> fabbione: good news
<smurfix> Dammit, every time lately I fix some of the key select problems the result works for me but somebody else has problems with it. :-/
<fabbione> daniels: i just noticed we forgot one little detail
<daniels> fabbione: oh?
<fabbione> daniels: like copying the multiseat-config binaries in the deb
<fabbione> daniels: there is no way to reconfigure it manually after install
<fabbione> s/manually/automatically
<fabbione> well..
<fabbione> not a big deal right now
<daniels> right
<daniels> that package should just die in the long term though
<fabbione> daniels: die? how?
<fabbione> we will need to something to regenerate multiseat.conf somehow
<daniels> well, the xorg.conf-generating bit of it should ideally go away
<daniels> and whatever we use to write xorg.conf when we throw away the scripts in xserver-xorg should deal with that
<daniels> and multihead as well
<fabbione> daniels: i am not talking about multiseat-configurator
<fabbione> i am talking about the piece of script that creates multiseat.conf
<daniels> oh, right
<daniels> there's no way to kick the multiseat-udeb stuff
<mvirkkil> jdub: mvo: mail sent.
<daniels> yeah
<fabbione> daniels: not that i know off.. well tough luck
<daniels> i need to go take care of my little sister for a bit, i'll be back later
<fabbione> daniels: there is no full support for multiseat anyway
<daniels> about 15min
<fabbione> daniels: later
<mvo> mvirkkil: thanks
* fabbione starts live testing
<mdz> daniels: yes, powerpc being >1 CD was a critical bug and was fixed
<pitti> good morning
<pitti> i386/server installation works fine
<fabbione> i386/live machine 1/3 is GO
<daniels> mdz: good t hear
<mdz> pitti: are you testing the latest images?  we had to do another build
<pitti> mdz: server installation was from yesterday's image still (did that before booting my main system)
<pitti> mdz: now I download today's and will test them, too
<pitti> mdz: any urgent catastrophes that require attention today?
<mdz> pitti: so far it looks good
<pitti> great to hear :-)
<mdz> DVD images need testing
<pitti> ugh
<mdz> cat hoary-live-$arch.iso hoary-install-$arch.iso > hoary-dvd-$arch.iso && rsync
<fabbione> mdz: burning DVD now
<pitti> rsync can re-sort blocks this way? cool
<mdz> powerpc and amd64 dvd-installs in progress, i386 burning
<fabbione> i386/live machine 2/3 is GO
<fabbione> i386/live machine 3/3 is GO
<fabbione> argh.. we didn't fix the DVD menus
<fabbione> Kamion: there is still space to change the .txt for the DVD?
<fabbione> i386/dvdlive is GO
<fabbione> this interesting :)))))))
<fabbione> DVD install proposes me to install on the DVD
<fabbione> it detects it as DVD-+RW
<mdz> amd64 DVD install successful
<mdz> i386 DVD live successful
<fabbione> mdz: i386 dvd is going here
<mdz> powerpc DVD seems to be no good :-/
<mdz> it is missing the live option in yaboot
<mdz> no idea how this happened
<fabbione> crap
<fabbione> mdz: if we need to rebuild the DVD's, would it be possible to fix the .txt for the help?
<mdz> what is broken about it?
<mdz> I don't even know how to fix the yaboot thing; I will need to dig in debian-cd
<fabbione> it still reports install CD and didn't notice the "live" boot option
<mdz> it has always been that way
<fabbione> so we don't want to advertise it?
<mdz> since we first started making DVDs
<fabbione> yeah i know that, but it would be nice to have
<mdz> we do, but it is not a regression and I do not want to rebuild, redownload, reburn and retest the DVDs just for that
<mdz> it takes hours
<fabbione> i agree
<fabbione> it can wait breezy
<mdz> if we are going to fix powerpc, we will do a powerpc-only build
<mdz> and only retest that
<froud> mdz
<froud> ooops wrong channel
<fabbione> i386/server install is GO
<mdz> amd64 DVD live successful
<mdz> oh
<mdz> my powerpc ISO looks to have been corrupted
<mdz> rsync: write failed on "/home/mdz/cd/ubuntu/hoary-dvd-powerpc.iso": No space left on device (28)
<fabbione> whops
<mdz> I will re-test when my i386 DVD install is complete
<mdz> hmm, the powerpc iso is broken though
<mdz> my iso was from the previous build due to the rsync failure
<mdz> mdz@little /srv/cdimage.no-name-yet.com/www/full/dvd/current $ isoinfo -R -i hoary-dvd-powerpc.iso -x /install/yaboot.conf | grep live
<mdz> mdz@little /srv/cdimage.no-name-yet.com/www/full/dvd/current $
<mdz> the current one has the same problem
<fabbione> mdz: it might be worth checking on the old images, when it did breack
<fabbione> break even
<mdz> it has never worked
<mdz> at least not with this debian-cd which is on little
<fabbione> ah
<mdz> the code seems to be simply not there
<fabbione> doh!
<mdz> I could swear that I tested this a long time ago
<mdz> perhaps the debian-cd changes got lost?
<mdz> I need to talk to Kamion
<mdz> it is also an option to release without a powerpc DVD, but if we can fix it, that would be better
<fabbione> i agree
<mdz> Kamion has been gone only about 3 hours
<fabbione> ok.. i can tell him when he is back
<mdz> I could try to implement combo DVD support for powerpc in debian-cd, but I have a funny feeling that it was already done and is just missing from this copy somehow
<mdz> i386 DVD install successful
<mdz> so powerpc DVD live is the only remaining blocker
<fabbione> it's installing lang packages here
<mdz> we only have DVD images going back to 20050402, and they are all broken with respect to the live boot
<fabbione> crap
* fabbione needs more coffe... brb
<mdz> kubuntu install and DVD are up
* pitti does a parallel test installation on all his machines, going offline for a bit
<Mithrandir> uhm, bugs filed in malone against stuff in main; what to do about those? :)
<fabbione> i386/DVD install is GO here
<fabbione> Mithrandir: good point....
<Mithrandir> resolve with "NOTUNIVERSE"? :P
<fabbione> ahha
<Duluu> when hoary will released?
<Treenaks> Duluu: sooner if you stop asking :)
<mdz> I think I need to sleep
<mdz> fabbione: as far as I am concerned it is all gold except hoary-dvd-powerpc
<Duluu> why stop askin?
<fabbione> mdz: ok
<mdz> Duluu: Hoary will be released at approximately 0800 UTC on Friday, April 8th
<fabbione> sounds good
<mdz> fabbione: are you able to test powerpc DVDs?
<fabbione> nope
<fabbione> ENOPPC
<fabbione> probably pitti can
<Duluu> is it hard to update from RC1 to final release?
<mdz> yes, I was just checking my list, and I believe pitti has both a DVD writer and powerpc
<fabbione> Duluu: no, but please use #ubuntu for this kind of questions
<mdz> Duluu: no, just click the update icon 
<mdz> pitti is short on bandwidth though, I think
<Duluu> where I can find ubuntu developers documentation?
<fabbione> mdz: i am pretty sure Kamion does too and he will have to rebuild the image anyway
<mdz> well, at the worst we will go out without a powerpc DVD, and I can live with that
<fabbione> mdz: it would be ashame considering that we have still a few hours to get it done.
<mdz> I discussed this possibility with sabdfl since DVD testing is a problem for us
<mdz> fabbione: this is our fallback plan ;-)
<fabbione> mdz: ehhehe
<mdz> I still hope that we can fix it, but I am all about the contingency planning
<fabbione> mdz: i do agree that it is an issue.. for me specially is the hw.. 
<fabbione> i only have one machine that can read DVD+-RW
<fabbione> 2 that can read DVD-R
<mdz> fabbione: just be sure to tell Kamion that I don't want to rebuild amd64 or i386 DVDs; they are already well tested and we should not change them
<fabbione> mdz: i will. don't worry
<mdz> I will be back in 7-8 hours
<mdz> call my mobile if there is a problem
<mdz> night all
<fabbione> mdz: i will and good night
<mvo> night mdz 
<jani> mdz or kamion I'd like to make an xfce-ubuntu-desktop package so xfce4 users not having {k}ubuntu-desktop have smooth upgrades. I took kubuntu-meta and modified the desktop desc files, is that how it's done, or some other source packages or seeds need to be modified ?
<fabbione> jani
<jani> yes fabbione
<fabbione> they bofh went to sleep
<jani> aha
<fabbione> and it's probably a good idea to wait monday for it
<jani> thanks, I'll be back tonight then
<fabbione> we are pretty busy with hoary release right now
<jani> I'd like it to be in universe
<jani> not main of course
<fabbione> jani: i don't think there will be any change after today
<jani> just wanted advice, no wok on theit part
<jani> fabbione, universe is still open I suppose till tonight at least?
<fabbione> jani: the seeds aren't involved for the meta packages
<fabbione> jani: probably yes
<fabbione> or better.. seeds are.. but for a fast upload i think you can live without
<jani> thanks
<fabbione> jdub: ping?
<dholbach> good morning
<fabbione> hey dholbach 
<dholbach> somebody please review krecipes, gourmet and hula from wiki/MOTUNewPackages and make a small signature - i want those packages to get in
<dholbach> hey fabbione :-)
<mvo> morning dholbach 
<dholbach> sorry for bickering, before saying "hi" :-)
<fabbione> dholbach: even if i upload them, either Kamion, elmo or mdz will have to approve them manually
<dholbach> hey mvirkkil 
<fabbione> and none of them is actually alive
<dholbach> fabbione: i'll talk to elmo later
<dholbach> hey mvo
<dholbach> fabbione: i'm not talking about uploading - our MOTU policy is that 3 people have to review them and i'm talking to people about "reviewing package" for days :-(
<fabbione> dholbach: new packages? or are they updates for old ones?
<dholbach> new packages, but i reviewed them already and would very much like to have them in
<dholbach> and as elmo has to get in the apt-get.org stuff today, it should be no problem to get 3 GOOD packages in as well
<dholbach> we just seem not to have enough resources for that "new process"
<fabbione> dholbach: you didn't ask the less busy person atm :)
<dholbach> dholbach: whom? :-)
<GheRivero> good morning
<dholbach> hey pitti 
<fabbione> hey pitti
<pitti> Hi dholbach 
<pitti> I'm back from the mass install rave
<pitti> ppc/install/desktop, 2 x i386 install desktop, 1 x ppc/install/server, 1 x i386 install server, 3 x i386 live, 1 x ppc live are all fine
<fabbione> pitti: good to hear
* Lathiat wonders i the terminology "k-bling" should be used in the release announcement
<pitti> mvo: bah, cd upgrading really sucks
<pitti> mvo: I upgraded from today's hoary cd, but still it downloaded *all* 247 new packages from the net
<HiddenWolf> pitti: you're kidding?
<pitti> HiddenWolf: no, I'm not. That sucks
<pitti> my traffic limit is at 93%
<pitti> mvo: may it be that synaptic prefers authenticated packages over unauthenticated ones?
<HiddenWolf> pitti: How can it upgrade from a cd that contains the newest versions?
<mvo> pitti: no, your cd is authenticated as well
<pitti> mvo: I test the same upgrade on my networkless laptop, and it claims that all apckages from CD are not authenticated
<HiddenWolf> pitti: cd should be authed, imho
<pitti> it isn't
<pitti> not completely, at least
<mvo> did you do a warty->hoary upgrade?
<pitti> NOT AUTHENTICATED:
<pitti> libxext-dev, x-dev, libice-dev
<mvo> pitti: warty->hoary-upgrade?
<pitti> and a bunch of other X stuff
<pitti> mvo: no
<pitti> mvo: RC to final upgrade
<astharot> ciao
<mvo> everything on the cd should be authenticated, if not that's a serious problem
* Lathiat did a warty->hoary yesterday
<Lathiat> did you want me to have another crack with 07?
<mvo> pitti: let me see if I can reproduce it here
<pitti> bah, "some packages could not be downloaded - do you want to continue and ignore these packages?"
<mvo> pitti: apt will prefer stuff that is authenticated and will not use non-authenticated sources (that's a feature)
<dholbach> i'm doing a dvd test install
<dholbach> bbl
<mvo> the question is: why is your cd not authenticated?
<pitti> mvo: okay, then this explains why it ignores the CD
<mvo> pitti: can you please have a look at /var/lib/apt/lists/*.gpg?
<pitti> mvo: I have daily/current
<Mithrandir> pitti: you're finding security hole too quickly! :P
<Mithrandir> s/hole/holes/
<Mithrandir> there's an USN every day, ATM.
<pitti> Mithrandir: I do?
<pitti> oh, I did ~ 5 of them at monday or tuesday :-(
<Mithrandir> yeah, but some of them are a bit delayed out of bugtraq
<Mithrandir> we should outlaw security holes.
<Gagatan> hirr
<Gagatan> Mithrandir: lets start with banning PHP ;)
<pitti> Moin seb128 
<Mithrandir> Gagatan: actually, the last USNs haven't been on PHP stuff, but other user-level stuff.  gdk and such.
<seb128> hi pitti 
<seb128> livecd amd64 works fine here :)
<seb128> install i386 too
* Lathiat just about to do a few i386 install runs
<Lathiat> warty hoary ugprade, fresh install, fresh install on xfs/resier
<MyNameIsChris> Hello, who here will be at Ubuntu DownUnder on the 25th? (Most of you I guess)
<pitti> yeah
<MyNameIsChris> pitti, I don't want this to sound demanding but make sure you have a minute of silence for Anzac Day
<MyNameIsChris> And I may see you on the 26th
<zyga> hello
<zyga> hmm
<zyga> did anyone notice a bug when audio cd gets burned and then cannot be ejected
<zyga> it doesn't appear to be mounted but nautilus shows the icon on desktop
<infinity> I've had that with bad hardware...
<zyga> running eject as unpriviledged user shows 'bad argument'
<zyga> but as root - the cd ejects fine
<infinity> Oh, not the same problem, then.
<zyga> could this be some kind of misconfiguration?
<dholbach> grmbl, amd64-dvd was buggy - hope a rsync solves the issue
<zyga> that is not the first user created during install
<zyga> but I've added it to all relevant groups AFAIR
<zyga> ejecting normal cd works fine 
<zyga> verified: the user is in cdrom group
<zyga> this is reproducible but costs one cd-r ;-)
<zyga> burning was done in k3b if that is of relevance
<gsuveg> re
* infinity -> home.
<Lathiat> hrmm just doary a hoary test install
<Lathiat> archive.ubuntu.com barfed on me for a release.gpg and a packages.gz
<Lathiat> so nwo its whinging cus some packages aren't authenticated
<Lathiat> i've noticed over the last month or so, archive.ubuntu.com is randomly flakey returning bad headers and whatnot
<Kamion> pitti,fabbione: ok, I'll fix the powerpc DVD now
<pitti> Hi Kamion, hope you slept well :-) We need you :-P
<zyga> hmm
<zyga> firefox doesn't launch after recent update
<zyga> how can I debug this?
<fabbione> Kamion: cool. just be sure not to rebuild i386 and amd64, or mdz will crossburn us :)
<Lathiat> zyga: have you tried 'killall -9 firefox-bin' // rebooting?
<pitti> amu: ping
<zyga> Lathiat: trying
<Kamion> fabbione: yeah, mdz sucks for making me do a single-arch rebuild when we might be publishing the results :-P
<zyga> Lathiat: there was a stray firefox-bin
<Kamion> I'm going to have to hardlink the amd64 and i386 images over to dvd/current/ afterwards, or something
<Lathiat> well just did an 07 i386 standard install, apart from archive.ubuntu.com being flakey it was fine.
<zyga> Lathiat: extensions are loading
<Lathiat> multiseat didn't mess up was the main thing i was checking here
<zyga> Lathiat: works okay now... hmm
<fabbione> Kamion: ehhe ok :)
<Lathiat> zyga: i've seen that a couple times recently tho
<Lathiat> perhaps it juts got stuck
<zyga> Lathiat: can firefox be updated when running?
<zyga> Lathiat: the ugly part is that the script just executed and exited immediatly, no comments - no warnings
<zyga> (script = firefox)
<zyga> on the other hand
<zyga> I've got all supported languages installed
<zyga> and updating-chrome-registry after ech one got updated took ages
<zyga> is it possible to delay rebuild-someting after all things that need to do it get updated?
<trukulo> hi ppl
<gsuveg> doh. cups dont works on my amd 64, it drop signal 15  :(
<doko> pitti: like to test another OOo xhosa package (chinstrap:~doko)?
<Mithrandir> doko: both the buildds and my network connection loves you. *smirk*
<doko> Mithrandir: :) no, that will not become another OOo upload.
<pitti> doko: would it work now?
<amu> pitti: pong
<Mithrandir> doko: ok :)
<doko> pitti: it should ...
<Mithrandir> doko: really, I don't mind, it just takes a little while.  I'm on a 100Mbit connection.
<doko> Mithrandir: "a while" ... :-P
<pitti> Mithrandir: someday I will hit you really, really hard if you complain about "only" a 100 MBit connection ... :-)
<Mithrandir> pitti: I complain when I have to regularly update 250-ish MB source packages, yes. :)
<CarlK> I used the gui, system, admin, networking to set an IP, it set it (ifconfig shows it) but dhclient is still running and renewing the lease.  for a bugzilla, I want to post the file showing that the static was really set - where is that stored?
<thom>  /etc/network/interfaces
<CarlK> perfect: iface eth0 inet static
<fabbione> dholbach: i am looking at hula now....
<Kamion> fixed powerpc DVD rebuilding
<fabbione> Kamion: rocking...
<pitti> Kamion: cool, thanks
<fabbione> Kamion: can you test it directly?
<fabbione> pitti: can you find a way to rsync it?
<Kamion> fabbione: theoretically yes, but not for ~12 hours
<Kamion> my amd64 DVD from last night is *still* rsyncing
<fabbione> Kamion: i guess we need that done before that :)
<Kamion> yes
<fabbione> Kamion: are you kidding?
<Kamion> nope, it's at 74%
<fabbione> Kamion: i would run a tcpdump on that :)
<Kamion> it did get some benefit from rsyncing
<fabbione> pitti: can you rsync? if you had the last dvd image, i guess the rsync bits will be very small
<pitti> fabbione: amu has bandwith, and I could download it to an uni computer and go there to fetch it
<Kamion> but my connection doesn't get much beyond 50/60kB/s
<fabbione> pitti: how long would that take for you?
<fabbione> Kamion: ok... i understand
<fabbione> amu: ping?
<pitti> fabbione: download should be relatively fast, I need 20 minutes with the bike to the uni, half an hour for copying, twenty minutes back
<pitti> fabbione: I already asked him
<pitti> Kamion: can you please ping if the image is ready?
<fabbione> pitti: if it's not too much of an issue could you that please?
<Kamion> pitti: sure
<amu> cool,thx
<pitti> fabbione: sure
<fabbione> pitti: thanks, i would really appreciate that
<pitti> sure
<pitti> fabbione: btw, it starts to rain, add another 10 minutes for the bus :-)
<fabbione> pitti: ok :))))
* pitti finds somebody in the uni to bother about this
<doko> fabbione: did you have success booting the powerpc DVD? 
<fabbione> doko: no.. it doesn't boot on my P4
<doko> the DVD is detected when I insert it on a running system, but not at boot time.
<fabbione> doko: ENOPPC here...
<fabbione> doko: no.. it doesn't boot on my ---> P4 <---
<doko> fabbione: oops, I read G4 ...
<Kamion> meh
<fabbione> i wrote it on porpouse :)
<Kamion> well, if it doesn't boot properly, we just don't release it
<Kamion> but I'd like to know why, there may be time to fix it
<doko> how can I help?
<fabbione> Kamion: as mdz wrote this morning, we can try to get it fixed as much as we want
<fabbione> Kamion: we just don't have to touch the rest
<Kamion> doko: figure out why it won't boot :-)
<Kamion> could be your OF just doesn't like DVDs, and there'd be nothing we could do about that
<Kamion> doko: does it make it into the CD's yaboot, even?
<smurfix> doko: You might try burning one of the CD ISOs onto a DVD
<doko> kamion: no, I get the one from the HD
<doko> smurfix: ok, I still have three blanks ... what a waste :-(
<smurfix> doko: DVD+RWs are your friend
<smurfix> doko: (except when booting from those is even less reliable :-/ )
<doko> hmm, DVD-RWs are supposed to work as well?
<adobbie> why not just burn a test disc on a regular +-R?
<smurfix> depends on the firmware I guess ... I haven't tried on Macs
<smurfix> adobbie: some people around here already have too-large stacks with dud CDs, thank you very much ;-)
<doko> adobbie: no it _is_ a DVD-R
<Kamion> ok, new powerpc DVD up, should be fixed
<dholbach> fabbione: thank you so much
<Kamion> I've hardlinked the old amd64/i386 DVDs into the same directory
<adobbie> smurfix: I collect coasters :) I have about 320 DVDs/CDs
<adobbie> some are just old discs with no longer useful data however
<smurfix> adobbie: I'm recycling them, I already have enough useless stuff lying around here
<pitti> Kamion: http://cdimage.ubuntu.com/dvd/20050407.1/hoary-dvd-powerpc.iso is the right one?
<adobbie> smurfix: my goal is to make furniture out of them someday
<smurfix> adobbie: well, I've seen worse lifetime goals, but still  ;-)
<pitti> Kamion: what's wrong here?
<pitti> wget http://cdimage.ubuntu.com/dvd/20050407.1/hoary-dvd-powerpc.iso
<pitti> 13:26:31 (0.00 B/s) - `hoary-dvd-powerpc.iso' saved [0/-1272184832] )
<pitti> -> 0 byte
<adobbie> -1272184832
<Treenaks> pitti: -1272184832.. nice :)
<adobbie> funny
<fabbione> pitti: you cannot wget a dvd
<fabbione> pitti: 32 bit limits
<pitti> *grumble* wget *grumble* 32 bit *grumble
<HiddenWolf> Ugh. Did the artwork per any chance change to a darker shade of brown.
<doko> hmm, my pbook just ejects a blank DVD+RW ...
<HiddenWolf> I just restarted rythmbox, and the colors differ from the rest of the desktop. :)
<kain> HiddenWolf, I've the same behaviour
<pitti> fabbione: I use lynx now, hope that works...
<fabbione> pitti: no rsync?
<pitti> fabbione: what for?
<fabbione> pitti: since it handles 64 bit without any problem?
<pitti> fabbione: I don't have a DVD image at the uni, and download with 1.7 MB/s is fun :-)
<pitti> lynx won't?
<fabbione> pitti: dunno...
<fabbione> i hope for you
<pitti> okay, let's try it :-)
<Kamion> you can rsync from nothing, of course
<Kamion> bit slower than just getting it, though
<pitti> Kamion: yeah, but isn't that a bit too much overhead?
<pitti> ETA 29 minutes
<HiddenWolf> pitti, stop making us jealous. :)
<pitti> HiddenWolf: unfortunately it's download to the uni, not to my home
<pitti> HiddenWolf: at home I have a mere 60 kB/s
<HiddenWolf> pitti, suffering the same fate here
<pitti> HiddenWolf: and 3GB/week traffic limit
<HiddenWolf> pitti, ouch. 
<adobbie> pitti: I feel sorry for you, I'd cry if I had a 25GB/week limit
<HiddenWolf> I DL about 3gb per day, really.
<pitti> I can't get a better link here where I live :-(
<pitti> well, for 10K per month, probably
<HiddenWolf> For me the agony is that I can get 10mbit sync, but can't afford the eur20/month extra atm
<doko> Kamion: should the new powerpc DVD make a difference regarding the booting capabilities?
<pitti> erm, good point, a previous ppc dvd did not boot for me either
<Mithrandir> hmm, seems like mdadm has a race condition; fsck is sometimes tried on the not-yet-existing RAID devices.
<Mithrandir> (since /etc/init.d/checkfs.sh runs so quickly after mdadm-raid)
<Kamion> doko: shouldn't
<Kamion> pitti: yeah
<pitti> Kamion: darn, I try it anyway
* pitti -> uni, cu later
<Kamion> hm
* Kamion looks at debian-cd changes for sarge
* Kamion waits for baz to get its life together to show him diffs
<robertj> https://bugzilla.ubuntu.com/show_bug.cgi?id=8516 <- :(
<Kamion> doko: ok, looks like there's a debian-cd patch I need to pull in to get the HFS catalog right on the powerpc DVD
<Kamion> once I get a proper delta out of baz, I'll apply it
<doko> ok, thanks, will you update the images again?
<Kamion> doko: yes, in time
* kain is away: simps
<Mithrandir> anybody seen mjg59 around lately?
<pitti> hi guys
<astharot> hi Martin1
<astharot> !
<pitti> Hi astharot 
<zul> hey
<elmo> seb128: ?
<seb128> elmo: pong
<elmo> seb128: you asked for gal2.2 to be dropped, but abiword still uses it?
<seb128> $ apt-cache rdepends libgal2.2-1
<seb128> libgal2.2-1
<seb128> Reverse Depends:
<seb128>   libgal2.2-common
<seb128>   libgal2.2-dev
<seb128> hum
* Kamion sighs and kills the DVD build yet again, fixing debian-cd harder
<elmo> seb128: abiword b-d's on it
* Lathiat comforts kamion
<Lathiat> seb128: apt-cache has an rdepends? heh sweet.
<seb128> elmo: I'm wondering why if it doesn't link with it. Can we fix universe stuff today ? If so I'll fix abiword
<seb128> is that the only package using it ?
<dholbach> seb128: sure... fix! :-)
<seb128> dholbach: and new version ? :p evince 0.2.0 by example :)
<mjg59> Mithrandir: Hi
<elmo> seb128: abiword's in main, dude
<dholbach> seb128: sure
<mjg59> Mithrandir: Re your battery thing - no idea whatsoever, I'm afraid
<elmo> seb128: abiword's the only thing in main using it, yes
<elmo> there's a bunch in universe, one sec
<seb128> elmo: k, forget about it for the moment so
<seb128> I'll fix all that for breezy
<Mithrandir> mjg59: hiya; ok, weird.
<elmo> seb128: ok - sorry for not getting it to earlier
<Mithrandir> mjg59: it seems like nstx isn't 64 bit clean.
<Lathiat> will there be any cd rebuilds anytime soon?
<mjg59> Mithrandir: Christ. This fails to surprise me.
<elmo> Mithrandir: dude, it's not even signed char clean
<mjg59> Mithrandir: It builds but doesn't run?
<Kamion> Lathiat: for what?
<Lathiat> Kamion: i386 install
<elmo> 64-bit clean is about 20 years too futuristic for it
<seb128> elmo: np, that's just an extra package for the archive, doesn't break anything
<Kamion> Lathiat: no, I mean for what reason?
<Mithrandir> mjg59: it builds, runs and falls over when it gets a packet.
<Lathiat> Kamion: just want to know before i went off bashign the current build
<Mithrandir> building it in 32 bit mode makes it work
<Kamion> Lathiat: unlikely] 
<mjg59> Mithrandir: Which version?
<Kamion> -] 
<Lathiat> Kamion: cool thanks
<dholbach> seb128: for breezy we should have big transition lists with all those old crap and chuck it out for good
<Mithrandir> mjg59: 1.1-beta5-6
<Kamion> Lathiat: if there are, they'll be very fast to rsync; but I hope not
<mjg59> Mithrandir: Right, it only works by accident
<mjg59> You need beta6-2
<dholbach> seb128: the MOTUs will be pleased to hear about even more lists ;-)
<Lathiat> Kamion: well yeh i was just more concerned that i was about to waste time if you were goign to do another rebuild within the next hour or something :)
<mjg59> Still no idea if it'll work on 64-bit, but it stands a better chance
<seb128> dholbach: yeah :)
<Mithrandir> mjg59: ok.  In unstable?
<Kamion> Lathiat: no, powerpc DVD is the only one I plan to change
<mjg59> Mithrandir: Yup
<Lathiat> Kamion: ok
<Mithrandir> mjg59: ok, I'll give it a shot post-hoary.
<dholbach> can anybody help me _PLEASE_ with decisions on http://people.ubuntu.com/~james/paste/002.txt and http://people.ubuntu.com/~james/paste/003.txt - i consider removing them wrt to unsupported-kernel-stuff-in-universe?
<Lathiat> well, if they can't build, they can't build...
<Lathiat> so theyre useless anyway?
<dholbach> no, it's not about not building
<dholbach> the packages on the right side are about to be removed, the ones on the left side depend on them
<Mithrandir> xen would be a shame to lose
<Lathiat> eek i just told synaptic to do an auto upgrade off this cd adn it crashed
<Mithrandir> dholbach: cpqarrayd too, for those who have the HW.
<dholbach> Mithrandir: i was told it was pretty useless
<zul> Mithrandir: there is going to be xen packages for breezy anyways i think
<dholbach> problem is: the patches these things depend on, dont apply on our kernels
<dholbach> i reviewed those patches closely and put the ones to be removed on MorgueCandidates
<dholbach> s/closely/briefly
* dholbach should get another coffee
<Mithrandir> dholbach: ok, let them go, then.
<dholbach> ok here goes my rant: hearing "they're not supported" and having to mess with unbuildable/uninstallable stuff is WAY SHITTY, i can't decide on all of this crap, since i'm not clever enough
<dholbach> </rant>
<Mithrandir> dholbach: why not just nuke them, then?
<dholbach> because i don't want to receive the hate mails alone
<dholbach> i don't use those packages and have no clue about how they work
<dholbach> i know it's very late in the release process to make those decisions, so i'd highly appreciate suggestions, ideas and complaints now
<pitti> Kamion: can I reassign #8557 to you?
<Mithrandir> dholbach: if those are unbuildable, they're useless.
<Kamion> new powerpc DVD up, stands a better chance of being bootable
<dholbach> ok... will have to investigate then
<Kamion> pitti: yeah, I guess so, sorry I haven't had any chance at all to look at it
<torkel> dholbach: you can probably nuke/move away arla-modules-source too, as it is unbuildable with the kernel in hoary
<dholbach> *making notes*
* Mithrandir hates mkinitrd with a lot of passion
<pitti> guys: do anybody of you know a tool to download a DVD image through http?
<pitti> rsync is blocked here in the uni
<pitti> and mozilla/ffox etc. truncate the files to 2 gb
<Mithrandir> pitti: rsync over ssh?
<pitti> Mithrandir: ssh to where? cdimage.u.c?
<pitti> wget doesn't work either
<Kamion> rebuild wget with LFS?
<pitti> *sigh*
<Kamion> or try curl?
* pitti just wants these damn images
<fabbione> pitti: ssh ?
<pitti> fabbione: give me ssh acccess to cdimage.u.c :-)
<fabbione> pitti: copy the image to roockery and scp
<pitti> fabbione: copy with curl?
<Mithrandir> pitti: ssh -L 1400:cdimage.ubuntu.com:873 chinstrap ; rsync --port=1400 localhost::whatever 
<fabbione> pitti: rsync from cdimage to roockery and than scp?
<fabbione> as Mith said too is good
<pitti> ah, that would work
<pitti> Mithrandir: cool
* Mithrandir is getting good at those "get out of blocked network" practices.
<dholbach> bbiab
<lamont> funny... I don't remember asking for a sync of memtest86...
<fabbione> lamont: probably elmo wants to blame it on you :P
<Mithrandir> lamont: I asked for a memtest86+ sync some time ago.
<Mithrandir> like, a week or two
<fabbione> Mithrandir: yeah, but that one is memtest
<fabbione> not +
<Mithrandir> fabbione: I know, but I wasn't sure if lamont knew there are two.
<fabbione> i am dead tired
<fabbione> and i also need to go to the block meeting
<fabbione> i hate to sit there 2 hours without getting a clue of what they are talking about
<lamont> Mithrandir: yeah, I know
<thom> Kamion: you don't fancy triggering orcadas, do you? just so i can see what the torrent stuff is up to...
<Kamion> thom: done
<jani> Kamion, I'd like to make an xfce-ubuntu-desktop metapackage to ease upgrades for xfce users. Copy over kubuntu-meta, search and replace, add/remove packages to the four architecure desktop files and that's it or is something deeper involved? Only universe of course. thanks
<Kamion> jani: kubuntu-meta is managed automatically using seeds, see SeedManagement on the wiki
<Kamion> but really for something the size of xfce there's probably no need to go for the full complexity of ubuntu-meta / kubuntu-meta, just write out the list of packages you want by hand
<thom> Kamion: thanks
<thom> Mithrandir: if you can, please try grabbing one of the torrents from torrent.ubuntu.com and seeing if it works for you? (one of the daily or daily-lives)
<doko> hmm, how do I start the live session from the DVD?
<Kamion> doko: type 'live' at the boot: prompt
<Kamion> yes, it's not documented :(
<Kamion> although actually it is documented for the powerpc DVD
<Mithrandir> thom: checking
<doko> kamion: is the bootable power dvd at cdimage?
<Kamion> doko: yes
<Kamion> well, maybe-bootable
* doko is syncing ...
<Mithrandir> thom: sits there "connecting to peers".
<thom> give it a minute
<Mithrandir> I've given it two
<thom> god knows why, but it takes for ever to get going if there's just the peer in the DC available
<Mithrandir> there it strarted
<thom> which one did you get?
<Mithrandir> amd64
<Mithrandir> daily-live amd64
<thom> cool
<thom> so it looks like auto-torrent is working correctly
<thom> lets hope it continues to do so
* Mithrandir wastes some more bandwidth by grabbing the others too
<Mithrandir> I wonder why I don't get more than 1MB/sec to the DC though
<doko> Kamion: where's the master index.html for http://cdimage.ubuntu.com/dvd/current/ ? Want to make it clearer by adding two enumerations (to start the installer, do ..., to start the live CD ...)
<Mithrandir> thom: sounds like we should have at least one out-of-the-DC mirror, then?
<Mithrandir> thom: bittorrent mirror network. ;)
<doko> 1920x1200 display detection doesn't work on the live CD
<thom> Mithrandir: agree
<doko> daniels: ^^^
<Kamion> doko: I don't think documentation of how to boot the thing belongs on that page, really
<doko> kamion: it already does (in parantheses)
<Kamion> doko: I suppose
<Kamion> unfortunately the instructions differ substantially by architecture
<doko> any better place? that's only needed for the DVD
<Kamion> dunno; I'll think about it in a minute, I'm bodging together a jigdo-a-lite at the moment
<Kamion> (download all packages from local mirror, cat together in the right order, rsync against DVD)
<maswan> Mithrandir: I'm working on that, cdimage is just a bit too big at the moment.
<Mithrandir> maswan: cool
<Kamion> maswan: how much too big? maybe I can help
<maswan> Mithrandir: So we're in the process of investigating additional storage.
<maswan> Kamion: I'll get back to you in a week or two if the current process does not go well. :)
<Kamion> ok
<pitti> seb128: n-cd-burner can burn DVDs, right?
<pitti> seb128: I need to burn a CD on a gentoo system, what does n-cd-burner use as burning backend?
<seb128> dvd+rw-tool
<pitti> seb128: thanks
<fabbione> Kamion, thom: did you talk with Md about torrents mirroring?
<fabbione> Md was offerring a release mirror on another 1xFE machine
<ogra> pitti, you also need enough space in /tmp for the image if you use just drag n drop 
<pitti> ogra: I don't have n-c-b on the box, it's a gentoo one without gnome
<ogra> ah, ok
<pitti> cool, growisofs seems to work
<fabbione> daniels: http://kecy.roumen.cz/roumingShow.php?file=architectural_geekery.jpg <- multiarse!
<fabbione> daniels: for some reason xorg doesn't detect my monitors :)
<fabbione> pitti: how is going the DVD test?
<pitti> fabbione: it currently burns
<pitti> fabbione: it was a real hassle to get it, believe me
<pitti> fabbione: I download the i386 one, ppc burn is at 48%
<Treenaks> fabbione: is that a GNU Arch?
<pitti> fabbione: I seriously hope that his one really boots (an earlier one didn't)
<fabbione> pitti: only ppc is the issue now..
<pitti> yeah
<fabbione> pitti: if it doesn't and Kamion is out of ideas, we will release without ppc DVD
<fabbione> Treenaks: eheh
<pitti> fabbione: gimme another 10 minutes until the dvd is burnt :-)
<fabbione> sure
<pitti> dvd is ready  !! :-)
* fabbione does the ppc boot dance
* pitti reboots to test
<Mithrandir> uhm
<Mithrandir> the ubuntu-artwork has a typo.  In the heading.
<Mithrandir> "Welcome to Ubuntu Linux 5.04: The Hoary Hehdeghog Release"
<jdub> Mithrandir: update :)
<ogra> here it is: Welcome to Ubuntu Linux 5.04: The Hoary Hedgehog Release
<Mithrandir> ok, I'm probably just not up-to-date, then.
<Mithrandir> jdub: don't give me heart attacks just like that
<Mitario> hi everyone
<mvirkkil> jdub: Have you had a chance to look at the gnome-app-install patch I sent?
<jdub> mvirkkil: unlikely any of us will get to it until next week ;)
<pitti_live> fabbione, Kamion: I quickly test the first phases of the install dvd/ppc, then return back to my normal system
<mvirkkil> jdub: Should've figured as much =)
<fabbione> Kamion: YAY
<fabbione> pitti_live sounds good :)
<pitti> re
<daniels> doko: the usual xorg.conf and Xorg.0.log please
<jbailey> infinity: ping?
<Kamion> pitti: it boots?
<pitti> Kamion: perfectly
<Kamion> rock
<pitti> Kamion: live session runs well, install as well
<pitti> Kamion: you rock :-)
<doko> dabiels: #8757
<doko> daniels: #8757
<jani> is there an env-var to use with dpkg-buildpackage to make debug builds?
<jani> without tweaking rules by hand
<doko> DEB_BUILD_OPTIONS=debug dpkg-buildpackage ... if the package honors that
<Kamion> used to be DEB_BUILD_OPTIONS=debug, but nowadays most packages are supposed to build with debug on by default
<Kamion> try DEB_BUILD_OPTIONS=nostrip to avoid stripping debugging symbols
<jani> thanks, I'll try those
<fabbione> Kamion: i guess we are done.. for hoary :)
<doko> pitti: was that the report for the new powerpc DVD, it's still syncing for me ...
<mdz> morning
<fabbione> hey mdz
<thom> morning matt
<mdz> how do we look?
<fabbione> mdz: very good
<pitti> Morning mdz
<fabbione> mdz: Kamion fixed the ppc DVD
<fabbione> mdz: one test is ok
<mdz> yay
<fabbione> mdz: we miss your
<pitti> yeah, works great for me now
<pitti> fabbione: ... final ok?
<mdz> where is it?
<Kamion> fixed (a) the yaboot.conf/boot.msg, (b) the HFS catalog so that it's actually bootable
<Kamion> mdz: usual place
<Kamion> mdz: I hardlinked the previous amd64 and i386 DVDs in beside it, for simplicity
<Kamion> they haven't been rebuilt
<mdz> rsyncing
<jani> ok the DEB_BUILD_OPTIONS thing worked binary are not stripped, but...
<jani> is there a way of making it link to -dbg libraries?
<jani> so I can debug the app down to glib in my case
<Mithrandir> jani: you don't link to dbg libraries, just install them and gdb will use them automatically
<jani> ah ok didn't try stepping into it will do, thanks
<jani> just saw the ldd show libraries from /usr/lib and thought it's not enough
<daniels> doko: uhm, it's amd64, nothing will get detected automatically
<daniels> doko: picking 1920x1200 from the list didn't work?
<jani> well I guess it's not that easy since I'd need sources for all libs too...
<doko> daniels: so, installing from the i386 CD on an amd64 doesn't help either? picking from which list on the live-cd? in the gnome resolution preferences: yes, this works.
<daniels> oh, that was an i386 cd?
<daniels> in that case, output of sudo ddcprobe would be handy
<daniels> i suspect ddcprobe is buggy and picking it up as analogue-input when it's not
<mvirkkil> Any suggestions for improving gnome-app-install?
* HiddenWolf just noticed rsync synced a perfectly good image down to 250kb
<mdz> elmo: thanks for remembering about gvr; I would have been in deep shit if it didn't go in
<elmo> mdz: sorry for not doing it until t-18 hours :/
<elmo> gack
<elmo> does zwiki have a raw download ability?
<Nafallo> mvirkkil: I would love if gnome-app-install detected totem-xine as totem installed ;-).
<doko> daniels: attached. maybe the last dtiming line is selected?
<mvirkkil> jdub: Any suggestions for improving gnome-app-install?
<jdub> mvirkkil: ask me next week :)
<fabbione> elmo: mind to give a sparc pulse, before the bw will be killed for the next days?
<mvirkkil> Nafallo: I saw a bug about that. I'll see what I can do, but I'm afraid it will be non trivial.
<mdz> elmo: argh NO, it has broken python deps
<elmo> *whine*
<Nafallo> mvirkkil: I layed the bug :-). Lack of comments I thought it was unnoticed ;-). thanks in beforehand.
<jdub> Nafallo: the totem .desktop should just use 'totem'
<elmo> call the MOTUmobile
<elmo> hmm, damn charles has already run away
<elmo> fabbione: done
<fabbione> elmo: thanks. btw no uploads for the next few hours.. it's munging ooo :)
<elmo> hey, that reminds me
<elmo> do we want stable symlinks in the archive?
<Kamion> elmo: zwiki raw> http://www.ubuntulinux.org/wiki/WikiWishlist says to append /src or /text to the URL
<fabbione> elmo: and how would you handle warty? as old-stable?
<elmo> kamion: score, thanks
<Lathiat> 'stale' :)
<elmo> fabbione: either that or nothing
<elmo> 'cos warty's here for 18 months, and old-old-stable would be, well, silly ;)
<Kamion> Lathiat: we can just keep deleting letters until the name is empty, at which point we purge the suite
<mdz> fix0ring
<fabbione> elmo: with breezy out, warty would be very-old-stable :)
<mdz> elmo: stable symlinks are evil
<fabbione> elmo: yeah exactly my point ;)
<Lathiat> and then extremely-old-stable ?
<Mithrandir> or just very-stable
<Mithrandir> and ultra-stable.
<fabbione> Mithrandir ++
* Lathiat thinks it should just be 'warty'
<Nafallo> jdub: it doesn't?
<Lathiat> Mithrandir: haha
<Kamion> dwarf-bread
<Mithrandir> (in the IBM sense of the word "stable")
<mdz> also-also-stable
<Mithrandir> (meaning "dead")
<fabbione> stable -> warty
<Kamion> also-sprach-zarathustra
<fabbione> possibly-stable -> hoary
<fabbione> will-be-stable -> breezy
<daniels> doko: er, where did you attach ddcprobe output?
<Kamion> we could use stable for blessed five-year-plan releases, if those ever happen
<mdz> Kamion: so as I slept, I thought about what a shame it is about the bootloader text on the DVDs
<Mithrandir> we have a software management system at the university with 10 different stability levels.
<Mithrandir> Kamion: "rock-1", "rock-2" and so on?
<Kamion> mdz: you're going to ask me to fix it, aren't you? :)
<mdz> Kamion: I'd like to give it a shot; if we don't get there in time, we can release with what we have
<Kamion> I can bodge it in debian-cd if I have to; I'd rather not fix the other boot screens though
<doko> daniels, ok, forgot to enter the description
<mdz> just isolinux.txt
<Kamion> i.e. the f1-f10 help menus will probably still say CD and talk about installation
<Kamion> ok, that's doable
<mdz> we've gone to some trouble over the live stuff; it'd be a shame to keep it a secret ;-)
<mdz> that's the only thing I'm interested in; instructing the user to type 'live' to get a live session
<Kamion> mdz: I'll let my jigdo-for-dummies approach to downloading the powerpc DVD finish, and then give it a go
<fabbione> mdz: let me remind you that this morning you told me that it was too time consuming :)
<mdz> fabbione: I know, but I have slept now, and I feel secure in the fact that everything else is OK
<daniels> Mithrandir: eh, surely we'd have to symlink rock -> ../debian
<fabbione> mdz: ehheh :)
<Kamion> mdz: (a.k.a. "cat live CD, cat all debs and udebs listed in the ISO indexes in extent order, rsync the result")
<mdz> first things first
<mdz> Kamion: haha
<mdz> my powerpc dvd is a bit older than I'd like due to running out of disk space
<mdz> so it'll take a bit for me as well
<fabbione> Kamion: when i installed from the DVD (i386) partman gave me the option to partition my DVD :)
<Mithrandir> mdz: nothing like testing while asleep?
<fabbione> Kamion: does it recognize DVD that can work in packet mode?
<Mithrandir> "I've slept on it, and it didn't give me nightmares.  Must be stable"
<Kamion> fabbione: yes
<Kamion> fabbione: libparted claims that a DVD-RW is writable
* pitti returns home
<Kamion> it's not ideal, but fixing it didn't seem obvious
<fabbione> Kamion: eheh neat
<fabbione> i should try to install on a DVD from a net boot
<Kamion> To run a preinstalled system from the DVD, type 'live' then ENTER.
<Kamion> mdz: will that do?
<mdz> Kamion: sabdfl? ^^
<Kamion> mdz: he's not here
<sladen> 1/whois mako
<daniels> doko: right, it's what i thought, it picked up your lcd as a crt
<daniels> doko: xserver-xorg did the right thing given the circumstances.  i'll look at xresprobe code later.
<dholbach> re
<thom> right, i need to go out for about 4 hours. back about 2100
<Mithrandir> jbailey: seems like mkinitrd is massively unhappy when / is on /dev/i2o/hda. :/
<jbailey> Mithrandir: Is this a new bug, or a configuration you've not tried before?
<Mithrandir> jbailey: untried, cause I don't have boxes with expensive raid controllers lying about.
<jbailey> Mithrandir: 'kay.  I don't think we have any magic in there right now to dealw ith /dev/i2o* at all, and I think that udev-in-initramfs make that silently work.  Is this a system you generally have access to for playing with?  If so, for how long?
<Mithrandir> jbailey: it's ordinarily in production, but I can always take it out.
<Mithrandir> it's being reinstalled now
<jbailey> Mithrandir: I'm curious if the initramfs stuff I have now already detects it correctly.  I suspect it would.
<jbailey> Mithrandir: It's not integrated to the installer, though, so it needs to be done from a runnign system.
<jbailey> Hmm.  I could just hand you an initramfs to try, though.  Even just dropping to a shell and seeing if the node is there with right major, minor would be enough I guess.
<Mithrandir> jbailey: I can check if I can get you a shell on the box.
<jbailey> Mithrandir: That's cool, but unless there's serial access, I can't do the reboot test to see into the initramfs and see if it's actually working.
<Mithrandir> jbailey: to complicate stuff, the system is 500kms away from me, so I have to ask people to do stuff which needs console access.
<Mithrandir> I can see if I can arrange serial
<Mithrandir> that ought to work.
<Mithrandir> I got to run an errand for Karianne first; managed to have one of her gerbils bite her finger, brb.
<sterwill> I upgraded one of my servers to Hoary RC yesterday, and I think I've found a critical bug in the snmpd package.
<fabbione> sterwill: what kind of bug?
<fabbione> (given that it is too late to get it fixed anyway)
<sterwill> /var/lib/snmp is created owned (and only writable) by root, but snmpd runs as user snmp.
<sterwill> So it complains via syslog that it can't open files there, and custom user tokens won't ever take effect.
<fabbione> sterwill: this is a possible canidate for hoary-updates..
<lamont> sterwill: that sounds like one for bugzilla
<fabbione> please file a bug in bugzilla with all the details
<sterwill> OK, I'll file it.
<sterwill> Most people never use this functionality, so they can just ignore the warnings in syslog.
<doko> Kamion; powerpc DVD works ok on a Powerbook
<Kamion> doko: kewl, thanks - my rsync's at 50% here
<Kamion> doing the maths I think that means it's busy downloading language packs which weren't up to date on my mirror
<tritium> fabbione, I saw your review of krecipes.  Do you recall if it had a lintian.override for the warnings at the time you reviewed it?
<fabbione> tritium: yes, it did
<fabbione> i did the review 2/3 hours ago
<fabbione> according the url on the wiki
<fabbione> tritium: the lintian override triggered my attention to the problem
<mdz> powerpc DVD live successful, powerpc DVD install in progress
<tritium> fabbione, okay, just checking.  I used the override based on the wording of paragraph 3: http://64.233.161.104/search?q=cache:uLZusixuXP0J:lintian.debian.org/reports/Tnon-dev-pkg-with-shlib-symlink.html+&hl=en&start=1
<fabbione> no no...
<fabbione> tritium: the package needs splitting
<fabbione> there is no override there
<fabbione> it's just wrong
<fabbione> tritium: the override should not be there in the first place. and the source should create the 3 packages i mentioned in the review
<fabbione> the use of overrides is just bad.
<fabbione> not because you are using it wrongly.. 
<fabbione> it should be used at all :)
<tritium> fabbione, okay, thanks.  Since the package was small, I thought I could trust the info on lintian.debian.org
<tritium> I will ask ogra not to upload it.
<fabbione> tritium: lintian is a checker.. it cannot understand that the package needs a split
<Kamion> overrides aren't necessarily bad; however, they should only be used when lintian is generally correct about that particular type of problem, but when the package in question is a legitimate weird exception
<fabbione> tritium: the warning on the libs should have ring a bell that something was wrong :)
<sterwill> I'm not sure which package to log the bug against.  /var/lib/snmp is part of three packages (libsnmp5, libsnmp-base, libsnmp4.2), neither of which puts any files in it.  snmpd puts the file there when it starts (as root), then sets its uid to snmp, and can't open it when it closes.
<fabbione> Kamion: yes and i agree with you when you have a certain experience in understanding lintian
<tritium> fabbione, yes, but it appears to be a reasonable exception, rather than making 2 new packages for only 2 files
<dholbach> i'm not sure there is something wrong with the package... the paragraph tritium cited seems to be exactly the corner case he hit
<fabbione> tritium: no exception there.. libs needs to be packaged in a certain way, and the -dev package too.
<fabbione> tritium: there are very good reasons for doing it
<Kamion> fabbione: (I agree with you in this case, though)
<fabbione> dholbach: the problem is that the final .deb has libs and headers in it. together with the program that uses them
<tritium> fabbione, fair enough.
<fabbione> tritium: let me find you a reference for it
<dholbach> hrm
<tritium> fabbione, the URL above is what I referenced.
<fabbione> dholbach: in that case you need a libfoo$soname, libfoo-dev and the foo-application
<tritium> I pasted the google cache since lintian.debian.org seems to be donw
<tritium> down
<fabbione> tritium: no, i am searching the reason why it is good to have a split
<tritium> fabbione, I don't question you on that point.
<dholbach> fabbione: i understand the case in general and had that solution in mind as well, but it seemed to be a bit of overkill - but maybe my judgement is plainly wrong
<fabbione> dholbach: check all the libx<$whatever>
<fabbione> the are all made of 2/3 files
<tritium> dholbach, it's not your fault.  It was my judgement.  I should not have trusted the info on lintian.debian.org
<fabbione> ok i need to get dinner now.. wife is calling
<fabbione> i will come back in a short time
<dholbach> fabbione: libx* is actually being used :-)
<fabbione> and we can talk again
<dholbach> alright
<tritium> see you, fabbione 
<pitti> hi again
<astharot> ciao
<mdz> new DVD images are syncing
<Kamion> I was about to say that they're up, yeah
<Kamion> again, I've hardlinked the previous powerpc image in there to avoid confusiong
<Kamion> -g
<mdz> thanks
<lamont> Kamion: cdimages are still the same as last night (archive-copier)?
<Kamion> lamont: I fixed archive-copier and we respun the CDs
<lamont> right
<lamont> those, I have.
<lamont> how golden do we think these are?
<mdz> elmo: how soon can we get the ISOs mirrored once they're published to releases?
<mdz> elmo: we have some time, so we can do it early if needed, and maybe catch some normal mirror pulses
<Kamion> I'll do the pre-publish thing in a moment
<elmo> mdz: how do you mean?  triggered folks or non-triggered folks?  I don't have timing info for the latter
<mdz> elmo: both
<mdz> elmo: mm, no logging from rsyncd?
<mxpxpod> is there a reason my OO.o icons in the panel menu aren't showing up?
<pitti> Kamion: erm, yet another DVD image now?
<Kamion> pitti: yes, boot screen text change
<elmo> mdz: sure, but given rsync limits, round-robining, determing other people's schedule isn't trivial
<pitti> Kamion: ah ok, so rsync should be fast
<Kamion> should be quick to rsync
<dholbach> is the amd64 dvd sane now
<dholbach> ?
<Kamion> mdz: so what's the schedule for tomorrow morning? i.e. what time do I need to get to sleep / not go to sleep / whatever?
<Kamion> dholbach: should be, I have it here but haven't quite tested it yet
<dholbach> Kamion: alright, will rsync
<Kamion> dholbach: thanks for testing
<dholbach> Kamion: de rien
<elmo> mdz: triggered ones should be done in minutes, depending on amount to sync
<tritium> Kamion, have you had many people testing on G5?  I've got access to one that I check the LiveCD on...
<tritium> "can" check, that is
<Kamion> tritium: G5 testing has been patchy, more would definitely be appreciated; there've been problems on certain models, usually kernel-dependent I think
<tritium> Kamion, okay, I'll give it a try.
<Kamion> mdz: it'd be good if we could get the release up somewhat in advance of the announcement to give a few mirrors the chance to start torrent seeding; Md offered to do that if he got some notice
<elmo> I thought the announcement was due like 8am tomorrow?
<fabbione> elmo: 8 UTC 
* fabbione rsyncs i386
<fabbione> tritium, dholbach: should we take the lib stuff on #ubuntu-motu?
<Kamion> ok, releases.ubuntu.com/.pool/ should have the probably-final images now
<dholbach> fabbione: i trust your judgement completely and will be off testing amd64-dvd-install in some minutes
<tritium> fabbione, only if you have time.  I don't want to take you away from important stuff.
<mdz> Kamion: 0800 UTC has been the release announcement target
<Kamion> mdz: same question as for RC: where are Kubuntu images going?
<mdz> Kamion: agreed, re: mirrors
<Kamion> mdz: ok, I'll nap and be up early then
<fabbione> dholbach, tritium: i have time and it is important for both of you to understand :) it's not just question of judgment ;)
<mdz> Kamion: was the reason for not publishing them to releases that we hadn't prepared the publishing scripts, or due to not wanting to inflate the size of releases?
<mdz> we will need mirrors for kubuntu nearly as much as for ubuntu, I expect
<Kamion> mdz: partly the latter and partly that we thought it implied Kubuntu being golden, I thought
<mdz> Kamion: I'd like them on releases unless there's a compelling reason not to do so
<mdz> have they been tested yet?
<elmo> giggle
<mdz> Kamion: I suppose we should roll new kubuntu DVDs
<Kamion> I'm already doing that
<mdz> thanks
<SuperQ> I saw that the new ubuntu-artwork package has the new circle of people
<SuperQ> but the screenshot is old
<Kamion> mdz: there's discussion in http://people.ubuntu.com/~fabbione/irclogs/ubuntu-devel-2005-03-30.html, search for /kubuntu
<SuperQ> so when you browse to it in the theme manager, you see the 3 people from warty
<Kamion> although I suspect that's not complete
<mdz> powerpc DVD install successful
<elmo> triggered mirrors synced
<mdz> powerpc DVD -> gold
<elmo> so it takes that long, for ref
<Kamion> elmo: ... i.e. not long
<lamont> SuperQ: is already in bugzilla
<Kamion> 07:06 sabdfl     mdz: we can't put it on the releases tree, or people will
<Kamion>                  think it's golden
<pitti> mdz: just tried the new ppc dvd with install, works fine, too (already tried live)
<Kamion> oh, he was talking about ia64 there
<SuperQ> lamont: coo
<elmo> ah, hmm, which reminds me
<elmo> time to go architecture killing on archive.u.c
<Kamion> do we have anything like releases.kubuntu.com available?
<pitti> Kamion: btw, ppc/install DVD still copies _all_ packages to the hard drive
<pitti> (or does it?)
<Kamion> pitti: really? it should copy only Task: ubuntu-ship
<lamont> elmo: woohoo!
<Kamion> pitti: (but if it doesn't, it's a breezy thing ...)
<pitti> Kamion: sorry, no, nevermind
* T-Bone raises an eyebrow ;)
* pitti fetches brown paperbag
<pitti> uh, install DVD still asks whether to download language-support-foo
<Kamion> odd
<Kamion> which language, I'll test?
<pitti> de
<pitti> Kamion: l-support-de should be on the DVD, right?
<Kamion> yeah
<Kamion> d'oh, I suck
<pitti> Kamion: well, that should be only cosmetical, right?
<Kamion> I was grepping only over the list of packages to copy
<pitti> with the DVD being an apt source, it should not really require net
<Kamion> well, no, remember it'll have been ejected
* mako edits the release announcement
<Kamion> the right answer is to copy language-support-$LL and its dependencies to the disk, for whatever languages you selected
<doko> pitti: any chance with the greek OOo1 font display?
<Kamion> oh well, fix for breezy
<mako> doko: is the python note you saw in the release notes or in the announcement
<mdz> doko: release notes
<pitti> doko: sorry, still did not test this; I'm installing the DVD, when this is finished, I have a system with OO.o
<mdz> s/doko/mako/
<pitti> doko: btw, does it work for you?
<mako> ok.. i have no lock on that one at the moment :)
<doko> mako: in the mail mdz sent
<doko> pitti: yes, it does
<Kamion> pitti: todo note added in my working copy
<doko> pitti: but the bug submitter claims that it doesn't work for him
<pitti> Kamion: thanks (saves me from typing a bug report, hehe)
<Kamion> pitti: bug report's good too ;)
<pitti> Kamion: shall I file one in addition?
<mdz> what mail did I send?
<Kamion> pitti: yeah, if you wouldn't mind
* pitti files
<mako> is there a reason we don't have the forums in this list?
<mdz> nope
<mako> alright, they should be there
<mdz> mako: who has a forums account and can post the announcement there?
<mako> mdz: announce is automatically mirrored there
<mdz> ah, ok
<dholbach> ok... dvd burned, will install - see you later guys
<doko> mdz: http://lists.ubuntu.com/archives/ubuntu-announce/2005-March/000019.html (for the python reference)
<mdz> that's the preview announcement
<mdz> it really did have 2.4, not 2.4.1
<mdz> doko: https://www.ubuntulinux.org/wiki/DraftHoaryReleaseAnnouncement
<Treenaks> and gnome wasn't released yesterday anymore ;)
<Lathiat> mdz: as i mentioned earlier, 'k-bling' probably shouldn't be in the kubuntu section :)
<Riddell> what's wrong with k-bling?  k-bling rules!
<Lathiat> Riddell: sure, but i'm not sure its the right word for such an article :)
* Lathiat places emphasis on I
<sabdfl> mako: you might also... that is also... need to drop one also
<sabdfl> Lathiat: k-bling is a little joke, let's let it slide
<Lathiat> sabdfl: ok :)
<sabdfl> we're allowed to tease the k-dudes
<mako> i am going to do another read through. i wanted to let someone else get to it and also nto let me lock expire :)
<Lathiat> sabdfl: wasn't sure if it was, or if it was meant for later substitution :)
<Lathiat> Is anyone else having issues with www.ubuntu.com being stupidly slow?
<sabdfl> i'm biased, i wrote that, so shout if it's in really bad taste :-)
<Lathiat> or do i have some kind of link issue from here
<mdz> amd64 DVD live successful
<mako> sabdfl: i'm still thinking about it :)
<mdz> amd64 DVD install in progress
<sabdfl> the new site is running on gnome, the old one was on kde
* mako giggles
<fgx> Lathiat, me
<sabdfl> mdz: ccoonnggrraattss
<fabbione> i386 DVD live in progress
<mdz> sabdfl: I agree with Lathiat about k-bling; it's pejorative
<mako> Lathiat: that's because everyone is reloading it repeatedly to make sure it's not a fluke
<mako> Lathiat: and because it's so just much more fun to use now :)
<mdz> kubuntu is doing their own release announcement; I don't think we need to say much (if anything) about them
<sabdfl> mako: ack on the also.. also... thing?
<Treenaks> "k-thxbye" ?
<Lathiat> mako: ha ha
<sabdfl> mdz: only one will be picked up by the media, we should refer to kubuntu
<Lathiat> mako: but like.. it hasn't hit slashdot yet :)
<Lathiat> it does look sexy but
<Lathiat> who do i blame for that?
* Lathiat looks around
<mako> Lathiat: *yet*
<Riddell> yep, a quite reference to kubuntu in the first paragraph or two would be nice
<Pizbit> Ah! I knew the website would change at this rough time(hoary release)
<Lathiat> mako: yes but that fact its slow now and hasn't hit slashdot yet, problem no? :)
<mako> Lathiat: hmmm
<Treenaks> Lathiat: pre-slashdotting, so you won't notice the real thing
<Pizbit> Heh
<ogra> ARGH, thew wiki is down ?
<sladen> slashdotted by the loos
<Pizbit> Just paste the i386 install torrent link and I'll be happy:)
<Lathiat> mako: (in all seriousness, seems to take a while to spit the page out, and then it comes up in a flash 
<sladen> looks.  I thought there was a proxy infront of it
<Pizbit> (In due time of course)
<kent> the new look for the homepage do looke very good, but atleast the planet looks strange on my epiphany (Hoary)
<ogra> sladen, i steal the css from the wiki for hwdb.ubuntu.com..... :(
<Nafallo> 5 people. have we changed logo? ;-)
<ogra> ah, its just slow
<sladen> Nafallo: it's going to be 7 people next time (increasing prime numbers...)
<jdub> kent: p.u.c needs the loving
<Lathiat> sladen: eventually we will need 24" widescreen displays to look at all the people! :)
<Nafallo> sladen: seems a bad idea. two more ppl made it slow ;-).
<fabbione> i386 DVD live is GO
<fabbione> i386 DVD install in progress
<Pizbit> Yep, planet.ubuntulinux.org looks odd
<Treenaks> wow @ new site..
* SuperQ cleans out a slot on his work box for torrenting
<SuperQ> I should be able to output about 10mbit of torrents
* Pizbit doesn't care so much that the headings for the menus on the right are longer than the rest of each menu, but the lack of sensible line wrapping... *grin*
<ogra> jdub, will the hackergochis be added to p.u.c once ? i still only have mako, keybuk, Mithrandir and kinnison there
<Nafallo> should releases.u.c be that white? ;-)
<mdz> jbailey: ping?
<mako> Nafallo: please yes
<mako> or rather
<sabdfl> mako: ack the also/also thing please
<mako> sabdfl: got it
<mako> sabdfl: sorry
<sabdfl> cool
<Kamion> can somebody point me at what I need to grab to make releases.u.c look like www.u.c?
<elmo> kamion: ask hno
<mdz> i386 DVD live successful
<SuperQ> mdz: what's the predicted space requirement for all of the ISOs?
<mdz> amd64 DVD install successful
<mdz> amd64 DVD -> gold
<smurfix> Treenaks: not-wow at still not being able to log in :-/
<mdz> SuperQ: which ones do you mean by all?
<Pizbit> mdz: Hehe, you sound like a bot putting it like that:)
<mdz> Pizbit: what a great idea
<mdz> Pizbit: we should have a bot which does automated install and live CD testing ;-)
<Kamion> Pizbit: is it because of your mother that you say that?
<SuperQ> mdz: live/install, all arch, binary CD /DVD
<Mithrandir> mdz: that's certainly doable.
<Pizbit> Kamion: Extremely doubtful
<pitti> mdz: did you get some scary errors on "Registering documentation", too?
<mdz> SuperQ: about 14G
<Kamion> cjwatson@little:~$ du -c cdimage/www/full/{daily,daily-live,dvd}/current/*.iso | tail -n1
<Kamion> 12397132        total
<astharot> hey guys
<Kamion> SuperQ: ^--
<astharot> did you see spaces.msn.com logo ?
<SuperQ> Kamion: thanks
<pitti> we did
<astharot> pitti: it looks quite familiar! :D
<Pizbit> mdz: Get one of those wooden pecker things Homer used in the simpsons to just repeditively hit enter to keep the install going too!
<SuperQ> dang.. I need to put another disk in my workstation ;)
<pitti> ppc/install with latest dvd successful
<Pizbit> astharot: They even have the 'heads' in the same places
<astharot> Pizbit: they have everything in the same places... 
<blueyed> Who's rollinh the changes to ubuntulinux.org out? It might be a good idea to rename the .css files (so the fresh ones get picked up automatically)..
<Kamion> blueyed: I've passed that on
<blueyed> and it's indeed beautiful - you might want to pass this also on :)
<mako> so what the word on the u.c vs ul.o and the release announcement?
<mako> it's looking goooood
<dholbach> amd64-install-dvd has the bug pitti mentioned: wants to download german langpacks
<dholbach> and dpkg says before installing "amd64 is not in architecture lookup table"
<mdz> yes, it'll apply to all DVDs unfortunately
<dholbach> as a warning
<dholbach> but proceeds anyway
<mdz> but it isn't a showstopper
<pitti> I filed a bug about this
<mdz> I saw
<pitti> mdz: <pitti> mdz: did you get some scary errors on "Registering documentation", too?
<dholbach> apart from that NICE work
<pitti> ^ this really is a bit scary
<mdz> pitti: errors, or warnings?
<mdz> I do not watch the install, generally
<mdz> I wait for it to finish and then verify the functionality in the desktop
<pitti> mdz: three "I/O Error: could not open file" or so
<pitti> it doesn't really hurt, installation continues
<mdz> pitti: check dmesg
<pitti> it just looks scary
<pitti> mdz: it's during doc registration
* mako feels what is either a pre-release high or the effect of the vapor he breathed during a subway fire this morning
<mdz> pitti: yes, but is it a real I/O error, or something like a document trying to access a network URL?
<pitti> mdz: nothing really useful in dmesg
<pitti> mdz: it's probably the latter
<Lathiat> mako: website is going mucho faster now
<pitti> mdz: I don't have network currently (on the laptop)
<jordi> mako: I think it's the latter
<dholbach> will be rebooting or do you have a special amd64 install wish?
<dholbach> will reboot :-)
<zyga> mvo: hey
<mvo> hey zyga 
<fabbione> i386 DVD install is GO
<fabbione> i386 DVD -> gold
<trygvebw> Hi! I'm just wondering when the Breezy Badger repositories will be available?
<trygvebw> Tomorrow or later?
<mdz> trygvebw: when we start doing development on breezy
<trygvebw> mdz: OK :) And when will that be?
<mdz> (there isn't much point in creating it until we have something to put there)
<fabbione> trygvebw: in a few weeks
<fabbione> we are all going to hawaii first :P
<trygvebw> okay :)
<mdz> trygvebw: I expect we'll rest at least the weekend before diving in again ;-)
<trygvebw> :P
<mdz> releases are very stressful and a lot of work
<fabbione> mdz: i386 dvd is all green light here
<fabbione> everything is flashing...
<mdz> fabbione: I have an i386 dvd install in progress here
* fabbione starts the hoary dance
<mdz> the final test
<fabbione> mdz: yeps
<Mithrandir> trygvebw: impatient Norwegians, I say. ;)
<trygvebw> XD
<trygvebw> :)
* milli chuckles...  Breezy Badger
<trygvebw> that's quite different from warty and hoary? why was it chosen?
<Mithrandir> trygvebw: you should join #ubuntu-no too; not much activity there yet, though :/
<Nafallo> I'll check my mirrorlogs and notice breezy ;-)
<dholbach> re
<trygvebw> Mithrandor: ok :) :P
<trygvebw> *ir
<mdz> fabbione: your i386 system is not SMP, is it?
<mdz> I'm curious whether that works
<fabbione> mdz: no :(
<fabbione> it's an old P3 700
<fabbione> mdz: donations are always welcome
<fabbione> :P
* fabbione needs more CPU/RAM
* milli hmm...  Dapper Doggy
<fabbione> a gigabit backbone would also be nice to have :)
<zul> hawaii? i like that..
<mdz> donations to the "send mdz to hawaii" fund are welcome
* Nafallo loves jigdo *
<fabbione> mdz: ehheheh
<Mithrandir> mdz: you're going to .au, just drop off in hawaii?
<mdz> Mithrandir: parachute?
<Mithrandir> mdz: hijack the plane.
<ogra> Mithrandir, haey, but only on the way back .....
<Mithrandir> mdz: just use the metal thingy from inside a bra, it looks enough to hijack a plane with.
<fabbione> Mithrandir: ahaha you are really evil today :)
* mvo has a mental image of mdz wearing a bra now ...
<GhostFreeman> will i be banned for asking an approx time for Hoary Final
<mdz> Mithrandir: you aren't allowed to bring those on flights originating or terminating in the US anymore ;-)
<Nafallo> baah. they give you fork and knife when you get on ;-)
<ogra> lol
<Mithrandir> mdz: uhm, you're not allowed to wear bras?
<Mithrandir> fabbione: just got inspiration after we had to get one such out of the washing machine today.
<mdz> GhostFreeman: approximately 0800 UTC
<ogra> funny
<GhostFreeman> k
* lamont lunches
<mdz> Mithrandir: you aren't allowed to carry cable crimpers
* milli lunches
<ogra> mdz, as bra's ?
<fabbione> mvo: aahhahaha
<jbailey> mdz: Here.
<Mithrandir> ogra: please, my mental images.
<ogra> heh
* lamont will have limited cat-5 construction capability at UDU
<Treenaks> Mithrandir: you suggested it
<lamont> back in a bit
<Treenaks> I have one of these: http://www.thinkgeek.com/gadgets/tools/6d98/
<Mithrandir> Treenaks: I did _not_ suggest mdz wear a crimped bra.
<mdz> jbailey: have you hugged an ISO today?
<fabbione> lamont: do you want me to take my AP with me?
<Treenaks> and I'm pretty sure airport security won't spot it :)
<elmo> Mithrandir: (underwired)
<jbailey> mdz: I haven't.  Got a setup you want tested most?
<mdz> jbailey: if I had to choose one, it'd be hoary-install-i386, followed by hoary-live-i386
<Lathiat> mako: website is going mucho faster now
<Lathiat> argh ignore that
* Mithrandir twists his head off
<Lathiat> stupid focus
<mdz> thom: around?
<Kamion> hmm, I ought to fix the jigdo files to not point at daily-installer-*; that bit me post-warty
<mako> Lathiat: dejavu ;)
<jbailey> mdz: Usually pulls from cdimage seem to take forever from here, I'll see how quick those pull down and then do the matching set for PPC if they're coming down quick enough.
<elmo> mdz: he went out for a bit
<mdz> jbailey: it helps to download in advance and then rsync up to the latest image
<elmo> jbailey: us.archive.u.c also has a (usually fairly current) cdimage mirror, FWIW
<jbailey> mdz: My experience with rsync and iso's has been that they aren't any faster.  I have a recent ppc install iso.  Is there a special flag to make it not just pull the whole thing again?
<jbailey> elmo: YEah, mdz pointed me to that, it's been much nicer for testing.
<mdz> jbailey: I use rsync on our ISOs literally every day
<mako> i can get some independent verification of the fact that clicking the login link from anywhere in the new website when looking at www.ubuntu.com takes you to ubuntulinux.org and, as a result, works
<mdz> with excellent results
<mdz> of course, if your ISO is a week or two old, it's not much use
<mako> ^^^^^^^^^^^ sorry, CAN i?
<mdz> mako: that's a fairly ridiculous "fix" for the problem
<mako> mdz: yes, it is
<mdz> does plone really not support virtual hosts or something?
<mako> or something is i think where our problem lies
<mdz> mako: yes, it does the same for me here, including big red flashing security warnings
<mdz> and I end up with a very broken page
<jdub> oof, i'm getting old css for some reason
<jdub> on w.u.c
<mako> jdub: me too.. but only on UL.org
<fabbione> pitti: and now tell me that you have a CAN for me to fix by tomorrow with 60 remote root exploit :P
<mako> jdub: restart your browser.. cached css can be abnoxious
<mako> jdub: that did it for me
<pitti> fabbione: didn't I tell you already?
<fabbione> pitti: meh.. no :(
<fabbione> ehhe
<jdub> mako: mine just managed to go from new to old css with a force reload
<mdz> mako: http://people.ubuntu.com/~mdz/temp/Screenshot-Ubuntu%20-%20Linux%20for%20Human%20Beings%20-%20Mozilla%20Firefox.png
<jdub> (after being confused about b0rk css on other machine)
<pitti> fabbione: I discovered one more: "sudo rm -r /" will corrupt your file system
<mako> jdub: wonderful
<mako> mdz: i saw something like that too
<mako> hn
<mako> dude.. we need hno in here
<elmo> jdub: spethial
<pitti> fabbione: bad for a simple "read mail" command :-)
<jdub> mdz: that's what i'm getting on w.u.c
<Mithrandir> pitti: if it actually corrupts your file system, that sounds like a kernel bug. :P
<mdz> i386 DVD install successful
<pitti> Mithrandir: sure, what else :-)
<mdz> 12/12 successful for me
<Mithrandir> pitti: it could be a gtk bug.
* ogra applauds mdz
<pitti> Mithrandir: well, we could use evolution instead of the command-line readmail (rm) command
<mako> hno73: hola
<hno73> mako: hi
<mdz> hno73: we're seeing quite a bit of this: http://people.ubuntu.com/~mdz/temp/Screenshot-Ubuntu%20-%20Linux%20for%20Human%20Beings%20-%20Mozilla%20Firefox.png
<Mithrandir> pitti: yeah, then it'd be a gtk bug
<mako> hno73: can i get some independent verification of the fact that clicking the login link from anywhere in the new website when looking at www.ubuntu.com takes you to ubuntulinux.org and, as a result, works ?
<mdz> hno73: and similar problems, apparently CSS-related
<mako> mdz: restarting firefox made that one go away for me
<mako> it did not make the ubuntulinux.org login screen with the old CSS go away
<mako> is there a proxy/cache somewhere that needs to get to whalloped?
<hno73> I've had some strange things in firefox too
<jdub> the old css makes baby jesus cry :-)
<hno73> IE seems ok though ...
<jdub> especially now that he's seen the new web site
<mako> mdz: there's the solution
<jdub> baby jesus *digs* the new web site design
<mako> mdz: you mean, you're not using ie
<trygvebw-away> yeah, but the design is #ubuntu'ed
<trygvebw-away> :P
<mdz> hno73: someone suggested using different filenames for the new CSS to avoid this problem
<hno73> mdz: OK, can we do that at this stage?
<mako> hno73: i also need to know if my interpretation of the "fix" for the login issues is (a) correct and (b) will work
<lamont_r> no, I'm not really here...
<lamont_r> this isn't the lamont you were looking for
<mdz> hno73: I am the wrong person to ask ;-)
<mako> hno73: we'd prefer to use ubuntu.com domains in the release announcement but aren't going to do that if it keeps people from logging in
<hno73> mako: you mean restarting firefox?
<jdub> mdz: i think that suggestion was raised because other sites aren't including the new css files (ie. p.u.c)
<mako> hno73: no, as in, when you click login anywhere from the new site while looking at u.c it takes you to a login screen at ul.org
<hno73> has this just started happening after the skin change?
<jdub> mdz: and plone has a custom css file for doing just this
<mdz> jdub: it also avoids the caching problem
<mako> hno73: i can't verify that.. i haven't tested it in weeks
<jdub> mdz: no, the suggestion implied using the existing plone css files, same names, etc.
<Robot101> why is the CSS on shipit.ubuntu.com so horrible? :)
<jdub> mdz: which the new design does, but also adds more that you have to include manually
<mdz> jdub: then we're talking about different suggestions
<mako> Robot101: dude.. i got the other ones hours ago :)
<mako> and, more importantly, i can't install them myself
<smurfix> hno73: I've had login problems for days now
<jdub> mdz: same suggestion, don't believe your interpretation was right (understandable though)
<Robot101> mako: eh?
<mako> this whole "upgrade every piece of infrastructure the day of the release" plan... 
<doko> mdz: I'd like to upload a security fix for zope2.7, although we don't have hoary-security yet. See http://www.zope.org/Products/Zope/Hotfix-2005-04-05/Hotfix-20050405/README.txt. should I just use hoary?
<jdub> mako: better than a disk failure :-)
<mako> jdub: i had one of those yesterday :P
<jdub> mako: d'oh!
<mako> jdub: not really.. the enclosure failed, the disk appears fine
<mako> jdub: i can't use my disk right now.. but i didn't loose any data
<mako> but it had my music on it.. so i'll be doin the hoary dance in silence :(
<jdub> hoary miming is pretty rad celebration though
<fabbione> jdub: did you already find the dance for UDU?
<mako> jdub: speaking of pretty rad celebrating.. sydney? http://www.ubuntulinux.org/wiki/ReleaseParty
<jdub> mako: until last night, i wasn't going to be in sydney
<mako> mdz: until i hear convincing otherwise, lets stick with ul.org
<jdub> however, there's an installfest at a local uni on saturday
<mdz> mako: works for me
<dholbach> doko: isnt it in universe?
<jdub> i could co-opt it as a release party
<mako> jdub: installfest + beer + you == release party
<jdub> mako: + near dead exhaustion == release party in my bedroom ;)
<doko> dholbach: ugh, yes, in universe. ok, uploading it.
* zendog salutes :)
<trygvebw-away> zendog: what's happened? :P
<zendog> :)
<mdke> loving the ubuntu skin
<zyga> artwork changed again 
<zyga> ;-)
<zyga> someone keeps being busy
<trygvebw-away> what's done to the artwork now?
<mdke> not sure
<mdke> i was talking about the website
<trygvebw-away> ahh
<GhostFreeman> which one of you gayed up the site
<mdke> lol
<mdke> its struggling a little
<mdke> i guess it hasn't been fully implemented yet
<trygvebw-away> it's just the #ubuntu effect
<mdke> http://mdke.mine.nu/images/ubuntu.png
<mako> mdke: we're all seeing strange things
<mako> mdke: hardclearing the caches and restarting mozilla seems to fix them
<mdke> mako, k cool
<trygvebw-away> mdke: that's weird :o
<mdke> hi mako btw
<mako> mdke: ciao! 
<mdke> ciao :)
<mdke> mi hanno detto che parli italiano
<mdke> ;)
* mdke clear's cache
* Kamion embarks on a godawful procedure to regenerate jigdo files without daily-installer-* pollution
<mdke> hmm
<mdke> mine sounds easier
* lamont_r really lunches
<mdke> mako, yeah that seems to have done the trick. i love the new theme
<trygvebw-away> Will there be more base ubuntu updates before the official release?
<Kamion> trygvebw-away: extremely unlikely
<Kamion> hmm, I think I just sped up jigdo generation by accident
<trygvebw-away> Kamion: So what's in the repos now IS the stable release version?
<Kamion> trygvebw-away: not blessed as such yet, and universe may still change
<trygvebw-away> yeah, but the base one?
<trygvebw-away> the non-universe
<Kamion> I can't say yes or no yet; there may still be an emergency
<trygvebw-away> okay :)
<dholbach> trygvebw-away: not blessed, announce will tell :-)
<trygvebw-away> i know :)
<mdke> afk
<trygvebw-away> Will it be released as early as possible, or?
<dholbach> trygvebw-away: 8 utc is planned
<trygvebw-away> okay :)
<trygvebw-away> utc is GMT+-?
<trygvebw-away> don't mind :)
<mdke> gmt +1 i think
<trygvebw-away> ok
<Kamion> (export CDIMAGE_ROOT=/srv/cdimage.no-name-yet.com; export PROJECT=ubuntu; export CAPPROJECT=Ubuntu; export CDIMAGE_INSTALL=1; . CONF.sh; for ARCH in amd64 i386 powerpc; do export ARCH; rm -f /srv/cdimage.no-name-yet.com/scratch/ubuntu/tmp/jigdofilelist; make -C ~ /srv/cdimage.no-name-yet.com/scratch/ubuntu/tmp/jigdofilelist; tools/jigdo_header hoary-install-$ARCH.iso hoary-install-$ARCH.template "$CAPPROJECT 5.04 \"H
<dholbach> trygvebw-away: the clock in the tray (and date -u) knows
<Kamion> vomit
<Kamion> trygvebw-away: UTC == GMT
<mdke> yeah sorry
<trygvebw-away> okay :)
<Kamion> (unless you're an astronomer or similar in which case there are slight definitional differences)
<Keybuk> Kamion: especially those weird ones who like to use 00:00 GMT as mid-day
<Kamion> Keybuk: we call them "New Zealanders"
<Keybuk> heh, no :)  some older astronomy tables actually do use 00:00 as noon, because the peeps at Greenwich didn't like changing the date in the middle of the night but when the Sun was actually observable
<Kamion> Keybuk: freaky
<Keybuk> that was one of the reasons for the introduction of UTC, iirc.
<Kamion> jigdo generation seems to take under ten minutes by itself
<Kamion> I wonder (a) if my recent change significantly improved that (haven't got figures from before the change yet), (b) whether it's affected lots by caching
* Kamion -> dinner
<elmo> hmm, good idea.
<sabdfl> mdz et al: congrats on the gold images!
<dholbach> hey sabdfl :-)
<zul> hey sabdfl!
<fabbione> sabdfl: thanks :)
<sabdfl> Kamion, elmo, EUR guys, how about a good nights rest before release?
<sabdfl> fabbione has an early start, i know :-)
<fabbione> sabdfl: yeah.. i was packing the bag for tomorrow :)
* dholbach wont
* ogra neither :-/
<fabbione> sabdfl: cya tomorrow around 9:30 if everything goes as scheduled
<fabbione> good night guys
<zul> c ya fabbione 
<seb128> 'night fabbione 
<dholbach> bye fabbione
* Robot101 convinced daf to join him and come to the party :)
<ogra> ciao fabbione 
<pitti> night fabbione 
<jbailey> mdz: How long should the update ISO take from, say, the 5th to current?  It's been going for 20+ minutes now.
<jbailey> mdz: For rsync, I mean.
<mdz> jbailey: there were new language packs in there, so it could be a while, depending on your bandwidth
<mdz> jbailey: I've blessed the ubuntu images now, kubuntu still needs testing
<jbailey> mdz: 'kay.  I don't remember my bandwidth to cdimage specifically.  To archive.ubuntu.com I was getting 30kB/s usually, (As opposed to 300kB/s to us.archive.ubuntu.com)
<jdub> i'm still getting weird css issues with the website
<jdub> changing almost every force-reload
<smurfix> jdub: Me too. (I also still can't log in, but what else is new :-/ )
<mdke> smurfix, changed your email in launchpad?
<smurfix> jdub: Now would be a good time to replace the favicon, by the way. The ubuntuusers.de folks have one with transparency, looks much nicer.
<smurfix> mdke: No.
<jdub> smurfix: cool, can you mail or url it up for henrik?
<jdub> henrik@canonical.com    Henrik Nilsen Omma      2005-04-06 16:43
<lamont_r> moof
<carlos> mdke: any mail in your launchpad's account is valid as a login name
<mdke> yeah
<mdke> just thought that might be a reason
<carlos> jdub: I suppose you are aware already that planet.ubuntu.com is huge at the moment... It does not fits my powerbook display
<mdke> heh
<Keybuk> That's no planet ... IT'S A SPACE STATION!
<diamond> Keybuk: haha
<smurfix> jdub: Mailed the URL.
<blahrus> Mithrandir: you around?
<blahrus> any of amd64 devel around?
<lamont_r> Kamion: SERIOUS BUG IN i386 DVD (probably all) !!! :-)
<lamont_r> it says 'Scanning CD-ROM' - that's like, totally bogus
<kent> "Scanning your bank account" ;)
<pitti> night everybody
<dholbach> bye pitti
<fruggle> hi why dont the ubuntu guys fix Window Injection Vulnerability in Firefox 0.9.3 in the warty release? Impossible?
<dredg> fruggle: cos there's not going to be a new release within the next few hours.
<dholbach> re
<fruggle> dredg: what do you mean? I'm talking about this http://secunia.com/multiple_browsers_window_injection_vulnerability_test/
<HiddenWolf> fruggle, developers are busy releasing ubuntu 5.04, which will go stable within the next few hours
<Kamion> lamont_r: dude :-P
<HiddenWolf> fruggle, a release is a rather stressful and busy time, so they would probably like to focus on that, and care about firefox later
<Kamion> sabdfl: yeah, I plan to have a reasonably extensive nap soonish; just a couple of jigdo issues to clear up first
<fruggle> HiddenWolf: yes thats great but this vulnerability is not a new one (2004-12-08 secunia advisory)
<HiddenWolf> fruggle, file a bug, so it won't be forgotten
<Kamion> fruggle: our security guy (pitti) just left for the night; he'd probably be the best person to answer you
<lamont_r> Kamion: so no last minute panic/rebuild, right?  we're golden?
<elmo> PANIC
<HiddenWolf> fruggle, 
<HiddenWolf> Solution:
<HiddenWolf> Mozilla Firefox:
<HiddenWolf> Update to version 1.0.1.
<HiddenWolf> http://www.mozilla.org/products/firefox/
<Kamion> lamont_r: believe so
<lamont_r> elmo: on the other thing, hoary uploads for SCC arches gets to continue long enough for us to upload stuff?
<fruggle> Kamion: "pitti" cant fix it though. Warty is a difficult issue, though. The proposed patch is huuuge and does not apply at all to 0.9.3 (Thom already tried in vain for hours). Thus I have no idea how this could be fixed in Warty.
<Pizbit> fruggle: Also that bug might actually be fixed in the ubuntu version of 0.9.3
<dholbach> lamont_r: could you please have ibam rebuilt? (gkrellm was missing build-dep on amd64)
<HiddenWolf> fruggle, sorry, but I don't think this is the time
<lamont_r> dholbach: sure, why not...
<lamont_r> which arch, or do I get to go figure that out?
<fruggle> HiddenWolf: yes ok
<dholbach> lamont_r: amd64, others should be fine
<Pizbit> How big is the hoary i386 dvd image roughly?
<dholbach> Pizbit: cdimage.ubuntu.com
<dredg> Pizbit: roughly <----->*
<milli> 2.7G
<diamond> dredg: not to scale.
<Kamion> Pizbit: -rw-rw-r--    2 cjwatson cdimage  2929047552 Apr  7 17:49 cdimage/www/full/dvd/current/hoary-dvd-i386.iso
<dredg> *NTS
<elmo> lamont: err not for hppa, I doubt
* Pizbit ponders.
* HiddenWolf thinks that was _plenty_ of an anwser ;)
<milli> ...or 2.9g  (little g)
<elmo> lamont: is it really important that you can?
<lamont_r> elmo: not terribly tragically urgent, but it'd be nice
* Pizbit curses and atires himself in suitable clothing to go out and buy some blank cds.
<Kamion> fruggle: well, if our mozilla-firefox maintainer doesn't know how to fix it, nor our security officer, I'm not sure what more we can do save (a) try harder (b) ask for community contribution; I trust there's a bug report open in Bugzilla?
<Pizbit> Don't think we've got enough BW for the dvd image(this month anyway)
<lamont_r> elmo: more significantly, I really don't want to have to s/hoary/breezy/ in all the .changes files and resign...
<lamont_r> if I can avoid that, I really don't care if there's a dists/hoary/main/binary-hppa/Packages.gz or just breezy
<lamont_r> dholbach: ibam is installed on amd64 already
<dholbach> *arg* i must be blind
<dholbach> sorry
<dholbach> :-(
<lamont_r> np
<dholbach> beer_count[lamont] ++ :-)
<lamont_r> EOVERFLOW :-)
<lamont_r> or was that underflow?
<lamont_r> (you need to use something bigger than 4 bits for a counter. :-)
<dholbach> :-)
<dholbach> funnily enough we have a beer (where i grew up), which is called "Bitburger", so it's quite normal to say "Ich nehme 2 Bit" (i'll have 2 bits) ;-)
<lamont_r> Ich spreche nicht deutsch
<lamont_r> :-)
<dholbach> hihih :-)
<lamont_r> Ich kanne nicht deutsch gut gesprechen?
* lamont_r tries to learn enough to mutilate most languages. :-)
<dholbach> nice :-)
<lamont_r> you mean that was right???
<dholbach> nearly :-)
<dholbach> "Ich kann nicht gut deutsch sprechen." :-)
<lamont_r> my high school german teacher would be proud
<lamont_r> er, maybe not. :-)
<AFKwolf> lol@lamont
<diamond> lamont_r: as long as you told the teacher in english, you might get away with it -)
<lamont_r> heh
<AFKwolf> lamont, You managed to make a nice mix between german and dutch. German words, mostly Dutch grammar, I might mistake you for a bordertown peasant. :)
* AFKwolf grins innocently
<lamont_r> the worst part was when I was in 4th year german, and 1st year french.  The french class was right before lunch, and I tended to eat lunch in the german room... Dr Morrey couldn't figure out why I refused to try to do german homework during lunch
<lamont_r> AFKwolf: heh
<AFKwolf> g'luck with that release. My bed is waiting
<lamont_r> g'night then
<AFKwolf> night
<blueyed> "gksudo gedit /etc/fstab" (alt-f2 or term) fails here.. opens "fstab'" in "/home/username/'/etc".. confirmations?
<thom> Kamion: infinity is looking at firefox/mozilla security backports
<mjg59> What is it with Mozilla and security issues at the last moment?
<diamond> blueyed: not even getting that far here, it gets halfway through my username in the prompt for password, then stops.
<diamond> blueyed: amd64 btw
<Kamion> thom: ah, good
<thom> mjg59: they're a pain because security fixes generally involve upstream munging ABI like there's no tomorrow
<thom> (mozilla security fixes)
<blueyed> too bad, diamond.. a known or new bug?
<diamond> blueyed: not sure, never tried it before, will poke bugzilla now
<blueyed> Thanks, diamond (I'm with amd64@32bit).
<diamond> blueyed: hmm. searching for gksudo turns up 4 bugs, none of which look right
<blueyed> Might you file it?
<diamond> blueyed: i might, and i shall ,-)
<diamond> can't imagine it'll make the maintainer too happy to be getting bug reports at this late stage but hey
<diamond> blueyed: i presume you've been looking at #7202?
<blueyed> ok, diamond .. :)
* mvo is back from dinner
<diamond> ah. i think i might know why it's having problems on my setup. i'm using pam-krb. i'll remove that and see what happens.
<diamond> bing. right
* Pizbit confirms using the gksu package from hoary repository
<blueyed> What's pam-krb? I only find libpam-krb5 in the reps.
<diamond> blueyed: that's the one, i was being imprecise
<diamond> blueyed: right, bug report submitted
<blueyed> wasn't there #7202 already, diamond ?
<diamond> blueyed: yes
<blueyed> but?
<diamond> blueyed: it describes what you're seeing
<ogra> mvo, ping
<blueyed> diamond: ah, you're referring to libpam-krb5
<blueyed> #8774 
<mvo> ogra: pong
<diamond> blueyed: aye, 8774 is the one i just filed
<Kamion> maswan: hmm. could you please arrange that requests for http://releases.ubuntu.com/ hitting the ACC servers go to the /ubuntu-releases/ directory, rather than the "This ftp server belongs to ACC" page?
* thom jigdos
<elmo> hmm, it use to
<elmo> did when I tested it before adding them
<Kamion> yeah, I thought it did too
<Kamion> confirmed now with all four ACC servers though
<elmo> if maswan's not around I'll just drop them out
<Mithrandir> he's probably not around at this time of day.
<elmo> frei and durville and are man enough for /.
<Mithrandir> (he should be around in 8-9-ish hours, though)
<elmo> dropped
* elmo thwaps mithrandir
<elmo> he is too about
<maswan> I am here. I will take a look at it and see if I can enable virtual hosting quickly.
<sabdfl> hno73: can we get a search box on the top of every page please?
<sabdfl> also, not sure the Plone Control Center should be visible
<T-Bone> lamont: you around?
<Kamion> maswan: cheers
<lamont_r> T-Bone: no, but I am
<T-Bone> lol
<lamont_r> :-)
<hno73> sabdfl: is the plone control center visible for non-admin users?
<T-Bone> could you avg ghc6, i'd like to know if it's worth waiting for the end of the build or not ;)
<lamont_r> T-Bone: eternal'
<T-Bone> ewww
<lamont_r> ghc-cvs is 8 hours or so
<T-Bone> o_O
<lamont_r> ghc6:                   06:21:16 (10 entries, sigma 03:07:23)
* T-Bone gacks
<sabdfl> hno73: i thought i saw it, together with the "Log In" link, just now... but i must have been mistaken
<T-Bone> lamont_r: if only it was using SMPness :P
<sabdfl> hno73: and the search thing?
<lamont_r> T-Bone: then it would crash quicker
<hno73> sabdfl: I would have like to do some testing first
<T-Bone> lamont_r: oh, it's a tedious build heh?
<hno73> I've alredy broken plenty of stuff today :)
<hno73> sabdfl: I can look at it, but can't promise by 9am tomorrow
<elmo> sabdfl: when you login it gives you the option if you have supah powahs
<elmo> IIRC
<hno73> right, there are 10-12 admins
* Kamion switches releases.ubuntu.com and cdimage.ubuntu.com over to the new stylesheet
<Kamion> I haven't attempted to add the masthead or anything yet
#ubuntu-devel 2005-04-19
* lamont_r grumbles at kamion
<lamont_r> livecd has stale Packages files :-(
<SuperQ> so is next release going to use gcc 4.0 for compile?
<SuperQ> (now that Hoary is out the door)
<Kamion> lamont_r: hm?
<Kamion> what's out of date?
<zenwhen> Kamion, so are things going well or are you all still in a mad rush?
<Kamion> mdz: cool, looks like I indeed managed to accidentally speed up jigdo by a factor of two or so
<Kamion> zenwhen: going well I think, will nap soon
<zenwhen> cool. Enjoy. :)
<lamont_r> Kamion: one of the last steps in the livecd rootfs build is to apt-get update from archive.ubuntu.com/ubuntu
<lamont_r> and then we rolled archive-copier
<Kamion> but archive-copier is only a udeb
<lamont_r> hrm.
<lamont_r> nm then
<lamont_r> it's not like it's really bad either way, mind you.
<Kamion> phew
<lamont_r> what was in the install-CD only regen before archive-copier though?
<lamont_r> (the only effect is that (1) anything reved in main/restricted won't apt-get install without an update, and update won't be all 'Hit' and no 'Get')
<witless> hi guys.  just wondering how you got firefox to use native gnome dialogs in firefox, when this doesn't appear to be available in debian-unstable...?
<Kamion> lamont_r: partman-auto, apt, ubuntu-docs
<Kamion> lamont_r: but I thought we revved the live CD for that too
<mdz> we revved the live CD for apt and ubuntu-docs, yes
<lamont_r> woot
<mdz> second guessing from this point forward is strictly prohibited; my blood pressure is high enough :-P
* lamont_r will boot live and doublecheck soonish - butwaiting for dvd download to finish
<Kamion> manifest diff confirms
* elmo fedexs mdz some atenolol
<maswan> the 130.239.18.165 ip works well now?
<lamont_r> hoary/main fetched
<lamont_r> the rest hit
<lamont_r> we reved livecd, but not livecdrootfs
<lamont_r> in one of those iterations
<elmo> maswan: looks good to me
<maswan> I'm distributing the changes to the other hosts, but it seems to be unfast
<lamont_r> mdz: what's the name of the non-snapshot device (cloop)
<Kamion> maswan: yep, looks fine here too
<maswan> probably because the dist-script also makes sure that all the locally compiled software is up to date etc. :)
<Kamion> mdz: I'm post-facto generating jigdos for the DVD images, since I figured out how to do that
<Kamion> although this approach only works when the archive's frozen
<mdz> Kamion: I awty'd all the stuff we changed at the time, to confirm it made it onto the CDs consistently
<Kamion> and off for a nap while that runs, I think
<mdz> lamont_r: /dev/cloop0
<maswan> there, should be all done now
<Kamion> great, thanks
<Keybuk> meh, iaudio crashed :(
<Keybuk> in fact, that's odd; it hard-crashes whenever I plug it in
<Keybuk> weird; is ok now
<Keybuk> did we drop the patch that let the device be named "IAudio" ?  It's coming up as "39G media"
<tseng> Keybuk: yes, that was hal in gnome-vfs
<tseng> which is now gone (again)
<Keybuk> caused too many problems?
<tseng> yeah
<lamont_r> 17 packages changed from Priority: optional to Priority Standard between the livecdroot generation and now
<lamont_r> that's the diff
<lamont_r> could be mirror out of date or something
<Kamion> elmo did that recently I think
<lamont_r> well, was bugging me
<lamont_r> now I know.  Therefore I can sleep tonight. :-)
<zenwhen> so sound really is broken with the audigy 2?
<mdz> elmo: still here?
<elmo> mdz: yah
<mdz> elmo: a mirror admin emailed me about mirroring the release; copied you on my reply
<mdz> elmo: do you have any handy scripts to check cdimage mirrors and see if they are up to date, so that we know which ones we can list on the download page?
<elmo> eh, kind of, but not really
<ogra> erm, whats the default locale on the buildds ? C ?
<mdz> elmo: if a releases mirror were to update right now, would they get the gold images?  or not until we do the final publishing?
<elmo> mdz: they'd get it in .pool
<elmo> but they won't get the symlink unless they sync again
<mdz> ok, cool
<mdz> at what level of the tree is .pool?
<elmo> top
<elmo> releases/.pool, releases/hoary etc.
<elmo> I'll hack/n/slash the mirror checker I have, it's mostly for the archive and is super 6-am, but it's better than a kick in the head
<mdz> interesting; I checked ftp.ubuntu-es.org and they have ubuntu-5.04-install-*, but not ubuntu-5.04-live-*
<mdz> they're both in .pool on releases.u.c
<elmo> live is later
<elmo> well, according to the current timestamps
<Keybuk> ross' x-chat plugin is da bomb! :p
<mdz> according to what I see on releases, live is stamped 2005-04-06 and install is stamped 2005-04-07
<elmo> mdz: oh, btw, I was lieing about checking times, we have a .trace file
<elmo> check .trace/
<dredg> Keybuk: yeah, it wins
<mdz> that's handy
<xuzo> mdz: thanks for your quickly response ;)
<lamont_r> ogra: these days, butilds are all done with LANG=C
<ogra> lamont_r, thanks
<lamont_r> %ENV_OVERRIDES = {
<lamont_r>         'LC_ALL' => 'C',
<lamont_r> };
<lamont_r> actualy.
* mpt magically types into an unfocused "Change user..." window
<elmo> HEY
<elmo> did we fix gaim??
<lamont_r> elmo: fix how?
<ogra> lamont_r, so lets see what will happen to my ding upload :)
<elmo> the focus madness
<mdz> xuzo: we don't have much time before the official release ;-)
<mdz> elmo: no
<ogra> elmo, ot here
<elmo> RIGHT. that's it.  no release.
<ogra> not even
<mpt> haha
<lamont_r> elmo: gconf-editor, metacity focus mode == strict
* lamont_r owes seb128 a beer
<lamont_r> elmo: and no, I don't know how well documented that is.
<lamont_r> but I know it's not well integrated with the panel
<lamont_r> gonna have to send seb128 another patch for breezy :-)
<seb128> it's not documented out of the package changelog
<elmo> I actually stopped using gaim because of that
<Mithrandir> you could use another wm too. :P
<seb128> what is wrong with the focus made and the panel ?
<seb128> gaim sucks anyway :p
<Mithrandir> seb128: what's the alternative?
<seb128> I've not said there is one
<ogra> fixing gaim will take 100 years...
<seb128> gossip if you use jabber only :)
<calc> isn't gossip supposed to use libgaim eventually?
<seb128> that's an option
<seb128> but I don't think they are going to do that
<seb128> rather using the transports
<Mithrandir> the transports sucks since the jabber servers suck
<dholbach> elmo: could you please sync kazehakase from sid?
<elmo> dholbach: done
<dholbach> elmo: thanks
<lamont_r> dholbach: right up to the wire, eh?
<dholbach> lamont_r: :-)
<dholbach> www.ubuntulinux.org/wiki/UniversePriorityList is nearly empty - charming :-)
<lamont_r> dholbach: coolness
<ogra> lamont_r, total crazyness ...
<lamont_r> ogra: bummer
<elmo> mdz: results are encouraging
<elmo> in terms of the isos being there
<mdz> elmo: trouble is, there's going to be a tiny window to get the symlinks
<lamont_r> ppc dvd hits 67%.  sigh
<mdz> or hardlinks or whatever
<elmo> syms
* lamont_r decides that it's time to update his bios on his laptop tonight, to see if it will decide it has batteries again
<lamont_r> elmo: can we populate hoary-test with all the installed-on-any-arch universe sources?
<elmo> hmm, woops, missed the last tube
<elmo> lamont: dude, hoary-test?  surely it's time has passed?
<lamont_r> is good leadin to breezy, and the buildd's are bored
<thom> elmo: have fun with the night busses and all the CRAZY PEOPLE
<lamont_r> I thought there was a cot in the DC... :)
<elmo> thom: I might just stay here.. escudero makes a nice desktop for my laptop.. I have supplies
<Keybuk> thom: did you ever get the night bus back from TH when you worked at Positive?
<elmo> no need for the crazies
<Keybuk> that _was_ freaky!
<thom> Keybuk: i walked from HEX to paddington a few times
<thom> Keybuk: and did the night bus thing rather less; very freaky
<lamont_r> elmo: more to the point, if you put in another round of sources, then I don't have to answer questions about the busticated ones from cluster-day
<elmo> lamont: rpoblem is, I'm _really_ not bored
<elmo> lamont: I'll be happy to do -test stuff after we release, I've got at least two super-outstanding things before then
<lamont_r> elmo: certainly not a priority task
<Keybuk> I had to get the bus to and from Anchorage House once, that wasn't pleasant :(
<lamont_r> elmo: certainly - sounds like the best thing I can do to help you is leave you the hell alone or a few hours... holler if there's something more productive I can do to help
<zul> hey
<Keybuk> nothing worse than getting mobbed by drunken club-goers while you've a sparc under one arm
<thom> indeed
<robertj> Keybug: what about SGI machines? They can be pretty heavy
<thom> any machine is heavy
<robertj> thom: the minis are pretty light
<thom> ok, any *real* machine :-)
<zul> a cray is pretty heavy as well
<elmo> zul: so's a tank
<zul> elmo: yes it is
<thom> each is about equally useful in an average datacentre ;-)
<zul> well a tank might get you into an above average datacentre
<dholbach> elmo: could you please remove xfld-welcome? (xfce team's decision)
<dholbach> hey seb128_ :-)
<dholbach> pyjama party? :-)
<seb128_> 'night :p
<doko> dholbach: show your pyjama first ;-)
<thom> so, will the amd64 install overtake the ppc one, even though the ppc install was on stage2 by the time amd64 started
<dholbach> doko: hahahaha :-)
<robertj> thom: btw, what are the build machines/
<thom> which ones?
<robertj> thom: are there several per arch?
<elmo> they're crays mark stole from the ISS
<thom> robertj: they're a bunch of pdp-11s in orbit
<thom> and the amd64 overtakes
<lamont_r> robertj: about 3GHz, 2-4GB RAM, etc, etc.
<lamont_r> pretty high end on all 3 architectures.
<lamont_r> and (generally) 3 for each arch
<mdz> lamont_r, dholbach: are there any long-duration builds we need to worry about in universe?  be sure not to upload anything which will take longer to build than the time we have left before release
<dholbach> mdz: hrm, this will mean no apt-get.org
<dholbach> right?
<toresbe> thom: they done stole my PDPs!
<robertj> mdz: so are you excited about breezy or excited about doing nothing for a few days ;)
<mdz> robertj: I am excited about a weekend off
<mdz> dholbach: hmm?
<lamont_r> mdz: if elmo slams the door, it won't matter if they're running
<mdz> lamont_r: it will have been wasted time preparing the package
<lamont_r> we were periodically uploading bits to warty as late as 2 months ago
<lamont_r> true
<dholbach> mdz: elmo should be still importing it, or starting importing it
<zenwhen> what opts are most ubuntu packages compiled for?
<zenwhen> with*
<mdz> elmo: ?
<lamont_r> re warty: due to a particularly useless feature of wanna-build
<lamont_r> zenwhen: generally, -march=486 -mcpu=pentium4
<elmo> mdz: you didn't threaten physical violence when I asked you about it earlier, so I've been working on it?
<elmo> tho I just fobbed it off on thom to finish reese
<mdz> elmo: is that stuff suppressed from hoary-changes or something?  I hadn't noticed
<thom> amd64 completed install sucessfully; ppc is doing locales
<lamont_r> thom: you clearly need a G7
<elmo> mdz: I was writing a script to automate it, there's 39 different locations to fetch stuff from
<elmo> mdz: my sync automation doesn't extend to multi-location stuff like that
<lamont_r> muppomatic
<elmo> (since we only ever synced from basically 3-4 places)
<mdz> I guess I don't understand why dholbach said it wasn't going to happen
<mdz> I mean, certainly we won't finish, but there is a queue of stuff which is ready to be imported, yes?
<Keybuk> hmmm... will be interesting how/if mom will interact with apt-get.org
<robertj> so is every package in sid automatically brought into universe for breezy?
<mdz> robertj: roughly
<elmo> mdz: yes
<elmo> dholbach worked through the list and came up with a list of what was live and sane enough to import
<robertj> ie if there are python bindings for foo, will they automagically appear?
<dholbach> mdz: just because you throttled lamont and me about uploading stuff, that's why i thought... :-)
<lamont_r> robertj: if the package is in debian, and we haven't changed it, then it just shows up.
<lamont_r> if we changed it in hoary, then we have work
<mdz> dholbach: unless the list is enormous, I think there will be time to at least attempt to build everything
<robertj> lamont: ahh
<dholbach> mdz: wiki.ubuntu.com/AptGetOrg
* robertj dohs, no python bindings for zeroconf packaged :(
<mdz> less than 100 packages
<mdz> by eyeball
<lamont_r> given that most packages are < 5 min to build, should have a at least one run through the chomper
<elmo> is there some way to tee stderr and stdout to different files from the command line?
<haggai> (((./cmd | tee stdout) 3>&1 1>&2 2>&3|tee stderr) 3>&1 1>&2 2>&3) 1>out 2>err
<haggai> ie copy file descriptors around and use brackets to keep them all in order
<lamont_r> Kamion: wanna rm -rf ,,* from your seeds dir on people?
<ska-fan> What's FTBFS?
<haggai> fails to build from source
<dholbach> ska-fan: $ wtf ftbfs    :-)
<ska-fan> heh, no wtf in ubuntu
<elmo> mdz: people.ubuntu.com/~james/reese.output
<dholbach> ska-fan: sudo apt-get install bsdgames
<lamont_r> so can we have active directory support for breezy, milli asks?
<milli> lamont_r: That's not what I asked...
<ska-fan> Oh, it's a game .. I get to play atc again then .. great :)
<dredg> huh? `wtf' doesn't know what 'lrf' are?!?! stall the release!
<dholbach> dredg: patch it
<dholbach> dredg: koke already taught it, what ftbfs and sabdfl mean :-)
<dredg> :)
* dredg adds 'mrqf' to it
<ska-fan> grr, collision after only one safe plane
<infinity> Kamion : I patched the Windows Injection vuln last night, but I'm not going to upload until I've at least reviewed all the other pending security patches, to make sure there won't be any crazy patch interaction issues.
<infinity> Kamion : I also need to test it, of course (beyond a test build, which went okay).
<infinity> s/Windows/Window/
<dredg> right, new bsdgames gone up
<dredg> can't believe it didn't have lrf :)
<dredg> and now my gf is insisting that i go to bed
* dredg sighs
<dredg> nightol
<dholbach> good night dredg 
<mako> mdz: hey there good lookin'
<mdz> mako: *yawn* what's up?
<mako> so the plan is we stay up and then dance around releasing when europe wakes up, yes?
<daniels> i think release is 0800
<mdz> mako: that's what I'll be doing
<mako> cool.. sounds like a plan
* dholbach dances with you :-)
<mako> i'm just killing time till this party anyway ;)
<dholbach> how about fixing some universe packages until then?
<dholbach> ^^^ *bling* *bling*
<dholbach> :-)
<infinity> daniels : 0800 UTC?
<dholbach> infinity: yes
<mako> dholbach: i have a couple other things on my list but if you have some low hanging fruit for me :)
<mako> dholbach: how about this.. i fix universe packages and you answer my email
<elmo> mako: what are you doing on IRC?  I think you don't have enough mail.  I'll send you some more
<infinity> Bah, then I'll miss it.  Guess I'll just have to go out and celebrate with my girlfriend instead. :)
<dholbach> mako: already nicked them all, how you think i got 300 uploads that fast ;-)
<mako> elmo: *bastard*
<mako> cool.. i got an ubuntu talk accepted for linuxtag
<dholbach> elmo, mako: the thing i enjoy most about ubuntu is the atmosphere, you'll surely understand :-)
<mako> if i can't give it.. i can try to delegate to someone else
<zul> quick mailbox mako 
<zul> doh..
<mako> this is my number one skill.. i'm going to make a video of me processing mail at top speed.. it's gonna be a frickin' hit. i'll be on the tonight show as "that fast email guy"
<elmo> is there anything pre-done in python to parse ls -l -ish output?
<mako> mdz: i was so scared of your kibo stuff i basically wrote my own.. and it didn't work
<mdz> mako: only one person has mailed me about an LA release party so far; it may not happen
<mako> :(
<zul> not much of a party
<mako> we'll have two here in new york
<mako> SIMULTAENOUSLY
<mako> man, it's gonna rock
<Artemis3> wow the new page is up
<Artemis3> oops sorry wrong channel
<daniels> mako: two people, or parties?
<mako> daniels: two parties baby
<mako> daniels: hopefully, more than two people
<sladen> who's good at fixing plone things.  Various things (searching and documentation pages) seem to be broken
<mako> the NYLUG dudes advertised it on their announce list.. it might be big
<sladen> eg.  http://www.ubuntulinux.org/support/documentation/howto/miniRAM  404's
<mdz> sladen: hno73 is the person to talk to
<sladen> mdz: is there any awake?
<mako> y'know how the CC gives people crap for having shitty wiki pages?
<sladen> mdz: is there anyone awake?
<mako> mark's wiki page is crap
<mdz> sladen: no, not really
<mako> at some point, i'm going to go around to all of people that were grandfathered in and make them make decent wiki pages and sign the CoC and all that jazz
<mako> sabdfl: the calm before the storm
<mako> sorry
<mako> sladen: ^^
<elmo> $ cat COPYING
<elmo> TODO
<elmo> giggle
<dholbach> hahaha - yes... that was one of the funny ones
<dholbach> even better were those having indiana jones for scummvm
<dholbach> stating in debian/copyright:   copyright: yes   -    downloaded: from the net
<elmo> ROTFL
<dholbach> but don't worry, they're not on the list
<dholbach> they even had zakmccracken
<dholbach> will have to re-visit that one
<dholbach> :-p
<nullaresnata> hello, how do I change my console keyboard layout?
<mdz> elmo: hmm, the .torrents have the filename embedded in them
<mdz> how did we handle that the last time around?
<mdz> I guess we'll need to regenerate them when we publish
<elmo> mdz: how's that a problem?
<mdz> elmo: because the name is hoary-foo-bar.iso, rather than ubuntu-5.04-foo-bar.iso
<elmo> and the .torrent's have the old name?
<mdz> currently the torrents are named hoary-blah
<mdz> so are the ISOs
<mdz> but when we publish, we're renaming the isos
<mdz> and presumably the torrents to match
<elmo> oh, we don't have torrents yet
<mdz> sure we do
<mdz> on cdimage
<elmo> not in simple/ ?
<mdz> right
<mdz> we can't use the ones we have; we have to generate new ones apparently
<thom> yep
<dholbach> any python pro, who can tell me what went  wrong in http://people.ubuntu.com/~lamont/buildLogs/g/gaphor/0.5.1-2ubuntu1/gaphor_0.5.1-2ubuntu1_20050408-0139-i386-failed ?    (went nice in my pbuilder)
<mdz> eek
<dholbach> and it even runs fine here... hrmbl
<sladen> dholbach: is there an illegal UTF-8 sequence in "pofile" /
<dholbach> sladen: i didnt change it from the release before (which was some ages ago)
<dholbach> will look
<sladen> where's the source package?
<dholbach> sladen: http://archive.ubuntu.com/ubuntu/pool/universe/g/gaphor/
<sladen> is that the one that failed, or the previous one?
<dholbach> both
<ogra> hula_0.1.0+svn162-2ubuntu1_20050408-0207-ia64-failed
<ogra> :(
<dholbach> hrm
<ogra> heh
<dholbach> ogra: how where the odds?
<ogra> the other three were fine...
<ogra> 1000:1 ?
<ogra> 10000000:1 ?
<dholbach> *shrug* your bet was right :-)
<sladen> ../../../include/xplthread.h:98:3: #error "Safe variable operations not implemented on this platform"
<sladen> ...that ones a little simpler to fix/identify
<ogra> yop
<sladen> http://www.hula-project.org/Troubleshooting_FAQ#I_get_something_about_Safe_variable_operations_not_implemented_on_this_platform
<ogra> WOW, excellent solution :-P
<sladen> http://michele.pupazzo.org/files/patches/hula-ppc-atomic.patch
<sladen> oh jeez.  Why are they writing their own locking perimitives
<dholbach> hrm? it was ia64
<ogra> ppc works fine...
<sladen> yes.  I couldn't find the header---that is just illustrative of what needs to doing to fix thigns
<jdub> yo haggai
<Artemis3> is this image final? 28319b072a39f39b89a9f0e938ca7013  hoary-install-i386.iso
<jdub> ogra: rocking to see hula in universe :)
<ogra> sladen, i dont think i wanna touch this again....herzi cares for it and will eventually be a MOTU to care for it...
<ogra> jdub, yop :)
<ogra> sladen, i'm fine as it is now....the rest is something to fix for breezy....
<ogra> Artemis3, final images are named ubuntu-5.04-.....
<Artemis3> ok i want to help torrenting
<ogra> Artemis3, as far as i understood they are generated currently....
<Flonne> I can put up a ~100kB/s seed if that would help...
<Artemis3> array cd 7?
<zenwhen> thats not final
<Artemis3> ok
<zenwhen> final images arent out yet, at least I dont think
<zenwhen> are they?
<sladen> zenwhen: they're being renamed I think
<zenwhen> I am going to download a final image saturday when I have access to broadband and sit pretty in hoary final for a while
<zenwhen> well actually if some of that cool cairo stuff winds up in the next dev release I will be forced to upgrade
<blueyed> Please consider renaming the .css files, because it still shows pages in mixed style here and I think this will affect a lot of people that have been to ubuntulinux.* before..!
<mx|gone> I'm sure this has been asked a bazillion times, but why did you guys change the ubuntu login screen to the picture of all those people?
<jdub> mx|gone: the default login screen is an evolution of the warty login
<jdub> mx|gone: we've just updated the HumanCircle theme to our new circle image
<mx|gone> jdub: that's what I meant... the HumanCircle one
<jdub> mx|gone: because we have a new circle of people for this release
<Lathiat> jdub: has humancircle been made the default this time?
<jdub> Lathiat: no
<mx|gone> jdub: hmm... I guess the picture just looks very PSA-ish
<infinity> elmo : When will hoary-security be open for business (or is it already)?
<elmo> infinity: technically is
<jdub> elmo: -updates?
<infinity> elmo : While reviewing warty's outstanding mozilla issues, I'm finding a few things to update in hoary, too.  Though, I won't have uploads tested before release.
<elmo> that too
<elmo> jdub: ^--
<jdub> cool, thanks
<daniels> elmo: breezy?
<ogra> lol
<elmo> daniels: 9:01am
<elmo> (8:01UTC)
<daniels> elmo: i'll upload x-common (which forces /usr/X11R6 -> /usr) at 9:02
<ogra> hehe
<infinity> daniels : I hate you.
<daniels> infinity: but really, you love me
<thom> daniels: dbus 0.3 please at 09:03 ;-)
<daniels> thom: oh man, dbus 0.3 scares the shit out of me
<daniels> seriously
<daniels> 'SURPRISE!  A NEW API!'
<infinity> Nothing you can't fix in 6 months, right? :)
<thom> there's some fantastic crack in there though
<daniels> infinity: X stuff is what worries me most
<daniels> infinity: given the objective is X11R7, in /usr/{lib,include,bin,...}, in breezy
<daniels> (X11R7 being totally modular and all)
<ogra> yeah, and rebuilding the X world on top....
<infinity> thom : How do you feel about security updates causing useability regressions, if those regressions also exist in hoary? :)
<daniels> well, not really
<mx|gone> jdub: the gdmconfig SS needs to be updated for HumanCircle
<infinity> thom : https://bugzilla.mozilla.org/show_bug.cgi?id=283992
<daniels> i'd do one big local rebuild to ensure nothing brok^W^W^Wsee how much I broke
<infinity> thom : One update I'm doing will cause that bug... But that bug also exists in 1.0.2
<ogra> mx|gone, already filed
<daniels> but the rest would get to keep working
<mx|gone> ogra: cool
<thom> that's an astonishingly awesome regression
<thom> but yeah, i don't see we have much choice
<infinity> thom : Quite, yes.  I can fix the regression, of course.
<infinity> thom : And even fix it in hoary-updates, too.
<infinity> thom : But that wouldn't, strictly-speaking, be a security update. :)
<Kamion> lamont: ,, dirs> ah, that's a baz bug; removed for now, though not automated
<thom> i think we suck the regression up, tbh
<lamont> Kamion: right
<thom> and not worry about it
<Kamion> mdz: the .torrents get regenerated automatically by publish-release; no need to worry about them
<infinity> thom : Alright.  Consider it sucked.
<daniels> thom: my most annoying firefox bug right now is that, in the last couple of days, sometimes when I type in a text box, it treats *any* apostrophe as typeahead
<daniels> so I've got a lovely bunch of coconuts, in a comments field, searches for ve got a lovely bunch of coconuts
<daniels> only happens randomly
<jdub> mx|gone: yes, known issue
<thom> daniels: kick ass
<daniels> thom: can you fix it? :)
<thom> daniels: hopefully we can get 1.1 in breezy for whole new levels of madness
<thom> daniels: just call me bob the builder
<mdz> Kamion: ok
<mdz> Kamion: good morning
<mpt> My most annoying Firefox bug right now is that the preferences window won't open, and neither will View Source
<mpt> I'm hoping that it's just because synaptic hasn't finished yet...
<thom> mpt: xul errors? quit and reload. if that don't fix it, it's the super keen `find .mozilla -name XUL.mfasl -print0 |xargs rm -f`
<daniels> thom: this browser is so awesome
<mpt> ah, the infamous XUL preloading
* mpt tips his hat to Mister Brendan Eich
<mpt> thanks thom, I was beginning to think I had found a release blocker or something
* mpt gently deflates his own ego
<thom> mpt: fraid not dude; this is day to day in the trenches with ffox :/
<jamesh> I think it is just a case of the .jar files containing all the UI stuff disapearing
<jamesh> (or at least changing sufficiently for it to get confused)
<thom> jamesh: nod
<thom> it's still a *hideous* failure mode
<mpt> yeah
<jamesh> so if you unpacked everything, upgrades would be a bit smoother (although startup would be slower)
<mpt> At the very least, if there's a chrome:// XUL error, it should say "waitaminute, this might be fast-load goopiness" and clear the fastload cache
<jdub> thom: "failure mode" *cough* ;)
<daniels> shit man, I'd trade slightly slower startup for regularly working firefox
<thom> daniels: AOL
<daniels> the biggest pain in the arse is when I have ~70 tabs open, firefox dies horribly so I go to bookmark all my tabs, except whoops, I can't get the bookmark dialog!
<dholbach> morning doko
<ogra> hey doko 
<mpt> daniels: That's what Epiphany's Crash Recovery is for ;-)
<thom> i've been in the bad habit of pkill'ing ephy for a long time
<thom> whenever i want to log out or "save my bookmarks" ;-)
<Lathiat> heh
<Lathiat> and then it whinges when you open it back up
<Lathiat> which could be good or bad :)
<Lathiat> i always used to epiphany </usr/share/doc/file>
<janc> daniels : there is a crash recovery extension for firefox  :)
<Lathiat> and then ^C it
<Lathiat> and it'd annoy me everytime i open it again
<daniels> janc: does it load when you can't get the bookmark dialog?
<mpt> Lathiat: Because ^W would be too hard?
<janc> never tried that  :)
<Lathiat> mpt: wah?
<Kamion> mdz: morning. trying to decide whether to stay up at the moment ...
<janc> https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox&version=1.0&os=Windows&category=Tabbed%20Browsing&numpg=10&id=436
<mdz> Kamion: did you wake up, or have you not been to sleep yet?
<thom> Kamion: only 5 and a half hours to go!
<infinity> janc : &os=Windows?
<Kamion> mdz: got about 3 hours
<Kamion> (sleep)
<mdz> I tried to nap, but it didn't work
* Lathiat had 6hours, glad im not doing anythign important :)
<janc> https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox&version=1.0&os=Linux&category=Tabbed%20Browsing&id=436
* thom will be sleeping soundly on the way to .au
<janc> seems like their OS detection is not really working  :-P
<mdz> thom: you leave on release day, or the day after?
<thom> mdz: 12 hours after release
<mdz> heh
<mdz> perhaps the airplane will be all abuzz with the news
<daniels> thom: sleeping, or passed out?
<thom> daniels: yes
<thom> mdz: i shall burn cds and ask the trolley dollies to hand them out with tea
<hypatia> With the hot towels.
<hypatia> So everyone is alert.
<Keybuk> here's some CDs... NO DON'T USE YOUR CD-DRIVE!
<infinity> thom : Now that's a politically correct term, if I've ever seen one.
<Keybuk> It "interferes with the navigational equipment"
<thom> infinity: *g*
<Flonne> Just like a Gameboy.
<hypatia> infinity: "checkout chick" is in close contention.
<infinity> My girlfriend's brother proudly refers to himself as a checkout chick.
<daniels> hypatia: i don't think you get hot towels on BA
<daniels> thom: you should take a side trip to Melbourne and check out our JSBH
<hypatia> daniels: that's revolting.
<thom> daniels: thanks, but i imagine craige and i may visit the one in sydney a little
<hypatia> infinity: yeah, it works for men too. But trolley dollies does as well.
<daniels> thom: yes, but you need some variety in your life, son
<infinity> thom : Or visit Melbourne to hang with me, since I dunno if I'll be able to make UDU..
<jsgotangco> greetings
<thom> infinity: gar gar gar
<thom> how the hell do i fit that in?
<thom> hrm, could fly over thursday am
<thom> daniels: where/when/how are you getting to yass?
<daniels> thom: virgin flights are cheap, might be able to get qantas specials as well
<thom> aye
<daniels> thom: arriving Sunday per UDU, then I figure inertia will somehow get all the Ubuntu people arriving in CBR to Yass somehow
<daniels> else there's going to be 30 annoyed people standing around in Canberra trying to get to the party
<thom> hrm, right
<thom> see, i have a lift from sydney on saturday; guess i can just fly back saturday am
<daniels> probably some sort of wheeled vehicle
<robitaille> anyone knows why I cannot join #ubuntu tonight ("you have been banned").    Haven't there in 24 hours, so I'm not clear why...
<daniels> ah, you're going with hypatia and spiv?
<hypatia> not that I heard :)
<hypatia> but he can race us.
<hypatia> easy to beat spiv.
<daniels> heh
<daniels> robitaille: over-enthusiastic ban on someone flooding earlier -- try now
<robitaille> daniels,  thanks
<thom> daniels: craige
<daniels> thom: ahr
<infinity> Ugh... 11 CVE CANs patched, and I'm not even halfway through the list.  THis is pretty sad. :/
<daniels> thom: any 'nvidia-glx makes my shit hang' bugs should be duped as 7183
<daniels> thom: oh, and btw, don't forget sideshow's jumper :)
<thom> heh
<thom> i thought i might just to prolong the experience
<thom> i'm not entirely sure where it is currently
<daniels> heh
* fabbione yawns
<ogra> MORNING fabbione 
<dholbach> hey fabbione 
<fabbione> hey guys
* Keybuk observes that sideshow has been getting his eyes tested
<Keybuk> he's in for a shock when he looks in the mirror and sees what his hair looks like, finally
<thom> Keybuk: MIAOW
<sladen> the last piece of news on  http://www.canonical.com/  is the warty release, maybe it's time for some new news :)
<Keybuk> hmm, we didn't change the theme of that? :(
<dholbach> lamont: you're doing a one man show on #ubuntu, i'm impressed :-)
<Keybuk> nobody can fill a room quite like lamont 
<Kamion> hmm, meh, jigdoing the DVD is awkward due to the live filesystem
<Kamion> 600MB+ .template, yay
<lamont> Keybuk: feh
<lamont> figured I had to do _SOMETHING_ while I was burning isos
<Keybuk> I've given up, this CD writer hates me
<dholbach> fix some last minute universe packages :-)
<Keybuk> it always fails somewhere around the 370MB mark
<Kamion> clean the lens?
<Keybuk> how?
<Kamion> you can get special CD drive cleaning bits, can't you?
<Keybuk> ah, an excellent plan with one two minor drawbacks ... 1) I don't have any special CD drive cleaning bits and 2) nowhere that sells them would be open at 4am :)
<Kamion> well, not NOW
<Kamion> they're like five quid from Maplin apparently
<Keybuk> by the time I get around to it, I'd be flying to UDU and giving the laptop back, so isn't really worth the effort now :(
<lamont> dholbach: you have a favorite package for me to play with>?
<dholbach> lamont: if i wanted to torture you, i'd say gcompris :-)
<lamont> and I would have to hit you with it. :-)
<Kamion> elmo,mdz: [post-hoary]  any thoughts about sticking the live cloops into the archive at some point, maybe just in the run-up to release? if we ever do things like netboot casper, it'd be useful
<dholbach> nobody really knows how it could ever have built, even the new debian version is crack
<lamont> dholbach: note that I'm bandwidth challenged, and don't have most of universe here at my finger tips
<dholbach> lamont: then just relax :)
* Kamion runs away from anything that build-depends on gnuchess
<lamont> Kamion: heh
<fabbione> Kamion: that sounds interesting, but it would add 1.8GB of data to the archive that aren't really rsync friendly.. i think elmo would hand somebody if we decided to do so
<lamont> dholbach: actually, I was thinking I'd build my kamion-dvd knockoff
<fabbione> s/hand/hang
<Kamion> fabbione: yeah, there's that minor problem
<Kamion> fabbione: although they're pretty rsyncable now
<Kamion> lamont: hmm?
<dholbach> lamont: i don't quite understand
<lamont> Kamion: you're like missing all of universe on the dvd
<lamont> :-)
<lamont> and there's no kobodl in the livecd
<Keybuk> ...so, I was thinking; given that "deb" is short for Debian ... and everyone mis-spells Ubuntu anyway ... maybe we should call them ".nut"?
<lamont> Keybuk: lol
<dholbach> :-))))
<elmo> kamion: err, eww
<zenrox> lol
<ogra> Keybuk, yeah
<lamont> Kamion: and you like left almost 2GB unused on that poor dvd.. such waste will not be tollerated..
<zenrox> apt-get apche.nut
<Keybuk> zenrox: no, it'd be nut-get ... or perhaps just "squirrel"
<zenrox> lol
* dholbach wants his porn-get
<Pizbit> Keybuk: Which would then be shortened to sq or s.
<Kamion> elmo: yeah, it's ugly; just trying to think of solutions to the 600MB jigdo .template problem that don't suck
<lamont> elmo: just create a new component (part of main) called 'mirror-killer'
<lamont> or is that oo.o?
<Keybuk> that's "cotd" isn't it?
* dholbach likes the  blackhole  component best :-)
<elmo> any component like that would be named 'pitti' if I had my way
<Keybuk> yeouch!  saucer of milk, table two!
<Kamion> hmm
<Kamion> actually, I could distribute them on cdimage, and put an extra URL in the jigdo URLs section
<Keybuk> surely it'd be seb, the human upload machine?
<daniels> Keybuk: you just wait until breezy opens and the X uploads start flowing :)
<Kamion> that would at least mean you could point jigdo-lite at an existing live CD image
<calc> are the dvd torrents are going to be in the same location as the cd ones?
<Keybuk> when are we opening breezy?  in UDU?
<Kamion> calc: DVDs probably won't be released on releases.ubuntu.com
<Kamion> uh, before UDU I hope
<elmo> Keybuk: I planned to do it almost immediately?
<Keybuk> ah ok
<Keybuk> could someone prod me when that happens
<Keybuk> hard, if I appear to be asleep
<Keybuk> I'll need to change mom and nda too
<calc> Kamion: where will they be?
<Kamion> calc: probably cdimage.ubuntu.com/releases/hoary/release/ or thereabouts
<elmo> woo, some load for mcmurdo and mirnyy
<calc> Kamion: ok
<elmo> Kamion: what decision (if any) was made about kubuntu?
<Kamion> elmo: I had difficulty extracting a final decision out of anyone
<Kamion> elmo: I'm inclined to put them on releases
<Riddell> what's the question?
<Kamion> Riddell: where to publish the Kubuntu release CD images
<elmo> kamion: if that's the decision, the sooner we do that the better
<elmo> like -12 hours sooner
<Kamion> meh, ok, will .poolise them
<Riddell> Kamion: same server as ubuntu ones would be my preference, otherwise it feels like it's not a proper release
<Kamion> $ for-project kubuntu publish-release daily 20050407.1 install poolonly
<Kamion> working
<Kamion> it'll be http://releases.ubuntu.com/kubuntu/
<Kamion> er and a subdirectory of that
<Kamion> http://releases.ubuntu.com/kubuntu/hoary/ (http://releases.ubuntu.com/kubuntu/.pool/ for the pre-publishing stuff)
<Riddell> Kamion: what's pre-publishing stuff?
<thom> Riddell: means we can push stuff to mirrors before it's live
<lamont> Keybuk: my wife informs me that no one can clear a room quite like me either
<Riddell> clever
<dholbach> lamont: you simply ROCK! :-)
<Kamion> lamont: she's so sweet
<lamont> yeah
<lamont> Kamion: redheaded irish gal, ya know?
<lamont> <lamont> Keybuk: my wife informs me that no one can clear a room quite like me either
<lamont> in case you didn't see it
<Keybuk> lamont: yeah, I did :)
<Keybuk> I was trying to near-instantly jump machines
<Keybuk> but ident foiled my attempts
<lamont> lol
<lamont> Kamion: wondering how lazy I can be...  is filesystem.cloop in some md5sum file somewhere?
<lamont> and if I just dropped a extras/ directory on the CD that was it's own archive base, would anything bitch at me?
<Kamion> elmo: ok, syncing out now
<Kamion> lamont: it's probably in md5sum.txt on the CD, but only cdrom-checker cares
<Kamion> lamont: no, shouldn't
<elmo> kamion: thanks
<lamont> cool
<lamont> dholbach: sometimes I even know what I'm talking about...
<infinity> Y'know, tracking mozilla security holes could be a fulltime job in itself.
<dholbach> :-)
<mpt> (isn't that Chris Aillon's full-time job?)
<daniels> i thought he hacked on mozilla as well
<calc> probably both
<calc> he was doing non security stuff when i met him last oct
* calc recalls trying to break the ff in ubuntu warty for him
<thom> infinity: yes.
<thom> he's RHAT's packaging lead for moz.org stuffs afaict
<infinity> Yeah.  He also does a lot of backporting of patches to 1.4 (poor guy)...
<thom> almost as much fun as 0.9.3
* daniels has occasional twitching nightmares about needing to patch xfree86 4.3 in a couple of years.
<infinity> 0.9.3 and 1.7.3 aren't really all THAT bad to backport to.
<infinity> I'm not suffering too much, except for the sheer volume of patches that haven't been touched.
<lamont>  /dev/hda8             96124904  86947148   4294804  96% /home
<lamont> hrm... that's annoying
<dholbach> lamont: had that yesterday with rsync action going on, capped the file to 53% :-/
<lamont> dholbach: bummer
<lamont> then there's the other machine: /dev/sda2             11535376    497016  10452392   5% /
<lamont> that one has 2 73GB drives as well
<dholbach> i should start some dvd-backup action soon
<lamont> ditto
<dholbach> i'm nearly falling asleep, not even drum&bass music helps *hrmbl*
<daniels> dholbach: eep, that does suck
<daniels> dholbach: although it depends what sort of dnb :)
<daniels> if something like pendulum - another planet, doesn't keep you alive, then you have problems
* dholbach is bad at track names :-)
<ogra> dholbach, try freejazz....
<dholbach> daniels: i always nick mixtapes of http://breaksblog.biz/wp-rss2.php - and every third is acceptable :-)
<daniels> heh, cool
<dholbach> ogra: thanks... had enough headaches last week :-)
<ogra> heh
<infinity> wget https://bugzilla.mozilla.org/attachment.cgi?id=174833
<infinity> La la.
<infinity> -EWIN
<daniels> you'll probably want to put quotes around that, anyway
<infinity> Nah, works fine.
<infinity> The lack of & is helpful.
<elmo> yeah, zsh is fairly spethial in the way it handles unmatched globs
<Kamion> bash is the same
<Kamion> at least if you mean the !nullglob behaviour of just leaving the glob as it was
<diego> how goes hoary?
* thom wonders if there's something mako is not telling us
<elmo> Kamion: zsh errors out
<jsgotangco> makogirl?
<Kamion> elmo: oh
<makogirl> it's conversation in #debian-devel
<dholbach> in #debian-women rather? :-)
<jsgotangco> *grin*
<makogirl> in fact not, stargirl had an experience in #gaim that inspired me to try something out for a few minutes
* jsgotangco opens up planner mode in emacs and starts doing some notes
<lamont> dholbach: ~lamont/chroots only accounts for 8.6GB of that.  sigh
<dholbach> lamont: hm?
<lamont> my full disk
<lamont> du finally finished running... :)
<dholbach> argl :-/
<dholbach> pals... i'm off to bed - enjoy the party, i'm too tired to be drinking, cheering and dancing with you - have a nice day, see you later
<Lathiat> dholbach: hehe night :)
<lamont> g'night dholbach 
<dholbach> bye lamont, Lathiat 
<dholbach> *wave*
<infinity> Woo, only one screenful of CANs left to process.
<elmo> Kamion: I added maswan back to rotation, please shout if it looks broken to you still 
<elmo> kamion: (and triggering syncproxy will trigger him)
<elmo> well not maswan himself.  that would be harsh.  his machines
<elmo> ARGH
<elmo> it's still broken
<Kamion> haha
<Kamion> looks ok?
<elmo> really?
<elmo> maybe it's my browser
<Kamion> oh, 130.239.18.142 is broken
<Kamion> take that out of the rotation for now? the rest are ok
<elmo> ok, done
<Lathiat> Kamion: what server is on that ip?
<Kamion> Lathiat: it's one of maswan's mirrors
<Kamion> of releases.ubuntu.com and other stuff
<Lathiat> ah funk, its on internet2 which means its free traffic from uni here, shame its broken :)
<elmo> Lathiat: it's one of 3
<Kamion> one of four
<elmo> use on of the other IPs
<Lathiat> ah ok
<elmo> err, right
<elmo> basic math sucks anyways
<elmo> what did it ever do FOR ME??
<mako> Lathiat: i'm going to hop on the torrents.. i have a fast commerciail connection and i2
<lamont> elmo: got you out of 2nd grade?
<Kamion> it's pretty hard to get held back a grade in the UK
<elmo> "fortunes-spam"
<elmo> oh dear
<Kamion> ok, I think I've got the CD image pages to have about the same font as www.ubuntulinux.org now, at least
<Kamion> the masthead appears non-trivial to do, I'll get somebody who actually knows about this stuff to look at it at some point
* lamont wanders off for a bit
<daniels> holy fucking shit
<daniels> if you have two files, one of which is 644 and the other of which is 600, chmod 644 <tab> completes to the one that's 600
<Keybuk> daniels discovers zsh ...
<daniels> Keybuk: that particular facet of the completion is utterly insane
<Keybuk> the CVS completion is cool too; cvs add <tab> only completes files you haven't added or ignored :)
<Keybuk> man 1 <tab> only completes pages in section 1
<Keybuk> dict <tab> is over the top though
<Kamion> mdz: could you remove the stray ,,new-pristine.* directory owned by you in cdimage?
<Kamion> the dict tab-expansion plugin for irssi is cool
<Kamion> if insane
<Keybuk> I'm surprised X-Chat hasn't got wiggly-words yet
<Kamion> "hi, I'm too lazy to type English; I just hold down tab instead"
<Kamion> hmm. bored
* Kamion starts preparing cdimage for breezy
<daniels> Kamion: if you were truly bored, you'd start on graphical d-i ;)
* Lathiat grins at daniels 
<Kamion> that's next week
<Lathiat> anyone on internet2 with the cdimages i can suck down?
<Kamion> (vaguely serious there actually, I was planning to start on the cdebconf extension design)
<daniels> coer
<aj> why not do the graphical install from the livecd?
<aj> (ie, from a real debian system, not udebs)
<Kamion> I haven't decided whether that's crack yet
<Kamion> and in any case we want a graphical live CD startup process anyway :)
<Kamion> so need many of the same things
* Lathiat thinks it would be better to have a proper graphical install
<Kamion> work on a live CD installer will probably be happening in parallel
* |QuaD- thinks the ubuntu console install is great (simple, and fast)
<Keybuk> I can never decide whether cp -a off a LiveCD to install is any more or less of a hack than debootstrap
<aj> the nicest thing about a graphical install would be being able to switch to an xterm or a web browser while the install's running...
<Lathiat> aj: yeh that would rock
<Lathiat> iirc the solaris 10 graphical install gives you a web browser
<Pizbit> aj: And irc!:)
<Lathiat> Pizbit: xterm :)
<aj> hrm
<jdub> Lathiat: and herpes.
* Kamion IRCs from d-i not infrequently
<Pizbit> Lathiat: Bah, mrxvt
<Lathiat> jdub: heh
<Kamion> although it involves sshing somewhere else
<Keybuk> gods, I remember when somebody sold Debian to me on the basis that you could install an IRC client before the rest of the system
<daniels> irssi-udeb
<aj> put in the cd, click install, get the installer popping up in window, and get dropped in an irc help channel in another
<Lathiat> jdub: dear god is JDS a steaming pile of crack
<Pizbit> Keybuk: Buahaha:)
<Keybuk> I seem to remember having to install apt first though, from sid
<aj> keybuk: would've been slink/unstable at the time
<Kamion> daniels: oh, you asked about the warty linux+ thing
<Keybuk> may have been slink
<|QuaD-> when is the final freeze going to happen? what time today?
<Keybuk> I think hamm was the stable
<Kamion> daniels: that was a special I did for some magazine in Poland; warty plus security updates
<Keybuk> and didn't have apt, or a very broken one
<aj> hamm didn't have apt, slink did
<Keybuk> maybe it was bo?
<Kamion> |QuaD-: we've already frozen all but universe, release probably ~8am UT
<Kamion> er, UTC
<Keybuk> hamm then
<aj> bo didn't have libc6...
<|QuaD-> ok :)
<Pizbit> Keybuk: How many years ago was that?
<Treenaks> aj: hamm had a version availabe to download, so you could upgrade to slink, afaik
<Treenaks> aj: (maybe it was experimental? I didn't know much about the archive structure back then)
<daniels> Kamion: ahr
<Keybuk> Pizbit: uhh, figure about 6 or 7 years ago?
<aj> Treenaks: there was probably a backport somewhere, but i think mostly we just used the good ol' dselect methods to upgrade to slink
<aj> slink was released in '99 sometime i think
<aj> http://distrowatch.com/table.php?distribution=debian   knows ;)
<Kamion> hmm, we should get distrowatch to take ia64 out of http://distrowatch.com/table.php?distribution=ubuntu for hoary
* Keybuk tries to correlate the dates
* Kamion mails
<Keybuk> yeah, seems about right
<Keybuk> was probably bo/hamm then
<Keybuk> I know it was RH4.2 I left for Debian, so that makes sense
<Amaranth> hey, it's friday
<Amaranth> ;)
<Artemis3> 5am
<elmo> Copyright: ?
<ogra> elmo, still apt-get.org ?
<daniels> elmo: oh dear
<elmo> ogra: yes
<ogra> poor soul
* lamont wonders how things are going
* toresbe thinks about that
* toresbe silently opines that things are going OK by offering a piece of candy to lamont 
<lamont> heh
<pitti> Good morning, Hooray! Erm, Hoary!
<mako> pitti: oi!
<mako> two hours, no?
<pitti> yeah, 0800 UTC
<pitti> Morning mako :-)
<HiddenWolf> :)
<infinity> Mornin' pitti.
<mako> i'm gonna wander off for a bit then.. i'll be back before we do teh release.. sms me if there's anything urgent
<HiddenWolf> pitti, bad timing, they'll be burying a pope 15 minutes later
<HiddenWolf> if you want to make cnn, get better timing next time. ;)
<HiddenWolf> wow, new website
<Artemis3> so white...
<HiddenWolf> Wtf, just got a crash here
<HiddenWolf> gnome-panel crashed, came back up, then offered me 10 'panel already running, will exit now' errors
<schweeb> Artemis3: that's my complaint with it too
<HiddenWolf> I think the new site is slick!
<Artemis3> main site needs better access to l10n (ie: little flags or something non english ppl can quickly understand)
<HiddenWolf> daniels, ping
<daniels> pong
<HiddenWolf> Oh, sorry daniels
<HiddenWolf> there is a guy in #ubuntu with a warty-> hoary upgrade problem
<HiddenWolf> says he tried both nv and nvidia drivers
<HiddenWolf> if you would help, it's kakalto
<HiddenWolf> Why do I always find annoying little bugs when it's too late to have them fixed?
<daniels> HiddenWolf: yeah, got it, thanks
* lamont ponders whether he should stay up for the release or not
<HiddenWolf> daniels, thank you :)
<daniels> HiddenWolf: cheers
<Kamion> mdz: around?
<Kamion> mdz: is it time to publish stuff for mirroring yet?
<Duluu> where is new release?
<Kamion> Duluu: not yet
<Kamion> couple of hours
<Duluu> it'll today or?
<Kamion> yes
<Kamion> "couple of hours" => today
<sabdfl> morning all!
<HiddenWolf> Good morning to you! :)
<daniels> 'evening captain
<Kamion> yo
<Keybuk> Kamion: unless you're in (say) west-coast US, in which case a couple of hours time is "tomorrow" :)
<HiddenWolf> daniels, which logs do you need from that guy?
<Kamion> Keybuk: yeah, Duluu's IP suggests more like East Asia though
<daniels> HiddenWolf: /var/log/Xorg.0.log and /etc/xorg.conf
<HiddenWolf> daniels, cool, trying to calm the guy down. Seems bugzilla from lynx is a bitch
<daniels> yeah, I can believe that.  ugh.
<daniels> i'm stepping out for the night now; thanks a lot for stepping him through it.
* daniels waves, closes lid, vanishes.
<smurfix> Are the .torrent files in http://cdimage.ubuntu.com/daily/20050407/ the ones we'll use for the release?
<HiddenWolf> daniels, all in the days work for a groupie ;)
* smurfix can wrangle a bit of free bandwidth
<Kamion> smurfix: no
<Kamion> the filename will change so the torrent has to do
<Kamion> er, "has to too"
<smurfix> Kamion: OK, so I rsync the image and rename it locally
<Kamion> smurfix: fairly soon I hope, waiting for ok to publish
<Artemis3> i think you should publish torrent only for a while...
<Kamion> sabdfl: mdz's asleep I think; how far in advance do you want to create the symlinks?
<sabdfl> Kamion: ! thought we were going to release just before mdz crashed, was expecting that 9am-ish today
<Kamion> I didn't expect him to crash
<sabdfl> is mdz wanting to get up for the release?
<Kamion> and apparently he told elmo we should wait
<sabdfl> ok
<Kamion> (at ~5am)
<sabdfl> no mail from him
<Kamion> maybe I should phone
<sabdfl> i'll give him a call
<Kamion> k
<sabdfl> w.r.t. the symlinks, how many mirrors do we have that can be triggered, elmo?
<Kamion> the ISOs have been on releases.u.c for some hours, apparently triggered mirrors at least should be updated, and we had slightly older versions on releases since Wednesday
<sabdfl> just spoke with mdz
<mdz> morning
<mdz> I was just napping, so that I can stay up for a bit after the release
<sabdfl> let's aim for 7am UTC, 8am data-center time, which is in 10 minutes
<mpt> oy, who changed the GUI colors
<Kamion> ah, cool
<sabdfl> elmo: ping
<mdz> elmo: looks like MOTU are done
<Kamion> 07:26  * elmo runs back to hotel
<Treenaks> Run Elmo Run!
<sabdfl> swim trout, swim!
<Kaloz> :D
<Kaloz> good morning people
<mdz> who can man the download page?
* mdz fetches beer
<whiprush> !!
<Kaloz> =)
<thom> now that was good timing
<JaneW> mdz: greets
<thom> morning
<Kaloz> 2 mins and counting :PP
* Keybuk boggles ... something's decided that my filesystem wants to be remounted readonly
<JaneW> hmmm, still slightly early for beer here
<Treenaks> Keybuk: the kernel, sensing broken hardware?
<Kamion> I'm doing the publishing now, ignoring DVDs for the moment
<Keybuk> Treenaks: hmm, just noticing a few "SMART Prefailure Attribute" notices in syslog
<lamont> JaneW: some would consider that sacrilege
<mdz> hmm, we lost mako?
<mdz> sabdfl: the announcement is intact
<Treenaks> 08:51 -!- mako [mako@micha.hampshire.edu]  has quit [Read error: 104 (Connection reset by peer)] 
<Keybuk> yup, hard-drive appears to be dying :'(
<Artemis3> so can i get a torrent now?
<Kamion> Artemis3: patience please
<Artemis3> gao~
<jsgotangco> *drumroll*
<Kamion> I've done the Ubuntu publish on little (but not yet synced to mirrors), Kubuntu in progress
<Kamion> and in any case this isn't final 'til the announcement goes out, please don't hammer it straight away guys :)
<elbi> will there be any changes between the daily images and the final release of hoary?
<|QuaD-> congratulations guys!
<sabdfl> Kamion: will you holler when both publishes are fully complete?
<Kamion> sabdfl: yes
<sabdfl> cool
<Kamion> /srv/cdimage.no-name-yet.com/bin/sign-cdimage: line 20: /srv/cdimage.no-name-yet.com/www/simple/kubuntu/hoary/MD5SUMS: No such file or directory
<Kamion> hmm, bear with me here
<Artemis3> i just want .torrent
<mdz> Artemis3: it will be available soon, stand by
<Kamion> Artemis3: again, patience. the more questions I have to field, the longer it will take.
<elbi> we will ;)
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals | No more uploads to hoary/main without approval AND a damn good reason (ask mdz or Kamion) | Drumroll, please...
* jsgotangco starts drumroll
<elbi> waaaaaaaiiiiiiiihhhhh!
<Artemis3> teehehe
<Artemis3> ^^'
<Kamion> ... kubuntu live ...
<mdz> we ought to have elmo on deck for this...
<Kamion> I'll give him a ring
<thom> he's prolly just getting off the tube now
<sabdfl> sms'd him a few minutes ago
<sabdfl> told him 8am DC time
<Kamion> oh, ok, hung up on the ring tone then :)
<sabdfl> hung up on the ring tone?
<Kamion> I rang him, it was ringing, I hung up when you said you'd SMSed him
* Kamion pokes btmakemetafile. run faster.
<Artemis3> haha
<lamont> Kamion: it works better if you poke it with a stick
<Artemis3> killstick
<Artemis3> no wait
<Artemis3> not that one
<Flonne> Boomstick?
<Artemis3> ^^!
<sabdfl> hmm... maybe he hasn't checked sms's?
<mdz> Kamion: perhaps you can wave the same wand over it that you did over jigdo
<sabdfl> no reply from him yet
<thom> he's probably running
<thom> you'll hear him
<Kaloz> :)
<Kamion> ok, looks plausible, syncing to mirrors
<sabdfl> elmo's ready to rock in 30 seconds
<jsgotangco> ok houston's already set?
<elbi> live stream from your office please?
<Kamion> elbi: what office?
<Keybuk> elbi: Canonical doesn't _have_ an office! :p
<Artemis3> a webcam would do
<elbi> what?!
<Artemis3> hehe
<elbi> home work?
<Kamion> yes
<jsgotangco> its great isnt it
<elbi> sounds like a quite mess sometimes ;)
<elmo> here
<Lathiat> the css files on ubuntu sites really need to be renamed :) firefox seems to cache them aggressively
<mpt> Have fun, people
* jsgotangco still drumrolling...
* Kaloz too
<elbi> let's get some kickass torrent activity
<Kamion> thom: please restart the tracker if necessary
<Artemis3> sure
<Artemis3> provide
<jsgotangco> where's the official announcement so i can post in a lug list?
* smurfix still can't log in to ubuntulinux.org -- I'd say that's more urgent to fix than renaming CSS files :-/
<Artemis3> ah there
<Artemis3> about time...
<thom> Kamion: yes, watching
<Artemis3> slowpoke ftp
<Kamion> sabdfl: otherwise, should be done
<Kamion> jsgotangco: NOT SENT YET
<sabdfl> mdz: let's wait for elmo
<Kamion> sabdfl: 08:17 < elmo> here
<Mithrandir> thom: http://torrent.ubuntu.com/releases/hoary/array-7/ and friends doesn't have NameWidth=*
<mdz> <elmo> here
<sabdfl> ok
<Kamion> Mithrandir: that's my area not thom's
<Mithrandir> Kamion: oh, ok.
<Mithrandir> Kamion: just let it slide to post-release, then?
<sabdfl> bolshuyu krasnuyu knopku...
<Kamion> Mithrandir: er
<thom> torrents still rsyncing, fwiw
<Kamion> Mithrandir: actually, no, it is thom's. the .htaccess there does have NameWidth=*
<Kamion> sabdfl: ?
<smurfix> sabdfl: If you do that, at least use Cyrillic letters ;-)
<Artemis3> f6b3f164c99761234858a4d2c12d0840  ubuntu-5.04-install-i386.iso
<Artemis3> that should do
<Artemis3> except i only care for the torrent
<sabdfl> Kamion: big red button
<Kamion> ah yes :)
<mdz> elmo: please disable further uploads to hoary
<Artemis3> hey
<Artemis3> thats not fair
<Mithrandir> Kamion: it would be nice to have a directory with just the torrents in, so I could just do wget -m on them for my torrent mirror.
<Kamion> mdz: what should I do with DVDs?
<Artemis3> let me in in the tracker...
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Drumroll, please...
<d3vic3> mdz, no more uploads until release ? 
* JaneW enjoys watching the count-down sequence ;)
<elmo> mdz: done
<Kamion> d3vic3: we just released
<mdz> d3vic3: no more uploads to hoary _ever_
<Flonne> So the torrents are good to go?
<elmo> final(ish) cron.daily is running
<smurfix> Mithrandir: you can tell wget to fetch based on extensions
<Artemis3> grr
<d3vic3> O.o
<Keybuk> mdz: I guess I should disable mom today as well? :)
<mdz> Keybuk: redirect it to breezy, rather
<Mithrandir> smurfix: oh, how?
<jdub> Keybuk: mom has a new problem child to look after ;)
<Keybuk> there needs to be a breezy archive for me to do that...? :p
<mdz> Keybuk: elmo said 0801 UTC ;-)
<smurfix> Mithrandir: I dimly remember an option to do that ...
<smurfix> Mithrandir: I might be mistaken though
<smurfix> Mithrandir: no, "-A torrent" does that
* Mithrandir fires up a torrent client.
<Mithrandir> let's see what this gbit line is good for!
<Mithrandir> smurfix: ah
* Treenaks sees 2 peers and no seeds
<Treenaks> 3
<Artemis3> i cant get into the tracker
<Artemis3> :(
<elbi> try again, works now
<jdub> elmo: do we have any mirrors on Internet2?
<doko> maybe we should limit bandwith with direction Norway ... ;)
<elmo> jdub: se.{archive,releases}.u.c is
<Mithrandir> doko: dude, it's bittorrent, I'm seeding out too. :)
<elmo> at least
<jdub> elmo: rock, thanks
<Keybuk> mdz: want bugs turned on again I guess too?
<elbi> we need seeds!
<torkel> elmo: it is?
<mdz> Keybuk: not quite yet, let me breathe for the weekend
<Kamion> speaking of seeds, I guess I should branch the seeds archive now :)
<Kamion> (for breezy)
<Artemis3> ok
<Artemis3> im in
<Artemis3> thanks
<sabdfl> i'll edit the download page
<sabdfl> elmo: what mirrors can i point at out of the box?
<Kamion> I was trying to, but Firefox on this system remembers the wrong password
<elmo> sabdfl: guaranteed, us.releases.ubuntu.com, se.releases.ubuntu.com and releases.ubuntu.com
<elmo> sabdfl: I'll run the mirror checker now to see which have the symlink
<mdz> elmo: can you send mail to the rest and ask them to sync up as soon as they can?
<Kaloz> btw, when i mailed about that i want to provide a hungarian mirror, my mail was ignored :p
<Kaloz> should i set it up again? :p
<infinity> I'm getting the dailing boot from the library.
<infinity> Happy releasing, everyone.
* infinity -> home.
<thom> cya ifni
<Mithrandir> infinity: see ya
<thom> aaargh, torrent hash checks *so* slow
<Lathiat> thom: using the python stuff?
<Lathiat> a friend and i are working on some torrent stuff and his hashing (which is in delphi) seems to go *alot* faster than azureus or the python official stuff
<thom> yes, python stuffs
<lamont> thom: clearly it needs a C binding, eh?
<Lathiat> heh yeh
<zenrox> lol
* lamont can hardly wait for Kamion to tell ryman "_now_ it is."
<sabdfl> erk
<Kamion> erk?
<sabdfl> se.releases.ubuntu.com gives a weird page
<Keybuk> it does?  looks like apache to me
<elmo> http://na.mirror.garr.it/mirrors/ubuntu-releases
<elmo> is up-to-date
<Kamion> se.releases might still point to that broken mirror of maswan's
<elmo> http://planetmirror.com/pub/ubuntu/releases/ is up-to-date too
<Kamion> or at least one of the IPs
<elmo> so far those are the only ones to have caught up
<Keybuk> premature congrats, I've gotta go catch a train
<elmo> sabdfl: ^--
<Kamion> maswan: se.releases.ubuntu.com -> same virtual hosting as for releases.ubuntu.com please?
<elmo> alternatively http://se.releases.ubuntu.com/mirror/ubuntu-releases/
<elmo> or just http://ftp.acc.umu.se/mirror/ubuntu-releases/ (I guess)
<sabdfl> yes i'm going to link directly
<mdz> sabdfl: announcement is standing by
<thom> torrents look like they're rolling steadily
<mdz> sabdfl: hmm, there is no link to the release notes in the announcement; shall I add one?
<sabdfl> elmo: planetmirror still seems to indicate RC
<sabdfl> mdz: page is ready
<sabdfl> mdz: good idea :-)
<elmo> hmm, how special
<elmo> planetmirror have managed to mirror kubuntu but not ubuntu/hoary
<sabdfl> prejudiced b*stards
<elmo> sorry, I assumed no one would have done that
<elmo> the .it mirror is the same
<sabdfl> mdz: let's ROCK
<jsgotangco> *grin*
<sabdfl> we can add extra mirrors as they come online
<elmo> yeah, I'll make the checking script less kubuntu-biased
<sabdfl> mr zimmerman you have the floor :-)
<jsgotangco> go go go
<d3vic3> O_O
<haggai> elmo: hey that's just great how the checking script is now >:)
<mdz> doing final link check
<mdz> announcement is away
<Flonne> So it's official?
<jsgotangco> we have lift off?
<Flonne> Kubuntu torrent just started working. :)
<lamont> woot!
<pitti> \o/
<Flonne> 417 kB/s down, 302kB/s up (total) \o/
<pitti> Go, Hoary, go!
<sabdfl> congrats everybody, and especially mdz, kamion, elmo, fabbione, dholbach, ogra, main & motu! also thanks to the doc-team who are a new force to be reckoned with in the ubuntu world
<Burgundavia> Flonne: I hate you
<whiprush> congrats gentlemen. 
<jsgotangco> woo hoo
<Flonne> Shaw's based in Calgary, Burgundavia. :)
<Burgundavia> Flonne: bah
<Flonne> Hooray for Hoary!
<jsgotangco> nice one
<jdub> mdz: moderated
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Ubuntu 5.04 is released!  http://lists.ubuntu.com/archives/ubuntu-announce/2005-April/000023.html
<dilinger> congratulations
<jdub> mdz, sabdfl: moderate kubuntu announce mail from jr?
<mdz> jdub: yes please
<Burgundavia> mdz: download just reverted to old styel
<Burgundavia> w.u.c/download that is
<mdz> Burgundavia: browsers cache the old CSS sometimes
<sabdfl> jdub: moderate?
<mdz> sabdfl: s/moderate/approve/
<Burgundavia> mdz: bloody wierd
<jdub> done
<sabdfl> jdub, mdz: absolutely
<Burgundavia> mdz: I had the rc page, with the new style, then the old style
<mdz> Burgundavia: yes, we have seen this as well
<sabdfl> Riddell: when is yours hitting the streets?
<mdz> sabdfl: it just did
<mdz> sabdfl: http://www.kubuntu.org/hoary-release.php
<sabdfl> kool
<Riddell> we are go
* haggai pops open the champagne
* jani applauds and sends link to windows using friends
<Riddell> time for a good bowl of porridge
<jsgotangco> windows using friends?
<mdz> jsgotangco: "windows-using friends"
<morgs> friends don't let windows use friends... :)
<pitti> sabdfl, mdz: what about the home page? The news still talks about the RC
<Riddell> thanks to sabdfl, mdz, Kamion, elmo, jdub et al for all their help
* d3vic3 caffiene++
<jsgotangco> ok off to start breezy documentation
<jsgotangco> hehe
<sabdfl> i don't know how to add news to the home page :-)
<sabdfl> will ask silbs to add the final release announcement
<sabdfl> in a few minutes
<mdz> Mithrandir: are you torrenting some of that wondrous bandwidth of yours? ;-)
* Treenaks is torrenting with --ipv6_enable=1
<thom> mdz: i am abusing all the LINX i can get my hands on with torrents
<jdub> man, the site is weird
<jdub> bouncing through all different css b0rkage and workage
<HiddenWolf> yeah, just go from frontpage to planet, you'll be suprized
<HiddenWolf> white background, yellow logo
<jdub> elmo: did you update puc?
<Burgundavia> and sometimes the background doesn't load on the mainpage
<elmo> jdub: puc?
<elmo> oh
<elmo> doing
<jdub> thanks
<pitti> elmo: btw, is hoary-security open now?
<Mithrandir> mdz: pushing 1.9MB/sec ATM.
<jsgotangco> borked css
<elmo> pitti: hoary-security has been there for months and months
<elmo> it was only hoary-updates that was missing
<pitti> ok, thanks
<Kamion> breezy seeds archives created, for the sheer hell of it
<elmo> in any event uploads aren't being processed yet
<Kamion> copies of hoary
<pitti> elmo: will amber automatically recognize that there are now two affected distros?
<Kaloz> in 10 mins, my box will have all the release files. you can add it to the mirrors, too
<pitti> s/distros/releases/
<seb128> hi
<pitti> Hi seb128 
<elmo> pitti: amber doesn't care, the distro information is encoded in the upload
<seb128> i386 works fine here :)
<lamont> pitti: building chroots for hoary-security now.
<Kaloz> at least for hungary, it wil lbe faster :)
<seb128> s/i386/i386 DVD/
<pitti> seb128: you just missed the show :-)
<lamont> pitti: and then your uploads will actually build
<seb128> pitti: oh ?
<lamont> elmo: hoary-updates is in w-b as well?
<pitti> lamont: nice, thanks :-)
<pitti> seb128: [09:47]  <mdz> announcement is away
<elmo> lamont: yes, told you it was
<seb128> pitti: cool :)
<lamont> elmo: yeah, is late here.
<thom> CAN I UPLOAD TO BREEZY YET? CAN I CAN I CAN I? :P
* lamont will make sure that hoary-updates has at least one autobuilder/arch before he goes to sleep
<pitti> thom: <Kamion> breezy seeds archives created, for the sheer hell of it  ??
<lamont> thom: sure.  But I bet it gets rejected.
<d3vic3> thom: heheheheh
<elmo> lamont: no, days ago :p
<lamont> elmo: yeah
<Kamion> hmm, why isn't the seeds archive mirror on rookery updating properly I wonder
<lamont> I just hadn't created them yet, and didn't remember that you'd told me
<jdub> celebrating birth of hoary and death of pope all at once
<jsgotangco> haha
<jsgotangco> omg
<jsgotangco> i remember
<jsgotangco> its his funeral today
<jsgotangco> and im a catholic
<jsgotangco> *grin*
<elmo> jdub: http://people.ubuntu.com/~james/paste/006.txt
<d3vic3> OMG
<elmo> but I think I've whined about that before
<elmo> jdub: anyway, update done
<lamont> jdub: is my brothers b-day today too, he says thanks
* pitti works offline for a bit, main net connection down again
<Artemis3> they are actually moving the pope right now
<Artemis3> interesting coincidence
<jsgotangco> ive seen the pope twice
<Kamion> oh, I'm just a muppet, breezy seeds visible now
<jsgotangco> i think the hoary upgrade howto in the wiki should be updated
<jsgotangco> hrrmmm
<jsgotangco> let me check that
<JaneW> This may be a bit premature, but can I start updating http://www.ubuntulinux.org/wiki/HoaryGoals and add a BreezyGoals page yet?
<Kamion> don't see why not
<JaneW> :)
<sabdfl> JaneW: put it in the UDU wiki
<mdz> I managed to finish my beer before the release even happened
* mdz goes for the scotch instead
* Kamion grins
<Kaloz> :p
<Lathiat> haha
<JaneW> sabdfl: will do
<JaneW> /me sings "Keep on rockin' in the free world.
<jsgotangco> id like a scotch but its only 4pm
* JaneW sings "Keep on rockin' in the free world"
<Lathiat> i'd like a scotch or beer but im broke till monday :\ heh
<mdz> jsgotangco: the release was cleverly scheduled to be late enough for scotch on PDT
<Kamion> mdz: have a good release party
<Treenaks> mdz: the next one should favor Europe!
<Kamion> I think I'll go catch up on nap
<thom> mdz: enjoy
<mdz> Kamion: there are only three of us so far, for tomorrow night, but we'll see
<mdz> Kamion: sleep well and thanks for all your efforts
<Kamion> mdz: that can be a good party :)
<mdz> hmm, the Kubuntu release is on distrowatch, but not yet Ubuntu ;-)
<Burgundavia> ha ha
<haggai> mdz: muhaha
<Burgundavia> kubuntu hit distrowatch first
* Riddell cackles an evil laugh
<jsgotangco> haha
<Kaloz> okay. it's there. Hungarian mirror up at http://dune.hu/ubuntu-releases . I post it to HUP (Hungarian Unix Portal) to get people download from there to save some bw for You.
<sladen> haggai: it might be worth replacing that .php with a static page.  it's /. itself already
<Kamion> Kaloz: any chance you could mirror the .htaccess, HEADER.html, FOOTER.html too?
<Kamion> might as well make it look pretty
<mdz> sabdfl: adding to the release checklist: grep the release announcement for mentions of the _previous_ release ;-)
<Kaloz> Kamion: sure. can wget grab those or is should get rsync?
<Mithrandir> Kaloz: ask people to use bittorrent. :)
<Kamion> mdz: haha, d'oh
<Kaloz> Kamion: better? :)
<Kamion> Kaloz: wget should be fine
<Kaloz> yep, but .htaccess isn't wgetable for sure ,)
<Kamion> oh, rsync then
<Kamion> Kaloz: getting there, it's missing the descriptions and FOOTER.html shows up in the index
<Kaloz> ah
<Kamion> which probably just means you need the .htaccess
<Kamion> or possibly to tweak apache allowoverrides
<Kamion> Kaloz: I've added that to /download/, thanks; but only under "Other Mirrors" for now because I'm not quite sure what to do about the "Europe" entry in the current list
<sladen> is there any chance  www.kubuntu.org  could be put behind the reverse-proxy.  It's getting hammered
<Kamion> elmo: does Kaloz need to mail mirrors@ubuntu.com to get that onto your list?
<rubenv> Congratulations with the release everyone!
<mdz> sabdfl: eek, the FAQ is broken
<Kaloz> Kamion: no problems. anywa,y the box wil lbe upgraded next week, so it can hold the whole archieve, too
<Treenaks> are we on slashdot yet?
<mdz> http://www.ubuntu.com/support/documentation/faq/ shows nothing
<JaneW> sabdfl: sorry but I see there's already a Breezy page at http://www.ubuntulinux.org/wiki/BreezyBadger, which has similar info, sure that should be updated rather?
<mdz> http://www.ubuntulinux.org/support/documentation/faq?full=1 works though
<sladen> mdz: yes.  That was what I emailed Henrik about that last night...
<Kamion> Kaloz: cool, thanks
<mdz> hmm, zero upload on ubuntu-5.04-live-powerpc.iso.torrent
<Kaloz> Kamion: np :) how big is the whole archieve? arounf 70G?
<mdz> all the others are active
<mdz> rubenv: thanks
<Kamion> Kaloz: the archive, as in .debs? dunno, I only do CD images
<mdz> JaneW: that was put together by a random wiki passer-by; I haven't reviewed it yet
<Kaloz> Kamion: k :) warty with cdimages was around 40G if i recall right
<mdz> the FAQ needs updating, especially the KDE question
<mjg59> Congratulations, all
<HiddenWolf> I wonder, why do I have a kubuntu announce in my inbox, but not an ubuntu one?
<mdz> mjg59: thanks
<sabdfl> mjg59: thanks to you for our TotallyRadLaptopSupport
<haggai> sladen: the box itself is fine, 0.3% CPU usage tops
<Kamion> Kaloz: the whole of cdimage.ubuntu.com comes to ~139MB
<rubenv> Breezy is planned for october right?
<mdz> MB?
<Kamion> er, GB
<mdz> rubenv: yes
<Kamion> Kaloz: releases.ubuntu.com is ~98GB
<Kaloz> k
<rubenv> Great, given the fact that I've got little to do during summer, I'll try my best to help out :-)
<hno73> Those having wiki skin problems: are you logged in?
* Treenaks *headdesk*s @ distrowatch.. the DO have kubuntu 5.04 final, but NOT ubuntu 5.04 final
<hno73> try setting the skin to Ubuntu in prefrences
<lamont> elmo: hrm... I think I'm going to disable the buildds on ia64 for now...
<Lathiat> Treenaks: perhaps because the release announcement hasnt gone out yet :)
<Treenaks> Lathiat: it hasn't?
<thom> Lathiat: except it has
<lamont> Lathiat: huh?
<Treenaks> Lathiat: I have it.. on -announce
<elmo> lamont: good plan
<lamont> elmo: yeah
<Lathiat> oh it has
<Lathiat> i jsut got it
<Riddell> Treenaks: distrowatch looks good to me :)
<sladen> haggai: it's takes 24 seconds to return a page
<jsgotangco> hahaha
<jsgotangco> Kubuntu *evil grin*
<rubenv> Lathiat: but your point is right, the kubuntu ones were a bit quicker on the mailserver ;-)
<haggai> sladen: I guess it must be a bandwidth problem
<sladen> jsgotangco: it's all that eye-candy bling
<Treenaks> Riddell: yeah, but you're some kind of kde person
<Lathiat> rubenv: perhaps because it was sent 18 minutes earlier :)
* Pizbit joins onto the i386 cd iso torrent:)
<sladen> haggai: not at my end...
* Amaranth will hop on the i386 torrent
<sladen> haggai: try:   time wget -q -O - http://www.kubuntu.org/   or something similar
<Amaranth> 4mbit cable :)
* Lathiat has half megabit with quarter megabit upload
<rubenv> ah torrents, I'll put up a 100mbit seed for the cds
* Lathiat spits at Amaranth 
<Amaranth> oh, and 2mbit up
<Treenaks> website error: http://www.ubuntulinux.org/support/marketplace/ (marketplace link on front page) 404's
<Amaranth> rubenv: Ok, I don't need to seed then. :P
<Lathiat> Amaranth: the more the merrier :)
<mdz> Treenaks: tell hno73
<Treenaks> hno73: http://www.ubuntulinux.org/support/marketplace/ (marketplace link on front page) 404s
<rubenv> http://releases.ubuntulinux.org/hoary/ubuntu-5.04-install-i386.iso.torrent
<rubenv> why do i get a 404 for this?
<dredg> ah, thankfully planet.u.c no longer looks like it was beaten with the entire ugly tree
<rubenv> aha not anymore
<hno73> Treenaks: looking
<Pizbit> rubenv: Works here:)
<Burgundavia> hno73: didn't for me
<haggai> sladen: you're right, 26 sec from the machine itself :-/
<Amaranth> yay, 460KB/s download on the torrent :)
<Amaranth> i'll have it seeding in no time
<hno73> The right link is http://www.ubuntulinux.org/support/supportoptions/marketplace
<Pizbit> rubenv: The more on the torrent the better:)
<Pizbit> Amaranth: Yay, 'cause I'm keeping 0kiB/s:)
<hno73> Front page is wrong; thanks, fixing ...
<rubenv> Will take a while before it starts seeding thoug
<rubenv> *though
<Kamion> elmo: meh, 82.211.81.155 is out of date
<Kamion> rubenv: ^- that was your 404
<rubenv> Kamion: not really
<rubenv> 66.98.158.57
<Kamion> rubenv: huh?
<elmo> Kamion: ??
<Kamion> elmo: 09:33 < rubenv> http://releases.ubuntulinux.org/hoary/ubuntu-5.04-install-i386.iso.torrent
<rubenv> I'm not seeding it through my home laptop ;-)
<Kamion> (echo HEAD /hoary/ubuntu-5.04-install-i386.iso.torrent HTTP/1.1; echo Host: releases.ubuntulinux.org; echo Connection: close; echo) | socket 82.211.81.155 80
<Kamion> reproduces
<elmo> PLEASE GOD tell me we didn't use releases.ul.o in the announce?
<Kamion> the announce pointed to /download/, which points to releases.u.c
<elmo> anyway fixed DNS
<rubenv> The curious thing about ubuntu bittorrent is that the i386 ones are always the slowest ones, you'd expect otherwise
<mdz> elmo: we only used www.ubuntulinux.org/download/ in the announcement
<elmo> mdz: ok, cool
<elmo> it's a RR so dns will prop fast in any event
<sladen> rubenv: all the cheapskates use i386
<mdz> elmo: the ppc torrent just picked up, coincidence?
<rubenv> sladen: as a poor student, I currently can't afford a powerbook ;-)
<lamont> sladen: btw, wondering if the bind9.3.1 bits fix 212226 for you
<Amaranth> ssh is _painful_ when i'm maxing out on bittorrent :p
<elmo> mdz: imagine so, ubuntlinux doesn't appear in the .torrent's 
<sladen> lamont: there's two mentions in the changelog of things that might affect it.  I'll try it
<lamont> sladen: yeah, was thinking the same thing...
<Pizbit> rubenv: Yep, it's slowly picking up speed though
<maswan> http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
<maswan> nice :)
<maswan> Kamion: Ok, I thought I fixed that, but apparently I forgot some bit of it.
<mdz> maswan: wow
<mdz> I wonder what us.archive looks like
<jdub> maswan: *cough* "spike" :)
<maswan> http://stats.sunet.se/stat-q/plot-all/sundsvall1-umea2,today,raw,traffic-kbit
<maswan> made a nice impact on the 10Gbit backbone link too. :)
<sladen> elmo: the nameservers in resolv.conf on the kubuntu box are unreachable.
<maswan> http://stats.sunet.se/stat-q/plot-all/umea2.umea-srp,2005-04-08,raw,traffic-kbit
<maswan> that one is just our university
<lamont> maswan: heh
<sladen> elmo: ping haggai
<haggai> no I was using the wrong test, nameservers are ok
<Mithrandir> maswan: nice. :)
<maswan> ServerAlias releases.ubuntu.com se.releases.ubuntu.com releases.ubuntulinux.org se.releases.ubuntulinux.org
<maswan> any other needed?
<maswan> Fetched 4722kB in 30s (155kB/s) <- I've never seen the ftp cluster this slow. but it is still usable. :)
<HiddenWolf> Did the server just become totally unusable?
<Mithrandir> gah, bittorrent _eats_ my box.
<Mithrandir> we should write a better client, IMHO.
<elmo> maswan: hey, you asked for a test :)
<elmo> Mithrandir: err, and server
<elmo> the server's worse
<Mithrandir> elmo: sure, that too.
<Amaranth> What's wrong with bittorent 4? It looks nice and seems to run fine.
<Amaranth> Except for the odd time when it freezes, but all apps seem to do that.
<maswan> elmo: those ServerAlias, are those all that are needed, or do you want more?
<maswan> elmo: And it seems like my estimate of "somewhere around 500-600Mbit/s" is fairly accurate. :)
<koke> hi all! congrats for hoary :)
<mdz> koke: thanks
<maswan> elmo: any particular reason you didn't like 130.239.18.142 ?
<ska-fan> Is using shipit when I can perfectly well download the iso images at no additional cost considered abuse?
<jdub> ska-fan: no
<jdub> ska-fan: shipit means handign out lots of CDs to your friends
<Mithrandir> bah
<Mithrandir> rhytmbox skips 'cause I'm using too much bandwidth
<lamont> jdub: friends?  I give them a handful and make them hand them out.. :0)
<lamont> total strangers get the singletons..:)
<Mithrandir> lamont: yeah, that works well for me too.. given that my "friends" includes "computer university computer club" and "local LUG".
<lamont> heh
<lamont> anyway, I think it's bed time for me.
<lamont> 3AM and all that
<thom> torrent's done 30GB of i386 installer cds
<thom> lamont: is that all?
<Burgundavia> is early morning on the east coast
<pitti> Hi astharot 
<fabbione> hey guys
<astharot> hi Martin
<Mithrandir> thom: I'm responsible for about 1/6th of that. :P
<pitti> Hi fabbione, howdy?
<lamont> thom: yeah
<Mithrandir> thom: or, is that in total?
<Mithrandir> or just the seed in the DC.
<thom> Mithrandir: that's total
<astharot> pitti: today is THE day! I imagine that mirros are exploding! :P
<fabbione> pitti: just arrived at launchpad
<Mithrandir> thom: *chuckle*; then I've pushed 1/6th of it.
<mpt> astharot: That's seven years bad luck, you know
<mpt> astharot: ... each
<thom> Mithrandir: (torrent.ubuntu.com:6969)
<pitti> fabbione: erm, where's that geographically? :-)
<elmo> maswan: it didn't take the fixed you did to the other 3 swo releases.u.c worked
<thom> Mithrandir: about the same for amnesiac
<thom> pitti: south ken, aka mark's flat
<mdz> aka the lunchpad
<pitti> ah
<Mithrandir> thom: it seems a bit slow, I'm only pushing 1.3+2.9MB/sec here now.
<fabbione> pitti: sabdfl's home
<pitti> fabbione: cool
<lamont> thom: if 359 are complete, how can that possibly be 35GB, since that would make the iso about 100MB?
<maswan> elmo: Gaaah. Fixed now. All it lacked was an apachectl graceful.
<fabbione> elmo: did you get my sms?
<thom> lamont: meh?
<lamont> thom: ah - complete isn't how many have gotten it, it's how many have it.
<lamont> nm
<thom> yes
<mdz> ok, I'm going to crash.  good night all, congratulations and thanks
<thom> night mdz
<maswan> 'night mdz 
<Mithrandir> mdz: rock on
<jdub> night mdz
<fabbione> mdz: good night
<mjg59> elmo: Uh, gluck is down again (just in case you hadn't noticed)
<mvo> night mdz
<Kamion> maswan: serveralias> cool, thanks
* lamont sleeps.
<Treenaks> night lamont 
<fabbione> night lamont
<Kaloz> Kamion: okay, enabled the overrides, too
* Amaranth cries
<Amaranth> i'm going to miss 100MB/day upgrades
<Kaloz> hehe
<Amaranth> and i didn't even have anything to update from 24 hours ago to now
<Amaranth> this is a new low :/
<mpt> I paid NZ$35 for today's upgrades!
<mpt> I'm not going to miss them
<Amaranth> o_O
<Amaranth> Sucks to pay out the ass per byte.
<Mithrandir> Amaranth: you could just switch to breezy. :P
<mpt> Sorry, $37.50
<rubenv> Amaranth: yeah it feels so ... stable
<Amaranth> Mithrandir: It isn't setup yet, is it?
<rubenv> it's frightening :-)
<Mithrandir> Amaranth: it's set up, but uploads aren't accepted yet.  Give us developers the weekend to rest at least. :)
<Amaranth> well, as long as i can change to it now i'll be ok :)
<rubenv> Mithrandir: take a week off :-)
<Simira> :-)
<Mithrandir> hi Simira 
<Amaranth> No week off, must upload! *cracks whip*
<Simira> the weekend off, eh, Mithrandir? With me, then?
<jsgotangco> lol
<thom> Simira: mithrandir needs to get multiarch working by the time breezy opens
<Mithrandir> thom: are you sure you want me to do that?
* rubenv put async network on boot in the request jar
<rubenv> & attaches a beer to it
<Simira> thom: obviously not this weekend. He's mine ;)
* Mithrandir threatens to upload new glibc, binutils, gcc* and dpkg.
<thom> Mithrandir: it'll be fun!
<Mithrandir> thom: of course it will.  And it'll flood GB 'cause elmo will be crying so hard.
<thom> heh
<thom> do it quick while he's AFK!
* rubenv votes for major breakage, everything feels so smooth lately :-)
<Mithrandir> I think he would actually bring one of the Xserves to UDU and bat me to death with it.
<thom> it's entirely possible
<Mithrandir> (like he threatened when I suggested he should try random stuff from the obsd install manual)
<Kamion> Kaloz: cool, thanks, looks good
<jdub> Mithrandir: and once you're a bloody pool of gibs on the floor, can i have the big ipod? :-)
<Amaranth> grr, the ipod's mine! :)
<Mithrandir> jdub: it'll be bloody. :P
<Simira> jdub: hey, stay OFF!
<fabbione> hey Mith, Simira
<Mithrandir> hiya fabio
<pitti> fabbione: how's hacking@launchpad?
<fabbione> pitti: slow :)
<pitti> uh?
<Mithrandir> pitti: s/launch/lunch/
<fabbione> i miss my build cluster :)
<pitti> fabbione: ssh?
<pitti> ;-)
<fabbione> pitti: well i did shutdown stuff at home before coming here
<fabbione> it reduces the risks of my wife touching something
<pitti> hehe
<Simira> hi fabbione
<pitti> fabbione: she might pull out the plug when plugging in the vacuum cleaner *grin*
<fabbione> pitti: exactly
<pitti> fabbione: so where's the new kernel crack? 
<fabbione> pitti: working on it already
<pitti> really? I was just kidding
<fabbione> we have the orig and start cleaning the patches around
<fabbione> i am not :)
<fabbione> pitti: from now on. just focus for stuff that will not 2.6.12
<fabbione> we will skip .11
<pitti> yeah, makes sense
<jdub> fabbione: got inotify 0.22?
<fabbione> jdub: gimme a break
<pitti> given that we will probably have .13 at the time when breezy is released
<jdub> fabbione: ;)
<Lathiat> hehe
<pitti> jdub: got gamin 1.0?
<Lathiat> jdub: any idea if its better?
<Lathiat> 0.19 made my kernel cry
<jdub> Lathiat: significantly so
<fabbione> jdub: external drivers will be the last thing we will read
<fabbione> s/read/re-add/
<jdub> fabbione: ok, cool
<pitti> fabbione: btw, is the ppc sleep crack upstream now? this was a pretty intrusive one, wasn't it?
<jdub> pitti: gamin 1.0 doesn't exist
<pitti> jdub: write it :-)
<fabbione> pitti: no idea really.. you should ask to the ppc porter or acpi subsystem maintainer
<fabbione> gamin needs to be rewritten anyway
<jdub> pitti: definitely not my department ;)
<fabbione> what's the point of a 1.0 :)
<jdub> fabbione: oddly, rml wrote a new demo using giochannel, which could help with the gamin core
<pitti> gamin (1.0-1) breezy ; urgency=low
<pitti>   * unfuck everything
<sabdfl> elmo: looks horribly like a flattening at 480 mbit/s on our stats
<jdub> fabbione: (i think DV got caught up in using dnotify and fam abi compat)
* maswan ponders
<maswan> I have another machine that I'd like to do some performance testing on, the new cdimage.debian.org.. ;)
<maswan> Oh, well. Off to the uni, then ponder such evils.
<d3vic3> daniels: xorg is using 40% of my CPU and 12% of 512 MB memory, is this ok ?
<elmo> sabdfl: maswan's taking a big chunk of our load
<mjg59> pitti: Yeah, it's upstream
<Mithrandir> d3vic3: you can't see how much memory X uses easily, it maps the memory of your graphics card.
<jdub> weird, clicking on the screenshots prompts me to download them
<pitti> mjg59: cool, thanks
<d3vic3> hmmm
<sabdfl> elmo: mdz sent me their stats - that's awesome, but i'm worried that we seem to be hitting an infrastructure bottleneck
<elmo> sabdfl: I don't think we are - I know snares can do more, and the mirror boxes internally aren't even breaking  a sweat
<sabdfl> ok
<d3vic3> Mithrandir:  62.4% 11.9%   5:24.65 Xorg
<jdub> and the OOo screenshot doesn't have the gtk+ integration
<mjg59> elmo: You going to be in London tonight?
<doko> pitti: breezy already working? the toolchain update wasn't accepted yet ;)
<d3vic3> Mithrandir, CPU usage is going up ^
<elmo> mjI'm in london now
<elmo> mjg59 too
<pitti> doko: no idea
<mjg59> elmo: Rock
<elmo> I'm stuck in a never ending round of sales calls, it's making me want to jump out of the window
<Clint> you should have never become a telemarketer then
<mjg59> elmo: You've seen gluck is dead?
<mjg59> MAKE THE UNIVERSE WORK
<Lathiat> mjg59: woops
<Lathiat> mjg59: howd that happen :\
<elmo> mjg59: err, more dead?
<mjg59> elmo: Not pinging
<mjg59> Debian infrastructure obviously thinks an Ubuntu release is close enough to the real thing
<elmo> oh dear christ
<sabdfl> oh the conspiracy theorists will love that
<jsgotangco> a lot of people are asking why kubuntu is announced first in distrowatch while ubuntu is not even mentioned *grin*
<gsuveg> re
<gsuveg> squid compiled with #       --enable-delay-pools option ?
<sabdfl> jsgotangco: that's a real Riddell
<sabdfl> ;-)
<jsgotangco> hahaha
<dredg> oh dear
<Burgundavia> ouch
<Burgundavia> my eyes are bleeding
<sladen> your haggai'ng a laugh aren't you
<Treenaks> Burgundavia: your /eyes/?
<ska-fan> The CDs contain only the english language packs, right? Are you planning on doing CDs for other languages, too? So you'd have iso-en, iso-de, iso-ru and so on
<pitti> ska-fan: we have quite many packs on the CDs
<pitti> ska-fan: the world's most popular at least, and at least i386 and amd64 have all packs
<ska-fan> Hmm, and why the question whether I wanted to download language packs at installation?
<pitti> ska-fan: not packs, "support"
<pitti> ska-fan: support means dictionaries, OO.o and firefox locale packages, etc.
<pitti> ska-fan: desktop translations are available nevertheless
<pitti> Hi sivang 
<sivang> hey pitti 
<sivang> pitti: whassup?
<pitti> sivang: hoary's out :-)
<pitti> sivang: I'm currently at pmount bugfixing
<sivang> pitti: yay! I will now dist-upgrade
<pitti> will deal with new hal later
<sivang> pitti: still giving hot plugging trouble?
<ska-fan> Hmm, indeed. All language packs are on the cd. Why that question at installation time?
<pitti> sivang: not really, but hal 0.5 has some cool new features
<pitti> sivang: like, separating out hardware detection processes
<pitti> sivang: so even if the usb process dies, it won't hang the main hald process (#1891)
<pitti> sivang: and also beginning support for encrypted devices
<thom> pitti: needs dbus 0.3, right? (and i really want hal 0.5 for gnome-power love)
<Kamion> ska-fan: language-support-* != language-pack-*
<pitti> thom: yeah, -power is interesting, too
<Kamion> ska-fan: language-support-* is a big download, so it asks
<pitti> thom: and we need newer dbus, right
<thom> cool, we can tagteam daniels
<ska-fan> Kamion: And what does language-support contain as opposed to language-pack?
<pitti> ska-fan: <pitti> ska-fan: support means dictionaries, OO.o and firefox locale packages, etc.
<thom> since i need new dbus for network-manager :-)
<ska-fan> Ah.
<ska-fan> Now I get it :)
<pitti> ska-fan: the terminology may be a bit unclear
<sivang> pitti: cool!
<pitti> sivang: finally we can throw new upstream versions in again to break everything :-)
<sabdfl> hno73: we've lost the "mirror" page from the new site!
<sivang> hmm nothing to update..gues I Have the released hoary :-)
<sabdfl> can we get it back please?
<sabdfl> should I do that?
<sivang> pitti: yeah!
<sabdfl> or is there a plan in place
<sivang> pitti: I might through some dbusification hacks upstream with carlos for g-s-t ;-)
<pitti> sivang: you mean his privilege separation hacks?
<tseng> can we please get rid of that circle-of-lame
<tseng> :(
<sivang> tseng: circle of lame?
<Kamion> I rather like the new circle image
* Pizbit likes the new image too.
<sabdfl> tseng: you want the nekid people back?
<sivang> pitti: http://live.gnome.org/SystemToolsBackends
<tseng> sabdfl: nah, i am one of those that just doesnt like people in art at all, generally
<Kamion> it seems closer to the original stated intent of the Human thing, somehow
<sivang> sabdfl: put the nekid people back ! put them back! :-)
<Treenaks> Kamion: the logo doesn't match anymore, though 8)
<fabbione> sabdfl: is there a local ubuntu mirror here?
<sivang> sabdfl: Hello btw :-)
<Pizbit> Kamion: Because there's more, it's a brighter image and they're all smiling heaps?:)
<Mithrandir> nubuntu.  All nekkid people.
<Treenaks> Mithrandir: sounds too much like n00buntu
<Mithrandir> nudbuntu, then
<jsgotangco> i still have my nekkid people *grin*
<Kamion> Pizbit: it's more natural as well, less "here are some models"
<Pizbit> Kamion: Yep, not so obviously staged.
<broonie> I preferred the one that appeared oon planet :)
<jsgotangco> well let's keep the april fools gdm then!
<tseng> yes please
<pitti> yes, this was really nice
<maswan> yes, please keep the april fools gdm
<jdub> i'll put it up for download
<Mithrandir> pull the april's fools from the morgue?
* Pizbit hasn't seen the april fools gdm.
<tseng> april fools helped me realize why he goes by elmo 
<jsgotangco> maybe at UDU when can make an uber circle of friends *grin*
<broonie> Pizbit: http://www.livejournal.com/users/lifeguardasleep/22249.html
<Pizbit> cheers
<maswan> jsgotangco: Just create many circles, so you can rotate between different ones. :)
* Pizbit tries to decide which of the three scares him the most.
<Treenaks> btw, was that picture taken in that "Drunken Chicken" (or whatever it was called) place?
<jdub> http://people.ubuntu.com/~jdub/hoary/AprilFools2005.tar.bz2
<dredg> Pizbit: clearly the lhh in the bottom right :)
<jdub> plop that into /usr/share/gdm/themes
<jsgotangco> haha
<jsgotangco> no thanks!
<jsgotangco> *grin*
<Pizbit> dredg: I was thinking of the guy at the top middle:)
<dredg> Pizbit: they're all on channel btw. be nice :)
<jsgotangco> *grin*
<Treenaks> jdub: you should know that, as you discovered  that place :)
<jsgotangco> hehe
<dredg> Pizbit: so that guy down the bottom right. man what a hippy ;)
<Pizbit> dredg: It's all in the expression:)
<jdub> and if anyone disses the green shoe...!
<dredg> jdub: that's some dodgy looking shoe
<jsgotangco> nice shoes
<Pizbit> dredg: Hehe, also the guy with the reddish hair looks like a friend of mine:)
<dholbach> hey! how are the celebrations going?
<jsgotangco> the wine is almost done
<dholbach> :-)
<Pizbit> jsgotangco: Sounds like someone didn't order enough?:)
<jsgotangco> ask sabdfl for mre
<jsgotangco> more
<jsgotangco> *hic*
<tseng> hi dholbach 
<dholbach> hey tseng :-)
<jsgotangco> a few hours ago this place was smoking hehe
<jsgotangco> Post Hoary Thoughts: Kubuntu was a milestone, Really rad laptop support is just awesome, gnome 2.10
<jsgotangco> hmm
<jsgotangco> what else
<jsgotangco> docteam of course *grin*
<jsgotangco> very nice artwork
<dholbach> smoking?
<dholbach> did anything go wrong?
<jsgotangco> no no
<Kamion> the slightly-less-craptop hibernates and comes back to life successfully
<jsgotangco> everything was fine
<Kamion> mjg59: ^- impressive
<jsgotangco> right
<jsgotangco> hibernate works
<sabdfl> docteam, kubuntu, casper
<sabdfl> big steps during the hoary cycle
<dholbach> hey sabdfl :-)
<jsgotangco> sabdfl: docteam needs more solid process though
<sabdfl> agreed
<sabdfl> but we have the beginnings of a strong non-developer team
<jsgotangco> yeah
<Kamion> big steps> MOTU
<Kamion> previously discussed but unrealised :)
<dholbach> MOTU power! WOOHOO! :-)
<sabdfl> hallo-motu!
<jsgotangco> haha
<dholbach> ;-)
<dholbach> after some coffee, i'll do my final task... mailing the apt-get.org - guys
<dredg> heh, MOTU might as well be dholbach. he's like some sort of relentless machine
<dholbach> dredg: i'm blushing :-)
<d3vic3> true true 
<jdub> dholbach is definitely he-man :-)
<mjg59> Kamion: Rock
<jsgotangco> who's his orco
<dholbach> hahahaha :-)
<dredg> dholbach: you singlehandedly killed my mailbox with wiki notification changes to UPL 
<mjg59> Though we should really say thanks to Suse - they've done a lot of swsusp work
<Kamion> mjg59: (I mean, it takes about five minutes to actually manage to hibernate. BUT STILL.)
<jsgotangco> bravo still
* Lathiat finds swsusp2 *much* better
<Lathiat> hwoever, i just suspend to ram all the time *shrug*
<dholbach> dredg: sorry about that
<dredg> dholbach: i fear you.
<dholbach> jdub: big steps -> MovieOS :-)
<jsgotangco> how good is our suspend compared to others?
* jsgotangco never got to use other distros
<mjg59> jsgotangco: Our suspend to RAM is massively better than anyone else's
<Lathiat> interesting.. with hoary release, if you have a usb drive plugged in during install, it shows up in drivemount cus its in /etc/fstab, but its mounted by gnome-volume-manager on a different mount path so its not used
<mjg59> It doesn't work everywhere, though
<Lathiat> yeh suspend-to-ram rocks
<dredg> dholbach: that wasn't a complaint. 
<Lathiat> its almost as good as bernards hibernate script now
<dholbach> :-)
<Lathiat> (it was a little slow before)
<jsgotangco> hmm i usually suspend to disk
<mjg59> Lathiat: At the moment, it's rather more resiliant than Bernard's stuff
<Lathiat> mjg59:  how so?
<mjg59> I must get round to integrating stuff from the two of them
<Lathiat> mjg59: (I've never had a problem, so i have no idea)
<mjg59> Lathiat: It takes much more care about dealing with network interfaces and unloading modules
<Lathiat> one thing with my nvidia i need to turn off all the random options like POSTing the video hardware
<mjg59> The paranoia costs it some speed, but makes it work in more places
<Lathiat> else my lcd blows up
<mjg59> Is that with the nv driver or the nvidia one?
<Lathiat> both
<Lathiat> it might have changed
<Lathiat> i might try it now
<Lathiat> (i usually use the binary driver)
<Lathiat> im on nv as i just reinstalled
<mjg59> There's no good way of making this work everywhere, sadly
<Lathiat> if the nv driver didn't have these stupid colordepth issues i'd use it all the time.
<fabbione> hey mjg59 
<mjg59> Yo fabbione
<mjg59> You in the UK now?
<fabbione> mjg59: yup
<mjg59> Rock
<mjg59> I'll see you this evening
<fabbione> mjg59: getting ready to release .12rc2
<jsgotangco> *yawn*
<jsgotangco> im out
<fabbione> mjg59: sure..
<jsgotangco> congrats guys im outta here
<fabbione> mjg59: bring some good crack :)
<mjg59> fabbione: Haha
<d3vic3> hehehe
<dholbach> hey herzi 
<Lathiat> Can someone point me the discussion as to why gstreamer0.8-mad is in universe and can't/won't be shipped?
<Mithrandir> Lathiat: patent issues.
<Burgundavia> Lathiat: mp3 patent crap
<Lathiat> Mithrandir: why don't they affect whatever kubuntu is using?
<Mithrandir> Lathiat: I don't know; what are they shipping that does MP3?
<Lathiat> kaffeine, juk
<Mithrandir> they probably should be castrated, then
<Burgundavia> lawsuits are all about targets
<herzi> hey
<Lathiat> Mithrandir: ah, so tahts a mistake?
<Burgundavia> if there is no one to sue, then they probably won't be
<Mithrandir> Lathiat: I would think so.
<Lathiat> Mithrandir: rightio
<Mithrandir> Burgundavia: there is this legal entity called "Canonical Limited".
<Burgundavia> yes
<Lathiat> hope i didn't just cus some issue by mentioning that :)
<Burgundavia> that is what I was talking about
<Burgundavia> and a man named Mark Shuttleworth
<Burgundavia> who they say has a little bit of money
<Burgundavia> not much, you know
<Lathiat> go the law
<Mithrandir> Burgundavia: he's not personally responsible for what ubuntu, kubuntu or canonical does.
<seb128> hum
<Mithrandir> that's the "limited" part.
<Burgundavia> no
<seb128> they use libxine
<Burgundavia> but he makes a nice target
<Lathiat> Mithrandir: yeh but they can be for all sorts of fucked reasos like negligence
<Lathiat> at least in australia, so im told
* Lathiat boggles
<seb128> since when xine is main stuff ?
<Mithrandir> Lathiat: we're not an Australian company, so I'm not sure if that applies.  Anyhow, it ought to be fixed.
<Mithrandir> seb128: probably since it's used by kubuntu
<Lathiat> synaptic is refusing to get http://archive.ubuntu.com/ubuntu/pool/main/b/bison/bison_1.875d-1_i386.deb complaining about a "bad header line" but it works in wget.
<Lathiat> Mithrandir: oh i know that, i was just saying here i think it might be
<Lathiat> but maybe thats just incorporated associations
<Lathiat> i've never delt with running a company
<Lathiat> What does apt use to receive files?
<jdub> Lathiat: mmm, i was getting that the other day
<mvo> Lathiat: it's own http implementation
<Lathiat> jdub: i get it *all* the time randomly
<Lathiat> it gets annoying, especially during the install and it starts whinging about unauthenticated packages cus it failed to get release.gpg
<Lathiat> mvo: oh dear god why :)
<dholbach> Lathiat: because it needs to work with nearly no packages installed
<Lathiat> dholbach: point.
<mvo> Lathiat: try: "apt-get install $pkg -o Debug::Acquire::http=true"
<seb128> jdub: any reason to no put totem-xine for main since kubuntu use xine already ?
<jdub> seb128: possibly, i think we need to clean it more - i wasn't aware of the change until very late
<Lathiat> mvo: it works now :\
<Lathiat> and without debug on now
<Lathiat> heh
<mvo> Lathiat: just use it again when when it comes up next time :)
<Lathiat> mvo: :)
<Lathiat> it was doign somethign stupid before like
<Lathiat> it started to i think print the binary contents of th efile
<Lathiat> (in debug mode)
<Lathiat> after i removed the partial file it stopped doing that
<Lathiat> but the partial file wasn't there until it started doing that
<Lathiat> weird
<spacey> my upgrade to hoary broke at apache2 php4 module. because /usr/share/doc/php4-common/examples/php.ini didn't exists. I don't know if its because i removed it a while ago or other reason. dunno if its because my specific situation.
<mvo> Lathiat: are you behind a proxy?
<Lathiat> mvo: nope
<dholbach> elmo: good work on the import!
<Lathiat> Be nice when the new nvidia drivers go in
<Lathiat> as it fixes suspend issues on my laptop
<Lathiat> so hopefully others
<Mithrandir> hmm, I think nautilus should ignore mounts with a type of "proc" when it decides what to put on the desktop
<Lathiat> hmm
<Lathiat> the installer created a /media/usb0 of my external drive
<Lathiat> but its from /dev/sda
<Lathiat> not /dev/sda1
<Lathiat> that probably explains why it got automounted by g-v-m instead of that :)
<maswan> 500 requests currently being processed, 0 idle workers
<maswan> oops.
* maswan ups max servers in apache :)
<dholbach> amu: would you update the freshmeat page?
<diamond> 'Europe' link on front page of ubuntu.com is a 404
<maswan> oh. fsck.
<maswan> diamond: thanks, I'll fix it.
<diamond> maswan: np
<maswan> Kamion: reverting back the se.releases ServerAlias for now
<mvirkkil> The screenshot
<dilinger> daniels: ping
<mvirkkil> The screenshots at http://www.ubuntulinux.org/screenshots/document_view are served in some way that makes firefox download them and ask if you want to save or open with a program. It doesn't show them in the browser.
<dholbach> bbl
<ska-fan> They're served as text/plain
<Pizbit> Oops:)
<maswan> diamond: fixed
<diamond> maswan: cheers
<diamond> maswan: i've poked heanet.ie to update their mirror btw.
<dredg> diamond: esat's mirror of archive is current as well
<dredg> diamond: mainly cos i switched zefren to the one true way :)
<diamond> dredg: aye, but no mirror of relesases tho -(
<diamond> dredg: that said, i guess jigdo could manage with that, right?
<mdke> who knows about shipit?
<pitti> mdke: mako
<dredg> diamond: yeah, you could jigdo an iso using ftp.esat
<mdke> pitti, heh yeah, but he's not here
<dholbach> hey pitti 
<pitti> Hi dholbach 
<ogra> morning
<pitti> Hallo ogra
<dholbach> hey ogra 
<ogra> :-)
<mdke> don't think it can be qualified as morning now
<mdke> i guess it was a late night huh
<dholbach> mdke: :-)
<mdke> you have been to bed right?
<dholbach> mdke: yes... shortly after 4 utc :-)
<mdke> oh
<jdub> mdke: sleep is for the week
<dholbach> mdke: you?
<mdke> so usual bedtime
<mdke> dholbach, i'm fine thanks :) had an exam this morning so didn't sleep much either
<mdke> jdub, hi :)
<dholbach> jdub: i didnt see you around all the time i was here - i guess YOU were sleeping :-)
<jdub> dholbach: oi, i greeted you when you arrived :)
<diamond> jdub: rather than 'weak'? i like it -)
<dholbach> :-)
<dholbach> mdke: how did it go?
<ogra> so what are the improvements in breezy, where can i download it ? where are the berrzy backports ?
<ogra> :)
<dholbach> :-)))
<botbot> breezy devel isn't started yet, is it?
<jdub> ogra: ha ha ha :)
<mdke> lol @ ogra 
<Burgundavia> lol
<mdke> dholbach, not too bad thanks
<dholbach> goooood
<mdke> i don't see a german party on http://www.ubuntulinux.org/wiki/ReleaseParty
<mdke> whats going on?
<diamond> mdke: lunch? -)
<Burgundavia> http://www.osnews.com/story.php?news_id=10236
<ogra> pitti, http://www.heise.de/newsticker/meldung/58365 I CANT BELIVE IT ! they finally found us worth to recognize us :)
<pitti> YAY
<Burgundavia> bring on the trolls
<dholbach> ogra: but they're rather neutral
<jdub> aha, USA is waking up :)
<ogra> dholbach, they ignored EVERY post in the past
<Burgundavia> quick translation, what does Heise say?
<Burgundavia> anything useful?
<mdke> do these things not get put on slashdot?
<jdub> mdke: it'll turn up
<ogra> Burgundavia, they say we have released....
<pitti> ogra: reading comments now :-)
<jdub> slashdot space out their stories, and most of them are US-based
<mdke> hmm
<Burgundavia> ogra: ok
<ogra> Burgundavia, nothing exciting...
<Burgundavia> ogra: thanks
<Treenaks> jdub: but it's DEBIAN-BASED.. and MARK SHUTTLEWORTH is backing it
<dholbach> Burgundavia: they say "canonical hired some open-source superstarts." ;-)
<thom> mark gets the obligatory second space tourist mention in heisse i see
<dholbach> superstars :-)
<mdke> when??
* mdke runs away
<pitti> ogra: http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=7765987&forum_id=76739
<pitti> :-)
<Mithrandir> dholbach: actually, it says "visible free software developers" (prominent), not superstars. :)
<ogra> pitti, Riddel was looking for nice qoutes about kubuntu ;)
<dholbach> Mithrandir: you must have misread ;-)
<Mithrandir> dholbach: ;)
<ogra> Mithrandir, nah, that cant be....there are no promintent devs that are no superstars
<dholbach> ping all: for me you're all superstars!
<jdub> heh :)
<jdub> says he-man holbach :-)
<mdke> you too dholbach 
<dholbach> :-))))
<mdke> its getting a bit mushy in here now
<dholbach> now what project could we do as "Ubuntu Allstars"?
<jbailey> dholbach: Sober up in time for Monday so we can start the next round? ;)
<mdke> oh btw dholbach do you know who deals with seahorse?
<dholbach> release a hit-single as well? have a basketball/rugby/volleyball/frozen-bubble dreamteam?
<mvirkkil> How about a basketball game in udu. The "Ubuntu Allstars" vs general public
<dholbach> jbailey: I am sober! what about you? :-)
<pitti> yay, the guys out there _REALLY_ like live CDs for ppc :-)
<jdub> rawk :)
<jbailey> dholbach: *hic*
<dholbach> ;-)
<dholbach> mdke: sorry, don't know
<botbot> neither the norwegian nor the one in the netherlands is updated
<dholbach> 69 packages from apt-get.org made it in
<jdub> ahem
<jdub> "score"
<dholbach> it's the best i could do
<dholbach> and elmo of course
<jdub> heh
<pitti> dholbach: congrats! that's really good
<jdub> archive.ubuntu.com has entered bullet-time
<pitti> dholbach: better 69 selected and checked packages than a mere dump which consists of utter crack
<pitti> *way* better
<ogra> yeah
<jdub> dholbach: lots of *sane* apt-get.org imports == wunderbar!
<ska-fan> How many ubuntu devs are there?
* dholbach selects 69 ... hrmm...
* dholbach pipes innocently
<mdke> lol
<trygvebw> question: why was the name of 5.10 changed from Grumpy Groadhog to Breezy Badger?
<pitti> ska-fan: ~10 full time
<pitti> ska-fan: but a lot more from the community
<jdub> trygvebw: grumpy's reserved for another crazy project :)
<trygvebw> jdub: O_o ... Which one? :P
<trygvebw> *which project
<Simira> and what about the hogs?
<alp> righto. see you all at the london release party
<jdub> trygvebw: something totally different, coming soonish
<trygvebw> jdub: OK :)
<Lathiat> hmm bugger
<trygvebw> jdub: Is it Ubuntu related?
<Mithrandir> Simira: there are no bugs.
<Lathiat> ubuntu calendar didn't put itself in my background list
<jdub> trygvebw: of course! :)
<Mithrandir> oh, the hogs.
<jdub> Lathiat: wait for april, coming soon :)
<Simira> Mithrandir: not bugs. hogs
<dholbach> :-)
<mdke> hmm
<ogra> Mithrandir, yup, they eat bugs ;)
<Mithrandir> ogra: guess so. :)
<Lathiat> jdub: yeh but the annoyance is the current one decided not to put itself in the background list :)
<trygvebw> jdub: OK :)
<mdke> my wiki subscription folder in evolution stops at wed 18.45
<jdub> Lathiat: mmm, had to break old ones to fix an ugly warty bug
<Lathiat> jdub: ahh, bugger
<Lathiat> jdub: is the new calendar going to have the more orangy background?
<desrt> Lathiat; word.
<Lathiat> desrt: up?
<desrt> heh
<desrt> you an ubuntuer?
<jdub> Lathiat: they're going to be... quite different :-)
<zul> hey
<Lathiat> desrt: in what sense?
<Lathiat> jdub: ok :)
<desrt> a developer
<trygvebw> maybe ... grumpy = server :P
<Lathiat> desrt: nah
<Lathiat> just a user and general person who hangs around and bugs people when my shit doesn't work :)
<ogra> trygvebw, we already have a server distro
<Lathiat> pondering doing some MOTU
<ogra> Lathiat, yay
<desrt> what's this motu business?  i was reading about its irc channel on some planet last night
<mdke> lol
<Lathiat> desrt: "Masters of the Universe" -- looks after the packages in universe (which are imports from debian + some other stuff thats not in main, such as aptgetorg)
<dholbach> desrt: the MOTUs make the Ubuntu Universe ROCK - join the party! :-)
<ska-fan> wtf doesn't know, what motu is..
<Lathiat> ska-fan: desrt, obviously :)
<ogra> ska-fan, patches accrepted ;)
<ogra> -r
* dholbach points to #ubuntu-motu and http://wiki.ubuntu.com/MOTU
<trygvebw> ogra: Oh?
<Lathiat> well i just reinstalled my laptop on reiserfs, i wonder how long till i regret it...
<desrt> ah
<desrt> does this mean that abiword will finally get updated? :)
<ogra> trygvebw, type "server" at the install prompt of the cd and it installs a server distro for you ;)
<trygvebw> ogra: Thanks, didn't know that :)
<Lathiat> desrt: heh heh, how far behind is it?
<desrt> 2.2.2
<desrt> vs 2.2.7 or so
<Lathiat> rightio
<Lathiat> whats in debian unstable?
<desrt> no idea.
<lupusBE> when is Breezy repository going to set up :)
<Mithrandir> it's already set up
<Lathiat> the release versions need to be randomly +/- 1
<Treenaks> lupusBE: when everyone's sober again
<Mithrandir> but uploads aren't accepted yet.
<Lathiat> otherwise having 4.10, 5.04, 5.10, 6.04, 6.10.. its going to get boring :)
<Treenaks> Lathiat: maybe we'll miss a goal
<Lathiat> Treenaks: don't say that!
<desrt> 4.0/4.1/5.0/5.1 would be neat
<Treenaks> Lathiat: or we might make one early..
<Lathiat> Treenaks: woo woo!
<broonie> Treenaks: That always happens :P
<Treenaks> broonie: gnome did it once
<Treenaks> broonie: ask jdub
<Lathiat> woo just found a feature in firefox tabbed browser prefs - "Load URLs from the clipboard on midle-click"
<Lathiat> sucks so bad cus usually you go to paste it, then you select the address to delete it and then it blats over the URL in the clipboard :)
<Treenaks> Lathiat: oh, I did that in about:config :)
<Lathiat> Treenaks: heh
<Lathiat> so with the mp3 patent issues
<Lathiat> is it an issue with the specific implementation
<Lathiat> or in general?
<Treenaks> Lathiat: general, afaik
<Lathiat> cus i recall something about it being incompatible with the GPL or something
<Lathiat> so like a BSD license would work with one, for example
<Lathiat> but i don't remember, or how authoriative that was
<Kamion> maswan: what was up with se.releases and ServerAlias
<Kamion> ?
<jdub> Lathiat: see section 7 of the gpl
<Lathiat> jdub: so im right?
* Lathiat reads
<maswan> Kamion: If I vhost that with a DocumentRoot like releases, there is no /mirror/ubuntu-releases/ 
<Kamion> maswan: oh, I'll fix the download page then
<Kamion> maswan: can we coordinate now?
<mvo> seb128: mind if I upload a python-vte with the fix in gnomes bts for #169201? (when breezy opens)?
<Lathiat> jdub: ah right
<maswan> Kamion: Sure, we can do that now.
<Lathiat> jdub: im just curiuous if theres some way the situation can be resolved
<Lathiat> jdub: because ultimately, having as much multimedia playing out of the box would be good.
<Lathiat> at least, in my opinion.
<Kamion> maswan: ok, switch over in about one minute?
<jdub> Lathiat: fluendo, among others, are working on it
<jdub> won't be out of the box on ubuntu (can't be)
<Lathiat> jdub: similar to their dvd player project? (any idea where thats going?)
<Lathiat> jdub: and why?
<Lathiat> because we'd have to pay some kind of license?
<seb128> mvo: not at all :) when does breezy open ?
<mvo> seb128: I hope soon :P
<maswan> Kamion: Sure, I'm doing the fixes to the httpd.conf now
<Kamion> maswan: /download/ switched
<maswan> the machines are somewhat slow, but I'll get this around shortly. :)
<ogra> maswan, hwdb.ubuntu.com runs on a dual pII 233 with 128MB and still copes fine with the submissions....how slow are yours ? ;-P
<Mithrandir> ogra: 66MHz power nodes, I think.
<ogra> heh, o, so similar...
<jdub> Lathiat: can't ship libmad due to GPL section 7; can't ship proprietary mp3 implementation.
<maswan> Mithrandir: nope, 4x332MHz ppc 604e
<Mithrandir> maswan: oh, ok.  New and shiny?
<maswan> Mithrandir: fairly. not very good memory bandwidth on them though. :)
<Lathiat> jdub: is it possible for someone to implement a new mp3 library under some other license, such that it would allow shipping?
<dredg> hmm
<dredg> would it be worthwhile doing away with /etc/debian_version and having an /etc/ubuntu_version?
<jdub> Lathiat: you could reimplement, or you could buy libmad and re-release it
<pitti> Lathiat: no
<Mithrandir> maswan: don't you have a nice and shiny amd64 cluster which could work instead? ;)
<pitti> Lathiat: that's a patent issue
<jdub> Lathiat: but we still couldn't ship it!
<ogra> dredg, lsb-release -a
<pitti> Lathiat: the licens of -mad is not the problem, it's GPL(ish)
<ogra> dredg, /etc/lsb_release .... (afaik)
<Lathiat> jdub: What I don't get, is why I can download it out of universe, but I can't get it on a CD, whats the difference?
<maswan> Mithrandir: well, I have a new and shiny cdimage.d.o that we could put to work. :)
<jdub> pitti: the license is a problem (see section 7), but it's not the only problem
<jdub> Lathiat: semantics
<Kamion> maswan: ok, I'm off in a minute; hope you got that switched over, otherwise there are probably others around who can edit that page
<maswan> Kamion: Yes, we have that switched over.
<pitti> jdub: well, yes, but if there were no patent, the GPL would be valid
<jdub> pitti: thus the problem ;)
<dredg> ogra: ah, lsb_release -a :) winner, cheers
<Kamion> The requested URL /5.04/ was not found on this server.
<Kamion> maswan: ^
<maswan> yes, I'm lacking a few nodes still, it seems.
<Kamion> oh, hm, works now
<maswan> it just takes a minute or two to login and to apachectl graceful
<ogra> dredg, its also in the deviace manager in the advanced tab of the computer device.....try:  lshal|grep release
<pitti> ogra: ah, your toy project :-)
<ogra> hehe
<ogra> bah, there is still a third not up to date from the hwdb submitters
<dredg> ogra: ah, useful
<dredg> thanks again
<maswan> there, verified that all frontends work.
<dholbach> hey tritium 
<tritium> hi dholbach :)
* dholbach grabs tritium by the hands and does the Release dance
* tritium is a bit tired from staying up until the release :)
<dholbach> tritium: don't ask me ;-)
<tritium> dholbach, you've worked so hard in the past few days, you must be exhausted
<maswan> http://www.acc.umu.se/technical/statistics/loadstats/ftp.html <- doing good. :)
<dholbach> tritium: i'll just write the mails to the maintainers and be finished for hoary :-)
<Lathiat> maswan: damn :)
<Lathiat> maswan: is that in mbits or what?
<maswan> Lathiat: that's load
<maswan> http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
<maswan> that is the bandwidth graph
<Lathiat> maswan: load as in machine load?
<maswan> Lathiat: yes
<calc> looks like loadx10
<Lathiat> haha
<Lathiat> nasty
<tritium> dholbach, and then the weather will be getting breezy in your neck of the woods?
<Lathiat> and bugger me thats alot of traffic :)
<dholbach> tritium: then i'll take a nap :-)
<calc> well at least for tutankhamon
<tritium> dholbach, I think I'll do the same
<maswan>   03:33PM   up 28 days,   1:46,  3 users,  load average: 36.48, 38.85, 37.31
<Lathiat> i made a local mirror for a few people and am doing 1.5mbit/s or so
<Lathiat> thats about as big as it gets :)
<maswan> calc: that one had a peak up at 150 or so, but that went down again. :)
<trygvebw> Is it possible to download the official Hoary CD-label from somewhere?
<calc> are the dvd images not going to be put up?
<trygvebw> calc: What do you need dvd images for? Ubuntu Hoary fits on one CD.
<maswan> calc: a co-admin noted this nice number: load average: 148.55, 98.12, 59.04
<Mithrandir> calc: use torrent for them.
<Lathiat> trygvebw: the dvd images have alot more packages
<calc> trygvebw: the dvd version is supposed to have all of main on it
<calc> Mithrandir: well wrt torrent where is it? ;)
<Mithrandir> calc: torrent.u.c
<Kamion> calc: I haven't published it quite yet, forgot this morning
<trygvebw> ok :)
<Lathiat> Kamion: i noticed :)
<Lathiat> i was trying to suck a copy down
<Mithrandir> at least, I think so.
* Pizbit idly wonders why hoary though he needed 1.5GB of swap.
<Kamion> it has all of base/desktop/ship/supported; that used to be all of main, but that changed when Kubuntu appeared
<Pizbit> thought too.
<Lathiat> Pizbit: it seems to 3*ram
<Lathiat> did that for me too
<Lathiat> i went back and made it 1GB
<Lathiat> i used to have it at 512 which was enough but sometimes its handy with vmware and whatnot
<Pizbit> Lathiat: Just a tad excessive methinks, didn't notice until after everything has installed, *shrug* I'll leave it be
<Lathiat> between builds and vmware i often give my machine a good run for its money :)
* Pizbit grins.
<Lathiat> its gonna suck when vmware5 goes out of beta, will actually have to buy a license :)
<Lathiat> i wonder how much student pricing is
<Kamion> I'm publishing the DVDs now, will take a little bit
<Lathiat> hopefully <100usd
<Kamion> and will be torrent-only for now, as Mithrandir said
<Lathiat> if its more than that they can stick it.
<trygvebw> <trygvebw> Is it possible to download the official Hoary CD-label from somewhere?
<calc> is 20050407.3 the official release?
<Kamion> yes
<calc> ok
<Kamion> oh, er, yeah. you could grab that. :)
<Kamion> forgot about those builds, which is odd considering I'm publishing from them
<ogra> Pizbit, you have 512 MB mem ?
<Kamion> but would appreciate if the URL wasn't published too widely
<Mithrandir> Kamion: chmod o-r the dvd images?
<Pizbit> ogra: Yep
<Mithrandir> Kamion: or just .htaccess-disallow them
<Kamion> Mithrandir: if I do the first the rsync mirror processes won't be able to read them
<ogra> Pizbit, hibernate needs 3x mem to write your session to the swap space....so your swap is adjusted for that
<Kamion> Mithrandir: if I do the second, well, I could, but what's the point
<Kamion> it just creates confusion
<Treenaks> ogra: 3x mem??
<Mithrandir> Kamion: they won't show up in the listing if the user can't access them
<Pizbit> ogra: Ahh.. Doh, I never use hibernate:)
<ogra> Treenaks, the safety net....
<Kamion> Mithrandir: might as well just not publish them for now
<Kamion> surely?
<Mithrandir> Kamion: I thought you had to publish them to make sure they didn't disappear?
<ogra> Treenaks, it works here with 1,5x mem....but has proven not to do so on many machines
<Kamion> I only have to "publish" them
<Treenaks> ogra: scary
<Kamion> putting them in the torrent.ubuntu.com tree will do perfectly well
* Pizbit isn't sure how to use this hibernate business anyway
<Treenaks> Pizbit: just close the lid
<Kamion> and I don't want our mirrors trying to download new DVD images at the moment
<ogra> Treenaks, yop....but more scary are the systems out there that had not enough swap.....
<Pizbit> Treenaks: Hrm, I'd rather not be lifting up my 17" CRT and facing it down every night eh?:)
<Mithrandir> Kamion: you're going to get requests from users who will complain that they can't download, 'cause their client isn't LFS-ok.
* Mithrandir tries to save Kamion from extra work. :P
<Treenaks> Pizbit: 8)
<wasabi> yay for ubuntu
<Kamion> Mithrandir: unlucky; I'm acting under instructions. :-)
<wasabi> woh is somebody talking about hibernate?
<Mithrandir> Kamion: :)
<Pizbit> wasabi: Yep
<ogra> wasabi, mjg59 (if he is around)
<ogra> ;)
* Treenaks whines some more about smart batteries
<azeem_> congrats, dudes
<ogra> Treenaks, http://hwdb.ubuntu.com/nullswap.html
<ogra> Treenaks, 10%
<Treenaks> nullswap or zeroswap? :)
<wasabi> oh wow.
<wasabi> as much as it pains me, kubuntu is slick
<ogra> Treenaks, no swap mounted
<Treenaks> scary
<Lathiat> wasabi: yeh its not bad
<wasabi> i love the ubuntu artwork.
<Lathiat> wasabi: its still messier
<wasabi> the logo with gears, and the blue.
<ogra> Treenaks, yep...systems without 3x RAM = swap
* Mithrandir wonders why he's not pushing more than he is.
<Mithrandir> only 5MB/sec over two boxes.
* rcaskey waits for his uni mirror to update in the next few days
<ericf> both my girlfriend's system and mine have [netstat]  <defunct> zombie process running. Are we the only ones? Can people here please check?
<zul> whoo...release announcement on slashdot
<Mithrandir> ericf: it's firefox or something which uses it for collecting entropy
<Mithrandir> (most likely)
<ericf> Mithrandir: I quit firefox, nothing in 'ps aux' for it anymore. Still the zombie process, however. I'm sorry, but i don't know what collecting entropy is. But should I report this as a bug?
<Lathiat> ericf: defunct processes happen, if its messing something up just reboot
<Lathiat> its usually not an issue and they can just be left alone
<Mithrandir> ericf: what does ps axf show as its parent?
<Mithrandir> (in a terminal)
<ericf> Ah, it's thunderbird. THat is useful man!
<ericf> problem solved... for now. But this is still a bug, right? should I report it?
<Mithrandir> I think it's already reported.
<kent> Slashdot should have put a note about using bittorrent and not downloading the iso as is :(
<ericf> ok, thanks
<ericf> kent: that's right.
<jbailey> I suspec thtat anyone who knows what to do with a torrent will go looking for it, so it probably won't be all bad.
<Lathiat> oh oh the gnome apt frontend is looking slick
<mako> jbailey: i suspect it might be kinda bad
<Lathiat> as in the debconf stuff
<jbailey> mako: Really?  I would've expected people who know about torrent to go looking for it, and people who want ISOs would've found them anyway.
<jbailey> mako: I guess there's a higher risk of random clicks from people who didn't really want to download it anyway.
<mako> jbailey: this is /. :)
<mako> all types
<maswan> Mithrandir: 5MB/s? bittorrent?
<Mithrandir> maswan: yeah.
<mako> ooh, good comment: http://linux.slashdot.org/comments.pl?sid=145437&cid=12175437
<maswan> Mithrandir: do you have enough ram for full cache?
<mako> " I've been using Ubuntu for a couple of years now..."
<Pizbit> lol
<Mithrandir> maswan: no :(
<Lathiat> mako: haha
<mako> damn, he beat me
<Mithrandir> maswan: 2GB ram, though, so it's not too bad.
<zyga> woah
<zyga> ./ links to isos
<zyga> they are crazy again...
<Pizbit> Yep
<Lathiat> perhaps some person here should post the article
<Lathiat> or at least post one
<Lathiat> with BT links, next time.
<zyga> fortunatly someone has posted a link to .torrents too
<mako> well, it's not too late to change those links to torrents
<maswan> Mithrandir: Well, unless you have insanely fast scsi disks, it might be disk latency that you hit then.
<zyga> (you could rename .iso's to .no-slashdot-effect.iso)
<Pizbit> hehehe
<Treenaks> zyga: add a rewrite rule :)
<Mithrandir> maswan: I could split the torrents across the two boxes I'm using; two ISOs should fit in RAM easily enough.  (Dropping the two slowest ones.)
<Treenaks> RewriteCond %{HTTP_REFERER} ^http://(www\.)?slashdot.org
<zyga> Treenaks: /me has no access there ;] 
<Mithrandir> mod_rewrite is wrong.
<Treenaks> Mithrandir: mod_rewrite is coolness inc.
<zyga> Mithrandir: 90% will get i386
<zyga> most will take live cd probably
<Mithrandir> zyga: no
<zyga> Mithrandir: really?
<calc> i noticed the arch usage split on the hwdb site
<calc> i386 - 89.1%  amd64 - 8.7%  ppc - 2.3%
<zyga> Mithrandir: so what's the percentage?
<Mithrandir> {amd64,i386,ppc}{install,live} is {6.8, 15.7 5.2, 5.7 13.0 6.9}
<zyga> calc: :-)
<Mithrandir> (numbers in GB)
<sjmorgan> which package would i report a bug under if i was having problem with the installer network configuration?
<ogra_> calc, its very basci currently...
<ogra_> calc, if we have the SQL db you will see a _lot_ of hw statistics
<calc> ogra_: cool
<zyga> is there any place with up-to-date download stats?
<jbailey> Hmm, reminds me that I need to file a wishlist bug asking for a backbutton in the hwdb tool.
<zyga> some simple grepping of log files even :/
<Mithrandir> zyga: http://torrent.ubuntu.com:6969/
<ogra_> jbailey, i think there is already one....please look first (cant remember)
<jbailey> ogra_: There wasn't when I tried it (a week ago or so).
<calc> whats up with two different sets of isos?
<zyga> kubuntu is pretty popular too
<calc> hoary-install isn't 5.04?
<ogra_> jbailey, i havent planned it ;) 
<ogra_> jbailey, i meant a bug about it
<jbailey> ogra_: Ah. ;)
<zyga> calc: good question, seems confusing at least
<ogra_> calc, ubuntu-5.04 is 5.04 ;)
<maswan> Mithrandir: Yeah, do that and then tweak the max uploaders to high numbers. as long as you only serve data from ram, it doesn't hurt (much)
<HiddenWolf> lmao. I envision a future where Ubuntu and Kubuntu lead the list on distrowatch. :D
<Pizbit> HiddenWolf: Hrm, tomorrow?:)
* Lathiat grins at Pizbit 
* HiddenWolf grins
<zyga> ogra_: ?
<zyga> ogra_: 5.04 == hoary, right?
<Treenaks> zyga: ack
<ogra_> zyga, i thougt you talk about the iso name....
<zyga> ogra_: that's what I was talking about.. why both names?
<calc> hmm in the past month ubuntu has 2x the hits as 2nd place
<ogra_> not bots
<ogra_> both
<HiddenWolf> calc, cute, isn't it
<Kamion> c'mon, btmakemetafile, get a move on so I can mirror up the DVD torrents and go to the party
<ogra_> zyga,  ubuntu-5.04 is hoary 
<calc> HiddenWolf: yea :)
<Kamion> calc: "two different sets"?
<Kamion> calc: the automatic daily builds are hoary-*
<Kamion> calc: the releases are ubuntu-5.04-*
<calc> Kamion: ah ok
<Kamion> if that's what you mean
<zyga> ogra_: I know but the torrent stats page lists two set of iso
<calc> yea
<fabbione> hey Kamion 
<zyga> Kamion: ah :-)
<Kamion> zyga: that'll be dailies
<mako> i like how the slashdot article put ubuntu in the kde in category for kubuntu, but not in the gnome category
<Pizbit> heh
<jbailey> mako: Perhaps they'd be less confused if it were called 'gubuntu'? ;)
<sabdf1> maswan: ping
<Mithrandir> maswan: didn't really change anything, but the torrents will take a little while to pick up.
<maswan> sabdf1: pong
<sabdf1> maswan: thanks for helping shoulder the load!
<sabdf1> the setup for rsync and ftp doesn't look right though, and other mirrors who are set to rsync from releases.ubuntu.com are having problems
<sabdf1> is it possible to fix those?
<maswan> sabdf1: Ah, yeah, I'll take a look on how it should look.
<sabdf1> maswan: elmo's got details
* zyga notices that web page had some artwork changed too
<maswan> sabdf1: Thanks for giving us some load, it's fun. :)
<sabdf1>  "some" :-)
<dholbach> sabdf1: first reply back on my apt-get.org mailing :-)
<sabdf1> dholbach: positive?
<dholbach> sabdf1: yes :-)
<dholbach> sabdf1: i'll wait a week and them mail you and mako a summary
<Lathiat> maswan: is your capacity being flatlined now? seems to have levelled off.
<mako> with the way i'm commenting on slashdot, i feel like bruce perens
<azeem_> mako is pulling a Bruce
<ogra_> heh
<Kamion> let's hope not
<sabdf1> speaking of... did the userlinux packages make it into hoary?
<maswan> Lathiat: yeah, this is about as fast as the ftp cluster goes. We hope to add a few more disks to spread the load there, it seems like it is disk bandwidth that is the current bottleneck
<Lathiat> maswan: yeh, need some extra ram to cache the current busy files :)
<sabdf1> maswan: we are going offline for 5-10 minutes, will be back with an extra 500 mbit/s
<azeem_> oh, they changed the ISO links to torrents on /.
<maswan> sabdf1: Ok, how are you handling the load? :)
<dholbach> sabdf1: userlinux? 
<Lathiat> sabdf1: What you changing?
<ogra_> sabdf1, if MOTU had known about userlinux, dholbach would have transitioned them....
<mako> azeem_: :'-(
<Kamion> Lathiat: unforeseen ISP issue, being fixed
<Lathiat> Kamion: rightio
<Mithrandir> hmm, didn't even help much to stop the buildd on this box. :/
* Mithrandir kicks bittorrent.
<sabdf1> maswan: cockup at our isp, they are bottlenecked upstream of us and need to take us down to fix it
<maswan> sabdf1: ah
<Lathiat> Mithrandir: perhaps theres just not enough poeple who want stuff :)
<dholbach> sabdf1: second positive reply
<sabdf1> dholbach: the userlinux metapackages, lets people take the userlinux package selection using ubuntu packages
<Mithrandir> Lathiat: there's people wanting i386 isos, I'm sure.
<dholbach> mako: you're going to meet Jaldhar H. Vyas today?
<dholbach> sabdf1: didnt hear about it yet *blush*
<maswan> sabdf1: there, rsync fixed
<Lathiat> maswan: What link do you have out?
<maswan> Lathiat: from the university? 2.5Gbit, possibly 2x2.5Gbit depending on if the ring is bi-directional. :)
<Mithrandir> maswan: it is
<maswan> Lathiat: from the computer club? Probably just 1 GigE
<Mithrandir> maswan: at least according to the presentation during NUCCC.
<Lathiat> maswan: funk
<Lathiat> maswan: the unis here are depressing
<Lathiat> the IT courses are such a joke
<maswan> Mithrandir: http://www.nordu.net/stat-q/plot-all/ndn-sunet1,2005-04-08,raw,traffic-kbit
<maswan> Mithrandir: well, yeah, if the campus routers are setup to handle that though, I don't know. :)
<Mithrandir> maswan: it should be part of the failover setup
<maswan> Mithrandir: We managed to put a bit of a hump on the sunet primary uplink, starting at about 10. :)
<mako> dholbach: i doubt it
<maswan> Mithrandir: Yeah, but if it is fail-over or loadbalancing matters when it comes to how much I can push out. :)
<mako> dholbach: he has two kids in lives in jersey.. i haven't heard that he would show up but it's possible
<dholbach> mako: hrm... he said so :-)
<mako> dholbach: oh, ok, then i will!
<Mithrandir> maswan: I saw it.  Nice.
<mako> dholbach: he usually does come to debian-nyc/ubuntu-nyc events
<mako> dholbach: usually, ususally DOESNT come
<maswan> Mithrandir: Actually, we only have one gigE to the brick, and that one is more or less full. 938Mbit/s peak.
<dredg> best /. comment ever
<dredg>  Actually, Ubuntu was actually a scheme by the Gentoo user community to get rid of the fanboys. We figured that if we could create a distro that had an even more obscure name than Gentoo, all of the fanboys would flock to it so that they could stay l33t. It seems to have worked perfectly
<Lathiat> haha
<Kamion> sabdf1: if you could let me know when it's back, that'd be good - I need to sync DVD .torrents and some Kubuntu .jigdo fixes out to mirrors, but don't want to do that until the interruption's finished
* Kamion goes to the post office in the meantime
<dholbach> sabdf1: 3rd positive reply :-)
* maswan tries to figure out how to use the grid uplink :)
<Mithrandir> maswan: we can stress-test ravel. :P
<mako> dholbach: great, i'll talk to jaldar about that later for sure
<dholbach> woohoo!
<HiddenWolf> Lazy devs, no talk about programming at all in -devel
<HiddenWolf> :P
<sabdf1> dholbach: v cool!
<pitti> HiddenWolf:     if( regcomp( &re, "^[[:space:] ] *([a-zA-Z0-9/_+\\-\\.] +)[[:space:] ] *(#.*)?$", REG_EXTENDED ) ) {
<pitti> HiddenWolf: ^ that better? :-)
<jbailey> HiddenWolf: There's that small problem of not being able to use our wiki at the moment... ;)
<pitti> HiddenWolf: new pmount code, btw
<diamond> lo folks
<diamond> who should i be talking to about mirrors/
<HiddenWolf> pitti, I feel refreshed, thanks. :)
<pitti> HiddenWolf: I know, regular expressions are so delightful to read :-P
<HiddenWolf> pitti, does it come with a dictionary? 
<pitti> HiddenWolf: I add a /etc/pmount.allow now 
<pitti> HiddenWolf: this was requested by a couple of people
<pitti> HiddenWolf: a whitelist of additionally allowed devices
<Lathiat> ouch, archive.ubuntu.com is looking a bit sick
<pitti> slashdotted?
<Lathiat> oh wait
<Lathiat> sabdf1 mentioned something about unscrewing their isp connection
<Lathiat> might work better after that :)
<maswan> Mithrandir: I have a better dual opteron for that, it has 2.2GHz cpus. :)
<mako> slashdot made a strategic edit :)
<Mithrandir> I think my coworkers would kill me if I ran bt on our dual opteron servers.
<mako> alright.. i'm jumping on these torrents
<maswan> Mithrandir: heh. I'm going to set this up and offer it as a temporary se.releases :)
<maswan> or something like that
<diamond> maswan: are you interested in having heanet as ie.releases? i've been talking to the mirror team there, and they're up for it
<diamond> maswan: they'd be an excellent addition, they run a really top-notch ftp site, handling ~80% of sourceforge downloads, etc.
<maswan> diamond: I think it sounds like a good idea, but you'll probably have to clear it by those properly involved like elmo. Chances are that they are rather busy right now though.
<diamond> maswan: understood.
<diamond> maswan: i'll just mail elmo, let him deal with it when he gets time.
<maswan> Hmm.. That machine didn't seem to come up properly, I guess I'll have to go down and beat it.
<maswan> Mithrandir: unfortunately it only has a rather slow IDE disk, but I was figuring that with 8 gigs of ram, it won't have to hit disk too often. :)
<Mithrandir> maswan :)
<HiddenWolf> slashdotted alright
<HiddenWolf> At least they are now linking to the torrents
<HiddenWolf> pdate: 04/08 14:21 GMT by Z: Made the direct ISO links torrents.
<HiddenWolf> that's supposed to say Update
<GheRivero> res
<calc> about to break 1TiB on torrents
<maswan> Hmm.. We don't need an ftpd, right?
<Pizbit> calc: And that's just the torrents you know about.
<calc> Pizbit: yea
<calc> the ones listed off t.u.c
<thom> maswan: ftp is for losers anyway
<Kamion> what's the ISP status?
<elmo> they still haven't done their "testing"
<Kamion> meh
<Kamion> does anyone particularly care if the DVD torrents don't go up until tomorrow or much later today?
<Pizbit> elmo: Probably don't want all their BW whored:)
<Mithrandir> Kamion: go partying.
<Mithrandir> Kamion: (so, probably not)
<jdub> Kamion: gotta put them up so slashdot can direct link them :-)
<fabbione> jdub: bad boy
<Kamion> jdub: not putting the ISOs up for a while anyway
<jdub> we should not rest until the "level 3 puddle of molten metal and plastic" is a tourist destination
<fabbione> i think jdub forgot to take his pill this morning
<diamond> as has probably been done repeatedly today already, i'd like to congratulate everyone here on a successful and excellent release. great job guys.
<pitti> thanks :-)
<jbailey> fabbione: jdub's on the pill?
* diamond grins, flees.
* Kamion -> London
<fabbione> jbailey: yeah....
<HiddenWolf> jbaily, think of lots of little jdubs, you'll see why
<dilinger> heh
<dilinger> "just watch a few episodes of Rocko's Modern Life.  everything you need to know about australia.."
* wasabi hugs ubuntu
<jbailey> g'morning Jerry. =)
<wasabi> morning.
<Tyo> Web Reseller and Hosting Ads  http://www.resellerads.com
<dholbach> sabdf1: 7th positive reply - i won't do anything else but answering mails all day :-)
<nullaresnata> Hello, does anyone nows how to configure the console keyboard to use the dead tilde?
<nullaresnata> I'm not getting it to work. In the installer, under the test keyboard section it didn't work either.
<mvo> dholbach: all positive so far? nice!
<dholbach> mvo: YES :-)
<lamont> g'morning
<pitti> Hi lamont
<pincushion> p1nhead: give it to me, yeah :-)
<ogra> morning lamont 
<mvo> morning lamont 
<lamont> no dvd torrents?
<lamont> or am I just confused
<Mithrandir> lamont: not yet.
<Lathiat> lamont: might be port 6969 i forget which
<mdz> good morning, hedgehogs!
<dholbach> hey mdz 
<lamont> mdz: morning badger
<jsgotangco> im a badger wanna be now
<Lathiat> mdz: the array? :)
<Lathiat> jsgotangco: haha
<mvo> morning mdz 
<pitti> Hi mdz
<pitti> mdz: congrats again :-)
<Mithrandir> *bounce*
<Simira> *blinks*
<ogra> YEAH mdz
<doko> nice!
<mdz> 20mbits outbound on the torrent
<trulux> :O
<HiddenWolf> mdz, wow
<jsgotangco> weve been slashdotted *grin* the main site is so slow on my side
<mdz> hey, slashdot published it! hehe
<smurfix> mdz: *grin*
<pitti> mdz: yeah, and heise.de too
<pitti> finally...
<mako> mdz: well, they originally published links TO THE ISOs
<jsgotangco> Yes, Mr. CEO, we're going with Hoary Hedgehog (Score:4, Funny) 
<mdz> mako: yeah, on *our mirror* I'm sure
<mako> of course!
<mako> after about 2 hours, they changed it
* pitti is dragged away by gf, cu later
<maswan> mdz: actually not, us.releases and se.releases
<doko> pitti: just reading heise forum, trolls only ...
<smurfix> lwn too. They couldn't possibly have written much less, though
<mako> maswan: is that true? weird?
<mako> one from each?
<mako> the torrents are slow today
<maswan> mako: Yeah. The install was to us and the live was to se. For i386. "the rest" pointed to download/
<Lathiat> already done 1.2TB on them apparently
<Lathiat> crazy
<Lathiat> at a guess thats about what acc have done, 4 horus of 75M*60*60
<mako> they're very slow on my end.. usually i can get an ISO in 5-10 minutes
<Mithrandir> only 1.2TB?  That's not much.
<Lathiat> Mithrandir: well its only been a few hours...
<Mithrandir> Lathiat: six.
<Mithrandir> or rather, close to eight
<Mithrandir> I've pushed somewhere in the range of a 100GB out from here.
<Lathiat> more like 2TB from the acc mirror then
<calc> mako: the amd64 torrent was over 100KB/s for me
* Lathiat looks at the graphs to get a better idea
* Lathiat can only do 50K/s :(
<mako> calc: i was getting 3MB/sec but only for a couple minutes
<Lathiat> iso takes 3.5 hours!
<Lathiat> yeh, looks like ~2TB
<jsgotangco> *evil laugh*
* calc wants a 3MB/s connection :)
<Mithrandir> calc: I'm pushing all I can in your direction. Swallow! :P
<calc> heh
* Mithrandir is actually pushing about 7MB/sec now
<calc> i have a puny 1000/128 cable connection
<Lathiat> calc: i have 512/256
<Lathiat> so i guess its half worse down and twice as good up :)
<Lathiat> Mithrandir: this isn't at home right?
<calc> Lathiat: yep
<Lathiat> Mithrandir: if your pushing 7M/s from home im going to cry
<mako> Mithrandir: on a torrent?
<Mithrandir> Lathiat: university connection.
<Mithrandir> mako: yes.
<jsgotangco> yep, Mithrandir was godlinke link
<Mithrandir> two boxes, one on 100Mbit, one on gbit.
<Mithrandir> but it's clearly not the bandwidth which is the problem, it's either the demand or the disks
<maswan> Mithrandir: I'm going to add just torrents on cdimage.d.o, tryign to set up a work box on a different gigE uplink currently. :)
<Lathiat> Mithrandir: ah, thats ok then
<Lathiat> unis are so crap here
<Lathiat> i pay 4c/MB
<Mithrandir> .st, where's that?
<Lathiat> so i can't even upload stuff cus the backtraffic screws me
<Lathiat> Mithrandir: bur.st is actually in australia, but .st = sao tome, some island somewhere iirc
<Mithrandir> oh, ok.
<Lathiat> bur.st - burst, its a joke :)
<Lathiat> http://www.bur.st/
<Mithrandir> .au is said to have shitty bandwidth.  Must suck.
<maswan> Mithrandir: I just have to get the stuff mirrored, acc is rather slow right now. :)
<jsgotangco> heh nice
<Mithrandir> heh.
<Lathiat> Mithrandir: yuh, it sucks
<Mithrandir> maswan: use bittorrent? :)
<maswan> Mithrandir: people keep saying that it won't keep >3M/s
<Mithrandir> maswan: I'm pushing 4MB/sec on one of mine.  More when there's demand.
<smurfix> On my server it's the RAM. If I try to serve all six torrents my load goes through the roof, it wants all of them in memory.
<Lathiat> smurfix: yeh course, it goes through the roof cus everything is iowaiting :)
<mako> bittornado improved perofrmance on my end
<Lathiat> having iowait in the gnome system monitor is great
<ska-fan> Is that an ubuntu patch, or is it upstream?
<Lathiat> or more to the point, in the panel applet
<Lathiat> i'm fairly sure its upstream but i don't know
* Mithrandir twiddles a bit to see if he can make it all go faster.
<dholbach> i'm out... see you later guys - and have fun at the parties!
<Mithrandir> you too
<ogra> yeah
<dholbach> thanks :-)
* Lathiat wonders how big a main mirror is
<Lathiat> i386, no source
<calc> under 10GB (i think)
<lamont> Lathiat: kde made it larger, but it's not all that big.
<calc> Lathiat: do you mean just "main" or all of i386 without source?
<Lathiat> calc: just main
* lamont mirrors much of main, and pieces of universe/multiverse, for two architectures with source, in 14GB
<calc> Lathiat: ah just main is small, probably whats on the dvd image so 2-2.5gb
<Lathiat> hmm 
<Lathiat> how bigs all of universe for 1 arch no source :)
<calc> that was what the 10gb guess was for
<lamont> calc: dvdimage is supported, not main
<lamont> and ubuntu-supported != kubuntu-supported
<calc> lamont: oh
<calc> lamont: i thought all of main was considered supported
<Lathiat> as did i
<lamont> ISTR hearing 70GB for the whole 9 yards... split it 4 ways, and you're still under 20GB
<Mithrandir> just main (i386), no binaries is ~ 1.3GB
<lamont> calc: yeah
* Mithrandir thinks that's wrong
<lamont> main == ubuntu-supported | kubuntu-supported
<mdz> elmo: us.releases doesn't seem to be carrying (or at least exposing) /kubuntu
<lamont> Mithrandir: no source, you mean?
<Mithrandir> lamont: that's sans source, yes.
<calc> lamont: ok
<Mithrandir> lamont: hoary + warty is 50GB, I think?
<lamont> Mithrandir: quite likely
<Mithrandir> all arches + source.
<Lathiat> is kde stuff in its own section?
* lamont could go check, but that machine is kinda busy atm
<Lathiat> just trying to figure out how i can debmirror without pulling useless crap :)
<lamont> Lathiat: sections?  the pool/ layout doesn't do sections
<Lathiat> lamont: debmirror reads the packages file
<lamont> Lathiat: yeah.  I use a rather crufty home-brew bastardization to mirror only the packages I want (and their dependencies).... It needs a major refactoring shortly
<Lathiat> debmirror seems to work well...
<Lathiat> and it can use rsync which rocks
<Lathiat> due to my bandwidth lackage :)
<Mithrandir> I just _loved_ both the misclassification and content of this slashdot comment:
<Mithrandir> Re:Whacked names (Score:5, Informative)
<Mithrandir> Hoary Hedgehogs are common in South Africa and businesspeople relate very well to them. As well as the elephants and lions on the street corners and the aardvarks and jakkalse. Of course, if it was called Sprinkbok, life would be much better....
<HiddenWolf> Ugh, Afrikaans is so weird if you're Dutch. :)
<Mithrandir> maswan: I wonder how long it'll go on for..
<Lathiat> 2.5GB apparently
<Mithrandir> whow, the kubuntu people found a meaning for kubuntu
<jsgotangco> i thought kubuntu was a real word
<Mithrandir> it is
<maswan> Mithrandir: what, and which language?
<Mithrandir> maswan: It means "towards humanity" in Bemba.
<Mithrandir> (from the faq)
<maswan> ah
<jsgotangco> hehe
<Lathiat> and with universe
<Lathiat> its 10GB
<Lathiat> Mithrandir: ahah
<jsgotangco> but most people will say its just word play
<Mithrandir> so I guess it's a step on the way to ubuntu with gnome.
<Lathiat> i think i might mirror the lot
<Mithrandir> jsgotangco: yeah
<jsgotangco> i love the circle of dragons though
<jsgotangco> they should keep that
<jsgotangco> its cute
<Mithrandir> yeah, it is
<Lathiat> 2 and a bit days to mirror all of main and universe 
<Lathiat> mmm
<Lathiat> shold goto uni tomorrow and do it at 100mbit :)
<dle--> Hello.  I'm wondering what key was used to sign today's MD5SUMS.gpg files?
<Lathiat> pub  1024D/437D05B5 2004-09-12 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<dle--> Lathiat: Thanks! :)
<cartman> breezy is up yet?
<jsgotangco> savor the hoary moment :)
<cartman> I am getting ready for tomorrow ;)
<jsgotangco> tommorow can wait :)
<Lathiat> sabdfl: you guys fixed your connetion yet?
<Lathiat> sabdfl: archive.ubuntu.com is giving me like 8K/s :\
<sabdfl> Lathiat: no, still stuck i'm afraid, lots of engineers scrambling
<Lathiat> sabdfl: bugger
<sabdfl> Lathiat: torrent
<Lathiat> sabdfl: can't torrent the packages database :)
<Lathiat> local mirror is probably in sync now anyway
<Treenaks> apt-torrent...
<Treenaks> that'd rock
<Lathiat> no it wouldn't
<Lathiat> itd be slow :)
<sabdfl> even the mirrors are struggling at the moment
<diamond> Lathiat: it would rock slowly -)
<Lathiat> sabdfl: i know :)
<Lathiat> but the local one wont be
<Treenaks> sabdfl: that means ubuntu is popular, right? :)
<Lathiat> as its not an official one
<maswan> we've sent out about 2.5TB of ubuntu love the last 9-10 hours :)
<Lathiat> maswan: i noticed :)
<Lathiat> the torrents have one about 1.5TB too
<Lathiat> maswan: your cluster needs upgrading obviously :)
<maswan> Lathiat: I'm working on a temporary server to handle part of the load. :)
<Lathiat> maswan: haha yay :)
<Lathiat> maswan: by the time you get it the load will be gone? :)
* Lathiat wonders how long it will stay flatlined
<maswan> Lathiat: good question, we'll see?
<Lathiat> ah this is better, 54K/s
<Lathiat> not 3 :)
<Lathiat> poor archive servers
<mdz> Mithrandir: any idea what this is referring to?  http://linux.slashdot.org/comments.pl?sid=145437&threshold=1&commentsort=0&tid=162&tid=121&tid=106&mode=thread&cid=12176621
<mdz> Lathiat: why are you not using a mirror?
<mdz> Lathiat: <country code>.archive.ubuntu.com
<Treenaks> mdz: probably localhost being UTF-8, while remotehost is not
<Treenaks> mdz: the solution for this person is to upgrade remotehost to utf-8
<mdz> Treenaks: or use legacy locales on the local system
<Treenaks> mdz: (have that here in .nl as well, but to a lesser degree)
<Lathiat> archive.ubuntu.com has address 82.211.81.151
<Lathiat> archive.ubuntu.com has address 82.211.81.138
<Lathiat> au.archive.ubuntu.com has address 82.211.81.138
<Lathiat> au.archive.ubuntu.com has address 82.211.81.151
<Lathiat> mdz: i was.
<Treenaks> mdz: yes, but only sometimes.. because some remote hosts might be UTF-8
<Treenaks> mdz: mixed environments suck..
<mdz> Lathiat: hmm, we've been working on getting au.archive going, but apparently it's not there yet
<Lathiat> mdz: are they run by you guys or you get a third party?
<mdz> Lathiat: us.archive might be faster than the uk mirror
<Lathiat> mdz: uwa might be interested for example
<Lathiat> mdz: they already mirror it (its what im using now)
<mdz> Lathiat: third parties...my understanding is that there are already people interested in running mirrors in .au, it just hasn't been completely set up yet
<Lathiat> mdz: ah right
* mvo leaves to play some hockey
<zenwhen> Are all you devs asleep now?
<zenwhen> XD
<mdz> no
<mdz> mvo is playing hockey
<zenwhen> oh you should be
<zenwhen> :(
<ska-fan> I found "It's interesting that Ubuntu, a binary distro based on slow old Debian, has Gnome stable on 2.10.1, while we bleeding-edge Gentoo users are still on 2.8...." pretty amusing ..
<Pizbit> hehe
* ogra babysits his old server, hwdb.ubuntu.com is busy heavily with submissions :)
<ogra> heavily busy..
<Lathiat> ogra: hehe how much taffic is it doing :)
<stratus> ogra, hah isn't it good?
<Lathiat> or how many submissions a minute
<ogra> about 1 minute average time between submissions....
<stratus> ogra, i submitted a report from a ibm netvista yesterday. Do you know how/when the information will be published ?
<stratus> wow
<ogra> stratus, it already is
<Lathiat> ogra: oh, is that all :)
<ogra> stratus, open your client a second time ;)
* Lathiat grins
<stratus> ogra, i'm not too much into ubuntu atm.
<Lathiat> ogra: ooh, thats new
<ogra> Lathiat, but its rised the last hour....
<Lathiat> i've submitted mine a few times
<stratus> ogra, hmm i'll check after with the web developers here, i use debian.
<ogra> stratus, it offers you a button to get to your info
<ogra> stratus, but beware, submissions from debian systems dont work...
<Treenaks> why does my hwdb-client window disappear when I open my browser?
<Treenaks> I don't like losing windows
<stratus> ogra, i know of course.
<ogra> Treenaks, because it has done its job :-P
<stratus> ogra, i'm not a newbie. I was asking about general hardware compatibility information through a web page.
<stratus> Treenaks, don't you like losing windows? hmm, sounds interesting...
<ogra> stratus, wait for the SQL server...i'll start next week...
<Treenaks> ogra: no, I wanted to open that browser and continue using that program (to copy/paste my computer id)
<Treenaks> stratus: I don't mind losing Windows, but I hate losing windows
<stratus> ogra, sounds great keep the good work.
<ogra> Treenaks, sorry, its stable.... no changes the next 6 months
<Treenaks> ogra: oh yes... breezy changes
<Treenaks> :)
<ogra> stratus, i will, thanks ;)
<ska-fan> ogra: what's the software basis for hwdb? On the server?
<ogra> apache
<ogra> python 
<ogra> ls and grep
<ska-fan> storage? text files?
<ogra> currently textfiles, but eventually a SQL db.....(postgres is planned)
<Treenaks> ogra: I hope you're going to import that somewhere :)
<stratus> ogra, do you think that will be much harder port your code to use in Debian systems? We've discussed about a debian hwdb at debconf4 but i didn't see to much progress on this topic.
<sladen> ogra: the HWDB page will load a /bit/ quicker if you change the HTML code to stop fetching the CSS over HTTPS... https://www.ubuntulinux.org/plone.css
<ogra> sladen, argh, thanks....
<sladen> ogra: in about half a dozen places
<ogra> sladen, (in fact its a copy and paste of the plone head) *g*
<ska-fan> Why is the null swap thing so interesting?
<ogra> ska-fan, because its 10% 
<ogra> ska-fan, and a lot of these are 128-256 MB machines where no swap hurts
<Treenaks> c7bbcdc2dbcf0eec5ce714b27a3438d0 \o/
<ska-fan> Yeah, but are you going to tell them, hey, set up some swap space? I mean, why the statistics?
<Treenaks> ogra: My non-professional opinion is that those people do manual partitioning, people forgetting to set up swap that way
<Treenaks> ogra: or have no clue on how to do that
<ogra> Treenaks, nope, we had a bug in the hibernate code that roke the swap...and i still thik we should give people a hint to enable it again...
<Treenaks> ogra: aha
<ska-fan> Ah.
<ogra> in fact i already recieved some "thank you i didnt know that" mails
<sladen> could just forcefully run 'mkswap' on every boot.  This would also get rid of stale hibernations
<rcaskey> I set up my laptop without swap because I had plenty of ram but then suspend got fixed (mostly) and no dice ;)
<maswan> http://ubuntu-releases.acc.umu.se/
<maswan> a mirror few knows about, so it isn't overwhealmed yet. :)
<ogra> sladen, yup, in breezy....
<ogra> sladen, i'm worried about 10% broken systems out there now....and the number stayed constantly at this value.....
<rcaskey> Does breezy exist yet?
<zul> nope
<AstralJava> Hi all.
<ogra> sladen, you made my day ! thanks for the https hint....i really had no explanation for the slowness
<AstralJava> So, I wanted to let you guys all know that I sincerely appreciate hugely your work, and congratulate on reaching yet another high point.
<mdz> AstralJava: thanks, there are many more good things to come ;-)
<AstralJava> mdz: I'm sure. :)
<zenwhen> mdz: are elements of cairo supposed to be rolled into metacity before the next release?
<mdz> zenwhen: I don't know, seb128 might
<AstralJava> Also, all that great stuff has inspired me to join the forces, I'll begin working on those missing or broken .desktop entries next week.
<AstralJava> But that's more for MOTU stuff, just thought I'd share.
<mdz> glad to hear it, MOTU is becoming a strong community in itself
<daniels> agreed, they are doing very well
<AstralJava> I don't wonder why. :)
<AstralJava> So, are you guys two separate teams?
<AstralJava> I mean, MOTU and devel?
<seb128> zenwhen: cairo will be used by gtk2.8
<zenwhen> is that likely going to be a 2005 thing?
<seb128> correct
* calc notices gnome 2.11 start page isn't up on g.o yet
<seb128> http://www.gtk.org/plan/2.8/
<whiprush> man, 4 hours till our ubuntu party and I just can't get any work done.
<seb128> calc: http://live.gnome.org/TwoPointEleven
<jbailey> doko: ping?
<calc> ah ok
<jbailey> So Breezy releases on Oct 7th then? ;)
<jbailey> bradb: Heya!
<ska-fan> Whoo, I'm gonna be 5000 kms from home by then
<bradb> jbailey: hey :)
<lamont> seb128: thanks for the link - time to tell my wife she needs  a new husband that weekend... :-(
<rcaskey> seb128: thanks, i was looking for that 15 minutes ago ;)
<doko> jbailey: pong
<jbailey> doko: Did you wind up committing your changes to that wiki page?  You said you were working on it, but I didn't get an email saying the page had been updated.
<seb128> lamont: ah ah
<lamont> seb128: her annual trade show is the weekend prior...  I'm screwed
<seb128> utch
<mxpxpod> to get hoary updates, do I need to change anything in my sources.list?
<seb128> blame jdub for the calendar :p
<lamont> s'ok
<doko> seb128: maybe pia didn't allow him to make the next upload ;-)
* lamont goes off to do some user relations, etc.
<Lathiat> maswan: is it just me or is this 3x more than the max data you've pushed all year :)
<Lathiat> according to my calculations, theres been roughly 8500 iso downloads between bittorrent and ftp.acc
<maswan> Lathiat: well, pretty much yeah, the other peaks have been more artificial and thus shorter and eventually filtered out of the more long-time graphs
<Lathiat> maswan: right, well yeh this one has now hit the yearly graph on the large size
<Lathiat> maswan: wanna take bets on when it starts to ease off the top line? :)
<maswan> Lathiat: not really, I'm hoping it stays. :)
<Lathiat> maswan: well bet next year then :)
<maswan> Lathiat: besides, I'm not the right guy to bet with. I might "accidentally" trip over apachectl. ;)
<Lathiat> maswan: heh
<Lathiat> only data stuff i've dealt with thats close to this
<Lathiat> is a lan party i run :)
<Lathiat> heh
<Lathiat> usually do 40TB or something in the weekend accross the core switch
<Lathiat> but no where near the internet :)
<mdz> AstralJava: the MOTU team is a subset of the Ubuntu development team which focuses on universe
<mdz> AstralJava: likewise, we have a kernel team, a laptop team, etc.
<zul> kernel team is cooler though ;)
<ogra> AstralJava, and the MOTU team itself has subteams ;)
<zenwhen> so did all of gnome 2.10.1 wind up in hoary final?
<AstralJava> mdz, ogra: Right, I get it now.
<mdz> zenwhen: all of gnome 2.10.1 hasn't wound up on ftp.gnome.org yet
<mako> ok.. i just reimplemented userlinux, almost from scratch
<mako> and it's *way* better now
<zenwhen> mdz: oh ok. I keep having people ask me why their gnome about page still reads 2.10 when slashdot said Hoary had 2.10.1
<shaya> has badger been forked yet?
<shaya> wondering when I can change my hoary dists to badger
<mdz> you can try it; if you get a 404, it isn't there yet
<AstralJava> mako: Out of curiosity, what's 'userlinux'?
<shaya> mdz: cept I cant get in
<shaya> AstralJava: Bruce Peren's attempt at a debian based dist
<mdz> AstralJava: www.userlinux.com
<shaya> hasn't seemed to do anything
<AstralJava> Okay thanks.
<AstralJava> Seems interesting too.
<mako> shaya: well, it hasn't seem to do anything that i can't redo in half a day's work :)
<javi> hi, I have a problem with python on ubuntu hoary :
<javi> my symple script : #!/usr/bin/python  \n import os
<javi> make a plus (+) on my mouse
<Treenaks> javi: why /usr/bin/python ?
<javi> with that  plus i can make one square
<javi>  which python
<javi> /usr/bin/python
<javi> python myscript.py is ok
<Treenaks> javi: oh and "\n" means newline.. so your file is 2 lines?
<Treenaks> javi: (it shuold probably say /usr/bin/env python -- that's what my python books recommend)
<ska-fan> javi: not here
<javi> yes
<Treenaks> javi: also, #python might be better, yes
<javi> mmm, ok ... i think about a ubuntu question
<javi> ok
<javi> thank you
<Treenaks> javi: it is better to ask support questions about ubuntu in #ubuntu
<javi> I'll ask it on #python ...
<javi> I'll go there, thank you, and sorry
<Treenaks> javi: no problem :)
<shaya> mako: what's this nyc get together you are planning
<AstralJava> mako: Does that tell more of yourself?
<AstralJava> ;)
<maswan> btw, for those wondering where ubuntu-releases.acc.umu.se came from, it is a temporary host, and is graphed here (the pink, yellow is cdimage.d.o):
<maswan> http://cdimage.debian.org/stats/monitordata/index.shtml
<Lathiat> maswan: got that temporary server up?
<maswan> Lathiat: yes. serving one file only: Redirect /5.04/ubuntu-5.04-install-i386.iso http://ubuntu-releases.acc.umu.se/5.04/ubuntu-5.04-install-i386.iso
<Lathiat> ah rightio
<Lathiat> maswan: do those ftp stats include http?
<maswan> Lathiat: those graphs are network bandwidth, and is almost all http
<Lathiat> right
<Lathiat> teste not on those graphs?
<Lathiat> (so like, its those + another 15M/s ?)
<maswan> testse is ubuntu-releases and is on the cdimage.d.o link
<maswan> pink, out to the right :)
<Lathiat> yep
<Lathiat> oh, 45M :)
<Lathiat> so youd be doing more like 100M/s now :)
<Lathiat> maswan: what happened at 2pm?
<maswan> yes
<maswan> Lathiat: small misconfiguration fix
<maswan> probably dumped a bunch of downloaders, but seems to have retried quickly
<Lathiat> yeh did, what did you cchange?
<ogra> yay, 6000 submissions on hwdb.ubuntu.com
<maswan> added a virtual host for se.releases.u.c, but that broke the previous download link that pointed there.
<Lathiat> ah right
<Lathiat> oops :)
<rcaskey> is it normal for a window to show up in the window list twice if it has a modal child that steals focus?
<rcaskey> or even if it doesn't steal focus
<rcaskey> (ie. update manager)
<Lathiat> maswan: i'll be impressed if that lasts more than 24hours.
<maswan> Lathiat: me too
<maswan> I'm expecting the ftp cluster graph start dropping soon, since I've redirected away the i386-install iso
<Lathiat> maswan: cat5 getting warm? :)
<maswan> http://stats.sunet.se/stat-q/plot-all/umea2.umea-srp,2005-04-08,raw,traffic-kbit
<maswan> this is the uplink to our university. :)
* Lathiat laughs
<Lathiat> maswan: got pictures of the hardware?
<ska-fan> a heat camera picture :)
<maswan> http://ftp.acc.umu.se/mirror/ftp-about.html
<Lathiat> haha
<maswan> that has links to some pictures
<maswan> and some general info
<maswan> the temporary machine is just a boring 1U dual opteron with 8 gigs of ram
<Lathiat> wis i had one of those :)
<maswan> load average: 0.19, 0.13, 0.03
<maswan> that's delivering 45M/s average
<HWolf> maswan: You just happened to have it lying around in the bin?
<maswan> HWolf: We have a few extra test machines, in addition to the 190 ones we have in a compute cluster. :)
<HWolf> ..190..?
<maswan> HWolf: http://www.hpc2n.umu.se/resources/sarek.html
<HWolf> for what?
<maswan> resource for academia in sweden, researchers that need to do lots of computation
<HWolf> Ah. Cool.
<HWolf> And a bit of that bandwith is now given to Tux?
<Lathiat> i want to goto your university :)
<Lathiat> im lucky if i can get on the network at mine :)
<Lathiat> and then like.. i can can pull 1 or 2 M/s at 4c/MB on a good day :)
<maswan> HWolf: I borrowed one from there since one network there has a separate gigE uplink from the rest of campus. :)
<Mithrandir> mdz: because most people in Scandinavia are firmly latin-1 and converting to utf-8 is a bit more than "convert your terminal".
* HWolf wonders what people would do if he borrowed a dual opteron and a gig uplink.
<maswan> HWolf: depends on what you did with it? :)
* HWolf would chop it up, sell the parts, and go out drinking, really
* HWolf is just a poor failed student with a crush on ubuntu, so he likes to be the groupie of -devel
<Lathiat> maswan: man you guys have some slick hardware
<Mithrandir> Lathiat: his hardware even makes me jealous.
<Lathiat> Mithrandir: what do you have
* Lathiat has a lolely 2.0Ghz Pentiu-M laptop with 512M of ram and 260GB of hdd :)
<Lathiat> our computer club only *just* got a dual opteron server with 800GB of disk in raid-5
<Lathiat> and tahts not at my university :( no computer club at mine.
<Mithrandir> Lathiat: depends on what you mean by "have"; at least a triple of single athlon64 machines (2800+, 3000+, 4000+); at $work we have about ten dual opterons ranging from 240 to 250s.
<Lathiat> or at least, none thats worth caring about.
<maswan> hmm.. it seems to be holding at about 40MByte/s for ubuntu-5.04-install-i386.iso
<maswan> but I have no problem getting more when I try
<maswan> perhaps we have met the demand for that iso?
<Mithrandir> maswan: *chuckle*
<Lathiat> ftp.acc is probably still a bit backlogged
<Lathiat> perhaps you should kick a few clients :)
<maswan> Lathiat: hehe
<maswan> well, I could add a redirect for the livecd too
<HWolf> maswan: somehow I doubt it
<HWolf> I wonder when the first editorial raving about a 'blistering success" will be published
<Lathiat> maswan: so did you stick the iso image on a ramdisk? :)
<maswan> Lathiat: nah, I have a proper releases mirror on that machine. it's just that cache works pretty well when you have way more ram than workingset :)
<Lathiat> heh yeh
<Lathiat> hmm i dont think my isp is counting the amoune of data im doign correctly
<hohlraum> why was evolution packaged with two .desktop entries in two different categories? (Office and Internet)
<hohlraum> its the only inconsistency across all the apps that are installed.
<Lathiat> it fits in both really
<Lathiat> no idea if theres a policy in not having two ro somethign
<mako> hmm. shaya wandered off
<hohlraum> sure it does.. so pick one.. simple.  regardless of whether or not its against some policy doesn't make it right.
<dholbach> hey!
<maswan> Mithrandir: hmm.. you that know stuff like this, what's the optimum number of threads per worker proces in apache2? for serving isos at gigE to a couple of thousand clients that is
<ogra> hi dholbach 
<dholbach> hey ogra
<maswan> Mithrandir: I need to increase either the Server Limit from 50 or ThreadsPerChild from 25 by a factor 2-4 :)
<Lathiat> threads are cheaper 
<Lathiat> no idea where the balance lies
<maswan> I have no idea either, but I seem to remember that Mithrandir has some experience in high-performance webservers
<Lathiat> increase both? :)
<Lathiat> heh
<maswan> heh. I will if he doesn't answer me soon. :)
<Lathiat> 10000 servers with1 00000000 threads is obivously better :)
<Lathiat> and don't forget to compile your apache from source :)
* maswan reloads server-status and watches "741 requests currently being processed" getting closer and closer to the limit
<Lathiat> whats the limit?
<sladen> 25*50 = 1250 minus the percentage that are being reforked at that moment
<Lathiat> well, i've served up 33 isos off my small local mirror :)
<Lathiat> beat you all :)
<Lathiat> maswan: uh all the ftp data i sstarting to level off
<Lathiat> s/level off/drop off
<Lathiat> those disks but me a little toasty
<Lathiat> maswan: for that opteron cluster, do you run somethign like mosix or just lots of instances of whatever program on each node?
<maswan> yeah, the temporary host is still picking up though
<maswan> Lathiat: lots of instances
<maswan> Lathiat: they can communicate with eachother via MPI
<Lathiat> mpi?
* Lathiat reads up on mpi
<maswan> message passing interface, a standard for telling processes stuff
<maswan> optimised for high speeds and low latency
<Lathiat> cool
<Lathiat> im so jealous :)
<Lathiat> ahah be good for a gentoo user to distcc with :)
<Lathiat> make a nice buildd too :)
<Lathiat> "rebuild the entire archive once a day just for the hell of it!"
<maswan> well, given that it would take one of those machines somewhere around a couple of days to a week or two to rebuild the entire archive...
<maswan> entire debian archive, I should qualify
<Lathiat> so with all 160 or whatever.. :)
<Lathiat> maswan: got photos of the opteron cluster?
<ska-fan> maswan: maybe #apache people know more
<maswan> Lathiat: http://www.hpc2n.umu.se/images/archive/20040609-MoreOfM/IMG_0240.JPG
<maswan> two of the racks plus the myrinet switches
<maswan> http://www.hpc2n.umu.se/images/archive/20040609-MoreOfM/IMG_0211.JPG
<maswan> backside of the racks
<Lathiat> neat
<maswan> lots of more images in images/archive
<Lathiat> im jealous enough already :)
<mako> i liked the /. mention of MandrivaGNU/KUbuntu
<trulux> hey mako 
<mako> trulux: hey, anything from amaya
<mako> ?
<HWolf> Are the torrents still challenged for bandwith?
<maswan> HWolf: doesn't seem like that
<HWolf> maswan, cool
<maswan> HWolf: I seed considerably more to the debian iso sets
<HWolf> or rather, not cool. :S
<trulux> mako: nicht :(
<trulux> mako: nothing back from her
<mako> trulux: cool, i'll poke
<trulux> mako: ok, many thanks in advance
<trulux> I've been working out the final libssp packages
<mako> awesome :)
<trulux> and next are the gcc wrappers for gcc-3.4-hardened
<Lathiat> well, 4:30am
<trulux> I still need to make some work around SELinux targeted policy
<Lathiat> time to hit the sack
<trulux> mako: I would like to talk to the maintainer of the libpam packages
<Lathiat> night all
<doko> trulux: will you make a hardened release based on hoary?
<mako> i'm not sure who handles libpam for ubuntu but pitti may be a good place to point your fignre
<trulux> doko: yes
<doko> cool
<trulux> doko: as soon as I finish it, as soon as *WE* have a toy to play with
<doko> :)
<trulux> doko:I will prepare the first release of the gcc-3.4-hardened package tomorrow
<trulux> doko: rather than making gcc-3.4 + ssp packages....
<giskard_> ubuntu installer is the same of sarge right?
<trulux> doko: we use a gcc-x.y-hardened package which gives us both ld and gcc wrappers
<trulux> doko: so, we don't end in the overhead of maintaining separate packages
<trulux> instead, and as a careful study I did demonstrates (I will publish it as soon as I finish the remaining sections of the paper), the impact of having SSP flags capable topolchain is minimal
<trulux> we just *not* enable it by default
<trulux> and gcc-x.y-hardened will depend on libssp
<doko> you're going to UDU?
<trulux> doko: If I get the money, maybe, too close now, I think not, but who knows, I need a sponsor and I haven't started to look for it
<maswan> hmm.. the bandwidth use seems to go down now. perhaps we've handled the peak demand by now?
<Mithrandir> maswan: I don't know; I haven't really tuned a2 at all
<Mithrandir> maswan: and my web servers are mostly a1 still; that'll most likely change in the summer
* Mithrandir runs off for a concert.
<maswan> Mithrandir: I'll go for the classic "hmm, I wonder what this'll do" then. :)
<maswan> have fun!
<dholbach> Mithrandir: concert? who plays?
<dholbach> hey lamont_r 
<lamont_r> howdy dholbach 
<dholbach> already partying? :-)
<paulproteus> I am attempting to use the multiseat package in Ubuntu.  Unfortunately, while I see action in the Changelog (/usr/share/doc/multiseat/changelog.gz), I can find no documentation for the package.
<paulproteus> I used the Enable multiseat option in the Hoary installer, and afterwards did # apt-get install multiseat.
<paulproteus> Is there something I should know, or some tools that will help, or some documentation on how to use the multiseat system?
<Mithrandir> dholbach: Madrugada; norwegian band.
<Mithrandir> dholbach: but it was a bit too full, so I left.
<paulproteus> By the way, if anyone wants me to write documentation for multiseat, I can do that happily if someone explains to me what the package is capable of. ;)
<maswan> Mithrandir: I figured out that it doesn't matter much since I will run out of bandwidth long before I run out of cpu. :)
<Mithrandir> maswan: :P
<maswan> load average: 0.18, 0.13, 0.10
<maswan> only have 1 gigE to the "interesting" network
<Mithrandir> maswan: apache is ok-ish bandwidth-wise.
<dholbach> Mithrandir: that was fast
<Mithrandir> dholbach: packed with people and the band wasn't that good today.
<maswan> Cpu(s):  0.7% us,  2.1% sy,  0.0% ni, 80.1% id,  0.0% wa,  1.6% hi, 15.4% si
<Mithrandir> dholbach: I work at the student society, so I get free entrance to everything
<dholbach> Mithrandir: and free beer, i hope :_)
<Mithrandir> dholbach: nah, no free beer, but it's fairly cheap.
<maswan> ... for Norway. ;P
<Mithrandir> maswan: load seems to be dropping now. :(
<Mithrandir> I'm only pushing 1.3MB/sec.
<Mithrandir> (on one box)
<maswan> http://cdimage.debian.org/stats/monitordata/index.shtml
<Mithrandir> maswan: yeah, cheap for Norway.
<maswan> that one seems fairly stable
<maswan> http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html
<maswan> the ftp cluster is dropping a bit after I redirected the i386 installer+live cds
* dholbach looks forward to beer at UDU :-)
<dholbach> _mvo_: what about beer tomorrow? :-)
<Mithrandir> dholbach: are you also going to be drowned?
<robertj> is archive.ubuntu.com a round-robin?
<dholbach> Mithrandir: don't think so, i'm drowned too fast i guess ;-)
<crimsun> robertj: for 2, yes
<AstralJava> Okay, I'm too tired now, what's UDU?
<robertj> 2?
<robertj> 2 machines or 2 something elses?
<dholbach> astharot: wiki.ubuntu.com/UbuntuDownUnder
<dholbach> AstralJava: : wiki.ubuntu.com/UbuntuDownUnder
<AstralJava> Ahh....
* AstralJava wishes he'd have funds to go...
<mvo> dholbach: beer *yum*
<dholbach> WOOHOO
<AstralJava> Oh, that's the keyword. :)
<dholbach> mvo: hrm... no weather for biergarten in the next days
<dholbach> good night pals, i'm off to bed
<ogra> night dholbach 
<dholbach> bye ogar
<dholbach> ogra
<dholbach> :-)
* robertj bahhs, 524k/sec :(
<robertj> plan of action: apt-get -d dist-upgrade from this 2 day old mirror and then dist-upgrade again from the archives
* mvo heads to bed too
#ubuntu-devel 2005-04-20
* nullaresnata is away: estou noutro lugar qualquer.
<cybrjackle> libpt locked my amd64 box on new install and reboot upgrade, now dpkg appears to be messed up
<digale-tambien> why can't I delete /var/lib/gdm/:0.Xservers ? please help
<digale-tambien> obviusly ?m trying to delete it with sudo :)
<digale-tambien> root@kin:~# rm /var/lib/gdm/:0.Xservers
<digale-tambien> rm: no se puede efectuar `lstat' sobre /var/lib/gdm/:0.Xservers: Permiso denegado
<dhonn> ubuntu's mozilla uses debians default start page instead of ubuntus
<Flonne> Declare it a security risk. :)
<seb128> dhonn: ubuntu ships firefox
<koke> a simple question, hoary's main is already frozen forever?
<koke> (expect for security updates)
<koke> except
<koke> I just discovered a bug on update-notifier's translation to spanish
<koke> a bit late I guess ;)
<robitaille> dhonn,   ubuntu's mozilla (not firefox) contains some references to Debian; see Bug #1949
<digale-tambien> koke estoy teniendo un problemilla, como root no puedo borrar este archivo: rm /var/lib/gdm/:0.Xservers, y cuano instalo gdm necesita borrarlo y no puede
<digale-tambien> hay algo raro ahi
<Mithrandir> digale-tambien: english please
<digale-tambien> Mithrandir I said it in englush and you didn't help me.
<digale-tambien> here's an opinion of my problem:
<digale-tambien> dcraven digale-tambien, okay that's just whacked.
<RastaMahata> "koke, im having a bit of a problem, as root i cant delete this file: rm /ver/lib/gdm/:0.Xservers, and when I install gdm it needs to delete it and it cant"
<digale-tambien> thanks rasta
<RastaMahata> no problem
<digale-tambien> =) that's it. :/
<koke> digale-tambien: since there are more english speakers than spanish in the channel is just more porbable you'll get an answer by writing in english
<digale-tambien> ok
<digale-tambien> so... bugzilla?
* RastaMahata is chilean... :o
<digale-tambien> security update?
<digale-tambien> re-install it?
<digale-tambien> is yo tb :)
<digale-tambien> RastaMahata me too :)
<RastaMahata> anyway, I was just here to say that I'm unable to see devices in "computer:///" mounted on /media, when mounted from fstab. I hope you fix this :)
<zenwhen> RastaMahata, you may need to provide more information about your system in an actual bug report on the bugzilla site.
<zenwhen> This isnt a common issue.
<RastaMahata> really? ok, I'll look in the bugzilla site. Thanks zendog 
<RastaMahata> zenwhen*
<RastaMahata> (damn tab key)
<zenwhen> no prblem sir
<jdub> morning all
<zenwhen> mornin
<ogra> morning jdub 
<zenwhen> How are you doing jdub 
<jdub> i feel like a car crash ;)
<zenwhen> as do I, but thats because I am sick and all nyquiled up
<azeem_> that reminds me of an U2 song
<Mithrandir> jdub: I asked seb128, but not you -- do you know of any plans on a "location" kind of applet?
<Mithrandir> or "places"
<seb128_> Mithrandir: pkgconfig 0.16 breaks a whole bunch of GNOME stuffs :/
<Mithrandir> seb128_: uhm, like what?
<digale-tambien> there are so many bugzilla pages about it, and the final release of hoary it wasn't fixed, cool...
<digale-tambien> =)
<digale-tambien> I've made, at january, a bugzilla page about it, nad it wasn't fixed
<digale-tambien> ;)
<seb128_> Mithrandir: configure.in:131: error: possibly undefined macro: dnl
<seb128_> ross: its pkgconfig 0.16
<seb128_> seb128: ah ah
<seb128_> ross: you can't put dnl inside the stuff to check there
<seb128_> ross: gtk does this:
<seb128_> ross: PKG_CHECK_MODULES(BASE_DEPENDENCIES,
<seb128_>   [glib-2.0 >= glib_required_version dnl
<seb128_>    atk >= atk_required_version dnl
<seb128_>    pango >= pango_required_version] )
<seb128_> ross: there is too much quoting, dnl doesn't get expanded with 0.16
<Mithrandir> blah, ok.
<Mithrandir> I should fix that, then
<seb128_> several gnome people using debian are complaining than the CVS doesn't build now
<Mithrandir> does too. :P
<seb128_> you should probably not let this version going to sarge
<Mithrandir> oh, gnome cvs, you mean
<Mithrandir> I guess so.
<seb128_> yeah, the GNOME package just ./configure && make
<seb128_> packages even
* Mithrandir blames scott
<jdub> seb128_: ha ha, hordi's blog :)
<seb128_> yeah, nice one :p
<jdub> Mithrandir: location/places applet? what kinds of locations/places?
<jdub> Mithrandir: like wifi?
<Mithrandir> jdub: "home", "work", "wireless at parent's"
<jdub> or network profiles?
<jdub> yeah
<jdub> okay
<Mithrandir> jdub: yes, except it's not just network
<jdub> so you can try netapplet now
<jdub> but it's pretty yucky
<jdub> we didn't ship it by default for hoary
<Mithrandir> but say I want to have another background if I'm at the university than at home
<seb128> jdub: no, he wants the whole config
<jdub> for breezy, i think we're going to be looking pretty hard at NetworkManager
<digale-tambien> WTF! when I restarted my pc, gdm blocked the /var/lib/gdm direcotry, I can't do: ls as root, I can't delete nothing at that direcotry, how can I unlock it?
<jdub> which will let you do things beyond network
<digale-tambien> please help, I'm using hoary...
<Mithrandir> seb128: that's just because it used to do improper quoting, I think.
<seb128> Mithrandir: look at the example I give
<seb128> what is wrong with it ?
<Mithrandir> seb128: I don't know m4. :P
<seb128> Mithrandir: the fact is, that it breaks a whole bunch of stuff
<Mithrandir> but to me, it looks like you're quoting dnl
<jdub> heh, archive.ubuntu.com seems a little slow ;)
<seb128> and I don't get a reason to break, that used to work
<seb128> jdub: when do we open breezy ?
<jdub> seb128: dunno :)
<seb128> jdub: people need the crack :)
<digale-tambien> I'm going to cry, gdm blocked that direcoty, and now I cant reinstalll gdm by this, 'cause gdm reinstallation needs to delete the files at /var/lib/gdm, and it cant :( jdub help me please
<Mithrandir> seb128: worked by accident, I guess.
* seb128 wants to upload evince 0.2.0
<digale-tambien> how can I unlock it? I don't want to reinstall hoary :/
<Mithrandir> seb128: what happens if you just remove the dnl from there?
<seb128> Mithrandir: but works for ages, that's quite rude to break now
<lamont-away> moo
<Mithrandir> seb128: the upstream version was ancient.
<seb128> Mithrandir: that works, but your force a lot of people to fix stuff
<jdub> digale-tambien: that question would be more appropriate in #ubuntu
<Mithrandir> seb128: sorry about that, if you can provide me with a pkg.m4 which fixes it, I can look at it.
<digale-tambien> :( when I do,as root, rm -rf /var/lib/gdm I get Permission Denied
<lamont> hrm... 3.4GB... /me needs more to put on this...
<digale-tambien> jdub, sorry, I know, but there I dint get support about it.
<seb128> Mithrandir: k, I'll have a look tomorrow, that's time to sleep for now
<seb128> thanks
<jdub> digale-tambien: please try again; it is not appropriate here
<Mithrandir> seb128: sure.
<digale-tambien> jdub mm Im bored of this, nobody wants to help me about it...
<Mithrandir> jdub: so nm might have all the crack I want?
<RastaMahata> zenwhen, The problem I was talking about gets fixed when I do this: "sudo /etc/init.d/dbus-1 restart"
<RastaMahata> just so people know :)
<RastaMahata> or it gets fixed soon! :D Good luck!
<zenwhen> do you have to run this command on each boot?
<RastaMahata> I dont know that yet, I was going to reboot after I purge some old config files...
<jdub> Mithrandir: it provides the platform for your crack, yeah ;-)
<Mithrandir> jdub: yay. :)
<Burgundavia> digale-tambien, #ubuntu is for help
<digale-tambien> Burgundavia I know, there NOBODY helped me, thanks to remember me that.
<RastaMahata> zenwhen, ill reboot, come back here and hope I dont need to do this again
<digale-tambien> wtf, I don't wanna use debian :'(
<Mithrandir> hm, boo looks interesting
<maswan> Mithrandir: debian bo?
<digale-tambien> I like ubuntu, but its support... and I don't know why happens
<Mithrandir> maswan: http://boo.codehaus.org/
<maswan> Mithrandir: you guys going to base the next ubuntu release on bo? :)
<Mithrandir> maswan: :P
<AstralJava> digale-tambien: Okay to msg you? We could try and work this out and not bother #u-devel...
<digale-tambien> yep, please :)
<ogra> maswan, nope, rex
<maswan> ogra: rex is the one before?
<ogra> yop
* maswan is young enough in the debian enviroment to not have seen that
* ogra started with rex
<maswan> I might have skipped bo for this new and fancy hamm, but I was aware of it
* maswan looks at the numbers
* Mithrandir started with potato
<maswan> nope, 1.3, started with bo, might even have cds from cheapbyte around to prove it. :)
* jordi started with Bo
<jordi> a few months later hamm was released
<jordi> hmm, I seem to assume now that all Debian releases have taken 2 or 3 years
<ogra> heh
<jordi> at that time, we even had a release cycle :)
<maswan> the scary thing is that Gimp seems to have gotten a release cycle
<ogra> yeah
<jordi> heh, yes
* Flonne started with Potato. :(
<jordi> Flonne: that's quite some time ago already :)
<maswan> I remember the Gimp 1.2(?) release topic: "Gimp - We make Debian's release cycle seem fast."
<SuperQ> hehe
<jordi> heh
<SuperQ> Flonne: I was just talking about a Potato box I have to upgrade soon
<jordi> 1.2 took a while yeah
<jordi> SuperQ: I've given up on upgrading my potato box...
<SuperQ> jordi: well.. yea.. 
<jordi> basically because it's a 80386 :)
<SuperQ> jordi: it's getting "upgraded" to CentOS
<SuperQ> it's also geting all 900GB of disk replaced with a Fibre San
<ajmitch> hey jordi 
<jordi> ajmitch: hi andrew
<maswan> I remember speed-installing.. hmm.. probably slink, from floppies, me and another guy, one sitting ready to eject the floppy, the other ready to press enter. :)
<SuperQ> maswan: haha.. I think I did that back in the day with Bo
<jordi> ok, I know Ubuntu has had it since day one, but I'm pretty excited about Debian getting GNOME 2.10 rigt now
<jordi> this is so old news in Ubuntu...
<SuperQ> Bo was a huge step up from Slackware 96
<maswan> SuperQ: I used slackware around 96-97, before seeing The Light. :)
<SuperQ> aye
<SuperQ> me too
<maswan> SuperQ: for me it wasn't so bad, as a learning experience, since you had to do everytihng by hand
<jordi> you learned quite a lot with debian 1.3 anyway
<jordi> I remember when I first got my soundcard working.
<jordi> it was like a fscking miracle
<pvh> I just mentioned this a minute ago in #ubuntu, but it's probably better suited to here.
* jordi now looks at hotplug and alsa-base...
<jordi> and, well, PCI cards.
<jordi> we are spoiled.
<maswan> I was thinking of bootup process, having real _packages_, etc.
<ajmitch> jordi: going to UDU?
<pvh> In the past couple weeks I've lost the ability to launch programs from gnome panel.
<jordi> ajmitch: no way :(
<ajmitch> ah :(
<jordi> I can't take that week off at work, it's way too busy these days :/
<pvh> It tells me that it can't fork because it's out of memory.
<jordi> ajmitch: I was invited :|
<pvh> But I have no such problem when running from the command line.
<ajmitch> yeah, it would have been good to see you there
<jordi> one of my dreams is going to .au, missing this opportunity hurts.
<SuperQ> jordi: hehe.. you know.. I never had much trouble getting my SB-16 working
<jordi> SuperQ: which version of Debian?
<maswan> jordi: I feel kind of sorry for dumping a sarge/testing thingie on my sister, a couple of months before the warty release even. :)
<SuperQ> I had my SB-16 working with Slack
<SuperQ> jordi: I started with Slack in 94-95
<jordi> SuperQ: nod
<jordi> SuperQ: I can't remember what I found so tricky...
<SuperQ> jordi: dabbled with RedHat 4.x for alpha 
<jordi> I guess ISApnp wasn't on  the kernel even
<SuperQ> jordi: and finaly switched to Bo back in the day
<jordi> nod
<jordi> 1.3 or 1.3.1?
<SuperQ> I don't remember
<jordi> I think my bo cd was 1.3.1
<jordi> I have it around somewhere
<maswan> jordi: so was mine
<jordi> I love these conversations :)
<maswan> I seem to remember trying out rh-something (4?) and it lasting all of 45 minutes before I started rm -rf:ing /etc and so on out of pure frustration :)
<jordi> I remember the libc5->libc6 ugrade script. IIRC it was called "update.sh" and it was scary.
<maswan> I didn't really become involved in stuff until 99:ish though
<jordi> maswan: as in DD?
<SuperQ> the first incarnation of my main server (nerp.net) was RH (4? 5?) on a Jensen (DECpc 150) alpha architecture
<jordi> me neither
<SuperQ> man was that box cool
<SuperQ> 64 bit!
<SuperQ> back in 1997
<maswan> jordi: No, as a more clueful guy and starting around messing with acc.umu.se stuff, including the ftp mirror
<Flonne> I remember having that fail...
<jordi> maswan: *nod*
<jordi> I guess I started doing stuff late 98 and applied for DD in 99
<maswan> hmm.. we did have a computer association in high school before that though, and the fall of 97 or so I installed debian on machines with too small harddrives, think it was 386s with 20 megs
<maswan> I remember watching star extract the base and rm:ing "unnecessary" files so everything would fit. :)
<jordi> hehe
<maswan> and getting it wrong, rm:ing the file currently being extracted, making star die horribly and you had to do it all over again. :)
<jordi> I think I installed in December 1997
<jordi> maybe November.
<maswan> we had a server though, a sparcstation LX with 64 megs of ram. ;)
<maswan> I didn't become a DD until last month. :)
<jdub> 64! holy crap, that's huuuuuuge
<maswan> jdub: exactly. :)
<jordi> jdub: hey dude!
<SuperQ> lol
<maswan> it was much faster to telnet to it and run all the commands there, than doing them locally. :)
<jdub> once upon a time, 64MB RAM seemed limitless
<jordi> Tags added: wontfix
<SuperQ> now I work on machines where 64GB ram is not so big
<jordi> we still get bugs about gnome modules losing functionality
<jdub> jordi: heh
<jordi> maswan: hehe
<Flonne> 64 MB is still plenty. You just need to know how to manage it.
<maswan> heh. I also remember one of my first thingies I did at ACC, filling up a memory board with 48 1-meg 30-pin memory modules. :)
<ajmitch> I feel young now, around you people ;)
<Flonne> Heck, 8 is still enough for ome of my systems. :)
<SuperQ> % free -k
<SuperQ>              total       used       free     shared    buffers     cached
<SuperQ> Mem:     510707296  312700704  198006592          0        144  216268096
<SuperQ> -/+ buffers/cache:   96432464  414274832
<SuperQ> hahahahahahah
<maswan> I think that was ftp.acc.umu.se back then, waaay back in 98. :)
<jordi> jdub: when is the wedding?
<jordi> time flies.
<maswan> then we upgraded it to a dual supersparc at 50MHz and took on ftp.gnome.org. :)
<jordi> maswan: cool
<jordi> kids, this was the beginning of the Swedish Conspiracy.
<maswan> jordi: we've always had more bandwidth than server for that, today we ran out of server too. :)
<jordi> heh
<maswan> there is no swedish conspiracy
<maswan> of course, we seemed to hit bandwidth limits at about the same time, but that's juts an incentive for the networking guys to improve it. :)
<jordi> anyway, bediime here.
<dhonn> Is it possible to get the nvidia 1.0-6111 drivers in the repository, every version after that crashes with some LCD displays
<maswan> ah, indeed it is
<jordi> congrats all for the Hoary release, I still had not done that :)
<maswan> 'night jordi
* jordi will continue helping seb210 tomorrow...
<maswan> I wonder how big that bandwidth spike would have gone if we had had enough server and bandwidth to meet demand. :)
<jdub> jordi: 17th
<mdke> hi dudes. Is anyone else getting the gnome splash screen remaining on their desktop? Does anyone know how to resolve this problem?
<Burgundavia> jdub, what do you think about double clicking on cd/dvd icons on the desktop opening cdplayer/totem?
<dhonn> hey in gnome do you think some tools in Application->System Tools belong in System->Admistration?
<mdke> dhonn, maybe one of them
<ogra> dhonn, if we would think that we would have done it
<mdke> heh
<dhonn> of course
<mdke> add/remove programs maybe
<dhonn> its like applets vs applications too
<RastaMahata> zenwhen, nope, after a reboot i dont get to see my mounts in computer:///
<RastaMahata> sorry for the delay
<dhonn> it can get kind of confusing really
<RastaMahata> so everytime i get into X, i need to "sudo /etc/init.d/dbus-1 restart"
<dhonn> configuration editor can go
<ogra> dhonn, thats a tool to adjust your personal desktop settings, why should it be in the system menu ?
<mpt> dhonn: those two menus could be merged, really
<dhonn> its seams like a system related task, i mean its not normal to to use that editor
<mdke> gconf should be abolished full stop ;)
<dhonn> its like regedit
<mdke> but its in the right place in the menu
<ogra> dhonn, did you ever use regedit ?
<dhonn> yea i had to type it in Run
<ogra> dhonn, and did you use gconf-editor ?
<dhonn> yea
<mpt> Actually, now that I look at it, a large chunk of the "System Tools" should just be Nautilus menu items
<ogra> i dont think these are comparable at all
<mpt> "File Browser" should be replaced by an item in Nautilus's View menu
<mpt> Floppy Formatter replaced by an item in Nautilus's File menu
<mpt> Run as different user, ditto
<ogra> mpt, file browser is already in the context menu
<dhonn> mpt, they should be integrated
<mpt> ogra: Which isn't convenient if you already have the folder open :-)
<mpt> and if you don't have its parent open (which is, alas, more likely in Ubuntu than in other Gnome distributions)
<ogra> mpt, its just in the apps menu because there was a huge user request for a browsr like option to start nautilus
<zul> hey
<mpt> ogra: If browse mode was remembered for individual folders, like icons and list modes are, that wouldn't be necessary. Nautilus would just remember what you used last time.
<mpt> ... and "New Login" belongs in the same menu as Log Out
<ogra> mpt, i dont like or use browser mode... but i understand the demand that was there... and i think using two different menus for different targets is ok...
<dhonn> Nautilus -> View -> Browser Mode?
<ogra> the "new login" should be in the logout splash or a screensaver option....shouldnt be in any manu, but these options are not there yet
<mpt> ogra: I'd use browser mode more often if I could open a folder, see "oh, this is a folder with lots of subfolders in it, it'd be more convenient to browse it", and just choose View > as Browser.
<mpt> dhonn: right
<ogra> mpt, understood...and it would be a cool option indeed...
<mpt> Well, if you're willing+able to implement it, stick your patch on http://bugzilla.gnome.org/show_bug.cgi?id=170546 :-)
<ogra> mpt, lets see, i also want to add cursor theme selection to the mouse or theme properties, enhance the screensaver and have to care for hwdb before breezy.... but probably if some time is left :)
<ogra> nautilus is intersting code :)
<dhonn> how do you guys just jump right in?
<ogra> dhonn, look for annoyances and try to get them out of the way is my biggest motivation ;)
<zul> dhonn: you just do :)
<dhonn> i contributed 2-3 lines of code to this release
<dhonn> lol
<zul> dhonn: or you could start small and work you way up to be the next ogra 
<ogra> dhonn, good start :)
<zul> or you start to break stuff like i do
<ogra> oh, breaking stuff is essential !
<zul> especially kernel related
<dhonn> i play with the code alot
<mpt> ogra: enhance the screensaver how?
* mpt thinks cursor theme selection is crack, so he won't comment on that
<ogra> mpt, lets see, i'll have to talk to jdub in UdU, who will clearify some stuff with keithp afaik....
<dhonn> Heres an Idea i thought of this morning: I wanted to make an opengl enhanced live background
<schweeb> zul: sometimes breaking stuff is the only way to properly fix it :)
<jdub> ogra: you're coming?
<ogra> mpt, a "login as new user" option in the lock window for example
<ogra> jdub, YEAH :-D
<zul> schweeb: or to get people's attention
<jdub> ogra: rock! i didn't think you were
<ogra> jdub, waiting since 19 years to see your country :)
<tseng> hi
<mpt> ogra: Oh, right ... Yeah, there's lots about that window that needs changing :-)
<zul> hey tseng how is it going?
<ajmitch> ogra: bah, I've seen enough of .au already ;)
<tseng> zul: good thanks
<jdub> ogra: rad :-)
<ogra> mpt, ah, come on, i already changed a lot :)
<jdub> ogra: staying for longer than UDU?
<ogra> jdub, i fly with the other germans (dholbach etc) some days earlier....
<ajmitch> ogra: I hope you have a good time 
<mpt> ogra: You did? Were you the one who got rid of the "APPROVED" crack?
<ajmitch> plenty to see in sydney, I heard
<jdub> ogra: rad
<ogra> mpt, i was the one who introduced it ;) and got rid of it, yes :)
<ogra> jdub, yeah
<mpt> ogra: Good good ... Now get rid of the time display (or add the current weather alongside it), and get rid of the thermometer, and make the password field look like a real text field, and we'll be fine :-)
<mdke> there isn't a local initscript in debian/ubuntu is there?
<jdub> mpt: dude, chill out
<mpt> hmmm?
<mpt> I'm getting ahead of myself again, aren't I
<mpt> sorry
<jdub> just be grateful for what ogra's done
<mpt> I am
<schweeb> if you're so interested in changing things, learning to program and doing it yourself is a good start :)
<ogra> mpt, i already bugged jdub for fade in and out code.... :) i think he fears the featureitis ;) 
<ajmitch> ogra: fade-to-grey?
<mpt> schweeb: Yeah, I've never heard that argument before, thanks ;-)
<jdub> http://www.whiprush.org/2005/04/ubuntu_release__1.html
<ogra> ajmitch, i thought about black....until alpha belnding works right in xorg :)
<jdub> ^ whiprush has some cool photos of hoary upgrades and happy users
<ajmitch> ok
<mpt> ogra: Hmmm, fade in and fade out? I'd never thought of that, but that's a cool idea
<Burgundavia> jdub, did you see my question?
<schweeb> jdub: heh, I was there when he wrote that
<jdub> Burgundavia: no
<ajmitch> jdub: good photos
<schweeb> jdub: locally we're gettina  pretty good group of people using Ubuntu
<Burgundavia> jdub, wondered if it was a good idea for double clicking on the desktop icon of music cds/dvds should launch totem/gnome cd player instead of nautilus
<schweeb> too bad I can't make it to the release party that's right now @_@ (vehicle's in the shop)
<ogra> mpt, the nice thing is that he code is already there for the fading of the screensaver itself.... is just a matter of including  the right header and some lines of code... but lets wait how the gnoem screensaver project goes on
<mpt> Burgundavia: Or you could just remove the distinction between the two
* mpt ducks
<Burgundavia> mpt, I am thinking more dbclick to launch what ever is default for that type of media
<mpt> hmm, do DVDs contain files which it is useful to manage? I have no idea
<Burgundavia> some do
<Burgundavia> "enhanced" cds and dvds do
<jdub> Burgundavia: possibly, yeah - would be an interesting challenge handling mimetypes/g-v-m configuration, etc.
<Burgundavia> but they should be easy to catch
<jdub> Burgundavia: i think that's about the only reason why it doesn't do it already
<jdub> schweeb: man, whiprush's users have nothing on my users
<schweeb> lol
<jdub> http://perkypants.org/misc/happy-users-are-productive-users.jpg
<siimo> im waiting for the next devel repository ;)
<jdub> http://perkypants.org/misc/holy-usability-batman.jpg
<mpt> Burgundavia: Or maybe put a "Play" button in Nautilus's toolbar for CD/DVD windows
<Burgundavia> jdub, I feel sorry for the old man
<schweeb> jdub: rofl
<Burgundavia> mpt, too much crap
<Burgundavia> mpt, featuritis ala konq
<jdub> schweeb: even the pope can get ubuntu installed on a dell ;)
<schweeb> haha
<Burgundavia> just do what I want, do make me do it
<schweeb> jdub: h8 my Dell 8200
<jdub> Burgundavia: jump on #gnome-hackers and ask alex/campd about it, they ought to be able to tell you what's in the way
<Burgundavia> jdub, thanks
<cjb> jdub: Was that before or after dying?  :)
<jdub> Burgundavia: hrm, actually, mailing nautilus-list would probably be better
<schweeb> hopefully I get something that I can get suspend working on soon
<Burgundavia> jdub, ok
<schweeb> jdub: I hear most of you guys use X40's
<jdub> schweeb: ahem
<schweeb> heh, are you an exception?
<mpt> Burgundavia: We're coming from different directions, I guess. If the CD player is just a file manager window, rather than being an entirely separate UI, that looks to me like less featuritis, not more
<Burgundavia> mpt, true
<cjb> X40s are about as good as it gets, though there's the wireless minipci snafu.
<Burgundavia> mpt, I was looking at a quickhack to get it working
<Burgundavia> mpt, then you discuss the longterm changes in ui
<lamont> smurfix: you around?
<schweeb> cjb: what snafu would that be?
<jdub> mpt: dude, that is so nautilus 1.x and completely shite.
<mpt> Burgundavia: ain't that always the way :-)
<Burgundavia> mpt, sometimes sadly yes
<mpt> jdub: shite in what way?
<jdub> schweeb: there is a danegrously cult-like X40 "fan base" within canonical
<schweeb> cjb: I've heard the Intel 2200 card you can get in it works great
<mpt> jdub: I don't mean every single folder window should have View as Music ... now *that* was crack
<jdub> mpt: it was a failure -> file managers are great at managing files. end of story.
<schweeb> jdub: are you included?  I'm looking at X41's and Fujitsu P7k's right now
<cjb> schweeb: Oh, it does.  Just don't try to replace it, or to buy the laptop without one and then add it later.
<jdub> schweeb: no, my laptop is 7.5 times better than the X40.
<schweeb> cjb: some kind of proprietary minipci?
<schweeb> jdub: :) which laptop is that, then
* mpt wonders how he could get nautilus 1.x to see how bad it was
<jdub> schweeb: the X300 of course ;)
<schweeb> oh oh
<schweeb> haha
<ogra> heh
<schweeb> I just saw whip's X40 today... pretty nice
<cjb> schweeb: There's a BIOS lock; it only boots if the minipci card is one in its database.  And the database is tiny -- it doesn't even cover all the IBM cards.
<cjb> jdub: X300 represent!
<schweeb> cjb: o_O DAMN. that's pretty gay.
<cjb> (Now, if only I can work out how to get the ACPI even slightly working.)
<jdub> time to deliver a hoary mirror and ISO selection to a local installfest
<schweeb> er s/gay/not cool/
* schweeb tries not to offend anyone
<jdub> schweeb: yeah, thank you
<jdub> inappropriate
* jdub was a bit disappointed in arstechnica's #linux for that
<cjb> schweeb: http://www.srcf.ucam.org/~mjg59/thinkpad/ .
<jdub> www.angrydpl.com
<jdub> speaking of angry, HI mjg59!
<schweeb> jdub: yea, we're pretty brutal witih each other at times... most of the time it should be called #notlinux
<schweeb> jdub: haha, that site rules
<cjb> jdub: He's still out partying, I think.
<lamont> another ubuntu convert today
<cjb> We left him shouting at the manager in the restaurant Mark took everyone to.  It wasn't pretty.
<lamont> RH, SUSE, etc didn't even detect the disc controller.  I watched him do the install :-)
<ogra> lamont, only one ? 
<lamont> well, one very vocal one with his coworkers...
<ogra> :)
<lamont> and someone else who's taking it home to play with (wife is south african....)
<mdke> i am interested in the decision to make update-notifier difficult to stop. was there a discussion on this that I can read up on?
<schweeb> cjb: at least there's code (which although dangerous) makes you able to use other cards... at least there's a possibility for the uninformed to have a working minipci card... thanks for warning me though :)
<schweeb> maybe I'll get the p7k after all
<mdke> lol
<lamont> hrm... live i386 boot disk that supports ppc netinst... that sounds sick enough to do.
<ogra> night all
<tritium> schweeb, you're having trouble with your Dell 8200 not suspending?
<schweeb> tritium: it'll suspend, but not resume... blank screen on bootup... I've had it working before, just not on Ubuntu
<tritium> schweeb, I got my Dell C840 working after disable POST_VIDEO, and using NvAGP rather than agpgary (which requires blacklisting intel_agp).  You might try that.
<cjb> schweeb: Can you ssh in?  (ie. is it just the video card not resuming?)
<tritium> s/agpgary/agpgart
<cjb> 'cause one thing to do is lspci -v -v -v both before suspending and after, which tells you the PCI state, and you can setpci back to the before after suspending to get the display back (and bind a function key to it or something, assuming you can't hook it to the lid open event.)
<schweeb> cjb: I believe I could... it's been a while since I tried
<schweeb> tritium: I'll have to try that sometime again soon
<tritium> schweeb, cool - good luck.  Let me know.  I'm sure I'll see you around :)
<schweeb> of course
* schweeb points to #u-motu :)
<tritium> :)
<cjb> But, yeah, not having the display hardware wake up is really common 'cause it's usually handled by the Windows display driver code, and not in ACPI at all.
<dhonn> does ubuntu use prelink?  applications start faster
<crimsun> dhonn: afaik, no prelinking but -O1
<jdub> dhonn: we don't, and don't want to -> read the archives for discussion about it and a link to a document by ulrich drepper that describes why we don't
<jdub> crimsun: "linker hash table optimisation"
<crimsun> jdub: right
<lamont> crimsun: some things are ld -O1, but not by default
<crimsun> gotcha
<dhonn> i come from the rh world lol
<jdub> lamont: --as-needed and -Wl,-O1 by default for breezy? :)
<jdub> -Wl,--as-needed
<dhonn> thanks
<lamont> jdub: prove to me it doesn't break things, and we'll talk
<lamont> jdub: that is, get jbailey and doko to add that to their testing before breezy opens
<jdub> rad
<jdub> and also commentary from keybuk
* lamont gets dragged out the door to dinner
<Duluu> thanks for Hoary
<Duluu> what optimization option do you use? any suggestions?
<schweeb> wow, that question gets asked more and more often
<schweeb> Duluu: check the mailing lists... I'm pretty sure it's discussed in detail on there
<sladen> Duluu: analyzling the problem
<Duluu> in devel list I can't find discussion about compiler optimizations
<Duluu> please give me some advice on it
<dhonn> I noticed that the kernel config file shows its optimized for size.  does that help the kernel in terms of speed?
<cjb> dhonn: My advice, FWIW, is to stop worrying about compiler optimisations.  :)  They're often a, uh, chimera.
<Duluu> i mean not only kernel, but other applications. optimizations like -march=pentium4 -O2 or something else
<jdub_> d'oh
<dhonn> just wondering.  
<sladen> dhonn: yes, it makes the kernel run 0.000001% faster because more of the code stays in cache
<sladen> -march=ricer -OALLOYWHEELS -fgo-faster-strips
<schweeb> lol
<schweeb> the wonderful things Gentoo has done to the linux community :)
<daniels> mooch: abcde is utterly, utterly, amazing fantastic.  thankyou.
<daniels> s/amazing/&ly/
<tseng> mooch: its better than good, its great.
<sladen> s/$/\!\!\!/g
* jdub_ hugs sound-juicer
<tseng> sound-juicer cant make flac + mp3 in one pass
<tseng> or normalize afaik
<tseng> abcde can do *anything*
<tseng> it does my laundry
<SuperQ> haha
<SuperQ> is there any good one that runs as a daemon
<SuperQ> is/are
<tseng> any encoder/ripper frontends?
<SuperQ> yea
<SuperQ> something I can just attach to a drive for a dedicated rip/encode machine
<tseng> im at a loss as to why they would be a daemon
<SuperQ> well, maybe at worse a screen session
<tseng> but i guess you could wrap abcde in a clever cron
<jdub_> tseng: g-v-m script on audio cd insert ;)
<tseng> ive had gnome-volume-manager open rxvt with 
<tseng> yeah dude
<tseng> he beat me.
<jdub_> haha
<jdub_> sitting on my wavelength!
<jdub_> hrm
* jdub_ does not enjoy xchat anymore
<tseng> irssi in screen on your linode, dude.
<jdubFest> i run it on the server at home
<jdubFest> but i managed to reset my wrt and not put crucial settings back in... port 22 forwards, for instance ;)
<tseng> mines on a linode, so it runs 50% "cooler"
<jdubFest> heh
<tseng> caker let me test a new host running xen btw
<jdubFest> oh, rad
<jdubFest> nice?
<tseng> it rocks.
<tseng> boots in a few seconds
<SuperQ> I'm trying to avoid X based solutions
<tseng> X?
<SuperQ> right now, I use a Xvnc server with blackbox/grip
<tseng> oh that thing still
<SuperQ> it works great for the most part
<SuperQ> i just wrote a little startup script to load the vncserver, and start grip up
<SuperQ> grip auto-rips on insert, and auto-ejects on complete
<SuperQ> does all the cddb taging, and even has a post-rip script to poke the slimserver to re-scan 
<daniels> abcde has fantastic handling of cddb and multi-artist compliations, in particular
<tseng> i like encoding multiple formats at once
<SuperQ> that'd be handy
<SuperQ> I am doing all FLAC these days
<tseng> i do flac and mp3
<tseng> as ipod doesnt take flac.
<SuperQ> yea
<SuperQ> I recode my FLACs to ogg 64k to store on my cell phone
<tseng> ew
<SuperQ> well.. i've only got a gig of storage
<SuperQ> and it's usualy for bus riding, so there is a lot of outside noise
<SuperQ> for my home stereo, it's all FLAC to SPIDF to my stereo
<diego> poor synaptic...so ignored now :P
<blueyed> Would it be possible to automatically install aspell packages for the installed locale(s) during installation?
<lamont> heh... maswan's mirror isn't so slammed any more.
<calc> not bad nearly 4000 downloads via bt
<Pizbit> lamont: Grabbing extra packages is also faster than dialup now too!:)
<calc> hmm actually its roughly 14000 downloads
<calc> i misread the bt page
<WebWiz> oi all
<WebWiz> When will package updates for the "next" ubuntu after warty start?
<lamont> Pizbit: yeah
<Pizbit> WebWiz: What's the hurry?:)
<lamont> WebWiz: breezy should open within a week or 3, I expect
<WebWiz> all breezy... cool
<lamont> then there will be the normal chaos as we deal with all the merges that creates.
<WebWiz> all = ahh
<daniels> WebWiz: most of the developers are taking the weekend off and investigating this 'sleep' concept
<WebWiz> yeah i hear ya
<WebWiz> they all did an amazing job
<lamont> daniels: "you can sleep when you're dead".
<daniels> lamont: got about 7h last night; luxury!
<lamont> daniels: yeah.
<WebWiz> so sources.list will need "breezy" at some point to start getting the latest updates
<schweeb> WebWiz: only if you want to run the development branch
<lamont> daniels: I had fun today - went to "help" someone install an amd64 box that FC3 and suse hadn't seen any disks in (new scsi controller, etc).
<WebWiz> exactly
<WebWiz> which i will be contributing to the next one, so yeah
<lamont> so I let him do the install while I watched.
<lamont> he has been assimilated
* lamont boots his evil-dvd
<WebWiz> is there a reason why they chose to make a new dev branch every release? instead of making the dev branch always called a certain name? like (mandrake cooker)
<lamont> or debian sid?
<WebWiz> right
<lamont> I think it's because the dev branch is largely "debian sid", cleaned up.
<lamont> and you have to name it sometime...
<WebWiz> does universe work the same way?
<WebWiz> a 'new' universe is created for dev branch 
<lamont> hoary will get cloned into breezy, and then uploads happen to breezy.  (and syncs of debian/whatever sources)
<lamont> hrm... DVD doesn't boot in a CD ROM. :-(
<WebWiz> cool thanks :)
<soopurman> how can i get a /dev/sd? node for the firewire harddrive i just connected, so i can mount it ?
<schweeb> soopurman: this is probably a #ubuntu question
<schweeb> I'll hint that you'll probably wanna check dmesg, it usually tells you what device it registered itself as
<soopurman> thanks
<soopurman> sorry to bother
<schweeb> and it should probably automount in GNOME on Ubuntu
<soopurman> see, thing is it *did*  and then i did a manual "sudo umount /mnt/point" (to format the raw partition) and now when i unplug and then plug it back in, it doesnt auto-mount any more
<soopurman> even if it didnt auto mount, i at least just need the block device under /dev
<daniels> lamont: heh
<schweeb> udev handles device nodes... you probably screwed up the partition or something
<schweeb> it should under most circumstances see the partitions and create the proper nodes for it
<lamont> milli: you around?
<milli> ya
<milli> lamont: ya
<bluefoxicy> damn.  All records of whichever wiki held candidates for universe for hoary are gone?
<crimsun> package candidates or maintainer candidates?
<bluefoxicy> crimsun:  I noticed I can install gnomebaker now
<bluefoxicy> I just wanna know what else made it
<bluefoxicy> as I couldn't about a month ago
<bluefoxicy> the wikipage it was on used to be in the topic either here or in #ubuntu so I popped in here
<bluefoxicy> but it's time that I sleep, so goodnight.
<Burgundavia> can I get some feedback on a brochure I am working on?
<Burgundavia> http://img106.exs.cx/my.php?loc=img106&image=ubuntubrochure4uz.png
<robitaille> Burgundavia,  not sure I like the font of the "about: ubuntu" at the top...it seems a bit squezzed on my screen
<Burgundavia> ok
<Burgundavia> I was playing in inkscape
<SuperLag> tseng: ping
<Burgundavia> robitaille, what do you think of it generally?
<robitaille> Burgundavia,  it's nice
<robitaille> Burgundavia,   very sunny colours :)
<Burgundavia> it is advertising
<Burgundavia> robitaille, any other things you would suggest?
<robitaille> Burgundavia,  I would move the "Hoary Hedgehog" line a little bit to the left to see the corner of the "square"
<Burgundavia> hmm
<Burgundavia> I actually split the rect at the corners
<Burgundavia> and then moved them
<robitaille> Burgundavia,  I don't know...just personal preference really.  It's a pretty minor since it looks pretty good
<Burgundavia> ok
<Burgundavia> little things make the difference between good and great
<toresbe> Burgundavia: sort of nice, but the fonts are way too squished
<toresbe> uh, s/sort of//
<Burgundavia> ok
<Burgundavia> changed that
<toresbe> great 
<toresbe> Can I have the source? I'd love to play around with inkscape now that I have a box snappy enough for graphics (woo!)
<Burgundavia> I plan to dual license under CC by SA 2.0 and GFDL
<Burgundavia> it will be part of the doc team stuff
<toresbe> hah, now I know what non-nerds feel like in front of nerds
<toresbe> I'm a license noob, what did you just say? :)
<Burgundavia> rofl
<Burgundavia> GFDL is the Gnu Free Documentation License
<Burgundavia> is not really that great
<Burgundavia> CC by SA 2.0 is the Creative Commons Share Alike Attribution License 2.0
<Burgundavia> the both say the same thing at the end of hte day
<Burgundavia> you can use this, as long as you release under the same license as you got it
<Burgundavia> ala GPL
<toresbe> ah, okay
<Burgundavia> toresbe, msg me your email
<Lathiat> maswan: mm at 22:00 i think it might have topped you out again :)
<toresbe> crimsun: ping
<Burgundavia> any #ubuntu chan ops here?
<mooch> daniels, tseng: heh, thanks, man... ;)
<mooch> s/man/men/
<dholbach> morning
<Lathiat> afternoon
<jdub> morning dholbach 
<jdub> dholbach: read whiprush's blog :)
<ajmitch> hi dholbach :)
<dholbach> jdub: hey! its not on our planet, is it?
<jdub> no, whiprush is not a member yet
<dholbach> i think he is?
<dholbach> hrm, but not sure
<dholbach> so where IS his blog?
<ajmitch> heh, nice blog post
<ajmitch> www.whiprush.org
<dholbach> thanks :-)
<dholbach> HAHHHAHA
<ajmitch> dholbach: you didn't quite get to 400, right? :)
<dholbach> 300
<ajmitch> impressive
<dholbach> "i'm no dholbach" ... wish i could say that sometimes
<dholbach> and somebody else would finish my thesis ;-)
<jdub> ha ha :)
<dholbach> but this is really funny, thanks jdub for telling me :-)
<jdub> thousands of kilometres away, people are still singing your praises ;)
<dholbach> jdub: the lot at marks house is STILL on the loose?
<jdub> heh, i hope not ;)
<dholbach> what really amazed me are the mails to the apt-get.org maintainers - i ONLY got positive reactions and some are thrilled to hear about joining the MOTU forces
<jdub> awesome
<dholbach> although i didnt send off the mail to joeyh yet :-)
<jdub> i'm sure they're thrilled at the opportunity to contribute to something officially
<dholbach> yes... exactly
<jdub> IN THE TEAM!
* Pizbit hands jdub an A-
* Pizbit hopes jdub 'gets it'
<mooch> jdub: how was the party yesterday?
<jdub> mooch: i'm in sydney :)
<mooch> jdub: so? no party there? ;)
<jdub> we had an installfest today
<jdub> but no party 
<jdub> way too tired :)
<dholbach> whiprush: tell metallikop and the others "thanks" from me - it was really funny :-)
<mooch> jdub: i was thinking about getting a domain for my musical career, and thought about jesusdub.something, but then i remembered your nickname and sounds way too similar...
<mooch> jdub: i went yesterday to celebrate that the university in Helsinki is lending the conference center for debconf for free, and went to a dance party... which turned out to be a gothic party
<mooch> puah!
<dholbach> a pity pitti isnt here... i'm sure our security man could hack my dad's hacked server back :-/
* dholbach comforts mooch 
<pitti> Hi
<dholbach> hey pitti
<sivang> good morning post hoary ubutntu development channel :-)
<dholbach> hey sivang  :-)
<sivang> dholbach: hi daniel, what's up? still rushing work?
<dholbach> no... was just about to go to the flea market :-)
<dholbach> sivang: how are you?
<sivang> dholbach: pretty good, you?
<dholbach> sivang: fine thanks :-)
<dholbach> sivang: i guess murphy needs her walk, so i'm out for now
<dholbach> see you later!
<sivang> dholbach: laters
<toresbe> crap! the fleemarket!
<toresbe> Shit! I forgot about that! crap!
* toresbe takes all the money he has and runs out looking for cool stuffs
<jdub> yo
<jdub> anyone here use ndiswrapper?
<daniels> not any more
<jdub> do you have the card?
<daniels> sure do
<daniels> (unfortunately)
<jdub> when was the last time you tried it?
<daniels> about two months ago?  the card turned out to be horrifically shit and bascially stopped anything associating to the network when I used it
<jdub> heh
<daniels> so I stopped using it, and now my desktop just routes via my laptop
<jdub> can you give it a whirl again?
<daniels> sure.  it's an acx111 (free drivers are just as bad as ndiswrapper).
<jdub> styx is trying some assmonkey linksys card
<jdub> and it's not working
<jdub> can't set essid
<daniels> but if it doesn't associate, I dunno whether that's hardware being fucked or ... ah, hold on
<Lathiat> a mate of mine has an acx111, didn't want to work so well.
<daniels> try sudo iwconfig wlan0 key off
<daniels> then setting the essid
<daniels> sometimes, you need to set either 'key off' or a nickname before it will let you associate
<daniels> don't forget ifconfig foo0 up, too
<jdub> hrm
<jdub> wlan0     IEEE 802.11g  ESSID:off/any  Nickname:"pants"
<jdub> ^ ncan never get essid out of off/any
<jdub> nup
<jdub> no love at all
<daniels> not with key off, or key open?
<daniels> and is the interface up?
<jdub> no, can't set that at all
<daniels> can't set key off?
<jdub> $ sudo iwconfig wlan0 key off
<jdub> Error for wireless request "Set Encode" (8B2A) :
<jdub>     SET failed on device wlan0 ; Invalid argument.
<jdub> 
<jdub> interface is up
<daniels> bongtasmic
<jdub> that's exactly what i was thinking!
<jdub> assmonkeycard!
<daniels> no idea, sorry; let me throw the pci card in
<jdub> oh, don't bother then
<jdub> someone else will have a cardbus thingy to try
<daniels> ahr
<jdub> i'm basically worried that we h0rked ndiswrapper
<jdub> 'cos i'm SURE i had this card working on my laptop
<jdub> doesn't work on mine or styx's
<kent> I compiled a -xine version of rhythmbox (to be able to play radiostations with realaudio) and when i was done, the deb-packet is recogniced as older than the one in the ubuntu-archives, even though they seem to have the same version-number. What can I do to change that? I downloaded the source with apt-get source and built it with dpkg-buildpackage
<Burgundavia> not being a packager, you might try a conflict in the debian control
<jordi> kent: edit debian/changelog and bump the version number in the first line.
<jsgotangco> jdub u there?
<jdub> yo
<jsgotangco> ill pm you instead
<jdub> ok!
<kent> jordi, thanks. I saw that one my self a minute ago :)  Now the only problem is that it seems to not want to play mp3's, but I think i can manage that one my self. It compiles against xine now and atleast I can listen to radiostations. The swedish national radio-stations use realaudio, and rhythmbox with gstreamer cant handle that :(
<jordi> kent: np
<daniels> specific 0.23 alpha out; has gnome 2.10, gcc3.3 and kerberos.  http://www.specifix.com/blogs/index.php?blog=5&m=20050408
* jdub grabs his chest
<jdub> ARGH!
<jdub> AAAAARGH!
<jordi>   * debian/patches/04_bookmarks_menu.patch:
<jordi>     - removed the bookmarks menu entry.
<jdub> I'M HAVING A CONARY!
<jordi> hmm, this patch is going our package
<jordi> err, wrong channel
<Burgundavia> I never understood the purpose of listing all your updates apps in one big list
<kent> jordi, strange. It seems that when i did as you said, dpkg-buildpackage fails when applying patches. Is that expected?
<jordi> hmm. it shouldn't
<azeem_> CDBS tries to apply stuff again because it doesn't keep track I guess
<kent> jordi, To be sure its not my fault, i downloaded the source agin and will only do change changelog in debian/ and add the option to compile against xine in rules.
<jordi> nod
<kent> yes box! It compiles. 
<kent> jordi, rhythmbox with xine is buggy, :(  I could not import mp3s without making it crash :( I guess i understand why there aren't a rhythmbox-xine package in the archives ;)
<tseng> or because gstreamer works well enough for audio, and is freely distributable
<tseng> or at least the core is.
<kent> tseng, but it cant play realaudio radiostations-  If only there was an easy way to get a plugin for that for gstreamer :(
<tseng> the only thing i know that plays realaudio is .. realaudio
<tseng> and w32codecs
<tseng> gst is supposed to support those someday, alledgedly
<kent> tseng, well, since totem-xine can play the radiostation with realaudio, my guess was that rhythmbox with xine (and the w32codecs) would also be able to do so. 
<tseng> quite possibly.
<kent> but if gstreamer was able to do it, i would rather use it. But it seems not doable right now. :(
<Burgundavia> tseng, you see this note about mono and debian?
* tseng thinks of helix player and laughs
<tseng> Burgundavia: which
<Burgundavia> tseng, http://www.meebey.net/jaws/index.php?gadget=Blog&action=SingleView&id=19
<tseng> Burgundavia: yes ive been talking to him on irc
<Burgundavia> tseng, figured as much
<tseng> Burgundavia: i sent him a bunch of un /usr/share/dotnet bindings
<tseng> for review also.
<tseng> Burgundavia: actually, if you look at the MonoDebianPlan, i sent him a package for most of the stuff still on the list
<tseng> gtk# 1+2, monodoc, gecko, gtksourceview#
<jdub> tseng: rock!
<tseng> jdub: breezy will rock the mono.
<jdub> so you reckon 1.1.x will be doable when breezy opens?
<jsgotangco> whoo
<tseng> jdub: if we want to take the first batch of testing stuff
<jdub> let's do it
<jdub> breezy is going to be so broken anyway during merge ;)
<tseng> sure why not
<tseng> cant be worse than it is now
<thoreauputic> are you guys aware that  http://www.ubuntulinux.org/support/documentation/faq has an empty FAQ now? Just thought I's mention...
<jdub> may as well blaze fun trails ;)
<thoreauputic> *I'd
<jsgotangco> hmm
<Lathiat> maswan: interesting, ftp mirrors have gone right up again?
<jsgotangco> let me check that maybe it still has a recyled page
<jsgotangco> but it probably is so old
<lesshaste> I agree with thoreauputic by the way :)
<jsgotangco> whoa its empty
<jsgotangco> i though it was wiki
<lesshaste> yep.
<thoreauputic> jsgotangco: Some people might think no one ever asks questions ;-)
<Pizbit> thoreauputic: We can but hope!
* Pizbit grins.
<thoreauputic> heheh :)
<jsgotangco> heh
<jsgotangco> i wonder who has access to site
<jsgotangco> the /support/marketplace/ also gives a 404
<jsgotangco> community front page has old css
<kent> Goshawk, If i remember correct, your the one who did usplash, the thing that might get into next ubuntu? I tried the new deb packets on your page.. and it actually works. Very nice!
<Goshawk> kent, what you have tried it very old
<Goshawk> we have already implemented the configuration file in xml
<Goshawk> ^__^
<Goshawk> you can change everything (image, colors, progressbars and so on)
<kent> Goshawk, well, there is a 0.1 in your homepage right? I tried that one. I get graphics, and a statusbar. Thats all I need :)
<trukulo> daniels, you there? just want to inform that ati igp 320m has 3d acceleration now, perhaps problem was related to readahead not installed, don't know for sure
<Goshawk> but we need ubuntu developers consensus to relase the 0.1 version that is ready
<Goshawk> kent, you tried the 0.1preview
<trukulo> but in last hoary upgrade (yesterday) suddenly 3d start to work here
<Goshawk> kent, thanks ^__^
<kent> Goshawk, yes.. thats the one. Id there a deb package for a newer version? 
<Goshawk> kent, i hope people in ubuntu will give consensus to use "usplash" term because my usplash works different as it is described in the wiki page of ubuntu
<Goshawk> kent, no there is not a package, we can't relase it until i have ubuntu consensus
<Goshawk> kent, ah! there is also a splash on the shutdown process :-)
<kent> Goshawk, ok.  I hope they will use it. Or something else that works as well. I have no issues with it. :) Well, a way to configure themes would be nice :)
<trukulo> Goshawk, i'd like to try it
<kent> Goshawk, realy? working in the preview or the  0.1?
<Goshawk> yes.. for the preview there was no problem, after the preview ubuntu developers said stop, and i stopped
<Goshawk> trukulo, you can try the 0.1preview at http://wiki.nanofreesoft.org/index.php/UsplashHowDoesItWork
<trukulo> Goshawk, thanks
<kent> Goshawk, though I had one problem with the version before this. If i removed it with dpkg then it seemed not to remove all files and bring me back to default pre-usplash (after remove i still got the graphics on boot). The version before didn't work, i got some scrambled graphics.. And since i could not remove it completly it was a bit frustrating. I have not tried to remove it now, but since it works and looks nice, i
<kent>  dont want to remove it.
<Goshawk> :-) 
<Goshawk> kent, good philosophy
<trukulo> hi baby
<mdke> hi
<mdke> oh sorry
<maswan> Lathiat: yes. I removed the redirect in the belief that it was a one-time spike that was over last night. I was wrong.
<Lathiat> maswan: haha
<ogra> OMG....
<ogra> morining
<trukulo> morning ogra
<dholbach> hey ogra 
* sladen wonders what where everyone crashed last night
* maswan puts the redirects back and hope to have a more responsive ftp cluster in an hour or two :)
<ogra> hwdb gets bombed with submissions.....
<Pizbit> ogra: How many so far?
<ogra> 7100
<ogra> but the normal daily rate the last 10 days was around 500
<ogra> currently there are already 860 for today....
<maswan> I'm getting rather good at spelling "graceful" blind these days. :)
<ogra> so i assume we end up around 1500/day
<ogra> dholbach, i see you  :-P
<dholbach> hm? me?
<dholbach> must be ... err... my neighbour :-)
<ogra> dholbach, yop.... digging in the db
<ogra> hehe
<ogra> dholbach, oh, and you just pointed me to another broken record, thanks :)
<kent> ogra, does the hwdb-system has any way of notice if its a duplicate of an already reported system? Like, i reported a day (or two..) before final Hoary. Would it be marked as a duplicate if i reported again today?
<Lathiat> kent: the second time you open the client it just gives you a link to your submission
<ogra> kent, it uses md5sums as record names, so just submit again, if you submit the same thing it will be overwritten, if it is new, its new ;)
<ogra> kent, you have to dlete ~/.hwdb to make a new submission, else you get pointed to your record
<sladen> ...and assuming the spec of the machine hasn't changed in the meantime
<kent> Lathiat, ogra, i just ran the client.  It works,  i get the last submission :) great!
<ogra> :)
<maswan> we have served about 5TB of ubuntu the last 24 hours now. :)
<dholbach> WOW
<mdke> cool
<maswan> probably about 6 since the release then
<AstralJava> maswan: That's awesome.
<maswan> I think us.releases have a similar track record, they pushed their gigE up to 800-something Mbit/s
<sladen> maswan: 5TB/day is about 550 Megabit
<Treenaks> Whatever happens, there needs to be an easy way to say "I want to mount these partitions on boot" in breezy
<sladen> so, that's a couple of Gbit of Ubuntu...  5% of LINX...
<ogra> Treenaks, write a gui to do so :-P
<Robot101> did they stop throttling the release server now? :)
<kent> maswan, is that data from ubuntus official archive or some mirror? It would be nice to see some statistic about this release compared to warty. (Some people are using hoary from pre-final so its probably hard to see.. but some ~data would be cool.
<AstralJava> Is there gonna be a new installer for Breezy?
<Treenaks> I'm getting the first hoary users in #ubuntu-nl, and they're breaking their systems with sudo -s and running kate from there
<Treenaks> ogra: oh I might
<Treenaks> ogra: HAL-based :)
<maswan> kent: that's se.releases.ubuntu.com, which is a mirror
<maswan> kent: but that one is also part of the releases.ubuntu.com RR dns name
<kent> maswan, swedish mirror? :)
<ogra> Treenaks, yeah, cool
<maswan> kent: It's listed on the download page as "Europe" :)
<jdub> maswan: can you differentiate between kubuntu and ubuntu?
<dholbach> jdub: can we get such a world map for ubuntu, herzi already has http://blaubeermuffin.de/deutschlandkarte/ - we !need! that for LoCo stuff :-)
<maswan> jdub: not until the xferstats stuff has run, and it hasn't yet
<jdub> dudes
<jdub> holy crap
<Lathiat> jdub: at?
<jdub> 515 people on #ubuntu
<daniels> 22:59 -!- Irssi: #ubuntu: Total of 516 nicks [1 ops, 0 halfops, 0 voices, 515 normal] 
<Lathiat> whats it usually at?
<dholbach> were 565 yesterday
<jdub> maybe 250
<jdub> but i haven't really been watching since last release
<Lathiat> nuts
<jdub> so it may have been steadily rising
<jdub> usually around 300ish i think
* Lathiat looks in his logs
<daniels> it was around 300 ~48-72h ago, IIRC
<jdub> dholbach: yes, oddly enough, that was why i originally did the gnome one
<jdub> dholbach: easier to do with the gnome wiki ;)
<apokryphos> Nah, it was usually in the higher 300s
<dholbach> yes! yes! yes!!! give us maps!
<AstralJava> jdub: It has been ca. 400 during the last two months I've occasionally stopped by.
<Lathiat> 179, 209, 88, 291, 302, 268, 258, 260, 290, 274
<daniels> dholbach: do you !need! it, or need! it?
<Lathiat> so, high 200s looking
<dholbach> daniels: need! to be exact ;-)
<Lathiat> march 31st = 436
<Lathiat> 394 on march 27th
<jdub> dholbach: hrm
<Lathiat> 356 on march 4
<jdub> dholbach: actually, now i've figured out how to get the source
<jdub> dholbach: i can do it now
<dholbach> jdub: that would completely rock!
<dholbach> jdub: we then need it on ubuntu-users@ and #ubuntu, to make sure we harvest everyone and know where we are ... people-wise :-)
<jdub> dholbach: yeah :)
<jdub> dholbach: and sounder, to get the loco teams to do it ;)
<dholbach> jdub: you can imagine the pain of having !2! people on a release party?
<dholbach> i know there are more happy ubuntu users around me
<mdke> lol
<jdub> heh
<kent> its more people on #ubuntu than #fedora. Atleast everytime i have been on #fedora during the last months.
<jdub> kent: yeah, i just joined/parted to check ;)
<dholbach> jdub: i need to know where i can give my MOTU recruitment talks :-)
* maswan waits impatiently for the crashed node to get back up
<ogra> dholbach, in #ubuntu-motu-recruitement, the little room with the single table and the lamp ;)
<dholbach> ogra: nah... that's boring :-)
<ogra> :)
<maswan> dholbach: so, flashing lights and interesting small pills instead? ;)
<ogra> maswan, we call this Techno Party
<dholbach> maswan: that doesn't sound like a "talk"ing atmosphere :-)
<maswan> dholbach: you got to break down their resistance first. ;)
<dholbach> maswan: but you're right, i should point out MOTU was about fun in the first place :_)
<mdke> wine and dine em
<ajmitch_> why would they want to resist? :)
<maswan> dholbach: then rebuild them as good motus the next day. :)
<ogra> maswan, first he has to process the queue
<dholbach> maswan: jdub already agreed with me on MOTU boot camps around the globe :-)
<maswan> dholbach: hehe. good work. :)
* ogra imagines the MOTU chain gangs
<dholbach> yeah, rock! :-)
<herzi> i'm sure dholbach would make a good drill instructor
<herzi> ;)
<ogra> yeah :) the best teacher we have around
<dholbach> herzi: fabbione would need to train me a bit :-)
<ogra> lol
<dholbach> herzi: he's good at larting people
<jdub> dholbach: 
<jdub> dholbach: dude
<jdub> https://www.ubuntulinux.org/wiki/UbuntuWorldWide
<jdub> pop your details on there
<jdub> i'll start uploading images :)
<ogra> YEAH
<Pizbit> Hrm, anyone else have a mouse that's incredibly sluggish at times?
* dholbach will now have a "I  jdub"-sticker everywhere
<maswan> Hmm.. This is the first reason I've had to do anything with the wiki. Unless someone else feels like taking mine/se.releases' coordinates. ;)
<dholbach> editing the wiki is hell, i hope the people will soon have ubuntu CDs :-)
<Treenaks> the wiki is SLOW
<dholbach> it's more a bandwidth issue
<maswan> I think part of it is that www.ubuntulinux.org is hit for the icons in the directory listings for all releases/etc downloads on the primary mirrors
<jdub> so moin image markup doesn't seem to work in zwiki
<Treenaks> it looks quite ugly, yes
* apokryphos agrees
<jdub> hrm
<jdub> that didn't work either
<jdub> ah ha ha
<jdub> oops
<Lathiat> whatd you break jdub :)
<jdub> i just didn't use the right url
<jdub> there we go
<Lathiat> so i hear where going to have videos on 3d spinning cubes :)
<jdub> lovely
<Treenaks> jdub: now again, but with markers :P
<Lathiat> haha
<zenwhen> hey zenrox 
<jdub> it was uploaded before yours were added
* jdub mails sounder
<dholbach> jdub: put me on the map! :-)
<jdub> doing an update now
<dholbach> woohoo!
* dholbach does the release dance ... again ... this time with jdub
<dholbach> :-)
<tseng> yay, im a floating head
* jdub glares at daniels 
<jdub> grr, comments appear in the src
<daniels> ahr, sorry
<jsgotangco> ooohhh nice stuff jdub
<jdub> daniels: it was bound to happen
<imka> hi
<dholbach> hey imka 
<imka> i can't make it into bugzilla. when i try to accept the certificate, firefox crashes
<dilinger> daniels: oh yea, had a quick question for you.  in xfree86-common's postinst in hoary's xorg, there's a bit that removes the init script if it exists (since the socket stuff is handled by xorg-common now).  however, it doesn't seem to get removed if there are symlinks; instead, it requests usage of '-f' for update-rc.d remove.  was this intentional, or was the -f just forgotten?
<jdub> daniels: sorted :)
<daniels> jdub: i've already fixed it, you muppet
<jdub> oh
<jdub> you are the muppet!
<dilinger> s/if there are symlinks/if there's an init script/
<jordi> muppet muppet muppet
<daniels> dilinger: forgotten
<imka> any ideas why firefox crashes when i try to accept the cerificate trying to access bugzilla?
<dilinger> daniels: ok.  want me to file a bug?
* jdub points #u-d at #ubuntu for a moment
<daniels> dilinger: yeah, sure
<tseng> jeez im the first guy in the W hemisphere
<jdub> daniels: haha
<tseng> map me!
<jdub> daniels: ok, so how do you delete a comment?
<dholbach> jdub: just edit the "source"
<daniels> jdub: i already have
<jdub> oh
<jdub> daniels: i added it again
<daniels> except you broke it :P
<jdub> dholbach: i guess that makes sense
<jdub> (STUPID!)
* maswan hopes he doesn't break it
<dholbach> jdub: don't beat yourself up:-)
<tseng> the next guy that edits it, fix my name please
<tseng> no space
<imka> i can't access bugzilla. could someone help me? firefox crashes when i try to accept the certificate
<maswan> damn.
<maswan> I broke it. :)
<jdub> tseng: done
<jdub> nope
* Lathiat bats maswan around
<jsgotangco> nice map everyoneis invited?
<jdub> someone else was editing
<dholbach> that editing conflicts drain all the love
<tseng> jsgotangco: i think its meant for "members", motus and canonical folks
* maswan goes and hides a while
<jdub> it's for everyone
<jsgotangco> understood
<tseng> its easy to pitch in and become a member :)
<Lathiat> just throw insults around at people, its contributing :)
<tseng> yeah dude
<tseng> lets vote on HG
<jsgotangco> ok you suck *grin*
<tseng> jsgotangco: < jdub> it's for everyone
* Robot101 ponders
<tseng> add away.
* maswan would like to see a map to see if he got the coordinate conversion right
<jdub> maswan: i'll run the script again now
<maswan> jdub: thanks
<maswan> I'm used to this format for coordinates:
<maswan> mw.mw LOC 63 48 37.000 N 20 20 17.000 E 50.00m 1m 30m 10m
<tsume_> have the other version for the next development branch been started yet?
<jdub> nup
<dholbach> tsume_: nope
<tsume_> dholbach: when should it be expexted to start?
<tsume_> *expected
<dholbach> 2 weeks or something
<dholbach> dunno myself
<Robot101> is there an intro to how the livecd is put together on the wiki?
<dholbach> Robot101: yes
<Robot101> and does the livecd have debs on it? I foolishly gave someone my release candidate install CD and then came home, so I don't have anything to rsync up
<dholbach> searching for "live cd" should be fine
<Robot101> my ADSL is choking on the torrent :)
<tseng> sweet, i own the whole US
<jdub> tseng: which city are you in?
<tseng> West Chester
<jdub> NY?
<Robot101> is the wiki slow, or me, or both? :)
<tseng> closest major city is Philly
<tseng> PA
<jdub> ahar
<jdub> 23:50 < SuperQ> OMG WTF LOL
<jdub> daniels: ^ one for you
<tseng> WTFBBQ
<Lathiat> omgwtfbbq lol hai2u asl
<Lathiat> !!!111eleventy-one111 :)
<Robot101> kthxbye
<Lathiat> Robot101: nono, its kthxbai :)
<Robot101> no its not
<Robot101> see mjg59
<maswan> heh. proof-by-mjg59
<Robot101> see mjg59's DPL nomination e-mail :P
<Lathiat> haha
<Lathiat> i'll have to go read
<Lathiat> someone got a url?
<jdub> www.angrydpl.com
<Pizbit> heh
<Lathiat> i saw that
<ogra_> geeez hwdb just got it 1000st submission in one day....(the average was 500)
<daniels> crazy :)
<jdub> ogra_: nice!
<ogra_> i'll be running out of diskspace soon..... already 1,5GB of data
<maswan> ogra_: your small computer about to run out of hardware? :)
* Lathiat throws his box of 500Mb hard drives at ogra_ 
<Robot101> jdub: that's not his nomination e-mail
<jdub> Robot101: IT'S GOOD ENOUGH
<Robot101> Lathiat: lists.debian.org/debian-vote last month or so
<ogra_> maswan, i have 9G for user data on this server....4,5 are donated to hwdb currently.... but at this rate it will be full next weekend
<Robot101> jdub: possibly counterproductive to the actual campaign though
<Lathiat> website is crawling :\
<Lathiat> didn't we get the bandwidth issue fixed yet?
<Lathiat> or is the server just choking?
<ogra_> maswan, but its still impressive that a dual pII233 and 128MB stays responsive like that under this heavy load....
<jdub> hrm
<jdub> do i stay up until 0500 to pick up thom
<jdub> or go to sleep and play alarm roulette?
<daniels> stay up
<daniels> go downstairs and grab a Sprite Recharge or four
<daniels> are you picking him up, or is he rocking around?
<jdub> i have two in the fridge
<jdub> well, he thinks he's rocking around
<sladen> Robot101: you could always update it.  it's a wiki-by-ftp
<jdub> but i am going to meet him at the airport
<Lathiat> you guys meeting up for some patying?
<jdub> i wasn't going to be in sydney
<jdub> thom's coming over a week early
<jdub> get some sydney weather to heal him up
<jdub> after ELMO THREW A SERVER AT HIM
<maswan> go elmo!
<ogra_> heh
<Lathiat> haha what did he do :)
<jdub> *HULK SMASH SQUISH*
* Lathiat wonders why registering for the ubuntu site gives him a 'login name' which is a 5 digit number then asks for my email on the site instea
<sladen> ''I this week on WWF Worldwide, Elmo...''
<jdub> we have someone from calcutta on the map already
<Lathiat> d
<maswan> ah. the log resolver thingie asn't finished yet. that's why we don't have detailed statistics yet
<ogra_> argh....its rising....: http://hwdb.ubuntu.com/nullswap.html
<Lathiat> i really think we should move to swapfiles
<Lathiat> and have it automatically create one
<ogra_> Lathiat, doesnt work with hibernate
<Lathiat> does with swsusp2 :)
<Lathiat> go the file writer!
<Lathiat> also works on swap in files too
<sladen> swsusp2 is a pile of !^%"
<Lathiat> sladen: why do you say that?
<ogra_> Lathiat, swsusp2 is *ouch*
<Lathiat> works fine here, far better than swsusp at any rate.
<Lathiat> any rate i care about anyway
<dholbach> bbl
<jdub> you're not running an ubuntu kernel?
<jdub> HERESY!
<Lathiat> everyone says taht but no ones ratified it to me yet :)
<Lathiat> jdub: i don't use it now anyway
<sladen> however, swapfiles should work with early-userspace
<Lathiat> i jut suspend to ram 
<Lathiat> *just
<Lathiat> i used to run it on my old 266 laptop
<Lathiat> best thing ever
* jdub made a commitment before warty came out to always use ubuntu kernels
<daniels> yeah
<ogra_> jdub, good choice :)
* Lathiat does as well now
<ogra_> jdub, and you always know who to blame *g*
<Lathiat> i tried making my own kernel to play with new inotify 
<Lathiat> and it was just too much pain :)
<jdub> 0.22 is out now
<jdub> and gamin patches
<Lathiat> im waiting for new breezy devel kernels :)
<jdub> hopefully they'll go into breezy soon enough
<Lathiat> ok thats definately a bug
<Lathiat> the login form on the site asks for your eamil
<Lathiat> *email
<sladen> when are the breezy queues opening?
<Lathiat> but it really wants the number you get in the email
<jdub> soonish
<ogra_> jdub, do you have an idea if we will have pythin-cairo in time for breezy ?
<jdub> when elmo stops throwing servers at people
<jdub> ogra_: hrm.
<ogra_> s/i/o
<Lathiat> jdub: what did he do :)
<jdub> ogra_: you're so the eyecandy hornbag. :)
<maswan> Lathiat: the email worked well too, at least for me
<ogra_> lol
<Lathiat> maswan: not for me
<Lathiat> not the first login at least
<elmo> jdub: dude, it was a rack door - I don't do things in half measures
* Lathiat laughs 
* Lathiat wonders where the edit page button is
<jdub> elmo: didn't want to risk the overendowed ipods?
<maswan> elmo: hey, did you get the bandwidth stuff fixed? at least we got another surge today. :)
<Lathiat> oh duh, righ tthere
<jdub> Lathiat: log in
<jdub> Lathiat: or just add a comment
<Robot101> sladen: how's the usplash coming?
<Lathiat> jdub: yeh did, just missed the edit button :)
<elmo> maswan: no :( still fighting with our ISP about it
<maswan> elmo: :/
<maswan> Oh, well. At least it seems less traffic than yesterday.
<tseng> elmo: can you look into adding me to keyring if you havent already?
<ogra> elmo, we'll need to talk next week about moving hwdb to a server with a HUGE disk, 1.6 G in 11 days.... and the submission rate rises fast :)
<elmo> tseng: are you Brandon?
<tseng> elmo: yes.
<elmo> ogra: eh, compressed?
<ogra> elmo, nope, unpacked....(transfer is bz2 compressed though)
<elmo> ogra: ok
<elmo> tseng: ok, will do - can you mail a reminder to keyring@ubuntu.com?
<tseng> elmo: sure
<bluefoxicy> tseng:  ndiswrapper doesn't go on amd64 does it
<tseng> bluefoxicy: i doubt it, but i really have no idea.
<bluefoxicy> (I have an amd64 laptop with a broadcom built in wireless)
<tseng> is it minipci?
<bluefoxicy> um, what?
<Lathiat> bluefoxicy: does it appear on lspci
<daniels> bluefoxicy: newer versions of ndiswrapper work on amd64
<bluefoxicy> tseng:  I checked a bunch of laptops in the store, they all show broadcoms btw
<sladen> Robot101: well, I wrote some better vesa mode detection code yesterday.  It might get used.
<bluefoxicy> i'll check lspci when the ubuntu install finishes
<bluefoxicy> but i believe it does.
<bluefoxicy> dand:  nice to know
<tseng> minipci cards are cheap and easy to replace
<sladen> unless they have the wrong PCI ID...
<tseng> i paid $40 for my intel
<bluefoxicy> disturbing though, the Internet reports that according to thousands of users, most laptops these days are using broadcom cards
<sladen> *cough*IBM*cough*HP*cough
<Lathiat> my ipw200 is nice
<Lathiat> ipw2200
<Lathiat> driver almost works well
<bluefoxicy> tseng:  it's probably sodered into the board though
<tseng> not if its minipci...
<Lathiat> bluefoxicy: nah, highly doubtful.
<tseng> it goes in alot like a DIMM
<Lathiat> the driver for ipw2200 sometimes needs reloading
* bluefoxicy  hasn't opened the thing to look
<tseng> latches down into its slot
<trukulo> daniels, just report that ati igp has now 3d capabilities
<zenwhen> the solution to all Linux wireless woes is the Orinoco Gold Classic
<Lathiat> and xset dpms force off occasionally crashes the module
<bluefoxicy> tseng:  cool.
<Lathiat> but its otherwise good
<daniels> trukulo: awesome :) good to hear
<sladen> bluefoxicy: yup, Broadcom brought out an all-in-one chip.  Much cheaper than the 3-piece Orinoco chipset.  All the OEM switched, virtually overnight
<bluefoxicy> tseng:  I know the nics that come on mobos are PCI though, but they're chips soldered onto the board.
<trukulo> daniels, if you want any info, tell me
<bluefoxicy> and graphics cards that are on-board tend to be the same wap
<bluefoxicy> way
<Lathiat> bluefoxicy: yeh but wireless cards are more often than not minipci
<bluefoxicy> tseng:  but I've never seen a minipci card
<bluefoxicy> so it's a moot point
<Lathiat> bluefoxicy: in fact, i've never seen a wireless card that was soldered on
<bluefoxicy> I can't replace something I can't find in the store.
<Lathiat> bluefoxicy: sure you can, you can buy minipci wireless cards
* bluefoxicy should take a look inside his laptop later.
<Lathiat> driverloader does amd64
<Lathiat> but its commercial
<Lathiat> bluefoxicy: most minipci cards you can get to by unscrewing a panel on the bottom of your laptop
<daniels> trukulo: sure, thanks
<bluefoxicy> yeah
<bluefoxicy> I noticed said panel
<bluefoxicy> never opened it.
<Lathiat> bluefoxicy: there will most likely also be ram under one of them
<bluefoxicy> "no user servicable parts inside" says the cover.
<Lathiat> i have 3
<bluefoxicy> I know, the ram is user servicible
<Lathiat> one for minipci, one for ram and one for my bluetooth card
<Lathiat> actually i lie
<Lathiat> bluetooth is in the same panel as my wireless
<bluefoxicy> <Eevee> is it legal to give yourself below minimum wage?
<crimsun> toresbe: pong
<bluefoxicy> Lathiat:  well, there needs to be a driver.
<bluefoxicy> gimme a second.
<Lathiat> bluefoxicy: apparently you need a 64bit version of the ndis driver
<Lathiat> so says some mailing lists
<Lathiat> no idea on the validity of that
<bluefoxicy> http://linux-bcom4301.sourceforge.net/
<bluefoxicy> Lathiat:  I know, but I have one.
<Lathiat> bluefoxicy: in that case, ndiswrapper > v1 works apparently
<bluefoxicy> or at least I think I do
<bluefoxicy> win64 I think I have. . .
<toresbe> crimsun: well that was well-timed
<toresbe> crimsun: I just came in the door 
<toresbe> crimsun: anyway
<toresbe> crimsun: I was wondering about the Universe
<bluefoxicy> Lathiat:  well I just installed 32 bit ubuntu on my amd64 laptop, is there an ndiswrapper package
<toresbe> uh, a package in the universe
<bluefoxicy> I know there's a utils package, but I haven't seen a driver
<crimsun> toresbe: ok, which?
<toresbe> crimsun: mplayer
<toresbe> crimsun: the standard vo is wrong
<Lathiat> ndiswrapper-source: 0.12+1.0rc2-1 0 500 http://au.archive.ubuntu.com hoary/universe Packages
<crimsun> toresbe: they're in multiverse iirc
<Lathiat> ndiswrapper-source - Source for the ndiswrapper linux kernel module
<toresbe> crimsun: really? Oh.
<ogra> toresbe, where does it point to ?
<ogra> toresbe, the default vo that is
<Lathiat> time for me to attempt to grok dbus
<crimsun> the default should probably be x11 if it isn't
<ogra> yep
<crimsun> (since not all drivers have adequate xv)
<ogra> yep again :)
<crimsun> if it's not, please file a bug in malone :)
<ogra> :)
<Lathiat> my poor dsl connection, mirroring main is a bit hard on it :)
<Lathiat> let alone universe.. hah
<daniels> jdub: you don't know if thom's still planning on coming down on thursday, do you?
<jdub> to melbourne? no ide
<jdub> a
<toresbe> ogra: x11
<ogra> toresbe, perfect
<toresbe> crimsun: it should be "xv,x11"
<daniels> jdub: ahr
<toresbe> so that it fall backs to x11 if xv fail
<toresbe> s
<daniels> er
<daniels> imo the default should be xv
<daniels> if your driver doesn't support xv, then xv initialisation will fail 
<daniels> and it will fall back to xorg
<crimsun> toresbe: file a bug in malone to change it to xv,x11
<daniels> if it silently fails and stuff goes wrong, then file a bug on xserver-xorg and make it my problem ;)
<toresbe> heh
<crimsun> toresbe: and we'll change it when Breezy opens
<Lathiat> daniels: can i do that with upstream bugs to get them fixed faster? :)
<Lathiat> daniels: do you know if theres a bug open about the colordepth issues on nv? i couldn't see one
<daniels> Lathiat: if they're in the radeon or i810 drivers, yes; i don't hack on the rest of them (barely have any time to hack on the first two, either)
<daniels> Lathiat: which colourdepth issues?
<daniels> (i.e, no)
<Lathiat> daniels: on nv, things like gradiets look like total ass (at least on my graphics card, i've seen other reports)
<Lathiat> it claims its in 24bit
<Lathiat> looks like its in 16 or something
<Lathiat> its all lined
<ogra> Lathiat, flatpanel ?
<Lathiat> ogra: ya
<ogra> switch to 16bit
<daniels> could just be a 6-bit panel
<Lathiat> daniels: what does that mean?
<Lathiat> it works in the binary drivers fine
<daniels> ogra: should 16-bit be the default for nv on laptops?
<Lathiat> so .. dunno what the difference is
<ogra> daniels, i think so
<daniels> Lathiat: well, some panels have 6 bits of colour information per channel
<ogra> most of them have 16bit panels
<Lathiat> and it defaulted to 24 here
<daniels> Lathiat: but they can dither to 16.2M, which is *almost* 8 bit per channel
<daniels> only that dithering looks like total arse
<daniels> ogra: ok, will put that one in -- thanks
<Lathiat> shoudl i try setting it to 16?
<ogra> Lathiat, yes :)
* Lathiat tries
<Lathiat> grr
<Lathiat> you can't startx from an xterm, not authorized
<Lathiat> thats stupid
<daniels> eer
<daniels> startx -- :1
<ogra> or xnest
<Pizbit> Or gdmflexiserver
<astharot> ciao
<ogra> yup
<mjg59> daniels: No, the X wrapper doesn't work from an xterm if it's set to console authentication
<daniels> or just sudo Xorg :1 vt8 -ac
<daniels> mjg59: oh yeah, good point
<Pizbit> Applications -> System Tools -> New Login :)
<bluefoxicy> when does breezy open
<Lathiat> aha!
<Lathiat> looks sweet now
<Lathiat> daniels: startx -- :1 is what i was doing
<Lathiat> daniels: so i should file a bug against xserver-xorg that it shoudl put 16bit colour in?
<daniels> Lathiat: you can if you want, but I've already done it
<Lathiat> oh and having an nvidia binary server going, opening an nv one, then switching back to the binary one makes my lcd go randomly spangy coloured fading in and out :)
<Lathiat> daniels: oh, just then?
<daniels> yeah, I'm not surprised that nvidia and nv don't play happily together
<Lathiat> vbe posting with the binary drivers is fun too, does the same thing :)
<daniels> Lathiat: yeah
<Lathiat> daniels: sweet.
<Lathiat> thats been annoying me for a long time
<Lathiat> maybe my video overlays will work now
<Lathiat> huzaah, they do
<Lathiat> ogra, daniels: thanks :)
<Lathiat> wish i'd mentioned this the other day before release :)
<Pizbit> Lathiat: Well, it's not like many people will be doing that.
<Lathiat> Pizbit: doing what, using the nv driver on an lcd? :)
<Pizbit> Having an nvidia sever and nv at the same time
<Lathiat> oh no, thats not the problem
<Lathiat> the problem is having the nv driver look like ass on lcds by default
<crimsun> nv looks pretty good at 1280x1024 on a dell 1901fp
<Lathiat> crimsun: at 24bit?
<crimsun> Lathiat: yep
<Lathiat> on my inspiron 8600 laptop, needs to be on 16 bit otherwise it looks crap
<ogra> acer aspire 1520 needs 16bit too
<zyga> hello
<zyga> what's the thing with bug listing on apt-get install
<Lathiat> sigh, this bug in libbonoboui si still pissing me off
<Lathiat> i need better bonoboui hacking foo
<jdub> zyga: apt-listbugs
<zyga> jdub: apt-get can exploit the fact that it's installed?
<jdub> yes
* zyga is impressed
<zyga> :)
<jsgotangco> goodnite everyone
<sladen> talking of replacing broken chip.  I've just managed to break the ethernet port on my laptop.  Greeeeeeeat
<jdub> night jsgotangco 
<jsgotangco> jdub: still going further eh
<jdub> nah, should be getting to bed really
<Lathiat> daniels: don't suppose if you knwo if the nv driver can do dual head or at least mirror?
<jdub> gotta be up in 3 hours or so ;)
<jsgotangco> ok night
<jsgotangco> hehe
<daniels> Lathiat: no idea, sorry
<daniels> jdub: nah man, alarm roulette never works
<Lathiat> daniels: doesn't seem to be any docs :\
<Lathiat> dan	is there more docs in the source tree than /usr/share/docs ?
<daniels> not really, other than the source
<daniels> the nv driver is woefully documented
<ogra> jdub, let daniels call you to wake you up
<jdub> ha ha
<Lathiat> daniels: like pretty much verything else? :)
<Lathiat> jdub: i'll call you and whinge about some bug you haven't fixed yet :)
* jdub quite likes the april calendar
<jdub> very different to the warty calendars
<jdub> you guys will have to wait for elmo to let it out of NEW ;)
<daniels> ogra: arsed if I'm going to be awake at 4
<ogra> heh
* Lathiat kicks elmo
<Lathiat> :)
<Lathiat> jdub: hoary-updates ?
<jdub> yep
<jdub> *not* warty-updates
<jdub> warty gets no calendar love
<jdub> not anymore
<jdub> END OF LOVE
<sladen> ah, I was expecting it to get pushed into both queues 
<jdub> not anymore
<sladen> could it be stuck in a separate 'calendar' archivea
<jdub> no
<jdub> no love for warty anymore
<jdub> end of love
<Lathiat> poor warty, unloved.
<Pizbit> Poor warty.
<Pizbit> Mean jdub :)
<sladen> deb .../warty main restricted universe pr0n
* Lathiat grins at sladen 
<Lathiat> mm flexmdns smokes a bit of crack
<mdke> is the website ok?
<mdke> i can't load the pages
<srbaker> anyone know where i can look at a web interface for arch?
<srbaker> ahh, viewarch
<bluefoxicy> I  think I found a problem in hoary
<bluefoxicy> when i close my laptop lid
<bluefoxicy> after reopening it there's a flashing _ thing, cursor
<cjb> You can try "HWCursor off" in Xorg.conf.
<bluefoxicy> if I hit alt+F7 to switch back to X I can enter my password to unlock it; but that's counterintuitive.
<bluefoxicy> cjb:  me messing with xorg.conf is counterintuitive, but what section should i put that in regardless
* bluefoxicy thought ubuntu was supposed to do everything obvious for him.
<cjb> Ubuntu can often not do everything obvious.  In this case, it's likely that your laptop's lid-open code is usually run by the Windows graphics driver.
<cjb> (And we don't know how your laptop's Windows graphics driver works.)
<bluefoxicy> well, regardless.  I'll submit a hardwareprofile thing from device manager, and maybe file a bug later
<cjb> Anyway. Option "HWCursor" "off" in the Device section.
<bluefoxicy> k
<Kamion> (I think it's *un*intuitive, not counterintuitive - counterintuitive suggests to me that you have to do something that intuition says should have the opposite effect)
<Pizbit> Or non-intuitive:)
<Pizbit> Or randomenglishprefix-intuitice-maybearanomdenglishsuffixehere
<Pizbit> With intuitive *
<bluefoxicy> Kamion:  pressing buttons :)  intuition says if I open my laptop lid, it'll still be on my graphical desktop, or suggesting how to get there (i.e. "please enter your password")
<bluefoxicy> I kinda sat there and stared, waiting for ubuntu to switch it back over
<bluefoxicy> before figuring out I had to do something
* Kamion watches the point fly past ;)
<Kamion> (I wasn't arguing with your comment about what should be done, merely with the choice of word)
<bluefoxicy> I know :)
<bluefoxicy> but that was where my choice of words came from :p
<HiddenWolf> Kamion, when is the big meeting where Breezy's goals will be set out?
<dholbach> HiddenWolf: wiki/UbuntuDownUnder
<HiddenWolf> dholbach, meanie, that isn't clickable! :P
<dholbach> HiddenWolf: http://wiki.ubuntu.com/UbuntuDownUnder
<ogra> hehe
<HiddenWolf> dholbach, that was a joke. :P
<dilinger> haha.  the camel link from james henstridge's blog is great.
<ogra> is somebody aware that ubuntu.com and ubuntulinux.org arent reachable ?
<tseng> havent there been isp issues all day?
<elmo> ogra: they're back
<dholbach> hey elmo
<ogra> yeah
* dholbach highfives elmo release-wise
<ogra> response...
<elmo> tseng: isp issues were to do with limiting, they've haven't dropped us off the net until now
<elmo> hey dholbach 
* ogra enables the css on hwdb again
<dholbach> elmo: i wrote all those guys and they were all positively impressed
<elmo> dholbach: cool
<dholbach> elmo: although i didnt write joeyh yet... *blush*
* ogra wonders waht ubuntu will do if all these debian guys come over and we have no upstream anymore....
<Treenaks> ogra: we'll switch to redhat
<ogra> lol
<ogra> then i'll leave :)
<Treenaks> ogra: rubuntu..
<ogra> heh
<tseng> roobios
<Treenaks> tseng: not "rooibos"? :)
<tseng> maybe
<zenwhen> if all these debian guys come over then wouldnt the need for an upstream go away?
<dholbach> there'll be a new distribution with name .... erm ... Quit'zla ... which is ... ancient Maya ... for ... Cocoa or something
<tseng> i meant the african "tea"
<dhonn> debuntu
<Treenaks> tseng: rooibos :)
<tseng> k
<Treenaks> tseng: ("red bush")
<Treenaks> http://en.wikipedia.org/wiki/Rooibos
<tseng> it has a clever "os" at the end
<tseng> i dont like to drink it in any case
<Treenaks> we should suggest this to sabdfl 8)
<dhonn> what do you guys think about the name mandriva lol
<ogra> heh
<tseng> i already made my comment on planet
<tseng> sortof.
<Treenaks> dhonn: sounds like a monkey
<tseng> like a klamaraffe
<dhonn> lol. half man half diva
<fgx> how do i verify what's my system charset?
<dhonn> minus the r
<bluefoxicy> what does anyone think of more complex menus
<bluefoxicy> for grub I mean
<Treenaks> bluefoxicy: more complex? as in submenus and sub-submenus?
<ogra> fgx, you type: locale
<bluefoxicy> Treenaks:  yes, as in a submenu for rescue kernels and a submenu for memtest
<dhonn> drop down lists of kernels?
<Treenaks> bluefoxicy: it's not as if it's a really long list anyway...
<bluefoxicy> it's not hard.  'configfile' as the command for a menu entry does it
<bluefoxicy> Treenaks:  yeah, but the list now is like Kernel-1,Kernel-1(rescue),Kernel-2,Kernel-2(rescue),memtest
<bluefoxicy> if you have more than 1 kernel it's visibly ugly :)
<Treenaks> bluefoxicy: maybe sort order could be changed... but not a submenu
<ogra> bluefoxicy, where i the piont if you only have one kernel installed ?
<bluefoxicy> ogra:  no point
<tseng> for most poeople it doesnt even show a menu
<dhonn> i use hiddenmenu
<bluefoxicy> tseng:  Unless you hit escape
<ogra> yup
<tseng> at which point
<bluefoxicy> I know, I'm just saying
<Lathiat> bluefoxicy: and if a kernel upgrade breaks, then you don't have one to fall back on :)
<tseng> who cares?
<bluefoxicy> Thought it'd make a nice update-grub config option, but I guess nobody cares :)
* bluefoxicy goes to install ROS 0.2.5 for the hell of it.
<fgx> ogra, thx. it says en_US. is the utf-8 one? (im running hoary)
<ogra>  does it say en_US.UTF-8 or only en_US ?
<dholbach> i'm off - have a nice evening
<fgx> ogra, only en_US. strange. i think it should be en_US.UTF-8 in hoary
<ogra> hmm, i never tried a en_ locale here....only C and de_ ....but my de_DE says UTF-8
<fgx> ogra, locale -a says en_US.UTF-8 available. now i switch. oh now i see im in the wrong channel. apologize
<ogra> fgx, would have been my job to point that out ;) dont aplogize :)
<ogra> hmm, i think i should pull a local copy of the css for hwdb....seems slashdotted again....
<bob2> archive.u.c still seems unreachable for me
<ogra> bob2, slashdot.....
<bob2> like, completely unreachable
<Lathiat> yeh it is
<zenrox> we got /.ed
<zenwhen> is anything going to be done to support this new userload or are we going to hope they "go away"?
<Lathiat> zenwhen: it will calm down as the release hype gets over
<ogra> zenwhen, we'll hunt them until they're gone, yes
<Lathiat> zenwh	unfortunatey due to an error with ubuntus ISP, they have a large bottleneck on the traffic
<ogra> :-P
<Lathiat> which has yet to be sorted
<zenwhen> I think it would be a shame to lose so many users because there just wasnt an infrastructure in place to handle them
<zenwhen> I think there will be a lot of "ubuntu's repos are unstable" people floating around after this. 
<ogra> zenwhen, it will get fixed....
<zenwhen> Well it just seems that afterthe kubuntu announcement something would have gotten done to prepare for this. Its really none of my business and I have no solution but it seems like these two opportunities have been marred by the lack of extra bandwidth for these eager slashdotters.
<Lathiat> zenwhen: unfortunately there is nothign they can do about it
<Lathiat> (they are waiting at the hands of their ISP)
<Lathiat> so mark tells me anway
* zenrox slaps ubuntu's isp with a used winme disk
<bob2> zenwhen: dude, there's a billion mirrors they can use
<zenwhen> Are these mirrors linked in an easy to reach spot?
<Lathiat> bob2: the argument is still valid as synaptic does not use them or offe ran option for them
<bob2> zenwhen: yes
<bob2> wiki.ubuntu.com/Archive
<zenwhen> if they arent available as a link on the front page or as an option in synaptic, people will not use them
<zenwhen> and everyone will suffer
<Lathiat> that could possible be an item for breezy
<bob2> no, not everyone
<Lathiat> to put mirror support in synaptic
<Lathiat> "Pick a country..."
<bob2> just the people who don't know to use the mirror
<Lathiat> the installer sets the archives to my country
<Lathiat> but synaptic blows them away back to archive.ubuntu.com when you change them
<Lathiat> maswan: heh i see your ftp cluster is a little happier again now you put the redirect back :)
<Lathiat> i'd hate to put my hands anywhere near the disks of that thing :)
<zyga> hmm
<zenwhen> bob2, the site you linked is currently down along with the main repos. Where do you suggest the users get this information? I was simply pointing to an issue. You have every right to ignore it or pretend it doesnt exist.
<bob2> ok, thanks!
<Lathiat> hopefully the main site is down for the 15 minute window the isp needed to reconfigure them to have an extra 500mbit/s or so of bandwidth :)
<maswan> Lathiat: yeah, not as much load today as yesterdya, but still a bit more than the ~70M/s that the ftp cluster coudl deliver
<elmo> zenwhen: it's been down twice, for approx 20 mins each time.  down in the sense of, it broke at the tier-1 ISP level.  that's not something that could have been anticipated or "prepared for".  everything we can possibly do about it, is already being done
<zenwhen> oh alright
<maswan> elmo: you could throw more of your load over this way. ;)
<elmo> it's not being /. or otherwise overloading - it's BREAKING.
<maswan> ok
<dhonn> i have an odd problem with the volume control.  Aparently my volume settings are not saved after a reboot
<maswan> just figured it might be load-triggered breaking, but you
<maswan> 'd know much better. :)
<maswan> (the one thing I haven't gotten used to on this keyboard, hitting ' without hitting enter)
<bluefoxicy> did I miss something
<Kamion> mdz: could you have a look at colin.watson@canonical.com--2005/debzilla--fv3--0?
<Kamion> mdz: it copes with some changes I made today (though I haven't activated those changes yet, and this patch should work both before and after activation)
<srbaker> anyone know the place that shows the current status of eclipse packages?
<srbaker> i lost the link i had
<Kamion> mdz: I'm assuming that your bugzilla.submit() is happy being fed UTF-8 data
<Kamion> mdz: ... oh, except that my link to chinstrap is dead, so you can't see any mirrors of that archive. I'll mirror it later and let you know.
<mdke> is it likely that the website will be back to normal speed anytime soon?
<Kamion> 18:58 < elmo> it's not being /. or otherwise overloading - it's BREAKING.
<mdke> oh
<bluefoxicy> oy, ok, the ubuntulinux forums seem to be down, #ubuntu is no help, anyone have an hp pavilion zv5000 series laptop?
<crimsun> (no)
<ogra> mdke, that was about the backbone afaik...not the servers
<mdke> Kamion, i thought maybe its on the same bandwidth as one of the mirrors or something
<bluefoxicy> usb reportedly works with ohci-hcd, but I can't get 1.1 to work, 2.0 seems to with ehci-hcd
<spacey> the repositories seem down too
<spacey> at least i cant install some packages atm because it can't feth the packages
<Lathiat> spacey: use a mirror
<Lathiat> like se.archive or something
<spacey> i'll try
<spacey> using nl. now i think
* ..[topic/#ubuntu-devel:bob2] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Ubuntu 5.04 is released!  http://lists.ubuntu.com/archives/ubuntu-announce/2005-April/000023.html || yes, access to *.ubuntu.com is problematic at the moment, people are fixing it
<bob2> (season to taste if you're more in the loop)
<spacey> Lathiat, seems to work, tnx
<dhonn> interpreted c would be cool, with jit compliation
<bob2> and oh-so-wrong
<dhonn> lol
<dhonn> i am not familiar with python, its an interpreted lanugage right
<bob2> yes
<maswan> dhonn: clif?
<dhonn> im an idoit, c is my languange
<dhonn> what's clif
<maswan> Description: C language interpreter
<maswan> bbiab, laundry
<dhonn> ill get it
<dhonn> i dont know if I should be learning c# or something else
<ups> hi guys, i'm writing a gui for mounting/unmounting hdd partitions (using pygtk). the necessary info is fetched from hal/dbus. however, is there some way other than executing the mount/umount commands to do the actual task?
<ups> (i'm new to python as well as hal)
<desrt> ups; have you looked at pmount/pumount?
<ups> if that matters...
<ogra> ups, ubuntu uses pmount for userland mounting
<desrt> and pmount-hal, too
<ups> no...
<ups> i'll look into it now, thanks
<desrt> you say pmount-hal [hal UDI] 
<desrt> and it mounts it for you
<ups> ah sounds nice
<ups> desrt: any links to docs i should look at?
<desrt> ups; manpage
<ups> i'm looking at pmount man page atm
<ups> ok :)
* bluefoxicy calls that a bug as half his shit closes because he removed the notification area from his panel; liferea,however, stayed alive and migrated to the new notification area.
<edd> bluefoxicy: yeah, it's a common problem due to cut and  pasting of bad code
<bluefoxicy> edd:  I figured it was application code, not OS code.  Dunno if it can be fixed in gnome though
<edd> bluefoxicy: No, it's application code. There's only a small number of apps that get it right. (gnome-obex-server among them, of course ;)
<ogra> heh
<ogra> gaim should have survived too....
<bluefoxicy> gaim closed itself cleanly.
<ogra> (according t some changelog in the past)
<edd> my gaim icon is currently 1 pixel thick, annoyingly
<bluefoxicy> damnit 
<bluefoxicy> http://words.haddons.net/archives/000041.html zv5405US
<bluefoxicy> I have one of these.
<ogra> at least if you kill the panel (which killst the notification area)
<bluefoxicy> I can't make nvidia work, and I can't make usb 1.1 work (2.0 works apparently) meaning I can't use USB 1.1 devices (mass storage)
<bluefoxicy> even on 2.6.11 hrm.
<bluefoxicy> plus I need to compile a 2.6.10-5 ndiswrapper later for wifi
<bluefoxicy> why am I talking about this here
<srbaker> has anyone here successfully built a subversion package with javahl bindings?
<kagou> hi
<kagou> what's the soft who create the file /etc/modules ?
<kent> kagou, that question would look good in #ubuntu  :)
<kagou> humm i'm comming from #ubuntu-fr ;)
<kagou> i'm trying to help new user upgrading from warty
<kagou> sound don't work after upgrade, the /etc/modules have been manually modified, so my question is how to re-generate a "clean" /etc/modules like a clean installation with hoary
<kent> kagou, the thing is this is channel for the ubuntu-developers. I think its good to keep this as a channel for that, and an open channel which people can join and *listen* or perhaps talk, when they actually have relevant things to talk about. 
<kagou> ok kent
<Mithrandir> kagou: /etc/modules is created by the installer, but as kent says, #ubuntu please.
<kent> kagou, but, what is manually modified? the user should know what he/she changed and not. given the brand of card, it should be easy to change the module.
<kagou> re ok Mithrandir 
<Lathiat> kagou: i have no idea how to create a clean one, but a standard one for me has ide-cd, ide-disk, ide-generic, lp, mousedev, psmouse, sr_mod, and yes, in future please see #ubuntu :)
<elmo> Kamion: ?
<tseng> jdub: ping
<Mithrandir> jdub: how often is your worldmap updated?
<ogra> Mithrandir, i think he wanted to pick up thom...will be at the airport...
<Mithrandir> bah, silly person.
<ogra> hmm, he will need a bigger map...
<ogra> i'm not readable anymore
<Mithrandir> yeah, we should have an ultra-large one.
<ogra> yop....
<Mithrandir> or zoomed in on Europe, the US and other places with high densities.
<ogra> will get very fast very full
<maswan> or a neat mouse-over magnifier that zooms in on the areas you find interesting at the moment? :)
<Mithrandir> SVG! :)
<ogra> yeah
<Treenaks> and a "I want to see everyone within X km", so you can organise parties
* ogra had planned to get grass5 into breezys universe, including a mapserver
<Mithrandir> Treenaks: those scripts are already written.
<Treenaks> Mithrandir: ok, but not SVG-map-based
<Mithrandir> Treenaks: coordinate-based. :P
<Treenaks> Mithrandir: so all we need is glue ;)
<Mithrandir> Treenaks: Edward Betts wrote them for Debian; I think they're unlicensed ATM, so I'd like to get the licensed to be free.
<ogra> Treenaks, thats easy with a mapserver....
<Mithrandir> Treenaks: nah, just use the source list.
<Treenaks> Mithrandir: yes.. with dynamic svg + javascript magic
<SuperQ> this is awsome, we're having an installfest tomorow.  I borrowed a CD duplicator.  I am cloning a burn of 5.04 amd64, 5 disks at a time, time to copy: 70 seconds
<ogra> cool
<Mithrandir> SuperQ: yay.  And double-yay for amd64.
<ogra> thats what i meant :-P
<SuperQ> Mithrandir: i'm making 5 copies of everything, and 10 copies of x86
<SuperQ> just for starters
<Mithrandir> what kind of symbol should a czar have? ;)
<Mithrandir> (like, a king has a crown..)
<Treenaks> Mithrandir: sceptre?
<Mithrandir> Treenaks: possibly.
<Mithrandir> ogra: you're coming to UDU too?
<ogra> YEAH !
<ogra> you too ? 
<ogra> and simira ?
<Mithrandir> ogra: I'm coming, Simira's not; she didn't get funding.
<Mithrandir> ogra: but she's hoping to go to the next conference.
<ogra> sad :(
<Mithrandir> and she's coming to debconf in the summer
<Mithrandir> yeah, but it'll vary who comes.  That's ok too.
<ogra> yop
<ogra> but i would have expected she would get funding...
<tseng> where is debconf?
<Mithrandir> tseng: outside helsinki, .fi
<tseng> ugh
<Mithrandir> ogra: it's a long trip, costing a lot
<tseng> when is the us ubuntu conf :(
<ogra> yeah, thats true
<Mithrandir> tseng: not, I hope.  I'm hoping a bit for Canada or so next.
<Mithrandir> tseng: did you ask for funding for UDU?
<ogra> Mithrandir, i'm guessing .br or .za
<tseng> Mithrandir: yes.
<tseng> Mithrandir: never heard anything, i am on the other side of the world so..
<ogra> Mithrandir, youre on the map now :)
<Mithrandir> ogra: .za would be awesome, I've never been to Africa.
<Mithrandir> (nor have I been to NA)
<Mithrandir> tseng: :(
<ogra> me neither, but a teenage friend of mine lives there...
<Mithrandir> tseng: you should at least have heard back.
<ogra> yeah, thats not nice
<Mithrandir> it's actually in the right place too
<tseng> what place?
<tseng> i thought i put it on UbuntuDownUnderAttendees, but sponsor requests are removed now.
<Mithrandir> tseng: the map stuff.
<tseng> oh.
<Mithrandir> tseng: shame; you're in the US?
<tseng> i dont know any of these people showing up on the US now
<tseng> yeah.
<Mithrandir> we should lobby for you coming to the next one, then
<Mithrandir> it's only 'till August, so not that long.
<Mithrandir> (or early Sept)
<tseng> hm, neat
<tseng> we could have an openbox BOF
<tseng> or metacity-haters-club
<Mithrandir> you too use openbox?
<Mithrandir> yay openbox
<tseng> yep.
<tseng> i used to take my openbox 2.x straight up
<Mithrandir> (it does emacs-style keybindings, that's something which metacity would have to grow for me to switch)
<tseng> well actually
<tseng> openbox2 had a tool called epist that grabs keychains
<tseng> i used that with metacity for a time
<tseng> it would be nice if someone split it out
<Mithrandir> that could work, but you'd lose the gnome integration (clickety-clicky dialogs), so it's not a big win over going openbox3
<Mithrandir> IMHO
<tseng> what clickety dialogs?
<tseng> there are none for proper keybinding
<tseng> just binding a simple command to a keychain is a major PITA
<tseng> involves setting not 1 but 2 gconf keys by hand
<Mithrandir> uhm, you can't do it all with metacity, can you?
<Mithrandir> (without epist)
<tseng> you can
<Mithrandir> oh, ok.
<tseng> in gconf :(
<tseng> first you make a binding for commandX
<tseng> and then define commandX in a seperate key
<tseng> its awful
<tseng> in openbox i can write it in xml in a few seconds
<tseng> vi > gconf-editor
<Mithrandir> heh
#ubuntu-devel 2005-04-21
<ogra> hehe, hwdb.ubuntu.com submission stats:
<ogra> 07.04 - 515
<ogra> 08.04 - 839
<ogra> 09.04 - 1696
<Mithrandir> heh
<Mithrandir> what's the arch ratio like?
<ogra> arch ratio ?
<ogra> wait, i have to run the scripts
<Mithrandir> yeah, how many i386-vs-amd64-vs-ppc
<ogra> they run quite long now.... will be a serious task to get a database instead of flatfiles....grep gets slow with more then 30000 200k files in a dir....
<ogra> and i guess we hit 10000 on monday
<Mithrandir> use a hashing so you don't have that many files
<ogra> i think up to 30000 i'll be fine as it is... so i have until next weekend to get something basic in place there...
<ogra> (hoping the rate goes below 1000 a day again after the release hype)
<Mithrandir> just remember that ext2/3 is massively unhappy when you hit 65k.
<ogra> yep...
<ogra> amd64 691
<ogra> ppc is running....
<ogra> but i guess its below 250
<ogra> ppc is 197
<Mithrandir> jdub: we want zoomed images in the locations with overlap.
<ogra> hmm, this rised from 10% to 11% ... http://hwdb.ubuntu.com/nullswap.html
<blahrus> Mithrandir: still around?
<trulux> I know I'm timed out...but.... the new look and feel of ubuntulinux.org rocks!
<kivio> hi
<Robot101> ogra: what are other processing plans other than getting worried at lack of swap?
<ogra> Robot101, first of all i will writte something like a "online device manager" where you can lookup the data for your syste....i got basically all data from hal plus some X and boot data...
<ogra> (for support and bugreports you will only have to attach your id then)
<jdub> Mithrandir: yeah
<jdub> tseng: pong
<Robot101> hmm
<Robot101> ogra: cool. what about some "everyone has $foodevice and it works/doesn't work?"
<ogra> Robot101, next we could have a overview with ranking for best supported HW
<ogra> exactly
<Robot101> read it as soon as I pressed enter, hehe
* Robot101 ponders
<Robot101> upgrading from warty to hoary leaves a lot of cruft on your system
<ogra> the options are endless....
<Robot101> python2.3* for a start
<Robot101> could one provide upgrade metapackages which conflict with things obsoleted from main/universe?
<ogra> ubuntu-cleanup ?
<Robot101> ogra: does that exist, or was that a suggested name? :)
<ogra> just a name :)
<Robot101> ogra: something like ubuntu-upgrade-warty or something
<Robot101> ogra: because they would necessarily be unique to the release you were upgrading from
<Robot101> the release notes tell you to dist-upgrade (or equiv. with synaptic) and then install ubuntu-base and ubuntu-desktop
<ogra> i think a simple apt-get purge `deborphan` after upgrade would be sufficient
<Robot101> which isn't great - one downloads xfree86 from universe and them immediately you replace it with xorg
<ogra> hmm, indeed, thats a bandwith waste...
<Robot101> plus there are some automatable things in the release notes
<Robot101> "post-upgrade" reads to me... postinstall script of the upgrade package :)
<ogra> hmm, they are not written for devs ;)
<Robot101> well
<Robot101> I mean, as it stands the instructions aren't very easy to follow, and aren't optimal (downloads stuff then removes it, leaves stuff behind)
<Robot101> my ideal upgrade would be... update sources list, update, install magical-update-package, reboot
<Robot101> and if magical update package isn't possible, install magical-update-manager, run it, reboot
<alp> Robot101: yeah. i'd buy that
<ogra> Robot101, that will be the way hoary->breezy ... its already there
<Robot101> Setting up libasound2 (1.0.8-1) ...
<Robot101> ldconfig: /usr/lib/libgslcblas.so.0.0.0 is not an ELF file - it has the wrong magic bytes at the start.
<ogra> all other ideas would have involved to develop something for warty which was not an option
<Robot101> ldconfig: ow ow ow jesus christ
<Robot101> Setting up libxkbfile1 (6.8.2-10) ...
<Robot101> dpkg: error processing libxkbfile1 (--configure):
<Robot101>  : Input/output error
<Robot101> dpkg: failed to open `/var/lib/dpkg/status' for writing status information: Input/output error
<Robot101> E: Segmentation fault
<Robot101> robot101@phi:~ $ df -h
<Robot101> bash: df: command not found
<Robot101> me waves bye bye
<alp> ogra: deborphan won't check to see if packages are available in the repository or not, only if something depends on them
<Robot101> (I guess that would constitute a failed upgrade)
<alp> whatever have you done, Robot101?
<ogra> alp, he was talking about removing unused stuff from the system..... nothing in hoary main depends on py2.3
<Robot101> at a guess, xfs ran out of disk space and "forgot" to report an error until dpkg had written lots of 0 byte libraries over all my real libraries
<jdub> o/~ aaaaaaafternoon delight o/~
<Robot101> then ldconfig died
<Robot101> and hell broke loose
* Robot101 scowls
<alp> yeah, but if you have a single program from warty that depends on python 2.3 and is still installed (say, because it was dropped in hoary or renamed), it all stays
<Robot101> ogra: what does synaptic do to support upgrades from hoary to breezy?
<Robot101> change sources.list for you, run dist-upgrade, install -base and -desktop?
<ogra> update-manager does detect ubuntu CDs now...
<tseng> it doesnt seem to work very nicely with a proxy
<tseng> doesnt read http_proxy afaict
<tseng> unless its because gksudo is purging env
<ogra> tseng, update-manager ?
<jdub> yo tseng 
<tseng> yo jdub 
<jdub> man
<jdub> wtf
<tseng> ogra: yes.
<jdub> bbq!
<tseng> omglol
<ogra> tseng, i guess it uses the settings from synaptic
<jdub> there are hardly any names on the UWW list!
<tseng> :(
<tseng> jdub: so
<tseng> jdub: im running meebeys 1.1.6!
<tseng> jdub: with beagle 0.9!
<jdub> elite!
<tseng> 3-fn-1337
<tseng> BBQ4EVAH
<mdke> mdz, ping
<tseng> jdub: yeah dude, breezy
<jdub> elmo: ping
<jdub> elmo: flat thom says hi
<ogra> thom lied about his actual location i think :)
<Robot101> hmm
<Robot101> is there a file in /proc that has the dmesg output in?
<ogra> nope
<thom> ogra: well, my usual actual location is probably right
<ogra> /var/log/dmesg is the place
<Robot101> er, I'm guessing my / filesystem is suspended
<Robot101> so I can't read any files or use any binaries
<Robot101> robot101@phi:~ $ while read i; do echo $i; done </var/log/dmesg
<Robot101> bash: /var/log/dmesg: Input/output error
<ogra> thom, what is usual nowadays...we just had a release....
<ogra> :)
<mx|gone> tseng: what's meebeys?
<maswan> heh. still the most northly one on the map. :)
<mdke> who has special access to the wiki?
<mdke> need a couple of icons renamed
<ogra> maskie, at least your name is readable.... mine is already hidden in the crowd
<ogra> *maswan
<maswan> ogra: well, if torkel, stric and a few others in this city register, I'll be hidden too
<ogra> heh, by a handful of people, yeah ;)
<maswan> http://www.gnome.org/~jdub/random/GnomeWorldWideHuge.jpg
<maswan> actually, it is just me and Stric on that one, so we both manage
<ogra> jeah, but more southern it gets blurry
<ogra> i always wondered about the big distance between nat and miguel on this map...
<daniels> maswan: as far as I can tell, I'm still the southernmost :)
<Pizbit> Heh, lost city of atlantis
* mpt cheers for the South Islanders
<Pizbit> Bah, South Islanders aren't worth the breath to say their names:)
<mpt> haha
<mpt> A fellow Paradise subscriber, eh
<daniels> mpt: is that the first documented occurrence of a north islander doing that?
* Pizbit nods.
<Pizbit> In Wellington.
<mpt> daniels: If the North Islanders get too rowdy, we'll just cut the Cook Strait power cable
<Pizbit> mpt: And if the south islanders get too rowdy, we just ignore them like we always do! :D
<mdke> no one owns up to having edit permissions to the icons on the wiki?
<schweeb> wow, that map is neat
<mpt> Pizbit: What city are you in, anyway?
* Pizbit points up.
<schweeb> useful for telling you who should be awake in the ubuntu world :)
<mpt> oh
<schweeb> never noticed the nighttime shadow before
<maswan> schweeb: by looking at that map, should I be awake now?
<Pizbit> schweeb: What about nat and omiguel? They're in the night for long long periods of time, do they hibernate?:)
<schweeb> maswan: heh, no
<eruin> rupert looks lonely
<schweeb> Pizbit: yes. whiprush hibernates, why shouldn't they
<mdz> Kamion: let me know when your mirror is up to date so I can attempt that debzilla merge again
<thom> mdz: so can i do that firefox-loc-en-gb upload to hoary-updates soonish? you saw another instance of the symptoms over the weekend on #8821
<jdub> o/~ skyrockets in flight, afternoon delight... aaah-aah-aah afternoon delight! o/~
<ogra> mdz, did you recognize my hwdb numbers before ?
<jdub> UWW is looking better
<mdz> thom: that guy seemed to say that the buttons were non-functional; I thought the problem was only that the text did not appear
<mdz> ogra: no
<thom> mdz: no, it totally kills the buttons
<mdz> thom: oh, ugh
<thom> (go firefox! it's your birthdya, etc)
<mdz> thom: fix is simple and safe?
<ogra> hwdb submissions: 06.04 - 520
<ogra> 07.04 - 515
<ogra> 08.04 - 839
<ogra> 09.04 - 1696
<mdz> ogra: nice!
<thom> mdz: 4 line addition; yes, definitely safe
<ogra> Total: 8119
<mdz> thom: ok
<mdz> thom: (if you break hoary, I know where you live)
<thom> mdz: but i have cunningly changed continents in the mean time!
<ogra> heh
<mdz> I will lie in wait with the patience of the ages
<mdz> and a shotgun
<mdz> or perhaps I will follow you to australia
<daniels> mdz: easy enough to do at heathrow
<jdub> mdz: ha ha!
<ogra> hehe
<jdub> mdz: but you don't know thom's location!
<jdub> ha ha!
<jdub> (ah, shit... mdz knows where *i* live...)
<mdz> he can't be hard to find
<mdz> I'll ask in which direction the frightened englishman ran
<jdub> with NO HAIR
<mdz> taht reminds me, I need to cut my hair
<maswan> he ran _that_ fast?
<daniels> mdz: dude, it's *sydney*
<mdz> daniels: they don't cut their hair in sydney?
<mdke> jdub, you don't have permissions to rename icons uploaded to the wiki do you?
<daniels> mdz: they'll likely point you to either scubar or bondi beach, at which point you will be confronted with forty thousand frightened englishmen ('OH MY GOD!! YOUR STAR BURNS! I DEMAND FROZEN TREATS! MY SKIN IS MELTING! etc')
<daniels> mdz: that being said, the odds of thom being at either of those locations is good, you just have to spot him in amongst the other pale englishmen
<mdz> and there's where I have aa clever plan
<jdub> mdke: hrm, dunno
<mdz> I *know what thom looks like*
<thom> meh, i've not been to scubar for FOUR YEARS
<mdke> jdub, or maybe know someone who does? normally sm does these things for us but he's not here
<jdub> daniels: ha ha ha
<jdub> ah
<jdub> it's funny because it is true
<mdz> thom: it might be wise to confirm with elmo that hoary-updates is vaguely functional/safe
<thom> mdz: a plan so cunning you could pin a tail on it and call it a weasel!
<mdke> heh
<jdub> mdz: i've uploaded u-c-a there, but elmo hasn't turned it on yet (so it's safe in that it won't let us break anything yet)
<lamont> jdub: how often is UbuntuWorldWide's picture updated?
<jdub> thom: may a carrot fall on your head at an inappropriate moment
<jdub> lamont: every three minutes atm
<lamont> I see
<mdz> there are 50,000 sparc packages in queue/unchecked
<jdub> no, less than that
<mdz> like, every package dholbach uploaded this past week
<jdub> lamont: every half hour
<thom> mdz: so i'll do the locale update tomorrow, when i'va had sleep in a horizontal position
<lamont> mdz: I could provide a boatload of hppa packages to help fill up queue/unchecked... :0)
<mdz> thom: I hope you can sleep upside-down
<jdub> lamont: i was mistaking "time it takes to connect to the wiki and download the page source" and "how often it runs"
<jdub> ;-)
<thom> mdz: upside-down is fine compared to cattle class
<mdz> I suppose you all hang upside-down like bats to sleep down there
<lamont> jdub: heh
* lamont is tired - contemplates sleep
<thom> mdz: you're provided with straps to attach yourself to the floor at immigration
<Riddell> jdub: does UbuntuWorldWide update directly from the wiki?
<jdub> Riddell: yes
<Riddell> clever
<jdub> mmm, waiting for the kde scripts to turn up
<jdub> so i can spruce it up a bit
* lamont waits for the pretty yellow circle in the middle of the US to appear.
<Riddell> jdub: apparantly he uses an old version of xplanet because it has better support for these things.  a european zoom would be cool
<mdke> jdub, so that's a no?
<jdub> mdke: i don't really grok attachments with zwiki, no
<mdke> hmm ok
<maswan> I want a mouse-tracked magnifying glass with variable zoom. :)
<mdke> jdub, cheers anyway
<jdub> Riddell: so i attempted a euro zoom for the gnome one, took a lot of fiddling
<jdub> might have to roll back to old xplanet
<maswan> jdub: you don't have a bigger planet so you can start out by making a huge and then scale it down for the global view?
<jdub> maswan: *so* tempted to get one of the really high resolution maps and do a lame google maps style scroller ;)
<jdub> maswan: hrm?
<maswan> jdub: that would be neat. :)
<maswan> jdub: make a high res globe, convert(1) it down to a resonable size for the global map, crop out the hotspots for separate maps?
<mdz> jdub: isn't it possible to use google maps for this?
<ogra> jdub, this releases MOTU target for me was to find some hula to drop in.... breezys target for my MOTUness is grass5 and a mapserver :)
<mdz> (itself)
<maswan> mdz: hmm.. the satelite images are global these days, right? otherwise the maps were north america only lst time I looked
<jdub> mdz: you can't see other countries
<jdub> mdz: you imperialist scum!
<mdz> jdub: facts are boring
<maswan> jdub: click the "Satellite" link in the right upper corner
<jdub> maswan: yeah, but no love for most other countries
<maswan> jdub: well, it goes 5 zoom-steps in
<maswan> at least where I have looked :)
<maswan> that's enough for a screenful of GB
<mpt> Or use a fisheye map that magnifies places where people are currently present, pushing the isolated countries/continents out of the way
<maswan> or a sweden that needs two screenfulls
<maswan> mpt: yeah, that was the effect I was looking for. I doubt you can do that easily with a bit of javascript and some images though. :)
<eruin> http://maps.google.com/maps?ll=61.199341,4.932861&spn=2.642212,4.119873&t=k&hl=en
<eruin> thats where you wanna live ;-)
<sladen> jdub: you could actually improve on the Google Map scroller by smooth zooming---the browser will take care of scaling the map tiles for you up/down from the nearest mipmap
<jdub> dudes, i am so sticking to cheap off the shelf parts
<maswan> Cannonical should hire a full-time employee to make the best map ever! ;)
<thom> eruin: no dude, you've gone up and right too far and missed angland
<ogra> lol
<jdub> ahar
<jdub> thom raises a good point
<jdub> in his addled, jet-lagged state
<jdub> we need breezy-changes quick smart!
<thom> i am addled?
<mdz> if you have to ask, the answer is yes
<jdub> *snicker*
<thom> heh
<daniels> thom: f-i-r-e-f-o-x
<thom> this is possible yes
<daniels> firefox is more crackful than X, almost
<jdub> hrm, should i transfer the h-c subscribers over to b-c?
* jdub is very tempted
<ogra> yeah
<sladen> OMG.  Google maps have added europe
<daniels> jdub: you should transfer me, 'cause I'm lazy
<Riddell> sladen: ooh?
<maswan> sladen: only in low-res satellite images, right?
<jdub> Mithrandir: jdub_owes_tfheen_beer++;
<sladen> maswan: yup, but it's one step on their way to recognising that the World consists of more than just North America and Puerto Rico
<schweeb> jdub: you should automatically reconfigure my news reader too, since I'm using gmane :)
<jdub> i've just subbed the regular subscribers
<jdub> the others aren't dedicated enough
<jdub>   ubuntu-devel:792
<jdub>   ubuntu-users:1754
<jdub>   ubuntu-announce:3808
<ogra> jdub, i guess tollef wont do anything useful in UdU, everyone coming owes him beer++
<ogra> night all
<Riddell> I'm the most northerly Ubuntu person
<Riddell> no wait, there's some norwegians way up there
<ogra> Riddell, maswan and Mithrandir 
<ogra> and there is somene on iceland it seems
<ogra> ah, no...
<sladen> Riddell: I think Troodheim (sp) is more northerly than Edinburgh
<maswan> I'm further up north than Mithrandir
<maswan> and Edinburgh is way down south :)
<ogra> but it looks suspicious as if the script is confused by Byron Poland who has added no nickname....people below him dont show up
<ogra> hmm, now they do...
<sladen> ooh.  I've just found that   <script> while(1) { window.status="foobar"; } </script>    hangs Firefox
<ogra> sladen, thats a mean script...
<sladen> I was trying to debug something.  Turns out that updating  window.status  is disabled by default unless you toggle an option in about:config
<ogra> oops, thats bad
<tseng> hey dudes
<jdub> pants off
<tseng> pants way off
<schweeb> from the ubuntu-calendar backgrounds, and the conduct of this channel, it appears as though Ubuntu is a pants free zone :)
<daniels> pants are most certainly off
<jdub> schweeb: ahr, just wait until you see april's!
<jdub> (stuck in hoary-updates NEW)
<Lathiat> jdub: get it through NEW already :)
* Lathiat bats elmo 
<schweeb> jdub: got a linky? :)
<schweeb> if it's got the blonde chick in it, it's sure to be pleasing to the eyes
<tseng> i dont like her face
<jdub> no blondes :)
<tseng> i hope its not the dude
<schweeb> ^^^^
<tseng> its his turn to show his pooper
<tseng> can we skip him?
<schweeb> hahahha
<Lathiat> haha
<Lathiat> maybe its sabdfl in some kind of evil trick :)
<schweeb> jdub: whole lotta good the ubuntu-calendar for April is, if it's stuck in NEW... considering April is nearly 1/3 of the way over :P
<jdub> uh huh
<jdub> (it hasn't been in NEW for long though)
<Lathiat> this is why you should upload it to p.u.c so we can get a sneak peak :)
<jdub> special treats for #u-d?
<Lathiat> yup
<jdub> since when did we do that?! ;-)
<Lathiat> bah
<jdub> correct answer: SINCE ALWAYS!
<Lathiat> haha
<jdub> http://people.ubuntu.com/~jdub/hoary/
<Lathiat> :)
<Lathiat> bbl
<schweeb> jdub: omg... it's so... not naked
<gabaug> my display, mouse, keyboard, and sound freeze up often (since a couple weeks ago), usually when opening a new program or webpage (latest Hoary)
<SuperQ> schweeb: naked?
<schweeb> SuperQ: the ubuntu calendar artwork for april... no naked women or men
<daniels> jdub: shit dude, that's awesome
<daniels> jdub: i think the design people have a thing for sparkles though
<schweeb> yea, it is pretty neat.  and sparkly
<daniels> man, the weather applet says thunder/lightning and 33C
<daniels> I SEE NO THUNDER
<daniels> I SEE ONLY THE FRIGGING SUN
<aj> i see no thunder / see only the frigging sun / frigging burning me!
<ups> someone deleted the UbuntuWorldWide page?
<jsgotangco> yeah its gone
<jsgotangco> i was just checking today
<jsgotangco> ill check the recycle_bin
<jsgotangco> OMG even the recycle_bin is empty
<ups> i hope jdub can restore it :(
<jsgotangco> wait i think i can restore it now
<jsgotangco> ok ive restored it but i dont know if it will work hmmm i think the last guy in the entry accidentally deleted it
<ups> jsgotangco: i still get a blank page
<Pizbit> Er, what's a "sit0" as seen in /proc/net/dev ?:)
<sladen> jsgotangco: try, I got an edit conflict just as I pressed okay
<smurfix> Pizbit: that's a question for #ubuntu
* Pizbit decides against making his lame excuse for not having that open and does as suggested.
<jsgotangco> hmmm
<jsgotangco> the dots are not appearing
<jsgotangco> sladen: try again
<sladen> jsgotangco: no, I was just trying to fix the deletion
<sladen> you beat me to it
<jsgotangco> ouch
<jsgotangco> but the jpeg doesnt reflect the coordinates
<sladen> jdub only has it regenerated every 15minutes or so
<jsgotangco> ok i hope i didnt miss something
<sladen> there you are, it's been regenerate now
<sladen> press refresh
<ups> great, it's back :)
<jsgotangco> yay its back
<jdub> sladen: 30min
<jsgotangco> ahh
<jsgotangco> ooohhh the map is getting crowded
<jdub> jsgotangco: see live.gnome.org/GnomeWorldWide for comparison ;)
<desrt> fabbione; fam problems again :)
<zenrox> whares ours??
<Lathiat> jdub: well the blues are much less depressing than the browns :)
<Lathiat> jdub: but where have the naked wimin gone :)
<Mithrandir> blahrus: pong
<Mithrandir> jdub: why do you owe me more beer?
<trygvebw> Question: Is a XFCE version of Ubuntu being worked on or planned?
<GoneBoB> trygvebw: no
<trygvebw> GoneBoB, ok :)
<HiddenWolf> And that's an utter shame, really. :)
<brrrt> heya guys!
<brrrt> i just want to say THANK YOU all! 
<brrrt> you are the best!
<brrrt> hoary is soooo great :)
<brrrt> ubuntu is the distro many people were waiting for even if they do not know by now ;)
<brrrt> congratulations !
<HiddenWolf> Now _Any_ dev show up here and say thanks, pronto!
* HiddenWolf is just a groupie
<AstralJava> Guess they're all resting after partying :)
<sladen> jdub: has somebody broken the page agin?
<HiddenWolf> sladen, site still not up and running smooth?
<ups> sladen: this time it has been deleted completely?
<Lathiat> hmm hal died
<mdke> where's that worldwide page
<kent> mdke, this one? https://www.ubuntulinux.org/wiki/UbuntuWorldWide
<mdke> yeah that one
<mdke> its deleted
<mdke> and not in the recycle bin either
<mdke> oh yes it is
* mdke restores
<kent> Perhaps it took to much resources? If everyone tried to edit it, and it always showed that picture, then perhaps it was a bit to much?
<mdke> nah someone just pressed delete by accident/on purpose
<mdke> should let jdub know because when we restore it the map won't work no more
<Kamion> elmo: ?
<mdke> kent, ok i've restored it, maybe the map will restore itself automatically, dunno
<Lathiat> its ctd
<kent> mdke, thanks for restoring it. Now i'm on the list aswell.  :)
<mdke> ;)
<mdke> map isn't working tho
<mdke> ooooh now it is
<kent> mdke, Hopefully he can restore the xplanet-thing without deleting the list of people :)
<ups> mdke: the map updates every 30 mins
<mdke> right
<mdke> kent, i think you may have got your coordinates wrong
<mdke> doesn't look much like sweden
<mdke> kent, you have the same lat as long
<kent> mdke, oh, shit. Sorry :8
<mdke> heh
<brrrt> there will be a time called "before ubuntu" <---
<trygvebw> AU
<trygvebw> BU
<trygvebw> woops
<kent> mdke, updated :)
<trygvebw> wrong channel
<kent>  12 B.U  ;)   And A.U? (Aminus Ubuntus, haha, or something like that)
<brrrt> hehe
<brrrt> yes
<kent> mdke, pretty few dots in Russia and Africa.
<mdke> very true
<Kamion> mdz: my debzilla--fv3 mirrors on chinstrap/rookery are up to date now
<Micksa> hi
<Micksa> is xvncviewer broken for anyone else?
<Micksa> latest hoary
<ctd> Micksa: seems fine, here.
<trulux> oops
<trulux> neither doko or pitti are here
<trulux> tseng: time to start the work on gcc-3.4 and gcc-3.3, and, as I haven't ported all to 4.0, by now we must keep in mind to contact the GCC folks
<tseng> sure.
<trulux> I can try to move some things and see what happens, but I can't give any guarentee for it
<trulux> I'm going to send an email about our Breezy goals, CC'ed to -devel
<trulux> also I need to announce the final revision of libssp packages
<trulux> updated the PIC syscalls
<trulux> a step further is to work on portability
<trulux> I've done my homework reading on some specs. ;)
<tseng> we dont need to worry about pic for breezy really
<tseng> just try it on a few apps
<tseng> not *
<trulux> right, but we gain momentum by implementing it within libssp
<trulux> pappy- broke it (even if he thought he rocked the house ...), I needed to fix the syscall callbacks and the macros for PIC syscalls, so, we don't need to worry about it
<trulux> I'm using Kevin Q.'s fu, it was on the gentoo bugzilla time ago, he posted the bits
<trulux> so
<trulux> lorenzo@estila:~/kernel/selinux/01/execstack-regression $ ls ~/proyectos/hardened-toolchain-wrappers/
<trulux> hardened-gcc-wrapper-1.4.2.c  hardened-ld-wrapper-1.4.2.c  Makefile  vuln-stack.c
<trulux> lorenzo@estila:~/kernel/selinux/01/execstack-regression $
<trulux> I worked that with pappy-, when he wasn't that mad (quite good work from him), those are the wrappers for gcc-X.Y-hardened
<trulux> just lemme finish the physics paper I'm writing, mess a bit with povray and then I will be back to build it
<trulux> I've been working on a new SELinux permission, execstack, I'm testing and studying it's impact with Stephen (not spb), it will provide stack executability control from SELinux, enforced by somewhat NX tech. (ie. PaX, Exec Shield)
<trulux> also I've been studying ES, it's a good technology even if some people don't think so
<tseng> ES could be on for breezy
<tseng> and selinux targetted, as colin said
<trulux> tseng: without a sabotaged paxtest (too weird the nested function and the other anti-ES trick...)
<trulux> right
<trulux> we have +90% done around SELinux, openssh package is left and pam is broken due to syntax changes, I'm going to fix it ASAP
<tseng> targetted?
<trulux> right
<tseng> rock!
<trulux> you missed a while on ubuntu-hardened...
<trulux> look:
<tseng> paste it there
<tseng> please.
<trulux> http://pearls.tuxedo-es.org/selinux/ubuntu/selinux-policy-targeted/
<tseng> oh.
<trulux> I've testimonials on our work, a guy from an Australian GLUG was able to set up a SELinux box with our work
<trulux> so
<trulux> it's getting tested
<trulux> bbl, lunch time
<trulux> I will get the steroids for this afternoon session ;P
<bob2> all the network stuff is resolved, right?
<mdke> website is workin
<ogra> looks like
<HiddenWolf> What was the problem, besides the load?
<ogra> the ISP broke the line apparently
<ogra> the load wasnt a problem afaik
<Lathiat> just not enough bandwidth
<maswan> Lathiat: nah, it was actual breakage
<Pizbit> ogra: No one warned the ISP eh?:)
<ogra> Pizbit, according to our datacenter admin, the ISP was informed long ago, the line was ordered, it just broke...dont ask me why...
<Pizbit> Ahh
<ogra> (as i dont know more details) ;)
* Pizbit nods.
<maswan> I'm hoping that this showed to our campus network admins that we weren't joking when we said that we want bandwidth. :)
<ogra> heh
<Pizbit> Hehe
<chapeaurouge> thank you topic.
* ..[topic/#ubuntu-devel:ogra] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Ubuntu 5.04 is released!  http://lists.ubuntu.com/archives/ubuntu-announce/2005-April/000023.html
<chapeaurouge> aaah
<ogra> :) 
<ogra> thanks for the hint :)
<chapeaurouge> well..
<chapeaurouge> im trying to get to bugzilla
<chapeaurouge> but it wont get there
<ogra> works fine here
<chapeaurouge> hmm
<chapeaurouge> kk
<ogra> https://bugzilla.ubuntu.com/
<chapeaurouge> Secure connection: fatal error (10) from server
<chapeaurouge> https://bugzilla.ubuntu.com/
<chapeaurouge> Transmission failure.
<chapeaurouge> that's what i get
<chapeaurouge> hmm
<chapeaurouge> works with firefox..
<chapeaurouge> but not opera...
<chapeaurouge> anything weird with your certificate?
<ogra> no idea, i never had probs with it....(but i never used opera, and dont know any peorson on this world using it...)
<chapeaurouge> haha.. bc you haven't known the best yet ;)
<ogra> hmm....
<Robot101> where can I see how the livecd cloops are made?
<Robot101> http://www.ubuntulinux.org/wiki/LiveCDDesign seems old
<tseng> http://www.ubuntulinux.org/wiki/LiveCDCustomizationHowTo
<chapeaurouge> can't attach files to the LaunchPad ?
<Robot101> tseng: no I want to know what the difference is between what's on the LiveCD and what's on the HDD after you do an install
<tseng> oh
<ogra> there is none afaik
<tseng> there are different "seeds"
<Robot101> so the livecd & cloop is just made by running debootstrap?
<Robot101> there's no manual frobbing, just what casper does, which is similar to what base-config would do for you after the install?
<Robot101> I'm thinking you can just use device mapper to move the blocks onto the HDD, install a bootloader, eject the CD -> zero reboot install, and no need to address any "installer/packages on liveCD" problems
<ogra> Robot101, you'll have to wait for details until mdz shows up i guess
<mdz> ?
<Robot101> and you can just keep using it while your system installs...
<tseng> you could probably do a debootstrap off the cd anyway
<mdz> Robot101: http://udu.wiki.ubuntu.com/UbuntuDownUnder/BOFs/UbuntuDevelopment/UbuntuExpress
<Robot101> yes but that's lame, the CD is already a debootstrapped image that's running on the computer
<Robot101> mdz: hmm... I wanted to do this with Debian about two years ago, but no sufficiently unmutilated Debian liveCDs existed for me to base it off
<Robot101> mdz: the easiest method is just to relocate each block in the device-mapper thing onto the HDD (like what pvmove does with lvm)
<mdz> Robot101: that copies a lot of unnecessary data, and requires resizing the filesystem afterward.  it's simpler to create a new filesystem on the disk and do a file-level copy
<Robot101> hmm
<Robot101> but it does have the benefit that you can keep using the system whilst and after the "install" takes place
<mdz> of course it does
<Robot101> which is cool... zero-reboot install :D
<melodie> hello :)
<Robot101> ext2 can do on-line resizing can't it?
<mdz> zero reboot is possible, but it's not the same thing as running from the CD
<Robot101> sure, you can pivot into the disk and then do the first boot tasks then
<mdz> the same thing is possible with d-i; we've discussed it in the past and agreed that a reboot is a good idea
<melodie> I'm looking for a link to read lists of packages in Live Hoary. Is there a list for that ?
<mdz> melodie: http://www.ubuntu.com/wiki/SeedManagement
<melodie> thanks! :)
<mdz> Robot101: oh, I read "does" as "doesn't" in your earlier message
<Robot101> mdz: possibly in the installer a reboot is neater, but in the liveCD you're using it and think it's cool... if it can move itself to your HDD in the background and then just eject the CD when it's done
<mdz> file copy is both simpler and faster
<Robot101> it doesn't matter it takes longer if you can use the system in the meantime
<mdz> Robot101: the reboot is a good idea in order to test that the boot process works correctly
<mdz> rather than, say, using the system for a week and then discovering that it doesn't boot
<Robot101> if you have to sit and stare at a progress bar, it does matter
<Robot101> ok, so it can tell the user to reboot at their nearest convenience :)
<smurfix> Robot101: Suppose you work with the new Ubuntu for a weekn and then it doesn't boot up for some reason. I don't want to experience the frustration of *that* user.
<mdz> you don't have to stare at a progress bar in any case
* smurfix worked hotline in a previous life :/
<Robot101> but the file modifications you make might not be reflected in the installed system
<smurfix> Much better to check that booting works, as soon as possible
<Robot101> hmm
<mdz> install-without-reboot is a neat gimmick, and I'm tempted to do it just because it can be done, but I don't think it's the right way to do a default install
<Robot101> I like the "no-install-at-all" gimmick
<Robot101> you boot the CD and just start using it :)
<Robot101> (how long does it take to dd 2GB anyway? presumably cloop's good at compacting consecutive zeros)
<tseng> so if beagle/mono goes into main for breezy, does the universe team loose control of that?
<smurfix> Robot101: It takes quite a while when you also try to do some actual work on the system at the same time
<smurfix> Robot101: Seeking on a CD is expensive because the rev speed changes
<smurfix> Robot101: plus the copy flushes stuff out of your memory unless you're extra careful
<ogra> smurfix, you should correct your data on the worldmap ;) or did i miss that nuernberg is an island :)
<smurfix> ogra: *sigh*
<ogra> *g*
<melodie> mdz: didn't find the list of apps I seek for yet but I found sthg that can interest developpers of Live branch: where should I report ?
<zul> there is a world map now?
<smurfix> zul: https://www.ubuntulinux.org/wiki/UbuntuWorldWide
<Nigelenki> where do I go if #ubuntu and ubuntu-users@ doesn't get me any help
<zul> cool...,miss a day...miss alot
<tseng> Nigelenki: google?
<melodie> Nigelenki: what level user ?
<Nigelenki> I have a laptop I can't make work, a zv5405us
<azeem> file a bug
<Nigelenki> according to google -->  http://words.haddons.net/archives/000041.html USB works out of box, nvidia needs tweaking, wifi needs ndiswrapper for a driver.
<Nigelenki> however, usb 1.1 isn't working, the given tweaking to get nvidia working doesn't work, and the mailing list and #ubuntu are giving me no help.  I'm about to crawl the forums but . . . :/
<Nigelenki> azeem:  I'll consider that, once i determine all of the things not working and what "should" work :)
<melodie> and here ?
<melodie> http://www.ubuntulinux.org/wiki/HardwareSupportMachinesLaptops
<Nigelenki> I think I saw that, my model is in there.
<Nigelenki> huh, no it's not.  There was another wikipage though that also mentioned the 5405 specifically though
<smurfix> Wow, the Wiki notices edit conflicts now
<Robot101> hmm
<Robot101> the livecd has hibernate
<Robot101> if I hibernate, will it resume? :)
* Robot101 suspects not :(
<Nigelenki> do you have a swap partition?  :)
<Robot101> yes
<Nigelenki> then it might ;)
<Robot101> but there's no way for the isolinux to know what that is, so it won't pass resume=/xxx to the kernel
<ogra> then it could work
<Robot101> ie, livecds shouldn't have a hibernate unless the bootloader can be made to do that
<Nigelenki> boot: live resume=/dev/hdc99
<alp> it's a bit worrying that both the livecd and installer enable powernowd by default, even if the laptop is plugged in. it slows things down a lot, particularly the livecd
<Robot101> well, there are 209 updates available... to my livecd...
<melodie> I just read a line about the Error 2  Grub reports on Live CD's :)
<melodie> Error 21
<Robot101> that's outdated, the livecd uses isolinux
<melodie> then no more 21 Error Grubs ?
<toresbe> /usr/local/lib64/libX11.so.6: undefined reference to `XauGetBestAuthByAddr'
<toresbe> /usr/local/lib64/libX11.so.6: undefined reference to `XauDisposeAuth'
<toresbe> oops, wrong #ubuntu
<trulux> Nigelenki: mine is zv5045eu, and I needed to do a lot of tweaking to get all working with Gentoo, the MMC/Flash card reader doesn't work yet
<Nigelenki> trulux:  heh, card reader is known to not work, what about usb1.1 with an x86 base
<Nigelenki> trulux:  http://words.haddons.net/archives/000041.html  I can't get these results
<trulux> hey pitti 
<pitti> Hi guys
* pitti just taught bazaar to his gf :-)
<trulux> pitti: I was talking to tseng on the Breezy toolchain work
<trulux> Nigelenki: no idea, it just worked well for me, the ATI card was the asspain
<trulux> pitti: :D
<zul> pitti: the things you do for love
<zul> or if you are a masochist
<ogra> hey pitti
<pitti> zul: hey, she liked it :-)
<pitti> and grokked it after 10 minutes
<zul> i bet :)
<pitti> she uses it now to write heir diploma thesis
<zul> cool
<dilinger> pitti: have you branched off that and forked your own thesis? :)
<Nigelenki> trulux:  you using an amd64 base?
<Nigelenki> or x86?
<trulux> Nigelenki: x86
<pitti> dilinger: too late, I already defended mine in July 04 :-)
<Nigelenki> trulux:  usb1.1 works with ubuntu?  or you don't have it installed?
<trulux> Nigelenki: I still have gentoo in the laptop
<Nigelenki> trulux:  it's an 80 gig hard drive dude :D  you can do more than one OS
<trulux> Nigelenki: that's stupid for a laptop ;)
<Nigelenki> heh
<trulux> Nigelenki: I was running FreeBSD 5.3 before Gentoo
<trulux> and it worked well too
* dilinger upgrades to the latest bleeding edge baz (mm, crack)
* Nigelenki wants nvu
<trulux> nvu is shit
<trulux> ;)
<pitti> dilinger: 1.3.foo?
<Nigelenki> oh wow
<trulux> test Amaya or just bluefish
<Nigelenki> I was gonna burn ros 0.2.5 yesterday
<Nigelenki> 0.2.6 is out.
<dilinger> pitti: yea, lifeless just fixed a bug for me, so it's usable again
<pitti> ah, cool
<Nigelenki> " NVIDIA OpenGL hardware acceleration works (Gregor Anich)"  :D
<ogra> Nigelenki, we will have nvu in universe in breezy...
<zul> bbl...going to re-install
<ogra> Nigelenki, there is already a package waiting for reviews....
<Nigelenki> cool
<Nigelenki> ogra:  when does breezy open btw
<ogra> no idea
<Nigelenki> I want snort 2.3(.2) so that I can do some tests with the new ids
<Nigelenki> it has IPS functionality -- snort-inline merged :D
<Nigelenki> (in 2.3 rc1 or something)
<tseng> ogra: after the backports are up!
<bob2> ew, backports
<ogra> tseng, i held back on that one ;) i'm fearing it could become a running gag ;)
<bob2> if people insist on making them, they should really get help so they can work properly
<tseng> bob2: its our inside joke.
<tseng> breezy can start after someone has a breezy-backports
<ogra> ;)
<tseng> im almost certain someone is going to backport our mono stuff as soon as I put it in breezy
* Nigelenki puts a plate of crack in front of the Snort logo
<ogra> tseng, yop
<tseng> at least its better than the current situation
<Nigelenki> tseng:  You've had enough for now, this isn't hollywood :)
<tseng> people doing their own horrible mono packaging
<tseng> Nigelenki: huh?
<trulux> lol
<bob2> tseng: hah, right
<Nigelenki> tseng: <tseng> breezy can start after someone has a breezy-backports * Nigelenki puts a plate of crack in front of the Snort logo
<trulux> Nigelenki: :)
<tseng> ENOBRAIN?
<Nigelenki> anyway.  I tend to wait like, a month or two; then add the next repo to the current sources.lst
<Nigelenki> so like hoary + breezy in june maybe
<tseng> good call.
<tseng> it will be pretty broken at the start
<Nigelenki> because setting just hoary last time was like "OMGWTF HALF OF PYTHON IS MISSING!!!!!!" and it wouldn't work :)
<tseng> yeah we spent most of the cycle fixing python stuff
<Nigelenki> yeah well :>
<Nigelenki> tseng:  what we need is a "current"
<tseng> why do we need that..
<Nigelenki> or something, some way to let users elect to automatically upgrade on release day (I know it sounds insane but people do it!)
<tseng> no way
<Pizbit> Nigelenki: As you said, it's insane.
<tseng> we talked about that for update-manager, its crack
<Nigelenki> tseng:  well, maybe a modification to update manager would work instead.
<tseng> and only in the context of "tell me when there is a new stable dist"
<Akrame> what does insane mean ?!
<Pizbit> Akrame: Worse than crazy.
<Nigelenki> on release day it can be configured to say, "Hey, a new version of Ubuntu is out, want to upgrade?  It will take like a gig of bandwidth and probably a couple hours"
<Akrame> ok Ty Pizbit
<Nigelenki> and I can be like
<Nigelenki> "Yes"
<tseng> yes, we talked about that.
<Pizbit> Nigelenki: If people want debian they can go get that.
<Nigelenki> k, cause I know most of the people I'd pitch Ubuntu at are too dumb to modify their repo every six months
<liran> hmm
<liran> does the new ubuntu using bleeding egde ?
<Nigelenki> root@icebox:/mnt# apt-get install bleeding-edge
<Nigelenki> E: Couldn't find package bleeding-edge
<crimsun> liran: in what sense?
<liran> |:
<tseng> the what now?
<liran> i mean it has all the newest packages
<tseng> it has the newest packages deemed stable by us at the point of freeze
<Nigelenki> I know that's a 'no' for universe
<liran> bah stable
<liran> |:
<Nigelenki> liran:  gnome 2.10.1 and firefox 1.0. (was it 1 or 2?)
<crimsun> .2
<crimsun> liran: if you want bleeding edge, track Breezy when it opens
<Nigelenki> tseng:  Just installed ubuntu amd64 fresh (I had i386), I have 5 menu entries in grub by default
<Pizbit> liran: And don't be suprised when things break, every hour.
<liran> so what
<liran> what KDE version?
<liran> 3.4 ?
<crimsun> Kubuntu has 3.4.0, yes
<Nigelenki> Pizbit:  Is it possible to not break during development?
<liran> wtf kubuntu ?
<Pizbit> Nigelenki: Yep
<liran> crimsun im talking about ubuntu.
<Nigelenki> Pizbit:  during the last 2-3 months of hoary it seemed rock solid the whole way despite RABID UNENDING 200 PACKAGE PER DAY UPDATES
<Pizbit> Nigelenki: The last few seconds before release and you're changing the version number and updating the changelog;)
<crimsun> liran: these are questions more targetted to #ubuntu or #kubuntu, not #ubuntu-devel
<crimsun> liran: yes, Ubuntu has 3.4.0
<liran> but i came here to ask why the devs didnt worked with the bleeding egde system
<crimsun> because our developers aren't insane?
<Nigelenki> Pizbit:  I don't much like the break-fix-cleanup-release development model, whatever it's called; not that it matters.
<Nigelenki> everyone uses it though
* Pizbit grins.
<liran> crimsun so gentoo and archlinux devs are insane?
<tseng> many of them
<tseng> and by that token
<tseng> we have gnome 2.10, gentoo doesnt
<crimsun> liran: since when were we speaking about Gentoo? This is _Ubuntu_.
<Nigelenki> tseng:  breakmygentoo.net
<tseng> lets not make a flamewar out of this please
<tseng> Nigelenki: .....
<liran> I know
<liran> its just an example
<crimsun> this is _extremely_ offtopic for #ubuntu-devel
<tseng> its a poor one
<tseng> so, please drop it.
<tseng> its not valid, you should look at the versions if you are so concerned
<liran> what's the xchat version?
<liran> 2.4.3?
<Nigelenki> 2.4.1 nearest I can tell.
<Pizbit> 2.4.2 and 2.4.3 break perl scripts, or have in my experience.
<Pizbit> s/have/do
<crimsun> liran: package version information is available on http://packages.ubuntu.com
<liran> thanks
<liran> didnt knew it
<liran> hmm
<liran> the latest kernel version is 2.6.7 ?
<crimsun> no, the latest supported is 2.6.10
<liran> its good
<liran> i had 2.6.11.3 too many bugs,and it didnt do well with my ACPI motherboard
<liran> crimsun i dont mind if its not bleeding egde,i dont need much from linux,i just like to config my fvwm all the time :-)
<liran> but bleeding egde is nice,unstable but nice
<usual> I don't know who is in charge of the new Ubuntu Device Database Wizard, but I have a suggestion. When the dialog screen says press ok to send data, and the transfer begins and finishes, it just disappears. There is no confirmation of thank you. It would be nice to see something say Data sent! Thank you for your support yada yada yada
<ogra> usual, i'll put it on my todo for breezy, thanks
<usual> ogra, Thank you. I just ran the wizard for the first time and it stuck out
<usual> ogra, Terrific job on the wizard as a whole though
<ogra> stuck out ?
<ogra> thanks :)
<usual> ogra, the fact that it didn't confirm or thank
<ogra> open it a second time :)
<usual> ohh cool
* ogra must write that down anywhere, most people dont read the introduction text it seems...
<usual> I started too, but my gf was talking to me
<Pizbit> ogra: Ever the optimist.
<ogra> heh
<usual> ogra, this is a first for linux dists as far as I can tell
<ogra> hmm, suse once had something in that direction....
<ogra> (ages ago)
<dholbach> hey!
<ogra> but regarding the growth rate i see on the server it will be unique very soon, just through the community...
<usual> I remember Debian using some package to collect what packages were installed or something, popularitycontest or something
<usual> that was interesting
<dholbach> usual: popcon.ubuntu.com
<ogra> usual, you have it installed already ;)
<usual> ahh
<ogra> usual, just not enabled ...
<usual> didn't know if you guys brought that over
<ogra> hi dholbach btw
<dholbach> hey ogra :-)
* ogra is still reading the mpt review
<usual> does the project have any interest in using the anaconda port that progeny ported?
<ogra> unlikely
<usual> ok, I can't help but wonder why not though
<azeem> heh, which reminds me, Ian shouldn't be speaking so loud against Ubuntu, if Progeny had rather helped on d-i back then, maybe sarge would be out by now?
<usual> they plan on releasing sarge?
* usual chuckles
<aj> ian's speaking against ubuntu?
<ogra> oh ?
<Pizbit> Yep
<azeem> hang on, I'll dig up the link
<azeem> aj: not /so/ bad
* Pizbit digs too:)
<azeem> http://internetnews.com/dev-news/article.php/3496541
<usual> "In that respect, Ubuntu's popularity is more harmful than helpful."
<aj> i kinda think there's some truth to that, but dissin' both ubuntu and debian simultaneously in the press hardly seems helpful
<usual> I agree
<spacey> i don't think he is right at all :p
<spacey> like debian is some "Greater Good" or something
<ogra> spacey, it is...and sarge will suffer from ubuntu if they dont release it this year, but both is not ubuntus fault....
<usual> it almost sounds like jealousy
<azeem> well, he's basing his product pretty tightly on Sarge I think (though I don't know how important that product is for his company and maybe they released it already, haven't followed)
<spacey> funny how they are so good, and distro for many years, and they complain about ubuntu, and they can't get a release out of the door
<azeem> spacey: who is "they"?
<spacey> debian :p
<spacey> or ian whatever
<dholbach> debian needs a DPL who makes strict changes, which are obvious
<azeem> Ian is part of Debian
<spacey> yeah 50%
<spacey> :D
<usual> Debian is notorious for very late outdated stable releases
<azeem> eh, Ian is not part of Debian
<usual> he's the ian in debian
<usual> heh
<spacey> yeah
<azeem> I know.
<aj> azeem: he's in the last stages of n-m, he'll be part of debian soon :)
<azeem> yeah
<kent> 8900 posts in hwdb.ubuntu.com.  Perhaps soon 10.000? Thats not so bad. Since i guess not all people posts..
<usual> 900 something today
<ogra> kent, its running 12 days now, yesterday i had more then 1600 submissions....
<spacey> yeah pretty cool
<spacey> Submissions Total: 8927 Today: 1000
<ogra> so i guess it will pass 10000 tomorrow
<usual> I have always wondered why so many dists use RPM, I want to know from a technical aspect, why? I know why I think dpkg/apt is superior, but what reasoning do these dists have for deciding to base on rpm
<kent> Its kind of strange that Fedora and Suse has not done something like hwdb (or have they?). It must be very nice to get a brief look of what hardware people run..
<usual> m$ does it I think
<ogra> kent, suse once had such a db, but no client app, it was derived from their support forum...
<kent> usual, perhaps they copied redhat linux once, and  i guess its a pain to change? But im no expert.. 
<kent> ogra, I guess its far better to have a client to collect information from hal rather than having user submitting in a forum.. :)
<usual> kent, yes, I understand that. But all these new dists, I mean there are new ones every day. Why still choose to start there
<ogra> and i remember the early days of redhats kudzu, there you had such an app...but it was only used internal and for kudzu development
<usual> is gnome still doing some sort of bounty to free up bloat?
<usual> or optimize code
<kent> ogra, regarding kudzu, I kind of like how it tells when a user has put in a new hardware, like printers etc. Perhaps the configuration of those devices could be made automatic and not bather users with it, and perhaps it could be made in Gnome rather than in text on boot, but its still a nice feature. Some people for example change graphicscard, and thats not so easy to manage manually :(
<ogra> kent, thats one of the endless usecases of our DB :)
<kent> ogra, you meen it can be used to get those events, where for example some card has changed? that would be great! 
<ogra> kent, if i have a local database on your pc that knows which kind of hw you have....sure...just tie it to hal and hotplug....et voila
<usual> ogra, still working on mrburns?
<kent> ogra, perhaps one solution might be that, if X dont start, then check against hal and the db..  That way it wont have to be checked on each boot?  Sounds like a fair solution :)
<ogra> usual, not recently....and there is a better project (serpentine), so i'm considering to dump it
<ogra> kent, yup, something like that
<usual> ogra, what about gnomebaker, opinion?
<ogra> usual, is in universe ;)
<Pizbit> graveman is better, it actually lets you set a label for dvds:)
<ogra> its there too :)
<Pizbit> yep
<ogra> coaster sadly didnt make it
<ogra> but will be ready for breezy i guess
<azeem> nautilus-cd-burner can now copy CDs, right?
<usual> ogra, my experiences with coaster have been awful
<ogra> caster is a great piece of software if its ready.... it can finally replace cdrecord which is a _huuuuge_ advantage
<ogra> coaster even
<usual> I would love to see a gnome port of amarok
<usual> awseome software
<Pizbit> Hrm, anyone got the home page of coaster handy? Not exactly high in the google.com/linux rankings for 'coaster' :)
* Akrame is away (Bye)
<ogra> coaster.sf.net ?
<Pizbit> Just found it,hehe, cheers.
<kent> coaster-burner.org 
<zenrox> i like to see a good port of flashFXP from windows some of the fetuers thare are nice and i havent found a linux ftp to match that
<kent> there is a debian/ubuntu hoary package for it aswell on that page.
<Pizbit> kent: Yeah, got redirected there, but the page loading load anything
<usual> same here
<Pizbit> Hrm, sleep, cyas.
<Zugot> what package is dch? in?  
<Zugot> the dch that allows me to modify the debian/changelog file
<dholbach> apt-file search usr/bin/dch
<ogra> devscripts
<moquist> I hope I'm not bringing up an old and contentious issue, but why doesn't apt have some more locking smarts?  I have an NFS-mounted /var/cache/apt/archives directory so that I can minimize my external bandwidth usage, and of course .deb files get clobbered whenever I forget and install the same thing in more than one place at a time.
<Lathiat> it does have smarts
<Lathiat> you cant run more than 1 apt at once
<Lathiat> your not supposed to use a network share :)
<Zugot> ogra: thanks
<moquist> Lathiat: yeah, I figured so.  but why not?
<Lathiat> moquist: look into apt-proxy/apt-cacher
<moquist> Lathiat: k; thx.
<Lathiat> better solution to said problem anyway
<moquist> I figured I couldn't possibly be the first one to think of this or run into problems with it.  :)
<Lathiat> heh
<moquist> as long as I'm careful about concurrency and collision, the NFS share works very well.  (well, AFAICT)
<Lathiat> :)
<Lathiat> apt-proxy is good but
<Lathiat> lets you fetch more than one time at once
<moquist> Lathiat: apt-cacher looks perfect.  thx.
<Lathiat> nps :)
<fabbione> lamont: ping?
<pitti> Hey fabbione 
<fabbione> hey pitti
<moquist> Zugot: you may wish to note the apt-cacher discussion...
<abelli> ogra: have you thought about the nautilus thing (moving files with rootly power)?
<ogra> abelli, nope, not yet
<abelli> shall we open something on the wiki?
<abelli> to collect ideas?
<ogra> abelli, i'm currenty busy with hwdb...dunno if i have time to hack on nautilus before breezy, but a wiwki page would be good...
* shaya is going through update withdrawel. :( no new packages to download in over a day
<ogra> thats how stable works :)
<abelli> ogra: doh. humour.
<ogra> heh
* |QuaD- doesn't like stable
<desrt> ya.  stable is really boring!
<desrt> so when someone says "we'll be moving to alsa 1.0.8 after hoary is released" does that mean:
<desrt> a) hoary will upgrade to 1.0.8 some time after release
<pitti> no
<desrt> b) breezy will contain 1.0.8
<pitti> hoary will not be changed any more
<pitti> b) is true
<desrt> crap.
<desrt> i just bought an sblive for my family's computer
<desrt> the alsa in hoary doesn't like it
<crimsun> more than likely we'll see 1.0.9 if thomas can push it out the door.
<desrt> although, i suppose now that hoary is stable, i don't have to worry about keeping up to date with the latest kernel releases
<crimsun> 1.0.8 already is in alsa-source from Hoary/universe
<desrt> ya.  it doesn't appear to work, though
<crimsun> for which sblive card?
<desrt> i say --enable-cards=ca0106 or whatever it is
<crimsun> the 24-bit sblive/7.1?
<desrt> and it tells me that ca0106 is an unsupported card
<desrt> ya.  it's evil.
<crimsun> ya, total piece.
<desrt> i'd take it back
<desrt> but an audigy is like 2.5x the price
<crimsun> desrt: erm...ca0106 is available in 1.0.8...
<desrt> crimsun; and i'd agree with you upon reading ./configure
<desrt> but for some reason, it doesn't work
<desrt> and i'm *guessing* it's because i need kernel source installed too, and the error reporting for that sort of thing is really bad
<crimsun> desrt: no, you only need linux-headers-$(uname -r)
<desrt> hm.  sexy.
<desrt> does that take care of the 686-5 or whatever business?
<crimsun> pretty much what you need to do is grab build-essential, linux-headers-$(uname -r), and alsa-source, then dpkg-reconfigure alsa-source, then follow /usr/share/doc/alsa-source/README.Debian
<crimsun> yes, it takes care of the append-to-version stuff.
<desrt> hot.
<desrt> man
<desrt> i should have come in here earlier
<desrt> i found some stuff on a mailing list about this but it was defective
<crimsun> on average, I probably walk two people daily through the whole alsa-source process
<desrt> heh.
<crimsun> I recommend using the last line of /usr/share/doc/alsa-source/README.Debian and bypassing the kernel-package business
<desrt> ah.  yes.  this looks a lot nicer.
<desrt> this is gonna roll me a .deb isn't it?
<desrt> what does the dpkg-reconfigure business do, exactly?
<desrt> make the debian/rules script behave differently?
<azeem> it restarts debconf for that package
<crimsun> desrt: sets the parameters passed to ./configure
<azeem> eh, I'm out of the loop obviously
<desrt> crimsun; that's what i thought
<crimsun> desrt: i.e., whether to enable PnP support, whether to enable debugging code, which drivers to pass
<desrt> it's doing stuff now :)
* desrt goes to cook a pizza
<desrt> slow box :)
<desrt> just a point of curiosity
<desrt> do you know if this card will play sound from multiple sources simultaneously?
<crimsun> I believe it's severely crippled.
<desrt> the first thing my sister did when i installed the box was kill off esound
<crimsun> you'll need to use a sound daemon or dmix.
<desrt> since it messes with flash's ability to work
<desrt> and she's a flash kiddie in the worst sense
<desrt> ugh.  if that's true, then the card has to go back
<crimsun> actually flash works with esd, you just need to create the necessary symlink (ln -s /usr/lib/libesd.so.0 /usr/lib/libesd.so.1)
<crimsun> blame macromedia
<desrt> that's interesting.
<desrt> so wait...
<desrt> dmix will work with *any* card?
<crimsun> yep
<desrt> wtf did i even waste my money on this piece of junk?
<crimsun> I dunno, I would have gotten a tried n' true sblive value
<desrt> they didn't have it
<desrt> my choice was 24bit live or audigy
<crimsun> ouch, those were the only two sound card choices?
<desrt> well
<desrt> plus a bunch of other stuff i wouldn't have even considered
<crimsun> the turtle beach santa cruz does multiplexing natively like the uncrippled sblives
<desrt> and then a whole whack of retail boxes
<desrt> i typically only buy OEM
<crimsun> (uses the snd-cs46xx driver)
<desrt> well, basically
<desrt> i thought i was buying an emu10k1 for $34
<desrt> does libesd-alsa0 do what i think?
<desrt> ie: esd clients play straight to alsa instead of going through esd?
<crimsun> err, that would be support for the alsa backend
<desrt> ya.  i don't get it
<desrt> this tutorial is telling me i need dmix *and* esd
<crimsun> to do what? (let's take this to #ubuntu)
<desrt> good call!
<mwh_> hi, I have a quick question .. about gnome-applets .. im wondering why I cant set my clock to display weeknumbers
<mwh_> I tried to find the clock applet in gconf-editor
<mwh_> but it does not show up
<mwh_> I have upgraded to ubuntu hoary
<mwh_> and I was wondering if the gconf stuff got installed
<mwh_> maybe its a bug
<kent> mwh_, #ubuntu for those questions.
<mwh_> noone there seems to know the answer :(
<mwh_> anyways ill try to ask there again
<seb128> mwh_: there is a gconf key
<dholbach> seb210 is here! woohoo! :-)
<seb128> hey dholbach 
<seb128> ah ah :p
<dholbach> you must be terribly bored, right? :-)
<mwh_> seb128: but it does not seem to be installed for me
<seb128> mwh_: use gconf-editor to search for a key with "week"
<mwh_> seb128: how can I have it installed
<seb128> what ?
<mwh_> seb128: I did that but it is not installed the gconf schema
<seb128> no
<seb128> use the search feature
<seb128> the key is a dynamic settings for the running panel
<seb128> there is no static path
<seb128> /apps/panel/applets/applet_<n>/prefs/show_week_numbers
<seb128> where <n> is the applet number
<mwh_> seb128: ahh sorry it is installed but it does not show up in gconf-editor for my user
<mwh_> its installed here /etc/gconf/gconf.xml.defaults/apps/panel/default_setup/applets/clock/%gconf.xml
<mwh_> so it should show up
<mwh_> if I look in ~/.gconf/apps/panel/applets/ then there is no clock directory
<seb128> have you read before ?
<seb128> not sure of what is not clear
<seb128> "search with gconf-editor" ?
<tseng> http://mpt.net.nz/
<tseng> why do people think this is acceptable, its an osnews-ism
<mwh_> seb128: the key does not show up in gconf-editor
<tseng> "lets post my complaints about gnome, and pass it around some websites"
<tseng> thats not bugzilla.
<mwh_> seb128: I have two boxes .. both upgraded to hoary .. on one of them the key exist and on the other it does not
<ogra> tseng, but he is right in many places
<ogra> s/places/points
<seb128> mwh_: create it
<mwh_> seb128: I should probably try to ask this question in a gnome channel ;)
<seb128> you will not get an another reply
<seb128> that's a runtime setting for the clock applet
<mwh_> maybe I will 
<seb128> and try to not just ignore people reply like you do here ....
<mwh_> seb128: was that for me?
<seb128> who else ?
<mwh_> hopefully im not ignoring anyway, if I have done so .. im sorry
<mwh_> I must have overlooked something
<seb128> have you tried to create the key ?
<mwh_> how to do that .. 
<seb128> gconf-editor
<azeem> tseng: did you read the end of that review?
<seb128> right click
<azeem> "My boss, by the way, is Mark Shuttleworth. I'm working for his company, Canonical, as an interface designer."
<mwh_> seb128: it is all of the clock settings which is missing
<mwh_> seb128: there is no folder named clock
<mwh_> it goes like applet_0 ... applet_4 then mixer
<mwh_> seb128: thats the really wird thing about it
<ogra> mwh_, did you read what seb128 wrote above '?
<mwh_> ogra: yes I think I have
<seb128> <seb128> /apps/panel/applets/applet_<n>/prefs/show_week_numbers
<seb128> <seb128> where <n> is the applet number
<seb128> again
<seb128> I've not spoken about clock
<ogra> seb128, heh, youre to fast
<seb128> why do you insist on it ?
<mwh_> argh
<mwh_> :(
<mwh_> im so stupid
<mwh_> seb128: sorry .. 
<seb128> np
<mwh_> here is the thing which really got me confused
<mwh_> on box1 of mine I took an etc directory from a hoary development install and replaced it with the etc dir from my newly upgraded hoary
<mwh_> and there the folder and key clock existed
<mwh_> but the other box I did not change the etc dir at all
<mwh_> and there it did not exist
<dholbach> mwh_: never ever do that
<mwh_> that did confuse me a bit :(
<mwh_> I did it, because the bootup procedure did not change with my upgrade of warty to hoary
<dholbach> you can replace single configuration-files, if you completely know what you're doing
<mwh_> and I wanted the slick and fast bootup
<ogra> mwh_, ubuntu-base should have taken care of that
<dholbach> everything else will fuckup your system severly
<mwh_> ogra: it did not for me :( 
<mwh_> its working okay though 
<mwh_> or that is its working, still some stuff which is not
<mwh_> anyways im walking through the etc dir to check each file for differences
<mwh_> btw do you guys know why the applet-configuration entries has changed from something like clock to applet_n?
<seb128> mwh_: these are dynamic panel settings (again)
<mwh_> ogra: I just did a search on ubuntu-base and it was not installed :( 
<mwh_> seb128: ahh
<seb128> mwh_: the panel don't know the difference between "clock" or "weather"
<seb128> it just has applets
<ogra> mwh_, thats why the upgrade notes state explicitily the importnce of ubuntu-desktop and ubuntu-base on upgrade :)
<seb128> you can have 2 clock applets
<seb128> 1 with and 1 without the week numbers
<mwh_> aha
<mwh_> nice
<mwh_> ogra: argh .. I must stop upgrading in the middle of the night, I miss to much :(
<ogra> http://www.ubuntulinux.org/wiki/HoaryUpgradeNotes
<mwh_> ogra and seb128 many thanks, I must stop bothering you guys ;)
<melodie> beg your pardon, I am being upgrading from Hoary Array7 - I don't need nvidia pilots and the dl brings the nvidia-kernel-common
<melodie> should I have deselected it at some time ?
<mwh_> seb128: I have another wird problem .. its with synaptic .. when I install with it it displays the shell like the old synaptic in warty and I cant get it to not display the shell .. do you have a clue about what might be wrong?
<kent> tseng, though i dont like the osnews-way of posting things on internet and refusing to help/listen,  that articel was kind of good.  Personly i think its needed, but it should be done in cooperation with Gnome development, and not on a homepage in fare distant from the developers.  :)
<azeem> mwh_: this sounds more on-topic in #ubuntu
<mwh_> azeem: yes
<mwh_> azeem: found a solution it was the settings which was set to allways install in a terminal window :(
<mwh_> better get out of this channel before I ask more questions :)
<mwh_> happy hacking guys!
<azeem> hmm, this is annoying. My mouse cursor has changed to the 'resize window' one and I cannot click anything anymore
<trulux> Error: API mismatch: the NVIDIA kernel module is version 1.0.7167, but
<trulux> this library is version 1.0.7174. Please be sure that your kernel
<trulux> module and all NVIDIA driver files have the same driver version.
<kent> azeem, sometimes my mouse gets f*cked up, but thats becaus it has several buttons (actually 5 buttons), and once i dropped the mouse on the floor which damaged it so sometimes the button to the left get stucked, which the system dont like :(
<azeem> heh
<azeem> for some reason I do not comprehend, it now switched back after about 15 minutes
<kent> azeem, well, its not relevant that it has several buttons, but since it has several, and i dropped it once,  it was doomed to damage one of them  *grr*
<azeem> this is a Thinkpad. I'd rather not try to reproduce your experiment :)
<kent> azeem, but you can buy one of those cheap mouse-bastards and drop it, if you got the time over.. ;)
<ogra> Riddell ?
<dholbach> i think i'll go to bed for now... bye
<pitti> good night everybody!
<mkde> mako, ping?
<Riddell> ogra: hmm?
<ogra> Riddell i just have testcompiled a kde package and was to lazy to clean up my broken chroot before... (i used debuild-pbuilder)....
<ogra> Riddell, pbuilder pulled in a lot of KDE dependencys....
<ogra> obviously konqueror is one of them..... when i clicked a url, it opened beside my 32 mozilla windows....(in gnome)
<ogra> does konquereor automatically set x-www-browser ? without debconf question ?
<azeem> x-www-browser is handled by alternatives, no? I guess this would be an issue of priority
<ogra> it shouldnt set it silently....i really dont like if my browser changes during a session...without me requesting it :)
#ubuntu-devel 2005-04-22
<blahrus> in beep-media-player in hoary amd64 was mp3 support taken out.
<crimsun> absolutely not.
<crimsun> why?
<blahrus> crashes everytime I try to play one.
<crimsun> blahrus: let's take this to #ubuntu
<blahrus> alright not a problem, just wanted to check here first
<netdur> in case you don't know, very interesting "My first 48 hours enduring Ubuntu 5.04" to read http://mpt.net.nz
<mdz> hehe
<netdur> thanks for Ubuntu
<ogra> yeah
<mdz> the blogging community agrees that the most interesting difference between Ubuntu and FC3 is the default theme
<dilinger> yuck
<dilinger> Clicking once in the address field does not do what people want 99 percent of the time, which is selecting the address so it can be replaced by typing a new one.
<dilinger> (firefox)
<tseng> mdz: or a hugely noticable speed increase
<dilinger> i despise that behavior
<tseng> mdz: or a lack of poor branding
<tseng> fc3 is a bit painful
<mkde> omg
<mdz> dilinger: you can turn on that damage if you want it
<mkde> gotta love tiger woods
<tseng> how is tiger woods on topic?
<mkde> c'mon man
<mkde> sorry to have taken up your bandwidth
<azeem> firefox still has native UI and not GNOMEish icons and stuff, right?
<azeem> or did I miss installing a package?
<ogra> nope
<ogra> its the native theme
<tseng> I suggest installing the industrial firefox theme anyway
<tseng> its much nicer.
<spacey> what happend with the gnome firefox theme, i liked it :p
<azeem> I wonder why he just picked on the Home icon and not flamed for inconsistent UI
<eruin> the deafault gnome icons have nothing to do in an app like firefox
<eruin> minus an a
<azeem> an app like firefox has nothing to do in a default gnome desktop, rather :P
<netdur> mozilla developers confurmed to me, that mozilla suite (seamonkey next) will uses icons theme as any other gtk/gnome app, moving to gtk+, actually mozilla 1.8 already uses native gtk+ 2.6 file dialogs... sadly mozilla suite die, still better than firefox
<robertj> netdur: why do you say that?
<robertj> I'm just a bit sad that Composer development has been limited to Nvu
<netdur> robertj, friefox still freeze few seconds here
<blahrus> mdz: that did fix the bug issue of 8696
<mdz> blahrus: thanks, please mark it as a duplicate then
<blahrus> mdz: done
<mdz> thanks
<blahrus> crimsun: you around? sorry I was jumping off and on
<netdur> er... sorry to ask!!! is there any plan to do ubunu with bsd kernel!?
<tseng> nope.
<tseng> feel free to start one.
<robtaylor> netdur: there are some projects to do debian with a bsd kernel. you might want to check those out
<mkde> are the security repositories working or not yet?
<netdur> LOL, I feel that would a clear message to you-know-who "killing linux doesn't kill open source" ;)
<eruin> and feed the bsd rox, linux sux-trolls
<robertj> oh happy day
<robertj> Linksys has added QOS to my Wireless Router
<zul> hey..
<zenwhen> :/ it seems sometime between RC and final Bistream Vera Sans started looking like crap.
<mdz> I find that highly unlikely
<dredg> zenwhen: more likely your fontconfig settings changed
<daniels> fontconfig didn't change between rc and final
<dredg> right, but the per-user settings might
<jsgotangco> hello
<kent> Sorry if this is OT. Im thinking of reporting a bug/enhancement to Gnome bugzilla about the trashcan in Nautilus. Bugzilla in gnome lets me specify not only version but target. Whats "target"? Version is 2.10.x, but I cant figure out what target to choose :(
<kent> sorry, i think its my fault. I was on the wrong page ;(
<shaya> anyone here running beagle?
<toresbe> Why has the standard PDF reader changed from gpdf to xpdf?
<melodie> bye all :)
<thom> toresbe: it's always been xpdf
<toresbe> thom: yeah, but it was scheduled to change in Hoary
<thom> toresbe: only if gpdf started to not suck, which wasn't the case
<toresbe> ah, I see..
<toresbe> The site said they expected it to stop sucking, but... it didn't... *sigh*
<mdz> thom: now, we'll probably go to evince instead
<mdz> that's what seb128 recommends
<mdz> it combines ggv and xpdf with a GNOMEish UI, which sounds nice.  I haven't tried it yet
<jdub> yes, i find it highly unlikely that evince won't be doable for breezy
<daniels> evince is very nice indeed
* toresbe tries
<Burgundavia> I will second that
<jdub> it will most likely be included in 2.12
<thom> mdz: indeed
<thom> evince is awesome
<toresbe> wow, you guys make it sound so cool
<toresbe> *tries*
<toresbe> neat
* jdub chuckles at DPL results
<toresbe> and fast, too!
<toresbe> shit, that's fast
<Burgundavia> jdub, you aren't a DD, are you?
<maswan> jdub for DPL! ;)
<jdub> Burgundavia: no
<Burgundavia> jdub, didn't think so
<toresbe> what was branden's view on platforms?
<mdz> jdub: it is so not funny
<infinity> jdub : You'll get yours.  Somehow. :)
<shaya> evince needs continious mode
* sladen joins in the orgy and pimps evince
<jdub> shaya: coming, i believe
<sladen> shaya: file it and get it in, your've got 6 months ;-)
* infinity realises he has to be at an immigration interview in under an hour and decides to leave.
<jsgotangco> evince is nice
* jsgotangco goes back to lurker status
<Nigelenki> what the fuck keeps breaking me with damned bad dns settings
* Nigelenki chattr +i /etc/resolv.conf
<Nigelenki> there.  Bite that bitch.
<fabbione> morning
<jdub> Nigelenki: keep it nice here, please
<Nigelenki> jdub:  I'm slightly annoyed.  I changed dhclient.conf or whatever to not ask for nameserver info, but every 2 hours I get my resolv.conf pointing at 192.168.0.1 which doesn't have a dns server on it.
<jdub> Nigelenki: that's fine - but keep it nice here, please
<nullaresnata> Hello, I was trying to use the utf8migration tool, but it gives me an error at the end, when it comes to rename the files in utf8.
<nullaresnata> Anyone has an idea about this?
<nullaresnata> The output error is:
<nullaresnata> Traceback (most recent call last):
<nullaresnata>   File "/usr/bin/utf8migrationtool", line 92, in change_setup
<nullaresnata>     os.rename(oldfile, newfile)
<nullaresnata> OSError: [Errno 2]  No such file or directory
<mdz> nullaresnata: please file it in bugzilla (if it isn't there already)
<nullaresnata> Ok.
<nullaresnata> I do not know how to do it.
<jsgotangco> just create an account in bugzilla
<nullaresnata> Have to install bugzilla?
<jsgotangco> https://bugzilla.ubuntu.com/
<Pizbit> No, they never said that.
<jsgotangco> its an online ticket/response tool for bugs, etc.
<mdz> it is necessary to create an account in order to file bugs, yes
<nullaresnata> Ok... found this, mdz. http://www.ubuntulinux.org/wiki/BugzillaHowto/view?searchterm=bugzilla
<nullaresnata> Why oh why do I do not RTFM???
<nullaresnata> lol
<jsgotangco> *grin*
<jsgotangco> its alright we learn from mistakes
<ajmitch> afternoon all
<nullaresnata> Hello again.
<nullaresnata> I found 2 bugs there for the same mistake.
<nullaresnata> One of them has a patch.
<nullaresnata> How do I use it?
<nullaresnata> https://bugzilla.ubuntu.com/show_bug.cgi?id=7723
<nullaresnata> Think I got it right.
<nullaresnata> Thanks anyway.
<nullaresnata> :)
<nullaresnata> Yes, I got it right ;)
<dholbach> hey
<ajmitch> hi dholbach :)
<hondje> Hi. I think I might have found some borkage in Nautilus.  Where is the Ubuntu bug-tracking thing?
<crimsun> bugzilla.ubuntu.com
<dholbach> bugzilla.ubuntu com    aaaaand     https://launchpad.ubuntu.com/distros/ubuntu/+bugs
<hondje> great, thanks :-)
<hondje> I don't see this bug, but I'm convinced it's nautilus
<hondje> Would #ubuntu be a more appropriate forum to get someone to test it?
<mpt> Hmmm
* mpt decides to fix that bug listing, it's too damn wide
<daniels> mpt: so, are the tables not entirely javascript now?
<daniels> mpt: the inability to open bug links in tabs renders it almost entirely useless to me
<daniels> mpt: (on a typical morning with bugzilla, i'll look at my bug list and open ten or more bugs in new tabs)
<mpt> I think someone else fixed that
<mpt> lessee
<mpt> daniels: Yes, that's fixed
<mpt> It should be fixed on launchpad.ubuntu.com sometime today
<daniels> awesome
<maswan> daniels: I see you are no longer the most southern map inhabitant?
<daniels> maswan: bugger.  bloody kiwis. ;)
<daniels> heh!  'quannum'. :)
<ajmitch> sorry daniels :)
<maswan> I'm on top of the world!
<maswan> ;)
<womble> OK, what's going to have caused the version of a package in hoary to be months old compared to the version in Debian sarge?
<schweeb> womble: no one requested a sync?
<schweeb> what package are you talking about?
<womble> schweeb: IRM.
<womble> The version that's in hoary universe is crustirifically old.  There's been 3 uploads since the one that's in hoary, dating from January.
<dholbach> we'll have it in breezy
<womble> dholbach: I'm more interested in knowing why it didn't get updated in hoary.
<dholbach> womble: i can't tell you when the last BIG SYNC was
<dholbach> the big-syncs had to stop at some point to make the overall situation settle down
<womble> dholbach: So in order to make sure that I don't get asked for support on horrendously out-of-date versions of stuff I maintain for debian, I need to poke someone in Ubuntu every time I make an upload in Debian?
<schweeb> otherwise the MOTUs would have to work their butts off to stabilize universe :)
<dholbach> womble: in the last weeks before release, yes, if nobody else complains about an out-of-date version
<schweeb> womble: it's helpful, yes
<womble> We're talking about code from January.  Over two months ago.
<thom> womble: which is when we froze, yes
<womble> Now, I know you've carried some traditions over from Debian, but I thought glacial freezes weren't one of them.  <grin>
<schweeb> gotta freeze sometime man
<maswan> two months seems resonable, even a bit on the short side for a freeze
<schweeb> otherwise you end up having to fix all of your bugs AFTER release
<dholbach> womble: if you have a better plan by the hand, start a discussion on ubuntu-devel@
<schweeb> need some level of QA
<womble> So can I request my packages don't get synced and just get removed instead?
<Lathiat> there is the MOTU team
<schweeb> no?
<dholbach> i wonder if it's reasonable to remove a package in that case
<Lathiat> you can overee pakages (specific packages) getting in after the syncs
<schweeb> have there been major security holes in it or something?
<thom> womble: if you're really that concerned about 2 month old code, i suspect you're going to be crying for some time after debian releases *shrug*
<schweeb> I mean, when sarge releases (if it ever does) there will be a version freeze too...
<womble> schweeb: Yes.  As well as a lot of major improvements to the functionality of the code and it's packaging.
<Amaranth> schweeb: fix all your bugs after release? that sounds so microsoft ;)
<womble> Yep, but I can handle that because I track Debian development.
<womble> thom: I wouldn't be worried about it if I knew what was going on.
<HiddenWolf> In dutch we have a saying for this kind of discussion. "a thunderstorm in a glass of water"
<schweeb> Amaranth: I wasn't advocating that
<thom> HiddenWolf: "a storm in a teacup" is the english :-)
<Amaranth> schweeb: I know, I was trying to be funny. :)
<schweeb> heh
<HiddenWolf> thom, fair enough
<thom> womble: there will  be stuff in the future that allows us to interact better with debian maintainers; but it ain't there yet
<HiddenWolf> womble: it's easy, this is open source software. No-one is getting paid to do what he doesn't like. Importing packages after a freeze is quite high on the don't like list. If you want it to happen, you'll have to make the effort, or find someone to do it for you.
<womble> thom: So, in the meantime, I should just prepare a form letter to send to everyone who asks me why IRM on Ubuntu sucks balls?
<womble> HiddenWolf: Yes, but I've still got my name on it, and I still get all the flack for why it's screwing up.
<HiddenWolf> womble, in that case, feel free to blame ubuntu, and tell people that for fast, accurate and utterly cool cutting-edge software, they should really really use debian.
<thom> womble: so just say you don't support the ubuntu packages and direct them to us
<aj> HiddenWolf: be nice
<womble> HiddenWolf: Cute.
<thom> womble: alternatively, don't suck packages that suck balls? ;P
* HiddenWolf grins at thom
<Lathiat> aj: coming to LCA?
<aj> yah
<Lathiat> cool
<thom> aj: so that's you and matthew to buy commiseratory drinks for; or possibly all of debian
* HiddenWolf has a tendency to be sarcastic before breakfast, sorry womble, aj
<aj> thom: gus should be there too
<HiddenWolf> I wonder why anyone would review FC3 over Ubuntu. :/
<womble> Is there something, somewhere that describes how random packages end up in Ubuntu from Debian?  Where they're sourced from, what the freeze dates are, criteria, requesting resyncing, that sort of thing?  If I'm going to do this, I'd at least like to do it properly.
<schweeb> womble: not "random" packages
<schweeb> we pretty much mirror debian completely
<thom> aj: ah, good point
<Lathiat> womble: If you like, you could become part of the MOTU team and ensure your packages are up to date in ubuntu.
<schweeb> womble: IRM is in "universe" the more "unsupported" branch... the Masters Of The Universe are in charge of Universe
<womble> Is there documentation or not?
<schweeb> not really, at the moment
<schweeb> but, join #ubuntu-motu to confer with the MOTUs any time you feel like
<schweeb> womble: there usually is a schedule laid out of freeze dates and such, but there was just a release, so I don't think a new schedule has been laid out
<schweeb> womble: http://www.ubuntulinux.org/wiki has a lot of info
<womble> schweeb: That's like saying "http://www.google.com/ has a lot of info" -- true, but unhelpful.
<spiv> womble: as far as dates of freezes go, see https://www.ubuntulinux.org/wiki/HoaryReleaseSchedule.  I expect there will be a similiar page for Breezy shortly.l
<schweeb> womble: I expect you can read the base topics and click links yourself *shrug*
<schweeb> spiv: I suspect not until after UDU
<womble> schweeb: One I clicked was termed "Ubuntu Code of Conduct"
<schweeb> and?
<jdub> womble: http://www.ubuntu.com/wiki/HoaryReleaseSchedule
<jdub> womble: UVF is when syncing from sid is stopped
<jdub> womble: after that it's done for bugfixes only (in main) and requested/tested updates for universe
<womble> jdub: So you're syncing direct from sid?  Does any of the MOTUs actually check that what's in Universe is reasonable after that date?
<dholbach> womble: there are lots of areas that haven't been covered by documentation yet, http://wiki.ubuntu.com/MOTUToSync is the place where we note down syncs that are to be made
<dholbach> womble: our team is still growing, so we mostly rely on information from users/developers
<dholbach> womble: a team of 10-20 people cannot perfectly handle 12.000 packages
<aj> oh, MOTU = Masters of the universe?!
* aj finally gets it
<dholbach> aj: yes :-)
<schweeb> aj: yes!
<jdub> whee -> http://150.203.164.99:8800/
<aj> i'd been wondering for days, maybe weeks
<womble> dholbach: Unlike Debian, though (which basically presents using testing as a fair accompli), Ubuntu releases often enough that there will be insufficient test coverage of Universe to pick up all the problems in Universe.
<schweeb> more jdub tv!
<womble> Before release, at least
<dholbach> womble: i can only hope our team will grow and we will form subteams which are aware of upstream/debian package changes
<schweeb> or maybe not
<schweeb> jdub: what is this?
<jdub> schweeb: room of hackers ;)
<jdub> i'm behind the camera atm
<jdub> stream testing for lca
<schweeb> ahhh
<schweeb> who is on cam?
<womble> dholbach: I don't think it can be done with the number of people you've got, either, but I don't think that saying "oh well" and letting it all hang out is the optimum point.  You'd be better off not syncing all of Debian, in that case (or at least not Sid, which might stop a few of the problems)
<jdub> schweeb: kfish and ozone
<spiv> jdub: Awesome, it made xine segfault.
<schweeb> womble: the point of the freeze is to hopefully find problems in universe and stabilize them
<womble> schweeb: Which depends on having a large enough pool of testers with sufficient motivation to withstand the breakages of pre-release software
<schweeb> while still providing a huge number of packages for people
<dholbach> womble: as i said, i hope we grow soon, but before that we will have to take all the snide of people saying "you can't handle it"
<womble> Debian provides that with a stable release that is so old as to be somewhat unusable, but Ubuntu releases frequently enough that many people will stick with the releases
<dholbach> jdub: could you wave into the camera for us?
<womble> dholbach: It's not a snide comment, it's something you yourself admitted.
<zenrox> nice but
<zenrox> butt
<dholbach> womble: i said all i could say about it :-/
<schweeb> womble: I still haven't heard of an actual major problem with the package in question, other than the fact that it's a few revisions behind the Debian one
<schweeb> is there a major bug in it?
<womble> schweeb: It's broken.  Badly.
<schweeb> or is it just old?
<zenrox> hi hand
<zenrox> jdub,  whats with the green line
<schweeb> womble: okay, elaborate on broken. and do you know the cause of the brokenness?
<dholbach> womble: i believe the overall situation will improve
<dholbach> a lot
<dholbach> :-)
<schweeb> basically, we're learning from our mistakes right now
<schweeb> and refining proper procedures
<womble> schweeb: Doesn't install on Hoary, doesn't uninstall on Hoary, probably has a pile of security bugs large enough to drive a truck through, bunch of usability and stability bugs.  Etc.
<schweeb> dholbach: something I've wondered, do the buildds test for install problems with packages?
<schweeb> or does anything
<dholbach> schweeb: we had a list with the output of    apt-cache -i unmet     around
<dholbach> but that doesnt cover all
<schweeb> ah
<dholbach> UniverseUnmetDeps
<schweeb> dholbach: do we currently have any scripts in place to track ubuntu versions vs debian versions?
<kent> womble, what is the package in question? I just connected to irc.
<schweeb> kent: irm
<dholbach> schweeb: not really
<womble> kent: irm
<schweeb> dholbach: perhaps I'll work on some... maybe with breezy I could generate a daily/weekly changelog or something
<ajmitch> schweeb: not too hard since there's a changes list for unstable
<schweeb> yea
<dholbach> or some nice script using python-apt
<schweeb> I was thinking more of comparing the versions in Packages.gz, but the emails might work too
<dholbach> shouldnt be too hard either
<dholbach> i used python-apt for the apt-get.org thing
<ajmitch> or use the existing merge tools that ubuntu uses
<schweeb> I'll be using perl if anything :)
<jdub> whee -> http://150.203.164.99:8800/
<dholbach> i'm off, bye
<womble> jdub: You know, you strain your neck doing that.
<pitti> Hi folks
<mike_douglas> are there going to be theora streams at "Ubuntu Down Under" for those that cannot make it?
<jdub> mike_douglas: no
* Treenaks watches Ubuntu TV?
<Treenaks> ah
<Treenaks> it's jdub TV with a twist!
<Lathiat> jdub: what are we watching?
<Lathiat> now im watching jdub :) haha
* Treenaks sees jdub's pants..
<Lathiat> thats an unusual siting
<Amaranth> URL?
<Treenaks> 08:40 < jdub> whee -> http://150.203.164.99:8800/
<Lathiat> too many powerbook
<Lathiat> s
<Amaranth> yay, neat bug :)
<Amaranth> i switched here then back to totem and the gui is totally blank and so is the video window
<Lathiat> i recognise those people
<Treenaks> Lathiat: you do?
<Lathiat> yeh from lca04
<Lathiat> im not goign to guess but because i probably have it wrong :)
<Amaranth> i'm assuming he is using flumotion
<Lathiat> yeh
<Treenaks> Amaranth: knowing jdub: yes.
<Amaranth> talking on the phone :)
<Lathiat> think i know what theyre doing too 
<Lathiat> heh
<Lathiat> i need to get a webcam that works in linux so i can play with this stuff
<Amaranth> jdub: quit arguing with sabdfl and do something funny ;)
<Treenaks> Lathiat: why a webcam if you can use a TV tuner card? :)
<mike_douglas> Lathiat: http://zc0302.sourceforge.net/zc0302.php?page=cams <- there are some
<Lathiat> Treenaks: laptop
<Lathiat> and no camera to go into tv turen card
<Treenaks> Lathiat: laptops with built-in tuners exist
<Lathiat> but mine doesn't have one :)
<Treenaks> [ok, who can read lips?] 
<Lathiat> On the other hand, when it works and you are capturing your Firewire camera
<Lathiat> on one machine, encoding to Theora on a second (with an overlay, of course),
<Lathiat> encoding the audio to Vorbis on a third, muxing to Ogg on a fourth, and then
<Lathiat> streaming both audio and video from a fifth, audio only from a sixth,
<Lathiat> video only from a seventh, and capturing all three streams to disk from
<Lathiat> an eigth, you feel very good about yourself.
<daniels> jdub: where the hell are you?
* Lathiat laughs
<Lathiat> And you also have too many computers.
<Treenaks> daniels: he's on the phone
<Treenaks> (if this stream is live)
<Lathiat> daniels: he appears to be somewhere with lca04 people organising lca05 streaming, at a guess, no idea where that is :)
<daniels> oh, right.  now it all clicks.
<Treenaks> daniels: http://150.203.164.99:8800/
<Lathiat> and the two people looked vaugely like aj and silvia but i have absolutely no idea the videos a bit hard to make out
<thom> Lathiat: k and silvia
<Lathiat> k?
<daniels> Treenaks: yeah, I was watching the stream, just trying to work out where he was
<daniels> Lathiat: conrad parker
<thom> Lathiat: conrad parker
<Lathiat> oh right
<daniels> thom: jinx!
<Lathiat> the hat put me off :)
<Lathiat> plus theres no sound :)
<Treenaks> there's some weird musicish thing
<Lathiat> oh i cant here that
<Lathiat> weird
<Lathiat> oh my internal speaker volume is off
<Lathiat> there we go
<Amaranth> heh
<Treenaks> hm, if UDU will have stuff like this... :)
<Treenaks> (too bad the timezone diff is hell)
<Lathiat> hmm flumation-admin crashes for me :(
<Lathiat> Treenaks: nah UDU wont
<Treenaks> Lathiat: :(
<Lathiat> apparently linux.conf.au will
<Amaranth> haha
<Amaranth> don't flip me off
<Lathiat> i keep missing screencaps of all these funny images
<Lathiat> i need to setup a gst pipeline to save the stream :)
<Lathiat> that was far too easy
<Lathiat> gstreamer rocks
<maswan> heh. bandwidth usage seems to be going up again. you guys rock with your releases! :)
<Lathiat> haha
<Lathiat> whats the url for the ftp data 
* Amaranth took the toolbars out of vlc and put them on another desktop
<Amaranth> then made the vlc window always on top
<Lathiat> Amaranth: use totem...
<Amaranth> so i miss nothing :)
<Amaranth> Lathiat: It froze.
<Lathiat> then just hide controls and set on top
<Lathiat> or
<maswan> http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
<maswan> plus this for the i386 install and live cds:
<maswan> http://farbror.acc.umu.se/stats/monitordata/index.shtml
<Lathiat> haha fark
<Lathiat> i can see we're goign to keep you busy :)
<Amaranth> did he just kill the stream?
<Lathiat> yeh
<Amaranth> dang
<desrt> Lathiat; wake up!
<Lathiat> desrt: what?
<Amaranth> oh well, back to system of a down
<desrt> nothing :)
<Lathiat> desrt: :P
<desrt> Amaranth; they're trying to build a prison.
<Amaranth> desrt: Nah, nothing that old.
<Amaranth> desrt: dancing in the desert blowing up the sunshine
<desrt> boring.
<Lathiat> gotta love PNG
<Lathiat> i took a screencap
<Amaranth> do you know what song it is?
<Lathiat> over a 16K/s stream
<Lathiat> and the image is 140K :)
<desrt> byob
<Amaranth> :)
<Amaranth> damnit :/
<Amaranth> i left my pepsi caps 100mi away
* desrt is more into the toxicity era
* Amaranth already figured out what songs to get with 20 of those caps
<pitti> daniels: here?
<fabbione> hey pitti
<pitti> Hi fabbione, could you finally sleep again? :-)
<Lathiat> man
<Lathiat> the intel speedstep driver sucks
<Lathiat> keeps getting stuck on 600mhz or 2ghz when scaling is off
<fabbione> pitti: no :(
<desrt> hey.  it's that gamin guy
<pitti> Kamion: here?
<Lathiat> hmm it takes a good 14 seconds to show up /usr/bin in the gnome file selector
<desrt> ya.  that's particularly annoying when you're trying to convince firefox to not suck
<Lathiat> yeh
<Lathiat> thats exactly the use case :)
<Lathiat> i wish it woudl show evince up
<desrt> i'm about ready to be driven back to ephy
<desrt> it's *so* much nicer in terms of integration
<desrt> everything *everything* works properly
<desrt> it just doesn't have all the features
<Lathiat> i used to use ephy 
* desrt installs it
<desrt> uh.  wtf
<Lathiat> heh i just did the same ting :P
<Lathiat> desrt: apt-get install epiphany-browser
<desrt> lame.
<Lathiat> yeh
<Lathiat> epiphany has been around longer
<Lathiat> the funny thing is
<Lathiat> the epiphany package
<Lathiat> installs the epiphany-game binary
<Lathiat> and the epiphany-browser package
<Lathiat> installs the epiphany binary
<Lathiat> :)
<desrt> is there a way to tell apt to remove dependancies from stuff i just removed?
<Lathiat> desrt: you could look at deborphan
<Lathiat> but not rally
<Lathiat> *reall
<Lathiat> y
<Lathiat> eww default epiphany install is broken
<Lathiat> doesnt shwo up the addres and statusbar
<desrt> ugh
<Lathiat> s
<desrt> how bad?
<desrt> oh.  that's so fixable
<Lathiat> yeh
<Lathiat> just wrong
<Lathiat> i need to get the industrial firefox theme or the buttons and stuff
<desrt> man.  running ephy fills me with a desire to switch back to bluecurve
<Lathiat> desrt: whys that?
<desrt> bluecurve has the best stock icons
<Lathiat> oh ok
<desrt> one thing i don't understand about web browsers is why they have like 12 different 'font' menus
<desrt> western/eastern/unicode/whatever
<desrt> oh yes.  a non-broken downloader.
<Lathiat>  i must try it
<Lathiat> firefoxes cant reven resume downlodas its stupid
<desrt> hot.  find toolbar extension for ephy
<daniels> pitti: hey dude.  should I SSH into chinstrap?
<Lathiat> dear god, its so cool
<Lathiat> im sold :)
<pitti> daniels: :-)
<desrt> smart bookmarks
<pitti> daniels: usn-linux.txt waits for a thorough pair of eyes 
<desrt> wow.  all it really needs now is half-decent gestures
<Lathiat> i dont use gestures anyway
<desrt> i do.. constantly
<thom> pitti: dude, are you likely to look at hal 0.5 in the next few days? or shall i port what we have already and start testing?
<desrt> it's infuriating to try to live without them
<daniels> pitti: only few -> very few
<pitti> thom: in fact I wanted to upload it ASAP
<daniels> (or 'only a few')
<pitti> thom: however, we need dbus 0.30 before --> daniels?
<daniels> pitti: does it need dbus 0.3x?
<daniels> yeah, i'll do that tonight
<pitti> cool
<daniels> pitti: the rest of usn-linux.txt is fine
<pitti> daniels: corrected, thanks
<thom> pitti: ok, great
<thom> i was just about to prod daniel about dbus ;-)
<pitti> thom: however, new hal/dbus will break some gnome stuff, but I have a pointer to patches, and gnome 2.11 will convert anyway
<thom> gnome-power and NM shortly after hal goes in, then :-)
<pitti> can we upload into breezy now?
<thom> pitti: yep
<pitti> cool
<thom> pitti: (that was about gnome) dunno bout breezy
<daniels> thom: i was too busy working on /usr/X11R6 -> /usr and modularisation
<pitti> ah
<pitti> -changes is sooo empty :-P
<thom> daniels: seems fair
<Lathiat> epiphany loads faster too
<thom> pitti: nod
<pitti> btw, wouldn't it make more sense to rename hoary-changes to ubuntu-changes?
<pitti> jdub: ^
<pitti> jdub: or is there a breezy-changes list now?
<thom> i think per-distro feeds makes more sense, and yes there is breezy-changes and you should be subbed already
<Amaranth> ooh, debian mono 1.1 packages
<pitti> but neither warty-changes nor hoary-changes will see any mails any more now??
* Amaranth hopes these go into breezy quickly :)
<crimsun> Amaranth: they work well so far.
<thom> pitti: arguably, hoary-updates/security should send mail there, IMO
<pitti> hmm, yeah
<bob2> I'd like to nominate update-apt as the funniest package in ubuntu
<bob2> and give it some sort of special icon in synaptic
<mantien1> Hi all
<desrt> update-apt sounds vaguely useful
<thom> so i'm automatically typing apt-get update && apt-get dist-upgrade every few hours by reflex
<desrt> my friend could use that.  he's on dialup.
<thom> bon jour seb
<seb128> lu thom :)
<Lathiat> thom: i do the same thing heh
<bob2> desrt: it's an entire package for 3-line shellscript
<desrt> fair enough
<bob2> desrt: the Packages entry is longer than the entire package contents
<Lathiat> haha
<desrt> wow.  the ubuntu-spatial-is-broken bug refuses to die
<Lathiat> to be honest
<desrt> hoary is released already
<Lathiat> i kinda like it now.
<Lathiat> rrequ
<Lathiat> ires less thinking
<desrt> i still despise it :)
<Lathiat> i despise it on principal
<Lathiat> but practically its kinda good...
<desrt> maybe you should be using browser mode, then
<Lathiat> reasoning being, i have to think less about when i want to keep a window open
<Lathiat> and for some reason, its easier for me to think about that
<Lathiat> than to constantly middle click stuff i don't want
<Lathiat> and when i want to open a new window without closing behind, i think about it
* Lathiat shrugs
<desrt> i rarely middle click
<desrt> metacity arranges the focus of the windows in a nice stack
<Lathiat> problem is, i end up with 30 open nautilus windows far too often
<desrt> so i can whack ^W a few times to go back to higher levels
<desrt> it's nice
<Lathiat> the only reason being because i was navigating around files
<Lathiat> desrt: also, assumedly
<Lathiat> they are stil whinging on the bug
<Lathiat> in the hopes its reverted in breezy
<desrt> ya.  that's true, i guess
<desrt> although, the whole time my argument was to delay until breezy
<Lathiat> mm browser mode
<desrt> since at least by then it might half-way work properly
<Lathiat> location bar is usefull
<Lathiat> for getting into hidden folders and stuff
<Lathiat> the places menu on nautilus windows needs sto be fixed
<desrt> after they figure out all the weird corner cases and actually have time to fix them
<Lathiat> to be the same as the one on the desktop
<Lathiat> s/desktop/panel
<desrt> hmm
<desrt> the file browser is a lot less offensive than i remember
<desrt> the tree is sort of extremely useful
<jdub> pitti: there's breezy-changes now
<jdub> hey so
<jdub> http://150.203.164.99:8810/
<jdub> http://150.203.164.99:8820/
<pitti> jdub: okay, thanks. Are we already sub'ed?
<seb128> hey jdub/pitti
<jdub> pitti: yeah
<jdub> yo seb128 
<pitti> Hi seb128 
<seb128> breezy open for uploads ?
<jdub> ^ two angles ;)
<jdub> seb128: don't think so
<pitti> we want new crack!
<pitti> :-)
<Lathiat> jdub: whats with the green line
<daniels> jdub: nice curtains
<Lathiat> totem needs to be able to have two windwos open
* desrt wonders how jdub convinces millions of people to watch him on a daily basis
<Lathiat> hmm the seocnd stream keeps rebuffering
<desrt> mm.  powerbook.
<Amaranth> the second one won't play at all for me
<Amaranth> never gets more than one frame out of buffering
<Amaranth> no more music? :/
<Lathiat> i need to get my ipaq to play them over bluetooth from my laptop :)
<Amaranth> jordi: You had a nightmare about epochs?
<jordi> Amaranth: I assure you I did.
<Amaranth> just....wow
<Lathiat> i dreamt in python once
<Lathiat> it was weird i was like defining the world aroudn me in code
<Lathiat> lets just say.. i hadn't slept in a good 48 hours
<Amaranth> heh
<Amaranth> worst i ever did was fix a bug in my sleep
<Lathiat> haha
<Lathiat> i dreamt about how to fix a bug in some bash script
<Amaranth> woke up, created the patch, and went back to bed
<Lathiat> haha
<Lathiat> i have a mate who sleep walks
<Lathiat> he like.. woke up in the shower
<Lathiat> full on having a shower, with the right temperature
<Amaranth> heh
<Lathiat> was like, wtf?
<Lathiat> heh
<Amaranth> i've only done that once that i know of, just going to the bathroom
<Lathiat> ive never sleep walked
<Lathiat> well.. not that i woke up in
<Lathiat> :)
<Amaranth> oh, i didn't wake up, someone told me about it
<Lathiat> haha
<Lathiat> i fell asleep on top of my laptop once :\ haha, my mum took a picture
<Amaranth> heh
<Lathiat> ah dear
* Lathiat wonders what he would do without gnome
<Lathiat> nothing else is usable for me
<Lathiat> everytime i use kde or windows i just want to stab myself
<Lathiat> macosx was kinda ok
<Lathiat> maybe i'd be a mac user
<Amaranth> i feel asleep working on a server through ssh, let's just say the server had to be reimaged
<Lathiat> haha
<Lathiat> oops
<Lathiat> i had a mate who was drunk and tired
<Lathiat> had to shut down a server
<Lathiat> shut down another clients server isntead
<Lathiat> on a friday night :)
<Amaranth> ouch
<Lathiat> they werent happy on monday 
<Amaranth> i appearently chmod'ed / instead of ~/something
<Lathiat> funnily enough :)
<Lathiat> Amaranth: -R? :)
<Amaranth> everything was non-executable
<Amaranth> yeah :/
<Lathiat> hahaha
<Lathiat> oops
<Lathiat> my school admin
<Lathiat> accidentally chowned / -R
<Lathiat> spent the next 2 days looking at a copy server
<Lathiat> and chowning everything back
<Amaranth> the server was completely lost, i couldn't run anything
<Lathiat> im not surprised
<Lathiat> :)
<Amaranth> it cost $$$ to have them reimage it, i got root privledges taken away :)
<Lathiat> haha
* infinity smacks thom around.
<thom> muh?
<thom> what am i getting smacked for?
<infinity> Just for being you, mostly.
<thom> oh, right
<infinity> And for having "rm /some/conffile" in a postrm without a "-f".
<infinity> (powermanagement-interface)
<thom> oh, meh
<infinity> (No, that's not the source of the bug on -devel, I just noticed your bug when investigating his)
<thom> well, i was gonna say
<thom> why debconf is getting invoked at all unless ucf does madness is confusing me
<infinity> ucf uses debconf.
<infinity> But I found your bug when deleting the conffile to see what ucf would do.
<infinity> Of course, I deleted the conffile, the installation still went fine, then I tried to purge the package, and it broke. :)
<thom> heh
<infinity> So, yeah.  File a bug on yourself and remind yourself to fix it when breezy opens up.
<pitti> Hi infinity 
<thom> infinity: tested and uploaded
<infinity> Hey pitti.
<maswan> there, made arrangments for more than one Gbit/s uplink for our computer club. Hope everything works out. :)
<astharot> ciao
<Mithrandir> has breezy opened up yet?  /me wants new crack.
* Treenaks is getting withdrawal symptoms too
<pitti> Mithrandir: I tried an upload, it just vanished
<Lathiat> almo probably took to it with an axe :)
<Lathiat> die updated software scum!
* Burgundavia keeps hitting reload but doesn't have any new software
<Amaranth> oh, does breezy at least not 404 now?
<thom> pitti: it's prolly in NEW
<pitti> thom: pmount???
<thom> well, or whatver the state is for something uplaoded to a distro that doesn't exist :P
<daniels> i uploaded l-r-m to breezy at 1000 UTC on friday, it still hasn't gone through
<fabbione> daniels: guess what?
<fabbione> daniels: there is no breezy yet in the archive
<fabbione> and lucky you that elmo didn't goatse you with my proposed mail for rejection :)
<Lathiat> haha
<mantien1> daniels: could you tell me what to do when dpkg-reconfigure xserver-xorg doesn't not autodetect my video card ? I could tell you output of lspci -n :)
<daniels> fabbione: i heard about your unaccept proposal
<daniels> mantien1: output of lspci -n, /var/log/Xorg.0.log and /etc/X11/xorg.conf is good
<mantien1> I modified xorg.conf, after autodetection I got vesa driver and manually replaced it with correct - nv driver, so it seems you don't need my manualy modified xorg.conf ;)
<Amaranth> does anyone know where mark pilgrim went?
<mantien1> ubuntu@ubuntu:~$ lspci |grep VGA
<mantien1> 0000:01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0343 (rev a1)
<mantien1> ubuntu@ubuntu:~$ lspci -n |grep "01:00"
<mantien1> 0000:01:00.0 0300: 10de:0343 (rev a1)
<Amaranth> mantien1: I think he meant on bugzilla.
<mantien1> Amaranth: ok
<Amaranth> Please don't dump Xorg.o.log into this channel
<mantien1> Amaranth: hehehe ;)
<daniels> hm, what the hell is 0343?
<daniels> hmmm
<daniels> are you running warty or hoary?
<mantien1> hoary
<daniels> oh, right, duh
<daniels> i'd be interested to see how it came up with vesa
<daniels> what's the Idenfitier in the Device section?
<mantien1> daniels: 0343 is NVIDIA Geforce  FX 5700LE
<mantien1> ubuntu@ubuntu:~$ grep "Chipset" /var/log/Xorg.0.log
<mantien1> (--) Chipset GeForce FX 5700LE found
<mantien1> (--) NV(0): Chipset: "GeForce FX 5700LE"
<daniels> mantien1: yeah, it's an nv36 (it's in discover1-data's list, not pciutils's list)
<daniels> mantien1: so what's the Identifier in the Device section of xorg.conf?
<mantien1> Section "Device"
<mantien1>         Identifier      "Generic Video Card"
<mantien1> but I'm not 100% if I don't changed this line manually
<mantien1> s/not 100%/not 100% sure
<daniels> generic video card?
<daniels> you sure that came from xorg.conf?
<mantien1> yea
<daniels> does sudo dpkg-reconfigure -phigh xserver-xorg, give you something that works?
<daniels> from xorg.conf -> from the xorg.conf that Ubuntu generated
<mantien1> sudo dpkg-reconfigure -phigh xserver-xorg gives me debconf window, which asks for X server driver
<daniels> huh
<daniels> are xresprobe, discover1 and discover1-data installed?
<mantien1> of course :)
<mantien1> root@ubuntu:~# dpkg -s discover1 |grep Ver
<mantien1> Version: 1.7.7
* daniels punts to /msg.
<mantien1> root@ubuntu:~# dpkg -s discover1-data |grep Ver
<mantien1> Version: 1.2005.01.08
<mantien1> other video cards are detected properly
* infinity notes that any day he has to deal with immigration is pretty much immediately a write-off and curses.
<thom> infinity: they're not booting you out of the country?
<infinity> thom : They better not be.  I need to go back tomorrow. :/
<thom> infinity: ouh :/
<jsgotangco> jdub: u there?
<daniels> infinity: eep.  good luck with it.
* torkel looks at maswan
<maswan> torkel: yes?
<jdub> jsgotangco: yo, pretty busy, but what's up?
<torkel> maswan: 02:32 #ubuntu-devel: (maswan) ogra: well, if torkel, stric and a few others in this city register, I'll be hidden too
<Mithrandir> torkel: the ubuntuaroundtheworld thing
<Mithrandir> jdub: why did you increase the number of beers you owe me (now-12ish hours)?
<Mithrandir> (as in, what have I done?)
<infinity> Mithrandir : Clearly, you're just an allround good guy.
<Mithrandir> heh :)
* Mithrandir kicks gnome
<torkel> ah
<jsgotangco> jdub: filling up my visa application for UDU there's a contact person field who's our Sydney contact for UDU?
<Mithrandir> "Battery is about to empty"  "42 hours 7 minutes (8%) is left".  Stupid.
<torkel> pitty I left the GPS at home then... :-)
<jdub> jsgotangco: me :)
<thom> Mithrandir: giggle
<pitti> Mithrandir: I want to have your battery :-)
<jsgotangco> jdub: OK I add you then but i need yo numbah
<Mithrandir> pitti: it's plugged in, acpi is just acting up and claiming that my battery is at 1/10th of the level it is.
<Mithrandir> the battery applet should "don't notify unless < 8% and <30 minutes"
* infinity -> home, to fill out more immigration forms.
<pitti> Mithrandir: oh, so your local power plant will go down in less than two days? :-P
<maswan> torkel: you're currently at N6349'13.213", E2018'23.941", or at least within 30 m from that. :)
<Mithrandir> pitti: :P
<maswan> torkel: at least according to the robot guy. :)
<torkel> maswan: :-)
<Amaranth> Hmm, this is interesting. gnome-menus appears to be using en_GB even though I'm using en_US
<Amaranth> So if I change Name[en_US]  it doesn't appear to do anything because the locale is wrong.
<doko> jbailey: ping
<ctd> I might aswell say now, bittornado in hoary appears to be broken.
<Treenaks> ctd: it's not.
<ctd> I must be missing something? I've had it running all day and it's not been connecting to other peers. Use btdownloadcurses.bittorrent and it's fine.
<thom> bittornado works for me (TM)
<Treenaks> same here
* Treenaks blames ctd's firewall
<ctd> Treenaks: Don't think so, been working for ages.
<ctd> Treenaks: till i updated today
<fabbione> mjg59: ping?
<Lathiat> ctd: i use bittornado all the time
<Lathiat> all day today in fact
<Lathiat> and yesterday and the day before
<Lathiat> :)
<ctd> Lathiat: I can imagine you doing that.
<Lathiat> i put in an upgrade to 1.5
<Lathiat> :)
* fabbione shakes mjg59 
* Lathiat tuts at fabbione 
<fabbione> mjg59: unpong
* Lathiat prefers 'deping'
<mjg59> Aww. I'm not wanted.
<fabbione> mjg59: nah.. i was just seeking info of the url for the sony acpi driver, but after a few hours of google i found it
<Treenaks> Is there any news on the "smart battery" (acpi-sbs) front?
<aj> anyone know offhand about how many TB of hoary have been served last couple of days?
<fabbione> mjg59: given that breezy will open within the next days, i should be able to give you some real good crack
<thom> aj: "lots"
<mjg59> Haha
<aj> thom: 1? 10? 100? 1000? petabytes?
<mjg59> fabbione: I'm off to LCA on Friday, not sure how much time I'll have that week
<Lathiat> aj: last count, at least 12
<fabbione> mjg59: oh lucky you.. have fun :) linux-source-2.6.12-2.6.11.90
<Lathiat> aj: would be far more by now
<aj> mjg59: "none" is a safe bet, but the rest of ubuntu probably won't either :)
<aj> Lathiat: so 20ish?
<Lathiat> aj: 20/30 + -- and that was just bittorrent and se.releases
<Lathiat> the primary site and us mirrors did similarly stupid amounts of traffic
<aj> oh, so 100ish all up say?
<Lathiat> perhaps
<mjg59> aj: On Friday evening, the main mirror was shifting 540MBit
<thom> aj: given how much traffic gb.archive was doing that may not be unreasonable
<Lathiat> se.releases was doing 550mbit for a good day
<Lathiat> http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
<Lathiat> they went up to 110M/s at one point
<Lathiat> including the second box on that sconnection
<mjg59> The number of pre-ordered CDs is something ridiculous
<Lathiat> http://stats.sunet.se/stat-q/plot-all/umea2.umea-srp,2005-04-08,raw,traffic-kbit
<thom> mjg59: ~300000
<Lathiat> http://stats.sunet.se/stat-q/plot-all/umea2.umea-srp,2005--14,hr,traffic-kbit <-- more usefull
<aj> is that peaking at ~2Gb/s?
<jdub> http://150.203.164.99:8811/
<jdub> ^ heh :-)
<pitti> smurfix: ping
<smurfix> pitti: 
<pitti> smurfix: I just added an UDU wiki page, and got a nice status message:
<pitti> [en]  MatthiasUrlichs: Connection to mailserver 'localhost' failed: (111, 'Connection refused')
<daniels> jdub: nice!
<daniels> haha
<daniels> works really well with the overlay
<daniels> (hint: it's solid blue on the framebuffer)
<jdub> yeah
<jdub> that's i855switch in action :)
<daniels> woah
<jdub> i855crt
<jdub> overlay probs
<daniels> watching IRC in realtime gives you a good sense of the lag in play
<smurfix> pitti: Tell that to whoever has set up the UDU machine
<jdub> plus still don't get my mouse cursor
<jdub> daniels: that's flumotion lag
<smurfix> pitti: (and/or the wiki)
<smurfix> pitti: should be mdz and/or mako
<daniels> jdub: oh man, dude, that script is a terrible terrible terrible hack
<jdub> haha
<jdub> it's great
* Pizbit wonders what the delay is.
<jdub> general stream delay
<Kamion> pitti: pong?
<aj> Lathiat: hrm, so that graph says ~72 TB per month, and then as much again in a few days post release?
<pitti> Kamion: Hi! that was about a USN review, daniels already did it
<Kamion> ok, cool
<fabbione> morning Kamion 
<fabbione> jdub: nice stream...
<fabbione> jdub: they re-added the pwc driver upstream. i am going to drop the external one
<Lathiat> aj: that ftp site does more than just ubuntu
<Lathiat> aj: just you can see the fuck load of release traffic on top of normal
<aj> Lathiat: how much stuff's mirrored? 500GB?
<Lathiat> aj: nah wouldn't be anything like that
<Lathiat> maybe 100?
<aj> oh, not even a full debian mirror on it or anything?
<Lathiat> maybe
<Lathiat> oh you mean total
<aj> yeah
<Lathiat> i dunno they have a page with the ftp cluster machines and listing their disks
<Lathiat> could add it up
<Lathiat> or just ask maswan :)
* Lathiat pokes maswan 
<aj> oh, it's one of maswan's, fair enough. maybe a TB then
<Lathiat> ftp.acc.umu.se
<Lathiat> cdimage.debian.org :)
<Lathiat> but thats on another machine
<Lathiat> aj: why you wondering?
<aj> just curious at b/w : disk ratios
<Lathiat> ah right
<aj> hrm, okay, 500GBish sounds near enough
<Amaranth> jdub: Don't you pay per GB for broadband?
<Pizbit> Not always
<bob2> I don't (in .au)
<kent> Its not so common to pay per GB in sweden either. I dont.
<Amaranth> oh
<Amaranth> last time i talked to an aussie about broadband was 3 years ago, things have changed?
<daniels> it's common to pay for it in .au
<zul> hey
<maswan> aj: se.releases did somewhere between 10-15TB
<maswan> aj: hmm.. probably closer to 10.
<thom> jbailey: dude?
<jbailey> thom: 'sup?
<seb128> he guys, there is a user on #ubuntu-fr with an some issues to get his soundcard working
<seb128> it worked after the installation and not since he restarted the box
<seb128> the lsmod output is here: http://rafb.net/paste/results/LL4YVp95.html
<seb128> is that due to oss and alsa drivers loaded together or something like that ?
<archster> can anyone point me to a change log please ..
<daniels> jbailey: dude!  radeon_drv from hoary final should work fine on your machine
<maswan> aj: the temporary host that have been handling the i386 install and live cds has delivered 3.8TB since the release. ftp.acc/se.releases proper has sent approc 12TB, out of which somewhere aroudn 6-8 woudl be normal "background" traffic of debian packages, gnome, etc.
<maswan> aj: (looking at the weekly numbers)
<jbailey> seb128: It could easily be.  Does the card show up at all in /proc/asound?
<archster> I'm trying to find the difference between the mar 30 release and the april 7 one
<jbailey> daniels: Nice, I'll do an update.
<seb128> jbailey: he has no /dev/dsp, let me ask that
<jbailey> seb128: If there's no /dev/dsp then I don't think it's an alsa/oss conflict.   I would've expected one of them to grab it and hold it against the other.
<thom> jbailey: so checkfs.sh runs before hotplug during boot; but if one of the filesystems to be checked is on a disk that hasn't had a mdoule loaded yet the whole shooting wagon goes off the rails; is this known/fixable
<seb128> jbailey: 
<seb128> <topgun> Camera  card1  devices  oss  seq     V8235
<seb128> <topgun> card0   cards  modules  pcm  timers  version
<jbailey> thom: https://bugzilla.ubuntu.com/show_bug.cgi?id=5204
<jbailey> thom: Best bet is /etc/modules right now, sorry.
<thom> jbailey: nod; is what i figured
<seb128> jbailey: do you know how to solve the issue of both alsa and oss modules loaded ?
<jbailey> thom: There are two things that I see happening for breezy.  1) Running a first hotplug pass inside the initrd, 2) running a second hotplug pass as soon as possible. 
<jbailey> seb128: hotplug blacklist.
<jbailey> seb128: (Assuming that they're hotplug detected, on not just /etc/modules'd)
<thom> jbailey: nod, cool
<seb128> he has not changed anything
<jbailey> seb128: Hmm.  via82cxxx_audio is already blacklisted.
<jbailey> I guess via82cxxx isn't the OSS driver, then.
<Treenaks> jbailey: it's the IDE driver, I think
<jbailey> Treenaks: Makes sense.  Hard to keep it straight with all the integrated chipsets. =)
<lunatik> hi there, is there a team for e17 in ubuntu like kubuntu ? 
<jbailey> dict e17?
<thom> jbailey: enlightenment
<jbailey> Wow, isn't that a blast from the past. =)
<aj> maswan: ta; interesting
<jbailey> daniels: I have a fresh install on here right now without ubuntu-desktop.  Should it work well enough that just installing ubuntu-desktop will take care of all the autodetection?
<Riddell> lunatik: no, but then e17 hasn't been released yet
<daniels> jbailey: as long as that drags xresprobe in, yeah
<lunatik> Riddell: not released but compilation and usage is ok for me :)
<jbailey> daniels: Okay, it's only recommended, so I'll add it in.
<lunatik> jbailey: not the past, the future ;)
<Riddell> lunatik: well you can join MOTU to get packages in the repositories if they arn't there already
<SlackShrike> I would like to help to the package language-support-pt and ubuntu-live.  How I make this?
<lunatik> Riddell: ok, I would like to help
<Riddell> SlackShrike: language-support is automatically generated
<Riddell> lunatik: /join #ubuntu-motu
<lunatik> ok
<jbailey> daniels: Looks like I'll be able to let you know in about 30 minutes or so.
<lunatik> thx :)
<SlackShrike> i am like to help in the ubuntu-live-cd. 
<trulux> heya folks
<trulux> how's it going!
<SlackShrike> I would like to help in the LiveCd of ubuntu and I would like to know where I am all the process of creation of live to study.  Thanks!
<Kamion> you mean contents of the live CD, or the process of starting the live CD up?
<SlackShrike> Riddell: why it did not separate pt of pt-br?
<Kamion> not separating those makes the installer's life easier
<Kamion> it's possible that it may change in the future but there were good reasons for it the way it is now
<Mithrandir> jbailey: moo.
<SlackShrike> Kamion: The two
<Mithrandir> jbailey: can we schedule some time to look at my mkinitrd problem (the i2o controller)
<jbailey> Mithrandir: Yup.  During what times and in what timezone is the box available?
<Kamion> SlackShrike: the contents are just the same as in normal Ubuntu; if you want to work on some component, just work on it; you don't need to work on it in the context of the live CD
<Mithrandir> jbailey: preferably day, CET.
<Kamion> SlackShrike: the startup process is in the casper source package
<SlackShrike> The reason is the difference between pt and pt-br and goes to install two packages of lingua of the openoffice without necessity
<jbailey> Mithrandir: Can we do Wednesday morning then?  I need a couple days to catch up from the weekend before I try to get up earlier than my usual time. =)
<Mithrandir> jbailey: your morning or my morning? :)
<jbailey> Mithrandir: Yours. =)
<jbailey> Thinking like 11 or so.
<SlackShrike> Kamion: the Ubuntu use the morphix for make the live cd, ok ?
<Mithrandir> jbailey: 11 CEST is fine with me.  Let me check with the people who are local too.
<Kamion> SlackShrike: no
<Kamion> we used Morphix in Warty, but it was too broken
<Kamion> and too difficult to autobuild in the context of our normal build framework
<jbailey> Oh wait, did you go through DST recently?  Is that still 09h00 GMT? or is that now 8?  I'll do it either way, just want to make sure we're there at the same time.
<Kamion> so we wrote casper, which unified the live CD hardware detection with that of our normal installer
<Mithrandir> jbailey: we're at UTC+2 now, so that's 0900 UTC.
<jbailey> Luvly.
<mantien1> SlackShrike: ubuntu live cd technology has better hardware detection than Morphix/Knoppix
<Mithrandir> jbailey: that's fine with us, we'll make sure the serial console and such is working then so you can hack around to your heart's pleaseure. :)
<SlackShrike> How it is the creation of the installation compact disc?
<jbailey> Mithrandir: Cool, this'll be a fun adventure. =)
<Mithrandir> jbailey: absolutely. :)
<Kamion> SlackShrike: I can't understand that sentence, sorry
<daniels> Kamion: how does the install CD get created?
<SlackShrike> Yes
<daniels> SlackShrike: we use a system called debian-cd to create all our installer CDs
<daniels> SlackShrike: also our live CDs
<Kamion> SlackShrike: a long process involving debian-cd which I'm afraid we haven't yet packaged up in such a way that anyone can run it easily
<SlackShrike> daniels: The difference of live for install is alone casper ?
<SlackShrike> thanks
<SlackShrike> i will stude this now
<daniels> SlackShrike: that's right -- the live cd uses debian-installer, and just starts a session with casper
<theine> Is linux-image-2.6.11-1 rather safe to use?
<Kamion> theine: no
<daniels> theine: safe, yes.  good, no.
<daniels> actually, no, a hojillion security bugs.
<seb128> it "just hangs" due to inotify too
* seb128 kicks the 2.6.10 kernel and its bogus i2c
<theine> I'd just like to have a stock Ubuntu kernel with the newest ipw2100 patch...
<Kamion> wait for breezy to start up
<theine> Kamion: approximately when will that be by the way?
<Kamion> dunno
<Kamion> soon
<theine> ok
<Kamion> the suite exists in the archive, but the cron jobs aren't running yet
<daniels> Kamion: the otherusplash author -- 23:13 < Goshawk> is there Colin Watson here?
<daniels> Kamion: (#ubuntu)
<Kamion> daniels: he should reply on the mailing list
<daniels> Kamion: too late, someone already sent him here
<Goshawk> daniels, i started developing it when usplash was just a word
<Goshawk> now there is a lot of confusion on that
<Goshawk> Kamion, ok i'll reply there
<Kamion> publish it as some other name if you want, you can rename it later
<Kamion> or whatever
<jnc> i think bug #6762 needs the title to be fixed, it does not accurately reflect what the problem is perhaps
<Kamion> but this "I can't publish a newer version because you haven't given me permission to use the name" is just blah :)
<bob2> I like the way gdmgreeter idles at 10% cpu time while there's no monitor plugged in
<Goshawk> Kamion, it sounds not natural but it is like i said
<Kamion> jnc: log in and change it, then
<Kamion> Goshawk: if you published an older version, you can update that
<daniels> bob2: cute
<jnc> Kamion: i didn't submit it, you can change any bug's title?
<Kamion> jnc: yes
<jnc> ah okay.  i misunderstood
<jnc> it is not so simple in gentoo'
<Kamion> Goshawk: but you appear to be expecting us to make a decision about code you have not published
<Goshawk> ok.. so i'll relase usplash-0.1 
<Kamion> note for future reference that I did not say "usplash-0.1"
<Goshawk> Kamion, i asked consensus since the usplash word appaired in the ubuntu wiki first
<Kamion> I think some other name would probably be better for now, to avoid confusion as you say
<Kamion> but the code needs to be published if you want us to make a decision on it at UDU
<jnc> Kamion: done. thank you :)
<Goshawk> Kamion, the code is in the svn right now
<Goshawk> it's thre from the beginning
<Kamion> is that linked to from the wiki?
<Goshawk> Kamion, yes.. but i have not placed the link there
<Kamion> Goshawk: in that case I don't understand why you don't direct users there, rather than saying "the version you're running is obsolete, but I can't release the new version"?
<Goshawk> since it works different from the specification of the ubuntu wiki
<Kamion> why?
<Kamion> the specification there was written with a great deal of care
<Goshawk> Kaloz, yes.. but really it's hard to implement and resource loseless
<Goshawk> excuse.. not loseless
<Kamion> ok, if it doesn't follow that specification or similar and you're not willing to work on the specification, then I think yours should be called something other than 'usplash'
<Goshawk> but it uses a lot of cpu
<lemsx1|atwork> Kamion, I have reviewed the code of the usplash project Goshawk is talking about and I can say is really clean and easy to include the features needed to match the specifications asked for in the Wiki
<Kamion> guys, lots of code that is not called 'usplash' is clean
<Goshawk> the ubuntu wiki talk of many programs that use intensively cpu
<Kamion> I'm not saying *anything* about cleanliness, good code, or whatever
<Kamion> but if you implement something totally different to an existing specification, I think you should call it something else
<lemsx1|atwork> Kamion, don't get me wrong, there is nothing magical about the word "usplash" per se... so I see no reason why not to name this project differently
<Kamion> that wouldn't mean that it couldn't be the version used in Ubuntu, if things turn out that way
<Kamion> but it sounds like it's just not a good idea to call it usplash
<Goshawk> Kamion, you are right
<Kamion> names are cheap :)
<lemsx1|atwork> indeed... 
* jbailey ^5's daniels!
<lemsx1|atwork> Goshawk, I think we should go ahead and release the code as a different name. something original. and tell the KDE people and whoever is working on themes to use the new name
<daniels> jbailey: word
<daniels> jbailey: (my hacked radeon_drv only tied *one* line down, not both)
<lemsx1|atwork> Kamion, thanks for your time
<Goshawk> lemsx1|atwork, of course
<Goshawk> Kamion, thanks
<lemsx1|atwork> in general, if anybody wants to help, please join us at #debsplash. we are working on packaging the libraries (which is done, but we are working the details so that it works seamless with all distros)
<jdub> fabbione: rad!
<daniels> jdub: itym GREAT ODIN'S RAVEN
<SlackShrike> thanks
<fabbione> seb128: patches are welcome :)
<zul> http://internetnews.com/dev-news/article.php/3496541
<mako> ~
* netjoined: irc.freenode.net -> tolkien.freenode.net
<mdz> smurfix,pitti: I already mailed admins about the UDU wiki mail issue
<pitti> Morning mdz
<mdz> morning
<pitti> ah, thanks
<seb128> hi mdz 
<mvo> morning mdz 
<fabbione> morning mdz
<zul> hey mdz 
<mdz> doko,jbailey: I'd like to speak with you two about the toolchain changes you plan for breezy, in order to set a schedule for opening breezy for general uploads
<jbailey> mdz: Yup.  I have a glibc-2.3.5 package mostly finished.  I've been testing nptl stuff on ppc and trying solicit some opinions from folks on default threading libraries.
<jbailey> mdz: Lemme find the wiki node where doko and I have been wokring.
<jbailey> http://www.ubuntulinux.org/wiki/BreezyToolchainTransition
<mdz> ok, so the plan is to stay with current gcc until after UDU?
<mdz> and presumably you would like to upload glibc before we sync+merge from Debian?
<doko> we can maybe switch earlier, but let's decouple the new glibc and the gcc-4.0 uploads by some days or a week.
<jbailey> mdz: Right, although a test rebuild of the entire archive might prove it just as well.
<jbailey> mdz: lamont told me that's generally about 3 days of buildd time.
<mdz> jbailey: yes, the builds are fast, but in the past it has taken some time to get the archive+buildd infrastructure set up
<mdz> and that would need to be done again for breezy
<doko> jbailey: did talk with lamont yesterday, we want to sort that out today
<mdz> so there is significant benefit to getting the build tests "for free"
<jbailey> gcc-4 just went prerelease, so it's getting close to the right space, too.
<jbailey> We need to sort out the c++ transition and how to cope with it.
<jbailey> At least none of our arch's require serious work beyond that.  Debian's bump won't be fun.
<doko> jbailey: what about linuxthreads/nptl, which one do we want to make the default?
<pitti> elmo: ping
<Robot101> hmm
<jbailey> doko: It varies per arch.  I'm testing an nptl-only ppc glibc right now.  amd64 is already nptl only.  i386 is the hard one.  FC4 still ship the linuxthread headers by default, and it's the place with the biggest risk of breakage.
<Robot101> libmad0 is in hoary/main but gstreamer0.8-mad isn't? license problem?
<jbailey> I'm least worried about i386 in its present config though.  It has the advantage that we're less likely to find out a month after a change that something's broken horribly. =(
<fabbione> mjg59: crack is on the way soon :)
<fabbione> mjg59: linux-image-2.6.12-1-686_2.6.11.90-1_i386.deb <-
* pitti wonders why his warty-security uploads just disappear into the void
<fabbione> pitti: i think all the uploads are still manually approved
<pitti> uh, ok
<fabbione> pitti: i didn't get a single ack for days uploading sparc binaries
<fabbione> anywa... cya tomorrow
<pitti> bye, fabbione 
<lamont> night fabbione 
<mdz> Robot101: the only component whose category is based on licensing is multiverse
<mdz> Robot101: main and universe are all free software
<Kamion> oh, so breezy won't open until the toolchain is ready?
<Kamion> do we expect to open before UDU?
<mdz> Kamion: that's what we're trying to establish now
<Kamion> 'k
<mdz> the transition says upload by April 13th
<mdz> (glibc)
<mdz> I suppose we'll need to do a test rebuild in any case, really
<bob2> NPTL on ppc?
<Kamion> yeah, upstream has supported that for ages
<jbailey> bob2: There are no testsuite failures.
<jbailey> bob2: Most of Debian's arch's can't make that clain on linuxthreads ;)
<bob2> hehehe
<bob2> yay
<maswan> aj: us.cdimage has "53,659 iso's", which is "a uniq count of host/iso name"
<maswan> aj: ehm. us.releases, right, ubuntu, not debian here. :)
<kent> http://poetry.rotten.com/weightlifter/   usch usch
<kent> oh, sorry. wrong channel. sorry for the spam :(
<GheRivero> res
<aj> maswan: what's that mean? served that many isos?
<maswan> aj: yeah
<maswan> aj: some of those might be partial though
<maswan> aj: his bytecounting stats stuff seems broken, it claimed ammounts of data that would require an average of 3.6Gbit/s during a whole day, that's the reason for the odd form of stats
<pitti> Kamion: I was asked by a friend (modem only) to build a set of Hoary universe DVDs for him. You use debian-cd for this, right?
<Robot101> mdz: so why is gstreamer0.8-mad not in main? that means rhythmbox can't play MP3s, but the actual mp3 decoder (libmad0) is shippped in main.
<pitti> It looks like libmad0 should go to universe then
<mdz> let's not discuss this here
<lamont> pitti: sudo mkisofs -r -V 'Ubuntu 5.04 i386 Custom' -o hoary-custom-i386.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table dir/
<lamont> after you unpack the existing dvd iso into dir/ and make edits...
<Kamion> pitti: yes
<lamont> with signed archives, it's easier to just drop a second repository with universe in it under say, universe/
<Kamion> pitti: baz get colin.watson@canonical.com--2005/cdimage--mainline--0 cdimage && cd cdimage && baz build-config configs/devel
<Kamion> I would not advocate doing it by hand, to be honest, not for something as big as adding universe; you'd end up reinventing half of debian-cd
<pitti> Kamion: ah, thanks, I look into your repo then
<pitti> I think universe DVDs could be of interest to other people as well
<lamont> Kamion: the one I abused into place consisted only of adding {dists,pool} from a mirror into /extras in the tree...
<lamont> pitti: of course they would.  Note that shipping universe debs puts them in the same category (support wise) as main, at least from the consumer view point...
<pitti> lamont: well, at least my friend knows the difference, but he wants the DVDs before he actually switches from SuSE :-)
<lamont> yeah
<pitti> lamont: it's a pain for him to even download the apt lists
* Amaranth heads for bed
* lamont already burned his 'lamont-special;
<lamont> doesn't have all of universe, but does have everything in my mirror
<Kamion> lamont: you can put them on DVDs but not enable those components by default - they'd go in pool/universe/ etc.
<lamont> Kamion: true
<lamont> Kamion: I was just talking user perception - "it's on the CD --> supported"
<Kamion> yeah
<lamont> hence I'm always make sure that anyone getting one of my custom ones (a) is capable of understanding and (b) understands the difference... :0)
<mdz> mjg59: a friend pointed out today that IBM has a semi-automatic update feed which includes BIOS upgrades, I wonder if we could hook into that
* decko j volta...
<lamont> hrm...  time to actually reboot and run the current kernel, I think...  brb
<mako> koke: dude...
<koke> hi all!
<mako> good timing.. i tried to message you like 10 seconds ago
<koke> hehe :)
<koke> tell me
<seb128> mdz: I'm not sure to follow the discussion about gnome-cd on the list, it does use cdparanoia ... seems you saying it doesn't ?
<mdz> seb128: it does?  I thought it played it with the CD player
<mdz> is that new?
<seb128> 2.8 was using the CD player
<seb128> 2.10 uses cdparanoia
<mdz> I see
<mdz> it uses it unconditionally?
<seb128> right
<mdz> I don't think I've played a CD under 2.10 ;-)
<mdz> seb128: please correct me on the list
<seb128> k
<seb128> mdz: about #8938, that's an hoary installation. Apparently the sound works just after the installation, but not on the next module ... could it be than the modules loaded are not the same ?
<seb128> mdz: the guy has just restarted to get the dmesg output 
<mdz> seb128: it doesn't make sense; the same modules would be loaded every boot (and I can see from lsmod that the right module is loaded)
<Zomb> hi
<Zomb> has anyone a hint why getpwent in Perl/adduser is so slow on Ubuntu?
<seb128> mdz: the same modules are loaded every boot, the sound doesn't work ... it just worked after the installer boot apparently
<Zomb> it seems to get ~5 entries/sec
<Zomb> so I can wait till tomorrow for a normal adduser call
<pitti> hehe
<pitti> watch out world -- the derooter is back
<Zomb> it seems to reread the password file for every getpwent call
<lamont> pitti: go! go! go!!!!
<pitti> lamont: dhcpd this time :-)
* lamont wonders what jbailey/doko/mdz decided wrt toolchains
<lamont> pitti: dhcpd3, you mean?
<pitti> yeah, of course
<pitti> dhcp3d, to be exact :-)
<pitti> oh, no, dhcpd3
<mdz> lamont: is #7937 still a problem?
<mdz> Zomb: I know of no reason why that would be so
<mdz> Zomb: unless it uses grep(1) internally perhaps
<doko> lamont: proposal at http://www.ubuntulinux.org/wiki/BreezyToolchainTransition
<Zomb> mdz: it seems to be the libc, it rereads the shadow file again and again
<Zomb> there is no such problem on Sid
<Zomb> the order of users is not sorted (root is not first), this is the only suspicious thing. But it should not hit the performance that much.
<koke> see you, leaving now
<mdz> Zomb: you can read the diff between our libc and Debian's; I can't think of any reason for that to be different
<mdz> http://people.ubuntu.com/~scott/patches/glibc/
<Zomb> ok
<mdz> I don't think it's glibc itself; the cause is likely some other difference
<lamont> doko: shouldn'
<lamont> doko: shouldn't call it build-essential_11 - > version collision with debian
<lamont> mdz: 7937: dunno, can't test
<lamont> (ENOARCHIVE)
<lamont> mdz: I do know that hppa has the same issue with final-hoary bits
<Zomb> mdz: sorry, just tested, same crap on normal Debian system with a really large shadow file
<doko> lamont: let's talk to the maintainer and propose a new major number for the transition. maybe it's possible to sync that version between etch and breezy
<lamont> doko: that would be the way to go
* lamont looks at who the maintainer is, laughs
* doko waited for lamont laughing ...
<lamont> doko: still, he should upload _11 to experimental or something... :-)
<mako> carlos: actually, over here is better
<carlos> ok
<mako> can you give me a good translation the paragraph under my picture that compares me to the devil in person? :) http://sadistic-nature.blogspot.com/2005/04/manizales-en-75-tragos.html 
<mako> i don't know what a duro is
<carlos> mako: duro == hard
<mako> ok, i knew that, but i can't understand it in that context
<carlos> mako: ok, I just saw it, it's not that meaning there
<mdke> must mean god surely
<mako> is this colombian spanish? :)
<carlos> mako: yes, it is :-)
<mako> bacano.. 
<carlos> let me think a bit the translation...
<mako> i can go try to find a colombia :)
<carlos> I think I get the meaning but I'm not able to find a good translation for it...
<mdz> mako: I just added a blurb to mailman about the code of conduct for ubuntu-users, so that new subscribers are notified of it.  can you check that I did it properly, and improve the text if you think it could be better?
<mako> mdz: actually, i don't have an account on the mailman machine
<mako> mdz: i am only a web-moderator for the lists
<mdz> mako: you're listed as a moderator in the web interfdace
<mako> oh, just in the web interface
<mako> right, sure
<mdz> mako: I made the change through the web interface
<mako> cool, i'll check
<mdz> mako: we should probably do the same for the other lists, with standard text
<mako> i agree
<mdke> thats a cool idea
<remi`> hi everyone
<remi`> i'm having troubles with update-notifier on ia64
<remi`> does anyone have a minute to spare?
<mjg59> Oh, argh, bootsplash things using vesafb
<mjg59> (NO NO NO)
<mvo> remi`: I'm about to leave, can you talk to me about it later (in ~2h)
<mvo> remi`: or send it by mail?
<remi`> sure
<remi`> what's your email?
<Lathiat> mjg59: whats the alternative?
* mvo is away for ~2h
<mxpxpod> mjg59: does usplash use vesa?
<Lathiat> as far as im aware, usplash doesn't actually exist yet
<Lathiat> someone pointed out a new project (debsplash i think) on u-d@lists.u.c as a possible project to use
<mxpxpod> Lathiat: ah, ok
<tritium> Lathiat, usplash exists: http://www.ubuntulinux.org/wiki/USplash
<kent> Lathiat, im using it on my Ubuntu Hoary and it works for me, but thats not the same as to say it will work for any one else..  :)  But its very nice with a graphical boot. :)
<mxpxpod> kent: i386?
<kent> mxpxpod, yes. But i guess i cant turn every one else into that platform overnight,  so it might not be a good id for other platforms,  right? Or do the vesa-thing work on other platforms?
<mxpxpod> kent: vesa doesn't work on ppc
<kent> mxpxpod, thats ok. Just tell them I'm willing to switch my i386 for a ppc if they complain ;)
<mxpxpod> kent: haha
<mxpxpod> kent: does usplash use vesa?
<kent> mxpxpod, well, i cant tell realy. But some one hear said that before. It uses framebuffer of some sort.. i think. Since it depended on a fb-library.. (if i remember correctly)
<mxpxpod> alright
<mxpxpod> gotta get back to work
<mx|gone> kent: where are the .debs for it?
<kent> mx|gone, http://wiki.nanofreesoft.org/index.php/UsplashHowDoesItWork
<ogra> hey hey hey.....
<mx|gone> dang... no source pkgs
<ogra> hwdb Submissions Total: 10017
<ogra> :-D
<mdke> :)
<mdke> nice
<ogra> yeah
<kent> wow, more than 10k reports. That cool.  Could the hwdb be used to, for example, filter which brand of graphicard is mostly used, etc? it would be interesting to get some statistic of what hardware people use..
<ogra> kent, it will be used for this, yes...as soon as we have the data in a searchable DB
<Lathiat> well look at that
<Lathiat> it does work
<Lathiat> my only complaint is that it takes far too long to bring up the splash
<Lathiat> and i see a bit of text before X starts
<Lathiat> but not bad, seems to work...
<Lathiat> it'd be cool in future to make the progressbar animated like the clearlooks stuff, gives the user a better feeling of the system actually doing something
<kent> Lathiat, he said (Goshawk) that there is a newer package somewhere (dont know why he didn't publish it) that also has animated progressbar (if i remember correctly) and aswell usplash working on shutdown-process..  The new version should use configuration from /etc/ and some other things.
<Lathiat> hey cool
<Lathiat> looking good
<Lathiat> i love projects that work
<Lathiat> the biggest thing is that X didn't cry when the nvidia binary drivers stated
<Lathiat> i was so waiting for that to happen :)
<Goshawk> kent, ?
<Goshawk> kent, yes.. we are relasing it in another name
<Goshawk> kent, it will be called splashy
* Lathiat laughs
<Lathiat> nice :)
<Lathiat> Goshawk: got a beta package i could try out?
<Lathiat> im impressed...
<wasabi_> i always wondered why we just didn't start X first thing.
<kent> Goshawk, yes. Did i get it right? I meen, i thought i remember something about a new configuration in /etc/ etc, but your the expert :)
<Goshawk> wasabi, i studied that
<Goshawk> wasabi, and it can't be done
<Lathiat> wasabi_: slow, migh tnot have various libraries or modules loaded ?
<Lathiat> Goshawk: why, specifically ?
<Lathiat> it could also be an issue with mounting filesystems
<Lathiat> if its a network share or something
<Goshawk> wasabi, X needs a lot of dependencies that are solved when the system boots and for now, X is the first daemon that is started
<sladen> mx|gone: vesa is i386 only.  usplash (or similar packages written by other people) just want a framebuffer---on PPC that is always there and works out of the box
<Lathiat> Goshawk: can't give me any beta love? :)
<Goshawk> Lathiat, not yet
<Lathiat> bah :P
<Goshawk> Lathiat, we are moving t alioth and a relase will be relased soon
<Lathiat> cool
<wasabi_> what about, for instance, my nvidia card.
<Goshawk> (less than a week)
<wasabi_> When you turn on the framebuffer, it breaks X
<Goshawk> phone
<lemsx1|atwork> Lathiat, try my old packages http://www.kiskeyix.org/debian/downloads
<Goshawk> wasabi, no... 
<lemsx1|atwork> Lathiat, if your system breaks, you get to keep both pieces :-D
<Lathiat> lemsx1|atwork: i just got one out of the phpwiki
<Lathiat> that seems to work...
<Lathiat> or is this one newer?
<mjg59> Goshawk: The only framebuffer that's going to be usable on laptops is vga16fb
<Goshawk> wasabi, try setting vga=792 on your grub configuration file at the "kernel" line
<mjg59> At the moment, vga16fb seems to make the code very unhappy...
<lemsx1|atwork> Lathiat, newer, but the same code
<Lathiat> i passed video=795
<Lathiat> and it just worked
<Lathiat> fucked if i know what it did?
<lemsx1|atwork> Lathiat, not much changes.. just compiled with gcc-3.4 (g++-3.4)
<Goshawk> mjg59, my work uses every framebuffer
<wasabi_> Goshawk, what's that do? I mean, when I enable the framebuffer, X works fine...
<wasabi_> but I can never LEAVE X.
<wasabi_> If I do, I get no video signal.
<mjg59> Goshawk: The stuff in subversion? No, it doesn't work with vga16fb
<Goshawk> wasabi, it's ok so
<lemsx1|atwork> bbl
<Lathiat> wasabi_: works fine here, depends on the laptop i guess...
<Goshawk> mjg59, you have to set a minor resolution and remember
<Goshawk> it's only a 0.1 relase
<wasabi_> Lathiat, it's not a laptop.
<mjg59> Goshawk: No, vga16fb only works in one resolution
<Goshawk> done in less than a month
<Lathiat> wasabi_: interesting, what X driver?
<wasabi_> Just my desktop. The nvidia binary drivers Really Suck.
<Lathiat> wasabi_: tried the latest ones?
<wasabi_> Yeah.
<Lathiat> wasabi_: i had that problem after suspending
<Lathiat> fixed in the last 2
<wasabi_> It's like, when I hit Shut Down... I do it blind.
<Goshawk> mjg59, i'll investigate
<Lathiat> as is power management in general
<wasabi_> Because I can never see the console.
<Lathiat> wasabi_: weird
<Lathiat> sux2bu, use the open sauce dirver :)
<Lathiat> and don't play games, its bad for work :)
<mjg59> Goshawk: For vga16fb to work, you need not to pass a vga= argument to the bootloader
<wasabi_> haha
<Goshawk> mjg59, it's exactly what i do with my program
<Goshawk> at install time it matches the vesa modes with the xorg configuration
<Goshawk> and set the proper vga=
<mjg59> Goshawk: Right. That's not acceptable on laptops.
<mjg59> Suspend and resume won't work otherwise.
<Lathiat> mjg59: more correctly, thats not acceptable on *some* laptops
<mjg59> Lathiat: Well, most
<Lathiat> worked on the last 2 laptops i had *shrug*
<Lathiat> but to the point
<Lathiat> if it breaks on some
<mjg59> The only framebuffer with decent suspend/resume support is atyfb
<Lathiat> it might as well break on all
<Goshawk> mjg59, ok.. we will think about that in the futer version
<Goshawk> mjg59, and how do you enable the framebuffer in those laptops?
<Lathiat> because the odds are, you can't detect if it does or doesn't work
<mjg59> Goshawk: You load vga16fb on boot
<Goshawk> mjg59, how?
<Lathiat> Goshawk: also, my Xorg mode is 1680x1050
<mjg59> Goshawk: That's the distribution's problem to solve :)
<Lathiat> theres no fb mode for that :)
<Lathiat> well, not as far as i know
<Goshawk> Lathiat, no.. it matches resolution.. don't get the default
<Lathiat> be nice if there was
<mjg59> Goshawk: Your code should just deal with a framebuffer that has any resolution and colour depth, then let the distribution set up the framebuffer
<Lathiat> Goshawk: eh?
<Goshawk> Lathiat, if your card support upper to 1024*768 1024*768 is set
<Lathiat> Goshawk: oh right
<Lathiat> be nice if you could make a widescreen framebuffer
<Lathiat> stretched screen looks crap
<Goshawk> i've to go
<mjg59> Lathiat: It ought to be possible with the accelerated framebuffers
<Lathiat> Goshawk: vga=795 (1680x1050) works btw
<Lathiat> mjg59: well i have an nvidia
<Lathiat> mj	rivafb + binary drivers = bad :)
<Lathiat> s/1680x1050/1280x1024
<Goshawk> Lathiat, if a framebuffer is active, spashy will work
<Lathiat> Goshawk: anyway, good work, keep it up and make it rock :)
* Lathiat sleep
<Goshawk> ok.. see you guys.. and remember splashy can be installed on every linux system (not only ubuntu)
<Goshawk> bye people
<mdz> Kamion: ok, I have your debzilla changes available now
<mjg59> Ok, DirectFB::Create() fails
<mjg59> That's an impressively bad sign
<mdz> Kamion: but why is it that the behaviour seems to change for version 2, while version 3 would behave the same as version 2 does today?
<mjg59> Ah. vga16fb isn't currently supported by directfb, it seems
<mjg59> Which is something of an issue
<mdz> yes, I imagine it is
<kent> Lathiat, i have a nvidia (tnt2) and it works for me even though i use the nvidia binary driver from Hoary,
<Kamion> mdz: the previous *handling* of version 2 was broken, but the on-disk version 2 format remains the same
<Kamion> mdz: so, two separate things:
<mdz> Kamion: ok, if that much is correct, then it looks fine to me
<Kamion> mdz: (1) fix the handling of RFC2047-encoded metadata
<Kamion> mdz: (2) declare that metadata in format version 2 is encoded RFC2047-style, while, for efficiency, metadata in format version 3 will be decoded into UTF-8 once, and stored that way in the file
<mdz> Kamion: I've branched the breezy seeds, if there's anything you're ready to change
<Kamion> mdz: I already branched the breezy seeds?
<mdz> in that case, "uh oh"
<Kamion> cjwatson@chinstrap:/home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--breezy/seeds--breezy--0$ cat base-0/CONTINUATION; echo
<Kamion> ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-220
<Kamion> cjwatson@chinstrap:/home/warthogs/archives/ubuntu-devel@lists.ubuntu.com/seeds/seeds--breezy/seeds--breezy--0$ cat patch-1/CONTINUATION; echo
<Kamion> ubuntu-devel@lists.ubuntu.com/seeds--hoary--0--patch-219
<Kamion> we are in weirdness territory
<Kamion> should I just nuke that archive, start again, and run away from lifeless?
<mdz> let's
<mdz> I don't think baz should have let me do that
<Mithrandir> baz also lets you branch a branch on top of itself
<Mithrandir> which is kinda weird.
<mdz> Kamion: I had to nuke my revision library, but otherwise it seems happy now
<Kamion> mdz: right, I just nuked and rebranched, you should be able to commit now?
<Kamion> though I got a weird 'Unable to connect to target archive ubuntu-devel@lists.ubuntu.com' - but I just upgraded to baz 1.3, and the archive seems fine
* lamont lunches
<mdz> Kamion: as soon as it finishes downloading the 200 or so patches, I expect to be able to, yes
<Kamion> mdz: I don't think I have any seed changes until we start the big merge
<Kamion> baz 1.3 claims to be better in that regard
<mdz> Kamion: hmm, spoke too soon
<mdz> Kamion: I can't commit to it now
<mdz> commit: tree is not up-to-date (missing latest revision is ubuntu-devel@lists.ubuntu.com/seeds--breezy--0--base-0)
<mdz> update says: * tree is already up to date
<mdz> baz get said earlier:
<mdz> * from revision library: ubuntu-devel@lists.ubuntu.com/seeds--breezy--0--base-0
<mdz> * tree version set ubuntu-devel@lists.ubuntu.com/seeds--breezy--0
<mdz> I think we may be in a bad place
<mdz> Kamion: did you by any chance backup the archive?
<Mithrandir> can't you just delete the commits from the archive?
<Mithrandir> as long as you two are the only ones who have it checked out, that should be fine
<mdz> Mithrandir: not since the whole tree has been deleted
<mdz> the patch log for base-0 is in my tree; I don't know what's wrong
<mdz> Kamion: can you reproduce?
<mdz> aha, baz created ~/.arch-cache behind my back
<mdz> that was the problem
<mdz> what is the difference between a cache and a revision library?
<Treenaks> (hm, planet.ubuntulinux breaks on kinnison's blog)
<mdz> Treenaks: tell keybuk/jdub
<Mithrandir> where has all the ia64 debs gone?
<pitti> mdz: I uploaded some warty-security updates for universe today, can you please approve them=
<pitti> s/=/?/
<mdz> pitti: warty-security shouldn't require approval; does it?
<pitti> mdz: I don't know
<pitti> mdz: all I can say is that I uploaded them and they just vanished
<mdz> pitti: you ambered them, and they didn't go through?
<pitti> mdz: no, they did not even appear in the accepted queue
<pitti> mdz: and I did not get a REJECT mail either
<mdz> pitti: you'll have to ask elmo about that
<mdz> I have no idea
<pitti> mdz: fabbione suggested that they might be subject to approval from you
<mdz> things pending approval show up in accepted
<pitti> mdz: okay, thanks
<pitti> mdz: I pinged elmo today, is he away currently?
<mdz> pitti: I haven't seen him today; I don't know
<pitti> ok, I try to reach him
<pitti> mdz: I have to do some main security updates, too
<mdz> pitti: did you check accepted/REPORT?
<mdz> pitti: what are the .changes that you uploaded?
<pitti> mdz: yeah, no sign of anything
<mdz> pitti: can you send me a list?
<pitti> mdz: gbatnav_1.0.4-2ubuntu0.1, gtkhtml_1.0.4-5.1ubuntu1.1, mailreader_2.3.29-7ubuntu0.1, rxvt_2.6.4-6ubuntu0.1_source
<pitti> pitti@jackass:/srv/ftp.no-name-yet.com/queue/accepted $ grep gtkhtml_1.0.4-5.1ubuntu1.1 REPORT
<pitti> pitti@jackass:/srv/ftp.no-name-yet.com/queue/accepted $
<pitti> pitti@jackass:/srv/ftp.no-name-yet.com/queue $ grep gtkhtml_1.0.4-5.1ubuntu1.1 REPORT
<pitti> pitti@jackass:/srv/ftp.no-name-yet.com/queue $
<mdz> pitti: it's waiting in queue/unchecked
<mdz> possibly elmo disabled the cron job?
<pitti> mdz: I don't have permission to look into unchecked, so I didn't see them there; thanks for cehcking
* mvo goes to sleep now
<Kamion> mdz: the cron jobs are disabled, indeed
<Kamion> mdz: glad you got the seeds thing sorted out; I was away
<pitti> night mvo
<Kamion> mdz: the cache is for ancestry calculation, AFAIK
<Kamion> "Upgrading from older releases or other distributions is not supported"
<Kamion> Upgrading from older releases or other distributions is not supported
<Kamion> oops
<Kamion> http://www.ubuntulinux.org/support/ReleaseNotes504/
<Kamion> who wrote that upgrading from older releases is not supported? that's ridiculous
<Kamion> and appallingly misleading
<mdz> Kamion: there should be a referent there
<mdz> as in, "older than Ubuntu 4.10"
<mdz> not that there are any
<pitti> did anybody try a woody->hoary upgrade?
<pitti> this is the only additional path I can imagine
<mdz> pitti: yes, it doesn't work
<mdz> and we do not support it
<pitti> makes sense
<pitti> however, woody->warty->hoary should reasonably work
<mdz> Zomb tried it and reported a bug
<mdz> right
<pitti> so it's just like with Debian, no upgrade with skipping releases
<mdz> ah, the referent in that sentence is woody
<mdz> I'll fix it up, at any rate
* pitti deroots dhcp3-client
<mdz> corrected
<rubenv> goodevening everybody
<pitti> Hi rubenv 
<rubenv> I'm just looking over the breezy goals, any plans for async network on boot?
<rubenv> or is that a too big structural change?
<rubenv> (as we basically need to make the whole boot async then, or some hackish stuff)
<mxpxpod> mjg59: ping
<koke> hey, whois the webmaster for UDU wiki??
<koke> InterWiki links for Ubuntu wiki would be great! :D
<mdke> koke, i think mdz is in charge of it but not sure
* Kamion notes that all the listed AwfulHacks are his
<Kamion> I wonder if I'm more inclined to produce awful hacks, or just more inclined to own up to the ones I do ;)
#ubuntu-devel 2005-04-23
* Kamion suspects at least part of the latter
<zenwhen> eas a change made to font renering between rc and final?
<zenwhen> was*
<zenwhen> i cant get bitstream vera sans to not look like crap since I upgraded yesterday
<pitti> good night everybody
* pitti falls asleep
<Kamion> mdz: maybe we should post a call for awful hacks :-)
<sladen> invite me :)
<ajmitch_> hi azeem_ 
<azeem_> hi Andrew
<mdz> Kamion: fine with me
<mdz> Kamion: I think you produced awful hacks because you had a full schedule
<mdz> in addition to any inclination to report them ;-)
<Kamion> mdz: probably accurate ...
<mdz> casper has its share of awful hacks; I just haven't gotten around to adding them yet
<Kamion> as does kickseed, for that matter
<Kamion> but they're not very urgent to undo
<Kamion> and in fact some of them may be further propagated ;)
<mdz> ogra/seb128: is #8339 a GTK issue or an hwdb-client issue?
<jcole> i need help with .udebs
<jcole> for the live cd i'm trying to remaster wit ha different kernel
<jcole> is there a way to convert a .deb to a .udeb?
<mdz> doko: are you sure about #145430?  it doesn't look like a gcc-3.4 bug
<mdz> jcole: no, they are quite different things
<mdz> jcole: to produce the udebs, build the linux-source-2.6.10 source package
<jcole> mdz: i saw kernel-wedgefor kernels, but what about making udebs of other apps?
<jcole> mdz: i'm guessing i have to apt-get debian-installer and build stuff from source
<mdz> jcole: no, you don't need debian-installer
<mdz> jcole: what is it that you want to accomplish?
<mdz> if it is to use a different kernel on the live CD, you only need to build linux-source-2.6.10, and that will give you udebs
<jcole> mdz: i'm trying to something unnatural
<mdz> doko: also #6820?
<jcole> mdz: installing an fc3 kernel on the ubuntu live cd (so a certain proprietary app will work)... works on a regular install of ubuntu just fine, believe it or not
<mdz> jcole: that will be complicated for the live CD
<mdz> doko: also #93991
<mdz> doko: also #253096. how did you generate this list?
<jcole> mdz: but is it possible... :)
<mdz> jcole: of course
<jcole> mdz: does the live cd actually use the kernel in /boot in to cloop? or does it get it from a udeb? ... does it boot the /boot/ cloop kernel and load the modules from the udebs? (during the probe for hardware)
<mdz> jcole: it doesn't use the kernel in the cloop, only the modules
<lamont> jcole: it does, however, use the modules
* lamont re-reads what mdz wrote, sighs at self
<jcole> ah
<mdz> it boots using the kernel in /install, unpacks the modules from the udebs and uses those for hardware detection, then loads any remaining modules from the cloop while it's booting
<mdz> the modules in the cloop must generally match those in the udebs
<mdz> for sanity's sake
<mdz> jcole: swapping in the CD kernel is easy, swapping in the cloop modules is also easy.  the complicated bit is making udebs out of the modules; we don't have a tool to make udebs from an arbitrary kernel
<mdz> they're built from our kernel source
<mdz> our kernel source and kernel-wedge (together) contain the lists of which modules go in which udebs
<mdz> if you build a .deb out of your kernel, you could possibly use kernel-wedge to slice it up into udebs
<lifeless> mdz: is there kernel-putter too ?
<mdz> lifeless: no, but we have many kernel drivers
<lifeless> )
<jcole> mdz: sounds like if i hack up install/initrd.gz just right i may get this to work
<jcole> mdz: along with putting the right install/vmlinuz and boot/vmlinuz (cloop)
<jcole> after this, it will prove that i am brave, crazy, and/or stupid
<mdz> jcole: if you can fit all of the modules you need in the initrd, yes, that could work
<mdz> there is a size limit, which varies per architecture
<jcole> mdz: when linux boots and searches for modules to load.... how is that different than d-i searching for modules to load?
<jcole> mdz: seems a bit redundant, doesn't it?
<mdz> jcole: d-i loads the modules from external locations and unpacks them into the filesystem, where LInux can find them
<jcole> when d-i boots, modules are loaded from the install/initrd.gz and the udebs?
<jcole> after all that, when booting into the cloop, modules are then loaded from /lib/modules/2.6.10-5-386?
* jcole head explodes
<mdz> jcole: the initrd contains a minimum set of modules needed to detect the CD
<mdz> jcole: the remaining modules are loaded from the udebs once things are up and running
<mdz> jcole: the udebs contain the minimum set of modules needed to detect the network, disks, etc.
<mdz> jcole: the cloop has a complete set of modules (sound drivers, etc.)
<jcole> mdz: oh ok... this is a bit complicated
<mdz> jcole: what did I tell you? ;-)
<jcole> :)
<mdz> jcole: if you want to do it quick and dirty, you can probably get what you need by adding your modules to the initrd and the cloop
<mdz> the installer will still unpack the udebs of course, but they'll be ignored (assuming your kernel isn't version 2.6.10-5-386)
<jcole> mdz: what would happen if i put *all* modules from /lib/modules/2.6.xxxx into the initrd.gz?
<jcole> mdz: attempts to load them all?
<mdz> jcole: it will probably end up loading the hotpluggable ones
<mdz> but that should be harmless
<mdz> I'd be more worried about the size of the initrd
<mdz> 55M     /lib/modules/2.6.10-5-k7
<jcole> mdz: one last question ;) what does d-i use for hardware detection?
<mdz> jcole: in Ubuntu 5.04, it uses hotplug
<jcole> mdz: cool, that's good
<jcole> mdz: thanks for your help
<jcole> mdz: i will report here my progress tomorrow
<mdz> jcole: good luck
<jcole> like you guys care, but still
<mdz> jcole: if you succeed, it would be nice to have a document in the wiki explaining the procedure
<mdz> (hint) ;-)
<jcole> gotcha
<zul> heh...yay! slashdot fud
* zul has to stop reading slashdot
<Lathiat> haha
<Amaranth> mdz: PING?
<mdz> ?
<Amaranth> you closed https://bugzilla.ubuntu.com/show_bug.cgi?id=9048 but as a dupe but i still have no idea how to fix it :)
<Amaranth> without manually editting /etc/environment
<mdz> Amaranth: you can reinstall, or you can edit /etc/environment
<Amaranth> *sigh*
<mdz> editing /etc/environment would be the better plan
<jba> hi guys, not sure if this is a developers question but not getting many useful answers in #ubunut. I can't seem to find the Schedule (i.e. timings) for the ubuntudownunder conference
* Amaranth gets to guide a bunch of newbs through editting this file
<Amaranth> what should it be set to?
<jba> I live in sydney and would love to attend, but I need to know if I can make it after work?
<mdz> jba: that's because there isn't one yet
<jba> mdz thanks dude
<jba> i'll check in closer to the dates then?
<mdz> jba: if your question is whether things will still be happening in the evening, the answer is yes
<jba> i'm a mono/pptpclient hacker so don't really have much to contribute, but i hafve been using/loving ubuntu for a while now
<mdz> though we don't yet have a schedule showing what is happening when
<jba> well I'd still love to attend, it's just that I have a two month old son, with whom i tend to spend all of mytime
<jba> so if it's gonna be stuff like "kernel optimisation processes" in the evening, then I don't think I'll make it :)
<mdz> there will be parallel tracks
<mdz> one of them will be for Ubuntu development plans, and will be very technical
<mdz> there will also be an Ubuntu community track, which will be less technical, happening at the same time
<mdz> so there will always be something in which to participate
<jba> cool
* sladen hands jba a nine-of-diamonds
<Nigelenki> I suppose I'm not going to find disaster recovery utils on the live/install CD
<Nigelenki> should i submit a <bug> requesting that the LiveCD have tools added to it by default to detect and recover partitions incase i.e. WinXP system managment console decides to erase my partition table when i ask it to add an extended logical drive in 37.4 gigs of unpartitioned space in my extended partition?
<Nigelenki> *cough*
<Nigelenki> or would this be an "enhancement"?
<GoneBoB> there is a tool to do that
<GoneBoB> it's an enhancement
<Nigelenki> oh sweet, which one
<GoneBoB> you can file a bug with priority enhancement
<GoneBoB> I can't remember offhand, but it saved me a few times :)
<Nigelenki> heh
<GoneBoB> http://www.cgsecurity.org/index.html?testdisk.html that looks like it will do it but it's not what I used
<Nigelenki> i'll try gparted and stuff
<mdz> Nigelenki: it already contains parted
<mdz> which is one of the best tools for that kind of work
<Nigelenki> mdz:  I know it has parted, but I *cough* don't like the parted cli (rather, I like it but I don't yet know how to use it)
<GoneBoB> mdz: last time I checked parted wont recover a shagged table
<Nigelenki> damn.
<Nigelenki> I know a mandrake install cd will do it
<Nigelenki> "Rescue partition table"
<mdz> GoneBoB: see the 'rescue' command in parted
<Nigelenki> mdz:  :)
<GoneBoB> excellent :)
<mdz> gpart is also good in such situations; that one is not on the live CD
<GoneBoB> yes, gpart was what I was talking about
<Nigelenki> mdz:  30 points to you.  Gparted however would be ideal, as well. . . even sysadmins are spoiled these days (look at MS, doing away with CLI in favor of GUI utils o_o).
<GoneBoB> Nigelenki: knowing how to use the CLI means you generally understand how it works
<GoneBoB> which is much better
<Nigelenki> GoneBoB:  I tend to like understanding how things work
<Nigelenki> it's easier for me to work with something when i know what I'm doing.
<Nigelenki> like when I code, I code thinking about what's going on with stuff in memory, how things are being moved, locking, what things are affected by what changes, and how the changes are done in terms of steps taken by the CPU (not 1:1 instructions but closer than high level code; helps to optimize C code)
<Nigelenki> because I love easy to use, intuitive interface; but I really REALLY want to know what it is I'm doing
<Nigelenki> anyway, too much white noise I guess, though this place was inactive when I got here :)
* Nigelenki goes to the bugzilla; also, gpart is interesting
<Nigelenki> ok gparted doesn't have a rescue option
<Nigelenki> parted CAN'T find anything
<Nigelenki> gpart is finding stuff.
<calc> 11.44TiB in 4 days on torrents, not bad
<lamont> calc: your mirror?
<calc> the t.u.c
<lamont> ah, yes
<thom> lamont: torrent.ubuntu.com:6969
<lamont> yea
<calc> are there md5sums for http://torrent.ubuntu.com/releases/hoary/release/dvd/ ?
<wasabi> We really need a protocol as simple as windows file sharing. Just without the suck.
<Nigelenki> ok well didn't work :(
<Nigelenki> I didn't lose anything important
<Nigelenki> I'll jsut reinstall.
<Lathiat> wasabi: windows file sharing is hardly simple :)
<Lathiat> wasabi: webdav+mdns-sd = simple :)
<Lathiat> and thats pushing it :)
<wasabi> webdav is missing a lot really.
<wasabi> It is simple from the user/config point of view.
<Lathiat> in what way
<wasabi> Any machine can access any other (given auth constraints).
<wasabi> And have full control: ACLs, extended attributes.
<wasabi> Etc.
<Lathiat> sure thats why you use authentication....
<wasabi> I mean *SET* ACLs
<Lathiat> you could do that with webdav
<Lathiat> possibly not with apache
<Lathiat> don't know anything about extended attributes
<wasabi> I suspect WebDAV isn't very good about locking.
<wasabi> Not as Just Worky as CIFS anyways.
<Lathiat> wasabi: well, thats an entirely different concern
<Lathiat> something that should be looked at i guess
<paulproteus> wasabi: It depends on the server-side implementation.
<fabbione> morning
<fabbione> mornin2
<jnc> the new protocol.  mornin2mornin
<robitaille> fabbione,  in case you haven't noticed,  bug 7078 has been re-opened today...  I think it was an old favourite of yours
<fabbione> robitaille: none of the above
<fabbione> gamin is buggy
<fabbione> really badly buggy
<zul> and on the sucketh meter its betwen 1 and 10
<thom> do we have breezy love yet?
<jsgotangco> oohhh
<zul> not as far as i know
<maswan> ah, finally some stats:
<maswan> http://www.acc.umu.se/technical/statistics/ftp/index.html.en
<maswan> note that those lack the redirected install and live cds for i386
<Lathiat> 3.1 million files?
<thom> maswan: nice
<Lathiat> oh thats -
<Lathiat> so like 95000 kubuntu install cds
<Lathiat> yowzas
<Lathiat> and 90,000 - the redirected once
<calc> so is breezy not really setup for use yet? i see the dirs there but no Packages files
<maswan> the redirected ones are 4.6TB by now
<zul> calc: i would say no
<maswan> and does not turn up in that ftp stats page
<Lathiat> i don't expect breezy to get into swing for another 3 weeks
<Lathiat> altho i suspect breezy will open up sometime this week
<sladen> maswan: 9 petabytes ?
<sladen> terabyte even
<maswan> sladen: 14 terabytes if you include those additional 4.6 and the smaller ubuntu directories of a few hundred gigs
<crb> Hi all. 
<crb> I'm trying to remaster an ubuntu installer cd with specific packages/preseed.  Started with a copy off the CD, but the installer is complaining that it's not an Ubuntu CD.
<crb> Any ideas why?
<crb> (well, it's obvious why; any word on how d-i knows :)
<womble> crb: Missing the .info directory (or whatever it's called) in the root of the CD?
<crb> womble: think thats it. *slaps rsync*  Cheers for that!
<fabbione> mdz: ping?
* Amaranth heads for bed
<pitti> Good morning
<thom> hey pitti
<infinity> Hey pittithom.
<pitti> Hi infinity! How's mozilla going?
<infinity> Well enough.  Right now, I'm booking flights to Sydney, though.
<thom> infinity: you definitely UDUing then?
<mdz> fabbione: pong
<infinity> And my visa expires in two days.  Immigration and I have another apointment tomorrow to fix that.
<jdub> i drank a lava lamp
<jdub> it wasn't lava
<infinity> thom : Apparently I am, yes. :)
<thom> infinity: ouch.
<ajmitch> not good
<infinity> Could be worse, I guess.
<ajmitch> worse as in already expired?
<infinity> Yeah. :)
<infinity> When I go in tomorrow and give them 1800+ AUD, they should give me a bridging visa while we sort out my de facto spousal visa thing.
<infinity> Or something.
<infinity> I've been told not to worry.  So, I'm worrying.
<thom> heh
<infinity> Which seemed a resonable thing to do.
<thom> yeah, seems fair
<ajmitch> flatmate only got his visa renewed on the day it expired
<fabbione> hey pitti
<pitti> Hey pinh^Wfabbione
<infinity> thom : What time/day do you arrive in Sydney?
<thom> sydney? sunday i guess
<fabbione> thom: are you still working on the readhead stuff?
<fabbione> and boot speed optimization?
<pitti> elmo: ping
<thom> fabbione: oui
<fabbione> thom: you are going to have some extra fun with 2.6.12
<thom> oh?
<fabbione> thom: they added support for timestamps on printk
<fabbione> so you can see exactly how long it takes to boot the kernel
<thom> oh lordy
<fabbione> and how long certain operations take
<infinity> Well, that was a necessary feature to add in a stable branch.
* fabbione needs more coffee
<pitti> infinity: 2.6.x is not stable any more :-/
<jdub> Annodex talk coming up soon: http://150.203.247.2:8810/ (theatre), http://150.203.247.2:8811/ (screen) -> discuss in #annodex on freenode
<infinity> pitti : Was it ever?
<pitti> infinity: no, 2.4 was
<infinity> pitti : I was using the term "stable" lightly.
<pitti> infinity: I think it's a shame that they don't have a stable branch any more ... :-(
<infinity> Well, they do.  2.4 still is.  Heck, so is 2.2.
<infinity> But 2.6's patch acceptance policy does seem a bit 'out there'.
<Burgundavia> infinity, stable and useful was what I think they were looking for
<pitti> this reminds me of stable woody vs. unstable sid...
<thom> a _bit_?
* infinity still uses 2.4 on a large number of systems.
<pitti> certainly not on a desktop?
<infinity> The only really desktopish desktop I have is the laptop here, which is running a stock ubuntu 2.6 kernel right now, but probably shouldn't be.
<pitti> noooooo! a OO.o vulnerability *sigh*
<infinity> Or, at least, it needs some talking to.  It really doesn't get a long with the ATA drivers in the current hoary kernels.  It's happy with old 2.4 stuff.
<Mithrandir> pitti: nooooooooooo!
<Mithrandir> :((
<thom> pitti: aaaaiiiieee
<pitti> http://www.securityfocus.com/archive/1/395516
<infinity> At least it's an easy bug to fix.
<pitti> infinity: yeah, it's trivial, but it still requires the users to download shitloads of MB
<infinity> And there, my flights are confirmed.
<pitti> a friend of mine (modem user) suggested "patch" debs, just like the rpm counterpart
<pitti> infinity: cool
<infinity> pitti : Mail then new CDs. :)
<infinity> s/then/them/
<infinity> Too late for patches to work, you would have had to have the openoffice deb depend on an empty "openoffice-security-patches" metapackage or something.
<infinity> At least, to get automatic updates to work.
<pitti> no, I mean patch debs in general
<pitti> not oo.o specific
<infinity> In general, it's quite a shift.
<spo0nman> do you guys manage your own packages? or just re-package stuff you get from gnome/other places ?
<Burgundavia> spo0nman, most of Universe is built out of debian sid
<Burgundavia> ubuntu is about to sync to debian sid
<Burgundavia> there is also some packages for the stuff at apt-get.org repos
<spo0nman> hmm ok, 
<Burgundavia> but the stuff in main is mostly Ubuntu specific stuff, though Ubuntu tries to pass stuff back upstream as much as possible
<infinity> (And we also have many ubuntu-specific packages, and we often have newer versions of the Debian packages than Debian has...)
<infinity> spo0nman : To answer your original question: "Yes, both".
<spo0nman> hmm ok.
<rubenv> infinity: how's the PHP5 work going?
<rubenv> and goodmorning :-)
<spo0nman> to intorduce myself, Iv been a debian user since the last 8 years and have done some level of gtk programmin to be at bug fixing level.
<infinity> rubenv : It's currently a "spare time" thing, but someone sent me some pretty comprehensive patches, so it's not much work for me to polish it up.
<spo0nman> In warty thereis  no software to burn cds? does nautilus burn:/// work well I havent tried it yet fund about it only today.
<infinity> rubenv : When breezy opens up, I'll upload it at some point, and get php4 and php5 to swap seeds (putting php5 in main for breezy)
<rubenv> infinity: well, I've sent you 2 or 3 patches, I hope they still apply to 5.0.4
<Mithrandir> infinity: uhm, you're going to remove php4 from main for breezy?
<infinity> spo0nman : If you have "universe" in your sources.list, you should have access to pretty much everything you would have had on a Debian system.
<infinity> Mithrandir : Well, that or leave php4 and php5 in. Whichever seems saner.
* spo0nman does not understand universe. ddoc?
<Burgundavia> universe is all free software that is not supported by canonical
<rubenv> spo0nman: universe are basically packages done by the motu's, not the main supported packages
<infinity> Mithrandir : Dropping php4 to unsupported seems more reasonable, from a "not causing Martin too muhc unwaranted pain" perspective.
<rubenv> universe is a polished pul in of debian sid
<spo0nman> another question, can i make a mix match in the source-list of ubuntu and debian server .... BAD things will happen?
<Mithrandir> infinity: well, I'm going to hate you moderately for that, since that means we can't upgrade to breezy for a while.
<womble> rubenv: Where does the "polished" bit come into it?
<crimsun> spo0nman: wiki/UniversePackages
<rubenv> womble: motu
<infinity> Mithrandir : "we"?
<jdub> Annodex talk is on *now*: http://150.203.247.2:8810/ (theatre), http://150.203.247.2:8811/ (screen) -> discuss in #annodex on freenode
<Mithrandir> infinity: hardware.no
<Mithrandir> infinity: being a medium-to-large PHP shop, it's not trivial to port to php5
<infinity> Mithrandir : Can't move to php5 at hardware.no, or don't trust the packaging to stabilise?
<infinity> Mithrandir : The former, I see.
<Mithrandir> infinity: former, at least yet.
* rubenv 'll backport any breezy php5 to hoary, I need to deploy them on a stable sys
<infinity> Mithrandir : The last place I worked, I spent a large portion of last year porting their stuff to php5, so they could move "eventually".
<infinity> Mithrandir : No one's stopping you from running universe packages at hardware.no, are they?  I'm not going to petition to drop php4 completely, just demote it.
<rubenv> infinity: if the patches i've sent you don't apply anymore, don't mind poking me to fix them
<Mithrandir> infinity: yeah, sure.  Eventually, after porting a few hundred thousand lines of code.
<Mithrandir> infinity: I'm not going to run an unsupported version of php4.
<rubenv> Mithrandir: have you tried running it on php5?
<infinity> rubenv : Someone just sent me a mess of patches a day or two ago.  If that wasn't you, then someone else is also just as interested. :)
<Mithrandir> infinity: there's just too many security holes.
<rubenv> turn on compat
<Mithrandir> rubenv: no, as there are no packages yet. :)
<rubenv> infinity: swell :-)
<infinity> Mithrandir : Hrm.  True dat.  Well, argue with me about it when I actually bring up changing seeds.  Maybe I'll change my mind, or come to my sense, or someone else will override me.
<Mithrandir> infinity: I'll just bribe you with beer at UDU
<infinity> Mithrandir : I don't drink much.
<rubenv> Mithrandir: unfair advantage ;-)
<infinity> Mithrandir : Bribe me with something better, and we'll talk. :)
* rubenv gets breakfast, I gotta be on campus by 10
* infinity runs to find a bottle of Coke.
<Mithrandir> infinity: cocoa, then?
<Mithrandir> infinity: chocolate, glass beads, whatever it takes. :)
<infinity> Heh.
<infinity> elmo :ping.
<thom> pitti: test.xml?
<pitti> thom: sorry, I wanted to ask before
<pitti> thom: I'm testing a jabber vulnerability (crash), can I test this with you?
<thom> sure
<pitti> thom: I have no idea where gaim has an "XML console", but I'd like to play around with that
<pitti> in any way it crashes if I stop a file transfer...
<thom> hrm
<pitti> but actually I wanted to crash _your_ gaim...
<thom> my gaim was pretty uncrashed
<thom> i need to go now, sorry dude
<pitti> I stopped the transfer
<pitti> cause I wanted to warn you first
<pitti> oh, ok
<thom> (have to get a coach back to sydney)
<infinity> pitti : WOuld you consider this Win32-specific? http://www.mozilla.org/security/announce/mfsa2005-25.html
<pitti> infinity: hmm, it doesn't look particularly Win-specific
<infinity> pitti : Well, except for the part where UNIX/Linux doesn't rely on file extensions to determine if a file is executable.
<infinity> The BUG isn't Win32-specific, but the vulnerability might be seen as such.
* pitti is @phone
<pitti> back
<pitti> infinity: no, but still you could download an ELF file which is named like a GIF, no?
<infinity> pitti : Erm, you can always do that.
<Treenaks> chmod etc.
<infinity> pitti : This bug is that I can make a file called "foo.gif.bat", which is both a valid GIF and a valid batch file, and it'll display as a GIF in the webpage, but if you DnD it to the desktop, you can run it as a batch file.
<infinity> pitti : I don't see how this could affect UNIX.
<pitti> phone again
<infinity> pitti : With any web browser, I can feed you "foo.gif" which is an ELF executable.  Nothing can "protect" against that.
<Treenaks> unforgeable mime-types!
<infinity> pitti : But, on UNIX, nothing you download will automatically be +x
<infinity> (Or, it shouldn't be.. if it is, that's a different bug, though, not this one)
<infinity> s/download/drag'n'drop/
<pitti> infinity: back, supporting my gf at the phone.. :-)
<pitti> infinity: okay, I'm convinced about the +x thing :-)
<infinity> pitti : Does your GF run Ubuntu?
<pitti> infinity: no, a pre-woody
<pitti> infinity: pentium 100, 48 MB RAM
<pitti> infinity: I compiled bazaar for her
<Treenaks> *insert obvious "woody" joke*
<pitti> infinity: but she had some troubles installing it since e. g. libxml2 was not even woody-recent
<pitti> infinity: I offered her to give here a more recent computer very often, but she just likes that old thing
<infinity> Scary.
<infinity> I gave away my last machine that was that slow a few years back...
<infinity> Several years, even.
<infinity> Though I still have two P200 systems in service at the homes of my parents and brother, acting as firewall systems.
<Treenaks> my slowest machine is an old unused 600MHz laptop
<Treenaks> (but I still have 80% of a P100-era PC)
<Treenaks> (Sony 2-speed CD player, anyone? QIC-80 tapedrive?)
<infinity> "old unused 600MHz laptop"... I hate you. :)
<infinity> The machine I've been working on for the last year is a 550MHz laptop.
<Treenaks> infinity: it's falling apart
<infinity> With no battery.
<infinity> And a missing key.
<Treenaks> infinity: I've only just bought a new one (2 weeks ago)
<infinity> And X and the kernel both hate it in neat and interesting ways.
<Treenaks> oh, mine works quite well.. one loose key, but lots of damage to the plastic "shell"
<infinity> Oh, that too.  I have a mess of glue on this thing.
<infinity> The back sort of pries open when you close the lid.
<Treenaks> I have 2 huge white spots where I rest my hands when typing
<fabbione> yay
<fabbione> inotify 0.22 works
<Treenaks> fabbione: works or Works ?
<infinity> Oh well, I'll be bringing this laptop to UDU, so everyone can make fun of it/me in person.
<jsgotangco> bah my laptop is much worse
<Treenaks> infinity: don't worry, we've seen the stuff sladen and mako haul around :)
<jsgotangco> when you see it in UDU
<jsgotangco> crappy Taiwan made thing *grin*
<fabbione> Treenaks: it works.. at least my laptop doesn't crash anymore
<fabbione> too bad i already saw at least one problem using gamin with inotify
<fabbione> but that will be a gamin problem...
* fabbione ENOCARES
<Treenaks> fabbione: diverted to jdub? :P
<fabbione> Treenaks: exactly
<doko> jbailey: /lib64/tls is missing from your packages?
<fabbione> hey doko
<fabbione> doko: any ETA for gcc-4 with ppc64 support?
<pitti> carlos: why did you go away? I wanted to test seomthing else
<doko> fabbione: chinstrap:~doko/powerpc64 and http://people.ubuntu.com/~jbailey/glibc/ , you're welcome as an alpha tester
<carlos> pitti: I didn't go away
<carlos> pitti: it closed automatically
<pitti> carlos: you are offline
<carlos> :-)
<doko> fabbione: that's still 3.4 
<fabbione> doko: ENOPPC, i need a chroot on davis with that stuff
<carlos> pitti: perhaps you kill it?
<pitti> carlos: dunno, that's what I want to find out
<pitti> carlos: I send you a normal file, as a comparison
<pitti> ... as soon as you logged back in
<carlos> pitti: but as I told you, my firewall seems to be blocking the files
<pitti> carlos: I didn't actually send you files
<pitti> carlos: just some h4ck1sh commands 
<doko> smurfix: ping
<pitti> carlos: so again, you stopped the download and gaim crashed?
<carlos> pitti: no, I didn't stop the download, it says I did it but I didn't touch the cancel button
<pitti> carlos: I mean, you logged off after stopping the download...
<carlos> pitti: first time, no, It crashed, second time yes, I moved to gossip again
<pitti> carlos: ah, so it did crash
<carlos> but I didn't get anything
<fabbione> jdub: ping?
<sladen> fabbione: he was two hours idle, but could do with finding him
* infinity -> home.
<fabbione> sladen: nothing urgent
<carlos> pitti: ?
<pitti> carlos: I switched to psi again
<carlos> pitti: you went offline
<carlos> pitti: :-P
<pitti> carlos: gaim does not have an XML console
<pitti> carlos: can you please install the updated gaim I sent you
<pitti> and login using gaim=
<pitti> ?
<carlos> pitti: I'm with a ppc computer
<pitti> D'oh
<pitti> carlos: could you compile the package yourself?
<carlos> pitti: I think so, where are the sources?
<pitti> carlos: apt-get source gaim
<pitti> carlos: cd gaim-1.1.4
<pitti> carlos: patch -p1 < gaim-1.1.4-1ubuntu4.1.diff
<carlos> pitti: ok
<pitti> carlos: ^ that is the debdiff at http://people.ubuntu.com/~pitti/gaim-1.1.4-1ubuntu4.1.diff
<pitti> carlos: that'd rock :-)
<mvirkkil> mvo, jdub: I'm thinking of patching gnome-app-install to store settings in a .conf file. Thoughts?
<Treenaks> mvirkkil: why?
<carlos> pitti: it's taking a while, getting the dependencies to compile it...
<mvirkkil> Treenaks: Because stuff like the names of the menus to be used is hardcoded.
<Treenaks> mvirkkil: names of the menus?
<seb128> the menu should be the same as the panel one, so the same names
<mvirkkil> Treenaks: Hmm.. I mean the filenamess that contain the xdm menus that are used.
<mvirkkil> Treenaks: The tree is stored in a menu file. The name of that file is hard-coded.
<Treenaks> ah like that
<Treenaks> why not just a command-line option to specify a different file then?
<seb128> xdm ?
<mvirkkil> seb128: xdg
<seb128> the menu is built using pythonxdg
<seb128> is there any real usecase to change the .menu to use ?
<Treenaks> seb128: "Which ubuntu-edu packages do you want to install?"
<mvirkkil> Treenaks, seb128: My previous patch added the functionality to have multiple menus. Each is read from a separate file.
<Treenaks> mvirkkil: /why/
<seb128> Treenaks: "ubuntu-edu", is that a panel submenu ?
<Treenaks> seb128: no, but I think that is what mvirkkil is trying
<MrNonchalant> Treenaks: sorry to intrude but here's a thought, maintainability?
<seb128> that's not the way g-a-i works afaik
<mvirkkil> Treenaks: General dislike of having stuff hardcoded in the source I guess. 
<mvirkkil> Treenaks: Plus if someone would like to use it as a base for installing restricted formats, that person wouldn't need to touch the source.
<seb128> zillion of config files is not better
<mvirkkil> Treenaks: to add his own menus that is-
<mvirkkil> seb128: Hmm... It woudl be one config file for g-a-i and the rest would be resource files ;-)
<seb128> I don't get the interest of this config file
<mvirkkil> seb128: What did you mean by "not the way g-a-i works"?
<seb128> you give .desktop file to g-a-i
<seb128> and it builds a menu like the app one
<seb128> which is its job
<mvirkkil> seb128: No, you give it a .menu fiele, currently just applications.menu
<mvirkkil> seb128: Though there could be several menu files.
<seb128> that's technical detail
<seb128> it displays the same menu as the panel one
<seb128> what do you want to change to that and why ?
<mvirkkil> seb128: But you are saying it's best to have the names of those files (that can be any number) should remain hardcoded?
<seb128> I don't understand what you want to do
<seb128> the current way makes than the panel and g-a-i match
<seb128> they both display the applications.menu
<mvirkkil> seb128: I'm just asking for feedback on separating the names of those files in to a separate config file. 
<seb128> which is what the user expect
<seb128> imho that's an useless extra config file
<mvirkkil> seb128: But it's a _different_ applications.menu, if I'm not mistaken.
<seb128> no
<mvirkkil> seb128: (I might be though)
<seb128> GNOME has one .applications
<seb128> from gnome-menus
<seb128> s/.applications/applications.menu/
<mvirkkil> seb128:I thought the .deb came with it's own. 
<seb128> no
<mvirkkil> a*its
<seb128> hum, it has one, lemme check
<mvirkkil> seb128: /usr/share/gnome-app-install/applications.menu /etc/xdg/menus/applications.menu
<mvirkkil> seb128: And those are not identical (but currently extremely similar)
<mvirkkil> So it does use a separate .menu file. And when support for multiple .menu files is used, it would use it's own .menus anyway I suppose.
<koke> hey, how is this "thing" called http://www.grawert.net/mataro/img004.jpeg.medium.jpeg
<koke> can I order some of these whit shipit cd's?
<mvirkkil> koke: CD stand? And they send you one automatically I think. Depends on the number you order.
<seb128> mvirkkil: I don't understand why you want to complicate it and get one new config file for nothing
<martink> koke, http://www.gnome.org/~jdub/blog/2004/12/01/
<seb128> mvirkkil: it should just use the gnome-menus one
<mvirkkil> seb128: And when the services.menu is used? Where does that come from? 
<seb128> there is no services.menu
<koke> mvirkkil: thanks
<koke> brb
<mvirkkil> seb128: But there will (probably) be one. For installing a "web-server", "ssh server", "web based e-mail server" or similar stuff.
<seb128> mvirkkil: not sure, an user doesn't need to install those
<seb128> mvirkkil: and an admin can use synaptic
<mvirkkil> seb128: I'm not the one who is suggesting to add a services menu. But there was references to that in the sourcecode and ross/mvo/jdub/seomeone confirmed.
<seb128> and even if we do a services.menu for that, not need of a config file, you just need to have menu selector from the UI applications/webserver/...
<mvo> having services in g-a-i was part of the original design, but it was dropped for hoary. I think we need to discuss this in UDU 
<seb128> imho that should be an UI option
<seb128> not one new config file
<mvirkkil> mvo: What do you think about specifying the .menu files to be loaded in a separate config file? Cluttering or cleaning?
<mvirkkil> *cleansing
<remi`> mvo, did you have time to check out the bug for update-notifier?
<mvo> mvirkkil: sorry, no opinion yet. that part of the code was mostly ross area of work
<madduck> could someone please tell me about how many packages are in {base,desktop,supported} together, please?
<mvo> remi`: looked over it very briefly only. will try to do it today
<remi`> mvo, ok thx
<mvirkkil> seb128: So you suggest using one enormous menu, instead of using smaller ones?
<seb128> mvirkkil: ??
<seb128> mvirkkil: how a config file would change the menu look ?
<mvirkkil> seb128:  "applications/webserver/"
<seb128> I suggest to have a command line option or a menu file with the different options
<seb128> so you pick menu, app
<seb128> menu, webserver
<seb128> and you have the corresponding simple meny
<seb128> menu even
<seb128> ups
<seb128> s/menu file/menu menu/
<seb128> user don't expect to go to /etc to change a config file
<mvirkkil> seb128: Even though I disagree, I'm not saying that a user would be going to any config file.
<seb128> just make the app listing the .menus installed and do a corresponding UI options to pick the one you want
<mvirkkil> seb128: Now that is a suggestion I like. I scan the directory where the .menu files are suppoed to be and just generate the tabs from them.
<mvirkkil> s/suppoed/supposed
<MrNonchalant> user has already had to change the grub menu.lst every time synaptic adds a kernel so that their machine dual-boots properly
<MrNonchalant> I'm sure user won't mind
<mvirkkil> seb128: BTW: Here's the way my patch changes how the UI looks: http://users.tkk.fi/~mvirkkil/old_new_appinstall.png (new to the left)
<Burgundavia> mvirkkil, not to be rude, but I am wondering what the point of the tab is?
<mvirkkil> Burgundavia: Well, the point is that there will be several tabs once several menus are used
<seb128> mvirkkil: nice, can you put a bugzilla bug with that ?
<mvirkkil> seb128: So now each .menu file would automatically be used to generate a new tab. I like the idea. A developer would just need to drop in a .menu file 
<mvirkkil> seb128: there already is one.
<Burgundavia> mvirkkil, ahh
<seb128> mvirkkil: oh, k
<Burgundavia> mvirkkil, are we talking places/system?
<seb128> mvirkkil: right, that's better than having a config file
<mvirkkil> Burgundavia: Not sure what you mean. I'm referring to the services menu/tab
<mvirkkil> seb128: https://bugzilla.ubuntu.com/show_bug.cgi?id=8762
<pitti> carlos: any luck?
<Burgundavia> mvirkkil, you finally removed the annoying grey space thing
<mvirkkil> seb128: I agree. I'll try to implement something like that.
<seb128> cool
<seb128> thanks
<mvirkkil> seb128: Burgundavia: I hadn't checked bugzilla lately. There is some interesting discussion there: https://bugzilla.ubuntu.com/show_bug.cgi?id=8892
<carlos> pitti: still compiling
<pitti> carlos: uh, I compiled the warty _and_ hoary version in the meantime :-)
<Burgundavia> mvirkkil, thanks, taking a look now
<carlos> pitti: I'm doing other tasks at the same time and my powerbook is three years old already...
<carlos> :-)
<Burgundavia> mvirkkil, services? are we talking things like servers?
<mvirkkil> Burgundavia: yes
<Burgundavia> mvirkkil, ah ok, we are talking different types of applications
<mvirkkil> Burgundavia: The terminology in use is that one server offers several services like e-mail, www, ssh etc.
<Burgundavia> ok
<Burgundavia> nice idea
<mvirkkil> Burgundavia: Meaning the server is the physical computer(i think)
<madduck> could someone please tell me about how many packages are in {base,desktop,supported} together, please?
<mvirkkil> madduck: Try something like  apt-cache dump|grep Package|wc -l
<madduck> mvirkkil: i don't have an ubuntu system. i just writing about it. :)
<madduck> mvirkkil: could you run it quickly?
<mvirkkil> madduck: I don't have a standard ubuntu installation, and I'm not sure it works, it was just a pointer in one direction.
<madduck> mh. thanks...
<Burgundavia> madduck, are you looking for a number count of the supported software?
<mvirkkil> mvo: Do you know about this separating .desktop files in to their own package thing?
<madduck> Burgundavia: yes.
<Burgundavia> madduck, ok, just a sec
<madduck> Burgundavia: just a rough estimate for http://debianbook.info
<madduck> right now it's at 850 packages, but that was before warty
<dredg> niall@binky:~(0)$ grep ^Package /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hoary_main_binary-i386_Packages|wc -l
<dredg> 3136
<mvirkkil> madduck: My non standard install has over 35 thousand, though I know most of them are not in main/base/whatever :-)
<dredg> madduck: will that do?
<Burgundavia> madduck, around 3000 for me
<mvo> mvirkkil: splitting it out is a planed feature. I guess we need to talk with ross and jdub about the future of g-a-i :)
<mvirkkil> madduck: Crap. It's actually just 20 thousand.
<madduck> Burgundavia: is that base,desktop,supported ?
<Burgundavia> madduck, that is just the supported stuff
<mvirkkil> mvo: How does that affect the .menu files?
<madduck> ...ts_hoary_main_bina... -- and I thought you guys don't have 'main'
<mvo> mvirkkil: I don't think it will affect them at all, it's just easier to maintain this way
<mjg59> madduck: main is the supported subset of Debian main
<mvirkkil> mvo: I mean would you separate them too?
<mvirkkil> mvo: Or would they be distributed with gai?
<madduck> mjg59: ic thanks.
<mvirkkil> mvo: Not sure that it really matters, though...
<mvirkkil> mvo: Especially if the .menu files are detected on the fly.
<mvo> mvirkkil: my gut feeling is that I would seperate them too or at least have some mean to install additional ones via a deb. it might come handy for people who want to add additonal stuff (like games :)
<Bnonn> urgle
<mvirkkil> Though then gai will expect them in one directory.
<mvirkkil> mvo: Ok. But if gai is autodetecting them, it will expect them all to be in one directory.
<mvo> mvirkkil: that shoudn't be a problem, should it?
<mvirkkil> mvo: No. This sounds pretty good, I think.
<Bnonn> might be the wrong channel to ask this in, but I notice on the hardware support list the Audigy ES listed twice
<Burgundavia> madduck, any other questions I can answer?
<Bnonn> since i have one, I have a vested interest in wondering what the difference is between emuk10k1 and snd-audigyls
<Bnonn> and is there any way to get my currently not-working Audigy working?
<madduck> Burgundavia: well, no. I am not sure 3000 is the answer... has ubuntu really grown from 850 supported to 3000 supported packages in half a year?
<Burgundavia> madduck, not having done the same on a warty system, I cannot judge
<carlos> pitti: sorry, it's ready. I didn't see it :-P
<carlos> pitti: installing
<mvo> madduck: I have 2870 here in main not including the "translations" section
<madduck> ok. thanks.
<jbailey> doko: No, they're native NPTL packages.  It's the configuration I'm hoping to have work out, so no need for /libc64/tls.  
<jordi> J! E! F! F!
<ajmitch> aha, jordi lives
<jordi> ajmitch: hello!
<ajmitch> hey jordi, what's up?
<jordi> I'm ultra busy
<jordi> this sucks.
<mvo> hey jordi 
<jordi> hey mvo 
<pitti> carlos ?
<jordi> I haven't checked, but if you have done string changes to synaptic I MIGHT kill
<carlos> pitti: it crashed :-(
<pitti> D'OH
<jordi> carlos: oooii carlos
<carlos> jordi !
<fabbione> pitti: yo dude
<carlos> jordi: sindominio spamassassin eats launchpad's mails!
* mvo whistles innocently
<carlos> pitti: any chance the crash is not related to that bug report?
<pitti> carlos: I don't know; http://sourceforge.net/tracker/?func=detail&aid=1172115&group_id=235&atid=100235
<pitti> carlos: ^ that's spanish; maybe you can tell me?
<carlos> pitti: try sending me a normal file so we can be sure it's not another bug...
<carlos> pitti: it talks only about the security bug, nothing related to a general bug
<pitti> carlos: sending...
<lifeless> anyone seen elmo today ?
<fabbione> lifeless: nope
<GheRivero> res
<jdub> fabbione: pong
<fabbione> jdub: inotify 0.22 works here
<jdub> fabbione: aha, wonderful! :)
<pitti> fabbione: yay
<fabbione> jdub: you will be happy to know that the new inotify will make gamin look even more horrible than it is now
<fabbione> i am going to push you the kernels soon
<jdub> fabbione: ha ha :-)
<fabbione> and you will have to fix gamin
* pitti runs away
<pitti> fabbione: there's still no answer from DV :-(
<fabbione> take into account that the loop on Desktop doesn't work at all
<jdub> fabbione: there are 0.22 patches for gamin, so we'll see how they look - should be a lot nicer in general
<thom> pitti: he's on holiday
<pitti> aha
<fabbione> because nautilus doesn't register it at all
<fabbione> or gamini
<fabbione> or whatever
<fabbione> well the kernel works...
<pitti> give it to us!!! :-)
<fabbione> now it's time to fix your crap :P
<fabbione> pitti: in a couple of days...
<jdub> fabbione: all that ooky desktop level mess ;)
<fabbione> i have almost done updating all the external drivers
<fabbione> + i want to add GFS and ipv6 statefull firewall before release -1
<fabbione> probably something more.. i haven't decided yet
<fabbione> GFS = teh w1n5
<Treenaks> GFS = the redhat thingy?
<fabbione> Treenaks: yes
<fabbione> Global File System
<Treenaks> l33t!
<fabbione> that on top of AOE is really n34t
<fabbione> Treenaks: remember.. it's not a case what i asked on -motu :P
<fabbione> everything has a meaning in this universe
<fabbione> specially inside my universe :)
<maswan> AOE = ATA Over Ethernet?
<fabbione> maswan: yes
<jdub> fabbione: mmmmmmmm, GFS. i will kiss you.
<maswan> Ah, that makes it a bit more resonable
<fabbione> jdub: you already own me enough beers... 
<fabbione> jdub: start to prepare the vaseline and bend ov^W^W^W^Wthe real liquors
* milli really wants working AFS
* maswan really wants working AFS too
* milli noticed that AFS is completely broken in Ubuntu
<fabbione> maswan, milli
<fabbione> afs is exactly as upstream...
<fabbione> we don't apply any patch to it
<milli> fabbione: I know.  What's in sid is the 2.4 kernel stuff
<fabbione> if you are aware of patches and stuff just open an enanchement bug with the patch
<milli> The patches for 2.6 kernel are in experimental
* milli is playing with 1.3.81 now
<fabbione> milli: if they are in experimental, there is a reason
<milli> nod
<milli> Debian sid has a 2.4 kernel offering however....
<milli> It just sucks that the AFS hooks in 2.6 kernel got left behind by Linus et al...
<fabbione> that's probably because the upstream for AFS isn't doing a very good job
<maswan> fabbione: which one of them, openafs or arla?
<maswan> or both?
<fabbione> maswan: i don't know..but if the code is clean, Linus usually have no issues in pulling in stuff
<maswan> fabbione: To be honest, I don't know if either of them are gpl-compatible even or if they are possible to relicense in such a way.
<milli> the prob with OpenAFS was it hooked setgroup* calls in the syscall table
<milli> and that's a no-no in the 2.6 world
<Treenaks> milli: sounds evil
<fabbione> maswan: there are not only license problems in life.. you know? ;)
<fabbione> linus wants clean code..
<milli> It had to do that because PAGs are not implemented in the kernel
<Treenaks> milli: then they should implement that
<lamont> milli: you should sleep sometime, you know...
<milli> It's getting worked out....
<milli> lamont: you should too
<lamont> milli: just finished
<milli> lamont: ditto :)
<lamont> heh
<Treenaks> lamont: oh, you're not pre-lagging for UDU? :)
<maswan> fabbione: sure, but then there has to first exist clean code that can be submitted. :)
<lamont> (morning)
<lamont> Treenaks: sadly, kids need taken to school pretty much 5 out of 7 days.
<Treenaks> lamont: oh yeah
<milli> lamont: They need to be there at like 7:30?
* milli hears his own children stiring
<lamont> milli: yeah - target is to leave the house by 6:45, so that we really leave by 7
<milli> lamont: All too familiar with time padding...
<maswan> milli: arla kind of works, but 0.38 isn't packaged yet,and packagin is apparently a big ammount of work due to how upstreams packages stuff
<lamont> OTOH, wifely one is driving today
* Treenaks has no kids, but does do the time padding thing
<milli> lamont: Well, AFS 1.3.81 does seem to build fine on hoary
<lamont> milli: coolness
<Treenaks> (so I'm an hour early, often)
<milli> maswan: If the kernel module from 1.3.81 openafs doesn't work reliably yet, I'm going to fallback and build a 2.4 kernel for hoary.. :(
<milli> and live without inotify and gamin and such
<milli> AFS is a very important part of my life
<maswan> milli: the packaged 0.36 arla works with a few small patches, at least it worked on warty
<maswan> same here, at least at work.
<milli> ...as in, all of my files live on my AFS server
<maswan> oh, well, bbiab.
<milli> er, servers
<mvirkkil> Ross isn't going to like me...
<mvirkkil> I made severa invasive changes in one sweep.
<bob2> "We continue to build libqt2 and all dependant packages with g++-3.3." <- isn't the whole kde2/qt2 tree still built with gcc 2.95?
<lamont> bob2: not on ubuntu
<lamont> 2.95 is not in the archive
<bob2> hrm, ok
<bob2> so it's binary incompatible with debian anyway?
<lamont> wouldn't surprise me
<bob2> heh
<lamont> bob2: it was an intentional decision to not bootstrap gcc-2.9*, nor gcc-3.2
<bob2> ah, ok
<fabbione> mjg59: ping?
<mjg59> fabbione: Hi
<fabbione> mjg59: yo...
<fabbione> the 2 suspend/resume patches for ipw2100 and ipw2200 were stolen from head?
<mjg59> From their respective heads, yeah
<zul> hey
<fabbione> mjg59: thanks
<fabbione> hi zul
<zul> hey fabbione 
<torkel> maswan, milli: neither openafs, nor arla will probably be in the kernel proper anytime soon. None of the are intrested in it
<torkel> and the afs code that are in the kernel is just plain broken, and has no connection with openafs or arla
<torkel> milli: if you want an unofficial arla that works with hoary I have it available at /afs/hpc2n.umu.se/home/t/torkel/www/arla/Ubuntu/
<milli> torkel: I was just perusing Arla's page...  any issues with that interoperating with openafs file servers?
<torkel> the right thing to do, is to drop kerberos4 support in heimdal, as krb4 is unsecure at protocol level
<torkel> then it _should_ be a piece of cake to build a newer arla
<torkel> milli: not that I am aware of. The performance is not the best, on the other hand it seems to be a lot more stable on amd64 than 0.36
<milli> torkel: That's why I didn't go with Arla way back when... no krb5 support
<torkel> milli: I think arla has supported krb5 as long as openafs
<mvirkkil> seb128: Posted the .menu-file scanning thing: https://bugzilla.ubuntu.com/show_bug.cgi?id=8762
<mvirkkil> Burgundavia, mvo: Posted the .menu-file scanning thing: https://bugzilla.ubuntu.com/show_bug.cgi?id=8762
<mvo> mvirkkil: thanks, that was quick!
<mvirkkil> mvo:Well, I made some other modifications too. Ross will hate my guts when he reviews the patch.'
<mvirkkil> mvo: Because it's large, invasive and non trivial.
<koke> mako: I've just sent you a mail about UDU
<koke> have to go now
<koke> bye all!
<mvo> mvirkkil: heh
<mvirkkil> mvo, seb128, Burgundavia: Any other suggestions for improvements?
<mvo> mvirkkil: have you seen ross comment about showing the gui early and having a busy-cursor then? 
<mvo> mvirkkil: we'll progress bar support for the initialization soon I think. my python-apt tree supports progress objects that can be used to give more visual feedback while it is initializing
<mvirkkil> mvo: Yes, it's fixed in the new patch
<mvo> mvirkkil: great, thanks
<mvirkkil> mvo: That'd be nice.
<ogra> hi all
<mvirkkil> mvo: How are the prgoress objects implemented? I poll them or they call back?
<mvo> mvirkkil: as callback objects, I can /msg you a example if you want
<mvirkkil> mvo: Sure
<mjg59> Goshawk: About?
<Goshawk> hi
<Goshawk> mjg59, about what?
<mjg59> Goshawk: About as in "Are you about" :)
<mjg59> Goshawk: sorry, I was just looking at the splashy thing again. The real problem is just that directfb doesn't work with vga16fb
<mvo> seb128: mind if I take over #6821?
<Goshawk> mjg59, the kind of card are you talking about are only few models (second me, it can't be true). Nowadays about 200 people are using an old version of splashy caleld usplash-0.1preview that is bugged, we need splashy-0.1 soon as possible
<mjg59> Goshawk: Ok, I can phrase this differently:
<mjg59> Goshawk: If Breezy is going to have a bootsplash system, it must work with vga16fb as otherwise it will not (in most cases) allow suspend and resume to work
<Goshawk> mjg59, for Breezy relase it will be ready.. and does not Breezy will have usplash? (it's a sarcastic question..)
<mwh_> Hi, I tried to reinstall debianutils and coreutils at the same time but it failed because coreutils replaces debianutils, is that a bug or a feature? Im wondering, if its a bug I would write a bugreport about it .. but if it is not, then please explain why its a feature
<mjg59> Goshawk: Breezy will have bootsplash if we have code that works with vga16fb
<mjg59> If we don't, it won't
<Goshawk> mjg59, sure
<Goshawk> mjg59, we will do all in our possibilities to agree with ubuntu requests
<mvo> ping lamont 
<lamont> mvo: ack
<mvo> lamont: do you have a ia64 machine with update-notifier runing by chance? I got a crash report 
<lamont> mvo: no.  the only ubuntu ia64 box I have just has a server install
<lamont> note that archive.ubuntu.com doesn't have ia64 bits in it, could that be the source of you rcrash?
<mvo> lamont: thanks. the crash seems to be deep inside the libhal/u-n interaction, I'm not sure yet
<mvo> might be a 64bit uncleanless even that does not show on amd64 :/
<lamont> mvo: I suppose I could install the 115 packages that update-notifier would require...
<mvo> lamont: no, better leave it then :)
<pitti> btw, daniels, if you do dbus packages, could you please put them on p.u.c?
<pitti> daniels: I'd like to play with hal, but I don't want to duplicate your packaging for dbus
<daniels> pitti: yeah, i'm going to put them up on p.u.c/~daniels/dbus/ tonight
<pitti> rock
<daniels> was hoping to get it done earlier, but had a rather hellish day
<lamont> mvo: fwiw, one of my home-office projects is to move the production stuff on the i2000 to another machine, so that I'll have both itanium and mckinley hw for testing
<mvo> lamont: nice! what time-frame are we talking about? days? weeks? I don't really think it's a pressing issue as ia64 is not the most common architecture around. but I still don't like crashes :)
<lamont> mvo: before UDU
<mvo> lamont: great, thanks
<pitti> ogra: here?
<ogra> pitti, yop
<lamont> mdz awake yet, I wonder?
<daniels> fuck
<daniels> Keybuk: advice?
<daniels> Keybuk: dbus-glib-1 just changed major soversion from 0 to 1
<daniels> Keybuk: do I take this opportunity to get rid of the stupid naming and call it libdbus-glib-1-1?
<daniels> (libdbus-glib-1.so.1)
<Keybuk> yes, if the soname has changed, the binary package name should change
<Keybuk> and as you're NEW-bound, it's a good time to fix it
<Keybuk> (imo)
<Mithrandir> Keybuk: any particular reason pkg.m4 had inconsequent quoting?  (And it quotes its secondary argument, which means stuff like gtk's configure.in falls over. :P)
<Keybuk> Mithrandir: e.g.?
<daniels> Keybuk: is libdbus-glib-1-1 a sensible name?  i just feel totally filthy
<Keybuk> daniels: if that's the soname of the only library in it, sure
<daniels> ugh
<Mithrandir> Keybuk: dnl inside the quoted string, for instance.
<aj> jdub: around?
<Mithrandir> Keybuk: gtk has that
<jdub> aj: yo
<aj> jdub: is pia changing her name?
<jdub> aj: yeah
<jdub> P. Waugh
<jdub> pwaugh!
<aj> jdub: so getting "Pia Smith" business cards on monday would be bad, right? :)
<jdub> everyone's been trying to convince her to change her nick to pdub
<jdub> aj: yeah
<Keybuk> Mithrandir: which string?
<jdub> aj: that would be kinda mistimed
<aj> "Pia Waugh" is correct spelling etc?
<Mithrandir> Keybuk: they have PKG_CHECK_MODULES([foo dnl\nbar dnl\nbaz] )
<jdub> aj: yeah
<Keybuk> Mithrandir: that's their own silly fault then, isn't it :p
<thom> shame her middle initial isn't 'h', really
<jdub> aj: thanks for tonight's surreal thought
<Mithrandir> Keybuk: depends on whether it makes sense for that string to always be quoted or not -- what's the reason for you changing it?
<Keybuk> especially given [foo\nbar\nbaz]  would work :p
<Keybuk> Mithrandir: consistency with auto* style
<Mithrandir> Keybuk: is this documented somewhere so I can twap people with it?
<Keybuk> nope
<aj> jdub: i asked if there were any problems with her card and she said no... dear oh dear...
<raavi02> hai folks
<jamesh> Keybuk: most autoconf macros evaluate their arguments once though, don't they?
<raavi02> Questions regarding codes for playing different formats of video and audio
<jdub> aj: she has *no* idea.
<jdub> aj: that's completely not on our radar, thus surreal for me too :)
<aj> jdub: i trust you don't mean "she has no idea that she's changing her name, but she will, she will" :)
<jdub> ha ha
<jdub> she has no idea she's getting married! HA HA HA HA HA!
<ogra> oh, you didnt tell her ?
<spiv> I don't think weddings really work as surprise parties ;)
<thom> ogra: she's in denial
<ogra> heh
<jdub> aj: you coming to the partay?
<aj> jdub: if i work out how to get there & back; the bus only leaves in the morning right?
<mantiena> Hi all
<jdub> aj: could you meet someone in sydney, or are you going to be in canberra already?
<aj> nah, brisbane to canberra flight
<mdz> lamont: here
<mantiena> ubuntu wiki is broken :(
<mdz> fabbione: here
<mdz> morning
<ogra> morning mdz 
<daniels> morning mdz
<jdub> aj: hmm
<jdub> hmm, tiger's due on the 29th
<mantiena> guys, I can't login into ubuntu wiki about 2 weeks I get an error:
<mantiena> Site error   This site encountered an error trying to fulfill your request.  The errors were:
<mantiena> Error Type   UnicodeDecodeError
<mantiena> Error Value   'ascii' codec can't decode byte 0xc4 in position 12: ordinal not in range(128)
<mantiena> should I report a bug ?
<daniels> mdz: got a few minutes?
<spiv> mantiena: Yes, please do.  Also, what's your username you're logging on with?
<mantiena> spiv: mantas@akl.lt
<mdz> daniels: yes
<jamesh> Keybuk: http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_96.html seems to say the extra quoting pkg-config-0.16's M4 did is a bad idea
<Keybuk> possibly ... talk to the maintainer
<spiv> mantiena: Ouch, looks like something in our plone setup is breaking because your name contains non-ascii chars.  :/
<Keybuk> I can't immediately think of a reason for the [[$2] ] , was probably a brain-fade
<Keybuk> but I don't maintain it or care anymore :p
<jamesh> Keybuk: I have :)
<mantiena> mdz: now hoary is released, maybe you can add install parameter (template) to casper (minor modifications to casper-check.templates and S60casper-check files) ?
<mantiena> spiv: yea, I'm from Lithuania and my family name contains ccaron and umacron symbols :)
<mantiena> mdz: I can give you patch'es
<spiv> mantiena: Yeah, I can see it just fine in the DB... the problem appears to be in the plone site somewhere.
<Keybuk> hmm, is breezy open yet?  </awty>
<spiv> mantiena: If you file a bug and tell me the bug number I'll make sure it gets sorted out.
<Kamion> Keybuk: no
<mdz> mantiena: you can send me an arch branch to merge; you insisted that I had to provide revision control, remember?
<mantiena> spiv: ok, I try don't forget to fill the bug :)
<Keybuk> ok, that explains "IOError: not a gzipped file" :)
<mantiena> mdz: hehe, it seems learning arch is not so fast as I think :)
<mantiena> GheRivero: hi
<GheRivero> res
<cartman> is it true that breeze development won't start before ~2 weeks ?
<Kamion> cartman: I don't think it's decided yet
<jdub> jdubtv! -> http://node.waugh.id.au:8800/
<cartman> Kamion: humpf ok
<Kamion> cartman: http://www.ubuntulinux.org/wiki/BreezyToolchainTransition
<cartman> Kamion: cheers
<ogra> jdub, hey, your beard is gotten long :)
<jdub> yeah, have to chop it a bit for sunday :)
<cartman> wowow
<ogra> :)
<cartman> that looks so cool
<cartman> toolchain updates that is
<cartman> finally I can stop recompiling C++ libs with gcc 3.4.0 :)
<Amaranth> it's going to be a PITA having the kernel compiled with 3.4 and the main compiler being 4
<cartman> is KDE 4.0 realistic for breezy? If not, transition qt and KDE as well. <-- lol
<cartman> KDE4 is not coming soon so its unrealistic
<Amaranth> I thought Qt puked on gcc4
<cartman> Amaranth: fixed as Qt is in their QA suite
<Amaranth> jdub: eww....
<cartman> Amaranth: ie you can't release a gcc that can't compile Qt
<cartman> stable release that is
<hno73> mantiena: Hi. Thank you for reporting the log-in error. I will look into it.
<Riddell> cartman: no
<cartman> Riddell?
<Amaranth> cartman: Sure you can, if they abuse gccisms and not standard C++.
<Riddell> cartman: oh sorry, thought you were asking not quoting
<cartman> Amaranth: Qt never does that ;)
<cartman> Riddell: hehe
<Amaranth> This is why people watch jdub, he randomly freaks out. :)
<daniels> bugger.
<mantiena> hno73: thank you for looking into it ;)
<Amaranth> ...and picks his nose.
<hno73> mantiena: np, thanks for alerting us :)
<cartman> so breeze will be a big change
<ogra> cartman, like oary was
<ogra> hoary even
<cartman> ogra: Abi transition is harder imho :/
<cartman> ogra: like hope Debian will do the same in parallel
<Amaranth> pfft, debian will be using 3.x until next year :P
<ogra> cartman, python and xorg transition were not easier i guess :)
<cartman> ogra: xorg was the reason I switched from sid to hoary :)
<ogra> :)
<seb128> mvo: not at all :)
<daniels> pitti, thom: this is a bit harder than I expected.  co-ordinating the soversion transition with hal will be a bitch, since we try to restart dbus in the init script ... blurgh.
<pitti> daniels: hm, hal needs to conflict to earlier dbus'es anyway, I think
<pitti> daniels: maybe just stop hal on upgrades
<daniels> pitti: but hal is stopped and started with dbus-1's init script :\
<pitti> daniels: upgrading hal when hald doesn't run will start hal again (or should be made to for this case)
<daniels> pitti: so we need to stop dbus before the upgrade, get hal and dbus installed at the same time, and then configured later
<daniels> ahr
<pitti> daniels: yeah, but if hal depends on the newer dbus, dbus will be upgraded and configured first
<hno73> mantiena: what is your login? does it have any UTF-8 characters in it?
<daniels> i need to crash now, but i'm putting my current sources up
<daniels> pitti: if dbus is configured first, we lose
<daniels> pitti: because libdbus-1-1's init script will try to start hal, and bomb out because the old hal is still installed
<pitti> daniels: right, you must not start hal if you upgrade from 0.23 -> 0.30
<daniels> yep
<pitti> daniels: otherwise you can
<pitti> daniels: you put your current package up?
<pitti> daniels: even if it's not yet perfect, its enough for playing around with the new hal and test what breaks
<daniels> pitti: yeah, just waiting for it to upload
<mdz> elmo: ping?
<pitti> Morning mdz
<mdz> morning
<pitti> mdz: I still had no luck with contacting elmo today; maybe he is travelling?
* pitti -> some workout and food, back in ~2 hours
<daniels> bah
<daniels> when pitti comes back, could someone please tell him dbus sources are at p.u.c/~daniels/dbus/?
<daniels> thom: ^^
* daniels -> bed
* Keybuk considers wandering into town to buy a new suitcase
* lamont will go into town soon to buy a computer for the 9year-old, and other errands
* milli wonders if lamont found Eagle Computers again
<lamont> milli: not yet
<CarlK> Wasn't this just brought up on the mai list?  from #xorg: ajax: if we had a way to probe DDC on a card without running all of X, we could do that pretty reliably
<hno73> mantiena: are you logged in ok to the website now?
<mdke> wiki rss feeds are down?
<astharot> ciao
<mdke> does anyone know what's wrong with the wiki rss feeds? I get a strange message: XML Parsing Error: not well-formed Location: http://ubuntulinux.org/wiki/pages_rss Line Number 38, Column 40:      <title>Web Browsing slow ( IVP6 <-> IVP4 )</title>---------------------------------------^
<Mithrandir> looks like the < isn't properly escaped, then?
<sm> mdke: you use those ?
<mdke> yeah
<mdke> hi sm
<sm> hi there
<mdke> Mithrandir, i don't understand that sort of thing ;)
* mvo is away for ~2h
<sm> looks like a bug, sorry
<mdke> oh right
<sm> can you paste that error into a new issue at http://zwiki.org/IssueTracker
<mdke> np
<mdke> its been working fine until today btw
<sm> you can work around by changing that page's title 
<sm> Web Browsing slow ( IVP6 <-> IVP4 )
<sm> do something with the <->
<mdke> me?
<sm> oops, wrong channel, my bad
<mdke> wanna go --> ?
<mdz> Kamion: I noticed that we never got around to disabling the addition of ide-* to /etc/modules :-/
<mdz> Kamion: let's do that early for Breezy
<Kamion> mdz: bug #9099 filed
<seb128> arg
<seb128> bug flood
<ogra> ?
<seb128> I've like 20 bugs on my box, FTBFS with gcc-3.4
<ogra> throw them away, gcc4 is the way to go ;)
<mdz> Kamion: thanks
<seb128> if I thow them, it'll not built with gcc3
<seb128> 3.4 even
<seb128> ups, nm
<seb128> mdz: when will breezy open to upload ?
<jordi> hmm. I wonder if all ubuntu mirrors are supossed to have cd images?
<mdz> Kamion: bug #9101 -> I seem to recall you preparing a patch so that pcmcia wouldn't be installed if it were disabled in the installer, but I can't find a bug reference.  was there a bug filed about it?
<mdz> seb128: I don't know; I have not received a response from elmo
<seb128> elmo: ping ?
<mdz> seb128: we will want to make the toolchain changes before we start with general uploads anyway
<seb128> arg
<seb128> the bug management is going insane
<mdz> yes, I can't keep up with ubuntu-bugs
<Kamion> mdz: ddetect (1.11ubuntu13) hoary; urgency=low
<Kamion>   * Don't install pcmcia-cs if hw-detect/start_pcmcia=false (closes: Ubuntu
<Kamion>     #8678).
<Kamion>  -- Colin Watson <cjwatson@ubuntu.com>  Tue,  5 Apr 2005 14:14:20 +0100
<seb128> and not beeing to upload packages is not funny
<seb128> there is like 40 new tarballs for GNOME, some of them fix the the gcc4.0 ftbfs getting filled since redhat is working on that 
<Kamion> mdz: I've pinged the bug
<seb128> bah, need to find a way to manage the backlog
<Kamion> jordi: not necessarily
<mdz> Kamion: oh, so that actually went into hoary, then? hmm
<Kamion> mdz: yeah
<Kamion> lamont: any chance you could fix everything apart from the _errors business in Debian #282672? That code is copied into busybox-cvs and there's a similar bug open there; it would be annoying for busybox-cvs to have to fork as well as copy.
<\sh> any debian packaging expert online to poke some questions and peek some answers ?? :)
<Kamion> \sh: just ask
<\sh> Kamion: I'm trying to build a lib package...it looks like that everything for the libfoo deb is ok..but for libfoo-dev not. it looks like it losing the predefined install directories or whatever
<seb128> how do you move files to the this package ?
<\sh> seb128: i'm using cdbs and using install hooks...cause the lib itself is not autotools 
<\sh> so install/libfoo:: \ install -D libfoo.so ${CURDIR}/debian/foo/usr/lib/libfoo.so <----works
<seb128> urg
<\sh> install/libfoo-dev:: \ install -D foo.h ${CURDIR}/debian/foo/usr/include/foo.h <--- works too
<mdz> tech board meeting in 30 minutes on #ubuntu-meeting
<\sh> but dh_install -plibfoo-dev : cp: cannot stat ./usr/include/foo.h 
<ogra> mdz, huh ?
<ogra> mdz, not 20:00 UTC ?
<mdz> er, 90 minutes ;-)
<ogra> heh
<mdz> silly DST
<\sh> so...where am I wrong?
<pitti> thom: here? can I please have the php4 build dependencies on concordia's amd64 dchroot?
<seb128> ogra: what hour is the current one ? 18:40 or 19:40 UTC ?
<ogra> ogra@honk:~ $ date -u
<ogra> Di Apr 12 18:37:04 UTC 2005
<ogra> says my hoary....
<seb128> right
<pitti> and it says right
<seb128> rock
<seb128> I'll have time for dinner before the meeting :)
<ogra> :)
<pitti> mdz: can we already upload to breezy (to have our crack waiting in the queue already) or shall we queue uploads locally until packages are actually accepted?
<zyga> what's the difference between breezy and breezy-updates?
<HiddenWolf> zyga, breezy-updates won't be used until breezy goes stable
<zyga> HiddenWolf: ah, okay
<HiddenWolf> zyga, afaik
<zyga> hmm
<zyga> when will archive.ubuntulinux.org actually contain something in breezy?
<pitti> zyga: uploads are not yet allowed due to the toolchain transition
<zyga> pitti: transition?
<pitti> zyga: doko and jbailey still prepare gcc-4.0 and a new glibc
<zyga> pitti: I was not following lataly
<mdz> pitti: I don't know; I haven't heard from elmo
<pitti> mdz: okay, I queue them on chinstrap for now 
<fabbione> re
<fabbione> doko: ping?
<\sh> ok...coffee time
<\sh> it will be a long night
<fabbione> doko: /wind goto 3
<fabbione> ops
<zul> hehe
<zyga> does breezy have release shedule or codename yet?
<pitti> zyga: breezy badger, to be released in october 05
<zyga> pitti: thanks
<zyga> pitti: so that makes it 10.5? 
<pitti> 5.10, yes
<pitti> zyga: btw, how far is your libintl-ng? :-)
<zyga> pitti: frozen, had no time to look at it lately
<zyga> pitti: I've been doing python gui magick 
<zyga> pitti: but that is still on my mind once I'm more free to do what I like
<zyga> pitti: I still kind of suck with ngettext support
<zyga> my preliminary idea was to create list of all known n_plural strings and add generic support later
<zyga> I wanted to reuse as little code as possible because of the incredible mess (or my reluctance to read it...) libintl presents
<ross> thom: ping?
<zyga> pitti: and one more thing... I most probably will need help to get glibc compatibility right
<zyga> pitti: all those weak_alias magic
<jbailey> zyga: What are you doing? =)
<zyga> jbailey: rewriting libintl
<zyga> jbailey: I want to add configuration stuff and flexibility on catalog placement
<pitti> ... and make the code readable in the first place? :-)
<zyga> jbailey: the first thing will be to smoothly support language-packs
<zyga> pitti: that too :-)
<zyga> and proper documentation built from source
<jbailey> zyga: Are you hoping to replace the intl/ code in upstream glibc, or just have something we link against instead?
<zyga> jbailey: not sure yet, I heard that upstream is pretty hard to convince as far as such things go
<zyga> jbailey: first I want full compatibility when doing LD_PRELOAD in existing apps 
<jbailey> zyga: Right.  They're usually not fond of rip-and-replace, but also you want to take care with copyright purity.
<zyga> jbailey: then I was thinking about getting someone to review it and decide 
<jbailey> zyga: If you can't assign the copyright over the to FSF, there's no way it can be considered.
<zyga> jbailey: how do I do that?
<jbailey> zyga: First thing is to make sure that you don't refer to code other than FSF copywritten code, or code to which you have the rights.
<zyga> jbailey: that's pretty easy, what's next?
<pitti> jbailey: you mean, refer to code he has _no_ rights for?
<jbailey> zyga: You need to email assign@gnu.org and ask for an assignment form.  They will ask you all of the relevant questions, like what you've already modified, and what you plan to do.
<zyga> jbailey: this sounds like lots of paperwork ;-)
<zyga> jbailey: once it's usable I'll think about it :)
<jbailey> pitti: English language needs ()'s: Don'y refer to code other than ( FSF copywritten code, or code to which you have the rights)
<pitti> ah
<zyga> jbailey: I'd be happy if I can provide libintl-foo GPLd and compatible with ubuntu
<jbailey> zyga: After that you need your employer, school or whoever else might have a claim over your code to send in a disclaimer saying that they won't try to make a claim.
<jbailey> It's worth postponing the paperwork until later, but you need to make sure that it's possible for you to do it after.
<zyga> jbailey: no employer or school is involved in this -- I's all in my free time
<jbailey> zyga: Depending on where you live, it being in your free time may not be good enough.
<zyga> jbailey: really?
<zyga> jbailey: explain please
<jbailey> zyga: In the US in particular, many employers can claim that if you're a coder during the day that they own all the code you write even on your own time.
<zyga> jbailey: geez... that's insane 
<zyga> jbailey: I live in Poland
<jbailey> zyga: Here in Canada, it has to do with what field you might be working in.  (Like when I worked at the Mutual Fund place, I would have needed a disclaimer for gnucash or oleo, but not for hotplug)
<zyga> jbailey: I have no legal knowledge about this so I might need to ask a few friends
<jbailey> hotplug is a bad example, since it's not GNU.  bUt inetutils or mailutils.
<jbailey> zyga: If your employer is generally friendly, it's often worth it to just ask them to sign the document and be done with it.
<zyga> jbailey: my work is totally unrelated to this, that's for sure 
<zyga> jbailey: but thanks for the insight, I'll have to look more into it
<jbailey> zyga: Then you may be able to simply say that you have no need for a disclaimer.  I don't pretend to know how European law works. =)
<jbailey> I have enough trouble keeping up with my own country's.
<zyga> jbailey: europe == lot's of different countries and lots of different laws
<mvirkkil> Is this BOF about restricted formats? http://udu.wiki.ubuntu.com/UbuntuDownUnder/BOFs/UbuntuDevelopment/MultiMedia
<dilinger> jbailey: i thought that was just a contractual thing?
<dilinger> jbailey: people in the US signing contracts when they begin employment that state all code they write is owned by The Company
<jbailey> dilinger: I might be mistaken on the US law.  It also wouldn't surprise me if it varied state to state.
<jbailey> Or if it were implied in the abscence of anything else.
<dilinger> have companies actually been successful in claiming that without a contract?  that'd be evil...
<\sh> dilinger: it's the same here in germany...u write code for company, u have the copyright, but the company the right to use it...
<jbailey> dilinger: ISTR the assignment clerk saying it was a problem.
<dholbach> hellas
<ogra> dholbach, holla
<\sh> holla dholbach 
<dholbach> hey ogra, \sh :-)
<pitti> mdz: meeting now?
<lamont> Kamion: will do
<doko> jbailey: ppc biarch looks fine. currently in the testsuite. the build will finish tomorrow
<jbailey> doko: Nice.  I'm trying to find something that definatively sais if NPTL is known to break Xen and UML. 
<jbailey> It looks like Xen works, but faces a performance penalty, and there's no mention of nptl on user-mode-linux.sf.net
<jbailey> (acc to google)
<jcole> are there any 2.4 ubuntu kernels out there?
<dholbach> jcole: i386 ones in universe
<jcole> dholbach: really!
<thom> pitti:  daniels> when pitti comes back, could someone please tell him dbus sources are at p.u.c/~daniels/dbus/?
<dholbach> jcole: yeah should be
<pitti> thom: cool, thanks
<pitti> thom: can I please have the php4 build dependencies on concordia's amd64 dchroot?
<jcole> dholbach: do they have all the kernel "crack" the 2.6 kernels have?
<thom> pitti: i suppose so
<dholbach> jcole: they are debian's 2.4 kernels, we don' actually support them, just have them around for convenience
<pitti> thom: I need to test-build with gcc-4.0
<thom> pitti: doooom!
<pitti> thom: ?
<thom> pitti: presumably you'd also like gcc4?
<pitti> thom: that's already installed
<pitti> thom: I already did some builds and FTBFS fixes with gcc-4.0
<thom> oh, so it is
<thom> cool cool
<mdz> doko: you wanted to talk about the toolchain?
<pitti> indeed :)
<thom> pitti: done
<pitti> thanksalot
<doko> many people are in vacation next week (me as well), so I'd like to start the ABI transition not before the UDU week. that doesn't hinder us to upgrade the packages in this time (i.e. glibc, binutils and GCC, without changing the defaults)
<jbailey> doko: The C++ one?
<mdz> doko: I think the decision to be made is whether we delay uploads to breezy until GCC is in
<doko> jbailey: yes, we shouldn't consider architecture specific changes (if there are, fabbione and lamont should tell us for sparc and hppa)
<jbailey> doko: ISTR for Sparc anyway that we decided at Debconf4 that the abi changes there didn't amount to enough to care about.
<doko> mdz: I don't see a reason why we should. IMO it's good to check packages with a new glibc first, without transitioning the C++ ABI
<seb128> you don't want to delay the uploads for 3 weeks ?
<mdz> seb128: no, we don't
<seb128> there is like 40 GNOME tarball already to package, and that's tricky for the bug management
<seb128> *pfiou*
<mdz> doko: we would like to be sure that things still work when rebuilt with the new gcc
<doko> seb128: why?
<mdz> doko: what is the best way to do that?  track which packages are rebuilt since the upload, and to manual uploads to rebuild the others?
<seb128> doko: because accumulation new package and bug fixes for weeks is not nice
<seb128> doko: the sooner we can get the running with breezy the better imho
<fabbione> seb128 ++
<doko> mdz: we can test that with a test rebuild. just recompile everything in another chroot, with the gcc-defaults package pointing to 4.0
<seb128> doko: ie: you are flooding me with gcc4 ftbfs for GNOME stuff fixed upstream
<fabbione> doko: but do we really need to change the toolchain for breezy?
<mdz> doko: that does not tell us whether the packages _work_, only whethere they build
<fabbione> can't we get to test it in deep for breezy+1?
<mdz> s/whethere/whether/
<doko> seb128: yes, these reports are bug reports from the Debian BTS. feel free to close them, if they are fixed.
<seb128> fabbione: is there a reason to not do it now ?
<mdz> we can either do it now, or in 6 months.  I would prefer to do it now.
<seb128> fabbione: FC4 already uses gcc4 now ...
<seb128> me too
<dholbach> the MOTUs will suffer, but stand behind a toolchain change :-)
<doko> fabbione: good question. if you can assure me, that sid is unfrozen after the breezy freeze, then maybe not.
<fabbione> seb128: because i don't think we can wait 3 weeks to start breezy..
<lamont> doing it now helps us lead the charge
<mdz> gcc-4.0 for breezy is worthwhile
<ajmitch_> dholbach: we'll at least get to get plenty of malone testing in 
<mdz> we do not need to wait 3 weeks
<lamont> much like hppa wound up doing with gcc-3.0
<seb128> fabbione: me neither, but I would just push gcc4 NOW
<seb128> and start uploading
<fabbione> seb128: ok..
<dholbach> ajmitch_: ha, exactly :-)
<seb128> let's face the transition :)
<doko> let's assume that sid unfreezes before the breezy freeze, then we'll have much less time for the transition
<fabbione> seb128: it's not like i really care :) i can't compile the kenrel with gcc4 anyway
<mdz> fabbione: oh?
<ogra> doko, is that likely to happen ?
<seb128> fedora guys are fixing the whole GNOME for FC4 now
<seb128> so I don't really care neither :)
<fabbione> mdz: according to doko is still no go and zul can't get to compile all of it yet
<doko> lamont: there are people already doing rebuilds for amd64 and ppc64, so that should give us more confidence
<seb128> FC4 is shipping with gcc4 in 2 months, that should be possible to face it for breezy too
<fabbione> doko: just let me know when you are going to switch default compiler
<fabbione> seb128: FC4 doesn't have 16000 pkgs in universe.. our MOTU's might not make it at all
<jbailey> fabbione: ARe you at least okay on gcc-3.4?  Can -3.3 be safely dropped?
<doko> fabbione: I think it's your decision, which compiler to use for kernel builds
<jbailey> (after the C++ transition)
<fabbione> jbailey: nope.. i am going to stay with 3.3 if 4.0 doesn't work
<ogra> fabbione, hey...a bit more confidence please :)
<mdz> doko: can we use gcc-4.0 and g++-3.3, to delay the ABI transition while still testing gcc-4.0?
<fabbione> doko: last time we talked you asked me not to build the kernel with 4.0
<fabbione> doko: what did change since than?
<jbailey> mdz: Current glibc still requires gcc-3.{34}
<fabbione> ogra: i would be really happy if you can make it easily.. but it is really a lot of work
<jbailey> The biarch ppc testing we've been doing has been with gcc-3.4
<mdz> jbailey: current glibc, or the one you'll be uploading soon?
<doko> mdz: I think yes, but I'll have to check. but this strategy won't work for java (dependingon C++)
<jbailey> The one I'll be uploading soon.  Sorry.  Upstream's view of "current" =)
<ogra> fabbione, but were also growing and we have a dholbach ;) lets see....
<fabbione> ogra: ehehhe
<dholbach> ogra: hahaha :-)
<mdz> so the kernel, glibc and a few hundred other packages in main can't be built with gcc-4.0 ;-)
<ogra> :)
<fabbione> mdz: kinda :)
<fabbione> mdz: that's why i don't see the need of leading the transition
<fabbione> what gain do we really have?
<pitti> mdz: fortunately many main packages already have patches
<mdz> the kernel and glibc we can use gcc-3.4
<mdz> the other packages we can fix
<fabbione> mdz: 3.3 for the kernel
<doko> fabbione: nothing changed. if I did say something wrong. for woody we did have some discussion if we should provide a kgcc binary, which the kernel uses for compilations. I'm not going to propose something for the kernel, which is not proposed upstream
<mdz> fabbione: 3.4 is no good?
<mdz> we could use -3.3 and drop 3.4 then.  I don't want to have three bracnhes
<mdz> branches
<fabbione> mdz: i don't feel comfortable in changing compiler right now that i am also changing major release
<jbailey> doko: Any idea if we can do biarch ppc with 3.3?
<fabbione> mdz: i need to be able to see regressions clearly and not messed up by gcc even more
<seb128> mdz: if that's any consolation GNOME works fine with gcc4 :p
<doko> jbailey: I tried for amd64 and that one didn't work well.
<fabbione> doko: ok
<tseng> is fc4 building with gcc4, or just packaging it?
<doko> tseng: building
<fabbione> doko: but talking about gcc4.. what benefits will bring to us?
<doko> fabbione: java
<fabbione> becuase i am not at all that convinced yet
<mdz> doko: I need to know if there is a way to get gcc-4.0 in while delaying the ABI transition
<fabbione> doko: and what else?
<jbailey> fabbione: Hand written C parser is supposed to give better error information.
<doko> fabbione: upstream maintainance
<mdz> upstream++
<fabbione> i agree on the last 2 points
<doko> mdz: you mean gcc -> gcc-4.0 and g++ -> g++-3.3 ?
<mdz> doko: by any means
<fabbione> brb
<doko> mdz: what's your goal with this combination?
<mdz> doko: the idea is to make the most of 1) the time we have over the next few weeks, 2) the build testing we get 'for free' during the sid merge
<zyga> mvo: hey
<mvo> hey zyga 
<zyga> mvo: when can we start commiting changes to u-m?
<mdz> doko: since we cannot complete the transition for several weeks, we must either a) stay with 3.3 and transition later, or b) go to 4.0 but delay the transition
<mvo> zyga: I integrated the patch today, I need to have a look over the diff again and will probably commit tomorrow morning 
<mdz> doko: I am asking you if b) is possible; if not, we must go with a)
<zyga> mvo: which patch?
<mvo> zyga: the stuff at http://www.suxx.pl/update-manager
<doko> mdz: I understand. Thinking about b), please let me delay the answer until tomorrow. I currently don't see reason, why this should not work, but usually you discover the failing bits later ...
<zyga> mvo: okay, I've updated that just a moment ago, warty-updates was nowhere in aptsources.py.in
<jani> fabbione, how can I get vmlinux (not vmlinuz) for current kernel?
<zyga> mvo: I also marked some debian strings translatable (they should be IMHO)
<fabbione> jani: zcat vmlinuz > vmlinux
<jani> it says it;s not gzip format
<jani> it's x86 boot sector
<fabbione> jani: rename the file to something .gz
<ogra> bz2cat ?
<jani> nope that didn't work either
<jani> isn't that compressed with zlib but not gzip?
<mdz> doko: ok, I do not expect to be able to upload to breezy until tomorrow at the earliest anyway
<dholbach> i think, i'll be off to bed now... have a nice evening :-)
<mvo> zyga: right now I only looked at the patches directory
<jani> ie it;s no gzip in makefile that I saw
<ogra> ciao dholbach 
<crimsun> need to either strip the boot sector and magic, or compile it and use vmlinux in the root of your kernel source
<zyga> mvo: they are mostyl outdated
<dholbach> bye ogra 
<doko> btw, does somebody know about elmo?
<crimsun> ^ jani 
<zyga> mvo: you probably want to take a look at a big diff or wait untill I start sending them myself
<jani> yup I asked if we have some deb package so I don;t need to recompile
<jani> my own kernel
<jani> night dholbach
<jani> ok I'll try reversing what the build prcess does to vmlinux
<jani> another Q: what about pacthing dch so it knows about ubuntu revisions while still working fin for debian 
<jani> like : http://sourcecontrol.net/~jmonoses/dch.diff
<fabbione> doko: in the worst scenario.. how complex would it be to revert back to gcc-3.3 ?
<dholbach> jani: i wrote a similar patch for dhmake :-)
<mvo> zyga: hrm, ok. would you mind sending the diff to me tonight or tomorrow? I will have a look then
<fabbione> doko: given that some packages cannot be easily fixed for gcc4?
<jani> :)
<ajmitch_> dholbach: night ;)
<jani> 
<doko> fabbione: if they cannot be fixed for 4.0, try with 3.4 first.
<dholbach> ajmitch_: you're right, should be off now
<dholbach> bye :-)
<fabbione> doko: uh? would that generate a set of packages compiled with A and another one with B?
<doko> worst scenario: increase the epoch on gcc-defaults binaries. we keep the shlibs anyway.
<fabbione> doko: + mdz was talking about dropping at least one version of 3.x
<doko> A and B are ABI compatible
<doko> yes, 2.95 ;-)
<doko> we'll need 3.4 for g77 anyway.
<doko> even in main, if gfortran doesn't work
<Gagatan> oooh.. f77.. brings back memories
<mdke> ogra, ping
<ogra> mdke, pongedipong
<mdke> https://www.ubuntulinux.org/wiki/ChangeMe or http://www.ubuntulinux.org/wiki/UbuntuGIS, which is newer?
<doko> amu, Riddell, haggai: anybody knows how KDE build with GCC 4.0 ?
<ogra> grrr....
* ogra curses the wiki
<mdke> ogra, ;) they have slightly different content
<ogra> mdke, the one with a name :)
<mdke> ok
<mdke> cool
<lamont> doko: we have no 2.95 in the archive
<lamont> well, no binaries...
<lamont> it would need bootstrapped, and I've specifically said 'when hell freezes over' (or mdz tells me I must...)
* fabbione turns off the fire
<doko> ouch ;-) but Mithrandir wanted to put the whole GCC history back to egcs into ia32-libs ... ;-P
<Riddell> doko: should build fine
<lamont> heh
<fabbione> doko: that's because he needs to :)
<doko> Riddell: please have a look at amu's buglist, I reassigned all GCC 3.4/4.0 related bug reports to him
<Riddell> doko: kde developers say 'it compiles fine but the resulting code may be broken'
<doko> yes, that should be addressed in RC2 or the final release
<doko> Riddell: I see you modified the wiki, so you are aware of the renaming policy ...
<Riddell> renameing?
<Riddell> oh for C++ packages
<doko> yes, renaming of library packages depending on libstdc++
<Riddell> sounds fun
<Riddell> doko: is there a recommended pattern to follow for the rename?
<doko> https://www.ubuntulinux.org/wiki/BreezyToolchainTransition
#ubuntu-devel 2005-04-24
<doko> Riddell: just add a 'c2' at an appropriate place
<Riddell> libkdecorec2  how hard can it be
<doko> Riddell: I'm open for better ideas, but we used that in Debian for the last transition as well (c102)
<Riddell> doko: the package name is libqt3c102 but the library is still libqt-mt.so
<Riddell> why's that?
<doko> Riddell: look at the wiki
<doko> Why don't we just change the sonames?
<doko> Because upstream chooses the soname to match their API. If we change the soname then we render ourselves binary-incompatible with other distros and vendor-supplied binaries. This is important because the LSB3 intends to standardise the GCC 4.0 ABI; for Ubuntu/Debian to become binary-incompatible at this point would be the height of perversity.
<doko> Of course, when your upstream does bump the soname, you can drop the c2' from the package name, just like very few libs still have a g' on the end. 
<Kamion> doko: any reason not to have c1002, apart from slight ugliness?
<doko> Kamion: good point.
<doko> as a compiler option, you write -fabi-version=[12] , the macros is defined as 102/1002.
<Kamion> just worried that at some point GXX_ABI will actually be "2" and we'll be screwed; or is that not possible?
<lamont> Kamion: I prefer c1002, since it is very unlikely to be chosen by someone for  a package suffix.
<Kamion> if GXX_ABI won't ever actually be "2", then I don't have a real objection
<doko> yes, we should address this and choose something that can be choosen by Debian as well.
<Kamion> mm, that's an interesting point
<Kamion> can we pre-clear it with Debian?
<mxpxpod> if I want to compile my own kernel (from kernel.org) to test some powerpc things... what inotify version should I grab?
<Kamion> because if there's a similar c1002 vs. c2 debate, and Debian chooses the other one, we're in for really serious pain
<jbailey> Kamion: y'mean ask the release manager and gcc maintainer? ;)
<doko> Kamion: no, I think the multiplier was introduced to get rid off the confusion (ABI 2 = 1002)
<tseng> jbailey: +1 funny
<Kamion> jbailey: last time round, it was neuro who did it; I guess that was with a gcc hat on though
<Kamion> doko: which multiplier?
<doko> 10
<Kamion> ok
<Kamion> I think going for a name that's picked for exactly the same reason as c102 was picked might leave us with less chance of being bikeshedded later
<mvirkkil> I'm tossing around the idea of implementing some sort of changes summary for the update-manager. Something that would list the changelog for all the packages at once. It seems however that update-manager is quite a bit more complex than I anticipated. Could someone give me a summary of the logic by which it works?
<mvo> mvirkkil: I can do this, but I would rather like to do it tomorrow 
<mvo> because I want to go to bed soon :)
<mvirkkil> mvo: Ok. I'll ask again then :) Thanks.
<doko> Kamion: so what is the most politically correct way to address this change? On Debian-release people were asked for transitions and transition plans, so I can make at least a proposal.
<Kamion> doko: that's definitely a good place to get a proposal semi-blessed
<doko> ok, will post something tomorrow. my preference still is: len('c2') << len('c1002')
<smurfix> elmo: ping
<elmo> smurfix: ?
<smurfix> What's the procedure for removing packages from breezy (like libgcrypt7...) -- assing the relevant bug to you?
<smurfix> elmo: ^
<smurfix> assign
<elmo> smurfix: already removed from Debian, or ubuntu specific?
<fabbione> hey elmo
<ogra> smurfix, thats in universe
<elmo> hi fabbione
<ogra> smurfix, put it on our MorgueCandidates page after bereezy opened
<elmo> smurfix: in any event, if it's ubuntu-specific removal in universe coordinate with the MOTMOTU
<elmo> smurfix: if it's removed-in-debian, that'll happen semi-automagically shortly-ish after breeze opens
<smurfix> ogra: It's on doko's FTBFS list, didn't know he also imported Universe packages
<ajmitch_> smurfix: doko's large list had mainly universe packages, iirc
<smurfix> elmo: OK, thx
<pitti> Hi elmo
<elmo> hi pitti 
<doko> elmo: please could you install a hoary chroot on davis and install jbailey's glibc packages (p.u.c)
<pitti> elmo: can you please make {warty,hoary}-security uploads work again?
<jbailey> doko, elmo: Thos epackages aren't ready.
<elmo> pitti: warty broke?
<pitti> elmo: I uploaded a couple of packages, and according to mdz they are stuck in unchecked/
<pitti> elmo: they aren't in accepted or in REPORT or accepted/REPORT
<elmo> oh, eh, blah, sorry
<pitti> elmo: and I did no get a REJECT mail either
<doko> ajmitch_: the bug reports for main are already imported in bugzilla
<elmo> anyway, I'm workin gon breezy now, they'll go live again with that
<pitti> elmo: thanks
<jbailey> doko: I haven't got all the langpack stuff done, I'm cracking through that now, and then I have a couple l-k-h fixes to do.  It'll be done by tonight.
<doko> jbailey: they are ok for building GCC biarch.
<ogra> smurfix, no idea why its there, but for MOTU we have http://www.ubuntulinux.org/wiki/MorgueCandidates to propose packages that should get dropped, its just not wiped yet...
<ajmitch_> doko: alright
<doko> jbailey, elmo: maybe we need another chroot for that kind of thing
* jnc balks  "Morgue!?"
<jnc> might as well call it the DebCemetary
<jbailey> doko: True, but the resulting binaries are also nptl-only right now as well as needing a minimum glibc version bump (for symbol versioning)
<elmo> doko: I can create another chroot in a bit
<jbailey> doko: As long as the result doesn't wind up in the archive somehow...
<doko> elmo: that would be nice, so we have a platform to polish ppc64
<pitti> night everybody
<ogra> night pitti 
<jbailey> g'n Martin.
<lamont> doko/elmo/jbailey: is there interest in building all of main to see what is ftbfs with 4.0?
<elmo> lamont: let me setup breezy first?
<lamont> elmo: sure
<elmo> (but yes, I definitely think we should do that)
<elmo> i.e. with breezy-test as soon as it exists
<lamont> elmo: either hoary-test or breezy-test is fine with me for the test build... :0)
<doko> lamont: yes, that would be fine. although we should dtermine the order of rebuilds first.
<lamont> doko: order???  what order... we just turn it loose... :-)
<jbailey> Kamion: Around?
<doko> order of library rebuilds, or do you want not have the rebuilt packages available for installation?
<mdz> lamont,elmo: just as importantly as building, I think we should ensure that the packages that we actually publish to the world are all built with 4.0
<mdz> lamont,elmo: so we know that they work
<Kamion> jbailey: yes?
<jbailey> Kamion: Is zoneinfo-udeb something that should be contrib'd back to Debian eventually?
<elmo> mdz: ABI change?
<mdz> elmo: that too, but I mean just in general
<mdz> the test builds tell us whether the stuff compiles, but not whether it still works
<elmo> [meh, god I wish irssi had per-channel/window currently-typing buffers] 
<mdz> xchat has that
<Kamion> jbailey: I'm not sure. It was for the first-stage-questions crack, but I don't think we actually use it at the moment
<elmo> yah, I know, that's why I miss it
<elmo> mdz: current gcc 4.0 RC is known to e.g. miscompile python
<Kamion> jbailey: however we might want to use it in the future since some people (*ahem*mark*ahem*) want me to lose the dependence on the base system being installed for questions like timezone
<elmo> so while I agree that's critically important, until we have 4.0 final and are prepared to start the C++ transition, it seems like a good head start to get started on the FTBFSes
<doko> elmo: fixed in my package
<elmo> doko: keeno
<mdz> elmo: oh, I agree, I don't think we should delay anything for that
<Kamion> wouldn't a python miscompile be caught by build-time tests?
<mdz> we just need to have some plan for getting everything rebuilt
<mdz> Kamion: we hope
<Kamion> (dreaming)
<elmo> Kamion: yeah, now just try to not think about the 99% of the archive which doesn't have a test-suite never mind a remotely comprehensive one
<jbailey> Kamion: I can see that, cool.
<Kamion> jbailey: so I reckoned you were going to ask me about that, but I honestly don't know whether it's just bad crack yet
<Kamion> given I made it up on the spot under a certain amount of goal-related pressure
<jbailey> Kamion: No worries, just trying to pick obvious places where merging could be made less hairy.
<Kamion> jbailey: if you want to kill it, go ahead; I've kept the patch here in case I need it again in future
<jbailey> Kamion: I'll keep that in mind for the next time I have to do this.
<lifeless> elmo: ping
<elmo> lifeless: hi
<lifeless> I'm here to nag
<Kamion> jbailey: (it's the interdiff from 2.3.2.ds1-19ubuntu3 to 2.3.2.ds1-19ubuntu4 if you want to reverse it)
<doko> lifeless: we know you ;)
<lifeless> doko: I'm touched ;)
<elmo> lifeless: did you mail me about this at all?
<elmo> lifeless: 'cos unfortunately, steve talked to me while I was hugely asleep and I have no idea what he said
<lifeless> elmo: I talked with you last week on IRC
<elmo> [beyond "authserver. kick."] 
<elmo> you did?  score my memory
<lifeless> steve was just a opportunistic nag
<Kamion> jbailey: mm, apart from adding libnss-dns-udeb and libnss-files-udeb to control_deps in debian/rules.d/control.mk; if that hasn't gone back to Debian yet, it should
<lifeless> ok, gimme a minute I'll dig up details and mail you. then I'll nag again.
<elmo> lifeless: don't worry, got it
<lifeless> elmo: cool
<lifeless> elmo: so I realised I was being dumb - i tonly needs to be the chinstrap chroot
<lifeless> it won't hurt the others though - so whatever is easiest for you
<zyga> PINE
<zyga> pine
<zyga> hmm ;] 
<zyga> definitly wrong screen
* lamont wanders off to convert another user
<ogra> yeah
<zyga> lamont: wander of to convert another mirror ;] 
<elmo> doko/jbailey: what arch name are you guys using?
<jbailey> elmo: The package name right now is libc6-dev-ppc64 and libc6-ppc64, but using "powerpc" as their arch.
<jbailey> elmo: Same type of config as sparc/sparc64
<elmo> ok
<Riddell> that'll be breezy open then
<thom> indeed
<ogra> YAY
<Riddell> adjust your .procmailrc accordingly :)
<dredg> Riddell: but /dev/null hasn't changed....
<kent> Riddell, breezy is open now?
<ajmitch_> ogra: dholbach will be so happy :)
<ogra> yeah
<Riddell> kent: according to breezy-changes it has
<|QuaD-_> Riddell: breezy changes is empty, isn't it?
<|QuaD-_> no messages yet
<ogra> |QuaD-_, 2
<|QuaD-_> ah, let me check again :)
<|QuaD-_> just checked :) that means we should start seeing universe open up again
<\sh> breezy is open?
<dredg> no, i just did a clean install on my desktop  :(
<blueyed> Is it a known bug that the password for a new user added through the "Users administration tool" is wrong? There is a different value in the shadow file from using passwd or KUser..
<blueyed> could not find anything in bugzilla..
<lamont_r> blueyed: different in that the password doesn't work when the user types it, or different in that it doesn't match exactly?
<blueyed> it does not work.. haven't tried if it's lowercase though.. mom..
<lamont_r> because I would expect it to not match exactly, 4095 out of 4096 times or so
<blueyed> k, but it also does not work.
<\sh> shlibs-control file==libfoo.la?
<blueyed> lamont_r, it's neither lowercase nor uppercase (would be strange enough).
<blueyed> not reproducable?
<blueyed> passwd works fine.
<lamont_r> blueyed: dunno - not really somewhere that I can conveniently check that
<lifeless> whats the best tool for maintaining a small apt repo on chinstrap?
<lamont_r> lifeless: apt-ftparchive packages . > Packages
<lifeless> lamont_r: so if I accrue my builds in a dir, then run that
<lamont_r> lifeless: and (of course) apt-ftparchive sources . > Sources
<lamont_r> apt-ftparchive searches the given directory (.) for all debs (packages) or dsc (sources), and builds the relevant file
<lamont_r> so yeah, put them all in a flat tree, and go for it.
<lamont_r> and yes, that can be multi-arch
<lifeless> at the moment I use dpkg-scanpackages
<lamont_r> apt-ftparchive obsoletes that
<lifeless> to get Packages and Sources. whats the advantage ? ok
<lifeless> what about a Release file ?
<lifeless> so I can sign it and make mdz happy ;)
<lamont_r> the other advantage is that apt-ftparchive is installed, and dpkg-scanpackages probably isn't
<lifeless> *I use dpkg-scanpackages right now* :)
<lamont_r> vi Release; gpg --detach-sign Release; mv Release.sig Release.gpg
<lifeless> an empty file ?
<lamont_r> lifeless: ah, ok
<lamont_r> you can give apt-ftparchive a nice config file (although I haven't figured it out yet... see mvo, mdz, kamion, or keybuk?)
<lifeless> apt-ftparchive release might do it
<lamont_r> see the one in dists/hoary on your favorite mirror, clone from that...
<lamont_r> yeah.
<lamont_r> but that doesn't set the invariant fields, just builds the md5sums/sha1sums for you
<lamont_r> the config file lets you specify those
<Keybuk> or just grep people's home directories on rookery for their scripts that perform archive voodoo :p
<lamont_r> Keybuk: any favorites?
<Keybuk> I use apt-ftparchive
* lamont_r figured invoking a string of names would be productive
* lamont_r will snarf Keybuk's config later then
<Keybuk> the docs are good
<lamont_r> Keybuk: to a point... :-)
<lamont_r> then again, I've tended to want to do strange things with it.
<Keybuk> oh, I just do "a directory with some packages in it" things
<Robot101> lamont_r: I have voodoo scripts at people.debian.org/~robot101/make-archive
<Robot101> slight inefficiency (multiply scans arch: all packages) but generally works...
<Robot101> although probably doesn't solve whatever problem you're encountering, so I'll go away now :P
<Keybuk> assuming it's still intact in the smoking embers of gluck
<lifeless> main problem is that the bazaar crack repo isn't signed
<lifeless> and I'm told it should be
<Keybuk> oh, I don't understand that stuff either
<Robot101> it is intact :)
<lamont_r> lifeless: once you have a Releases file, you just --detach-sign it and rename the .sig to .gpg
* lamont_r heads off to dinner and fire dept training.  back in a few hours.
<bob2> who should I ping about getting zsh from sid into breezy?
<bob2> it has working baz completion
<zul> open up a bug maybe
<daniels> it'll get synced eventually, I'm sure
<Clint> it's forked!
* bob2 forks Clint in the face
<mdz> bob2: when breezy opens, we'll be merging the latest stuff from sid as a matter of course; no ping necessary
<bob2> ah, excellent, thanks
<jcole> mdz: fc3 kernel + ubuntu livecd is too hard
<jcole> mdz: harder than michael jackson at disneyland
<\sh> guys, for a shared library package e.g. libfoo_major.minor  and libfoo-dev_major.minor what is the contents of shlibs.local?
<daniels> mjg59: http://www.linuxsymposium.org/2005/view_abstract.php?content_key=95
<daniels> mjg59: given by len brown
* mdz boggles at #9122
<daniels> mdz: yeah ...
<dredg> mdz: and while you're at it, i find that i sometimes make typos cos the # key is right next to enter...
<daniels> dredg: in that case, the problem is solved by getting a us-layout keyborad
<daniels> also, keyboard
<thom> oh, and can we force everyone to use a proper UK keyboard
<daniels> thom: oxymoron city
<thom> so i don't have to contend with vertically challenged return keys
<daniels> thom: will they be listening to good alternative Avril Lavigne while they're at it? ;)
<dredg> daniels: yeah but then the symbols don't match up and i cry :(
<daniels> thom: you can borrow sideshow's x40 if you like
<mdz> I find the ` key confusing because I don't know what it does.  Please disable it in all keyboard layouts
<daniels> dredg: hm?  every key I press on my keyboard matches up with what's printed on the caps
<thom> daniels: ozone now wants a uk keyboard for the  key :-)
<daniels> thom: oh dear.
<dredg> daniels: if i were to use a US layout
<daniels> dredg: oh sure.  you just need to replace your keycaps also. :)
<daniels> well, the entire physical keyboard, since we don't need this weirdo extra key.
<dredg> daniels: send your keyboard here. it obviously does what i want
<daniels> my keyboard is attached to my laptop, and so am I.
<dredg> this could get messy
* maswan hands dredg a proper knife
<dredg> maswan: proper? :)
<maswan> dredg: sharp, not too small? :)
* dredg laughs
<maswan> not a dull tiny knife for making decorative things to fruit. ;)
<elmo> ARGH
* maswan ducks and covers
<elmo> E: Failed getting release file http://ftp.debian.org/debian/dists/hoary/Release
<elmo> that's so lame
* daniels giggles.
<maswan> elmo: ... fix it? :P
<dredg> haha
<maswan> heh. that would be one way of solving mirroring infrastructure. dump it into ftp-master.debian.org in the appropriate directories. :)
<maswan> I suspect some people might have issues with that though.
<mdz> us.archive has breezy already, they certainly are quick
<elmo> mdz: they're triggered
<mdz> oh
<dredg> maswan: meh, they're too busy figuring out what the insert key is used for
<elmo> maswan: "we don't have space for your lame ass architectures, but 50Gb of Ubuntu??? bring it on!!"
<maswan> elmo: indeed. might even lead to a heated discussion on debian-devel@lists
<mdz> elmo: once you're happy with the breezy stuff, let me know before you head off and I'll announce it to -devel (unless you want to do it)
<elmo> mdz: I'm happy with it
<mdz> ok
* infinity breathes a sign of relief at remaining a legal immigrant for a while longer.
<daniels> infinity: huzzah.
<daniels> infinity: how long have you got?
<infinity> daniels : We just put in an application for permanent residence, and I'm currently on a bridging visa while that's being sorted.
<infinity> The Australian government how has 1845 of my dollars, so they better say "yes".
<infinity> Well, to be fair, they have 1845 of American Express's dollars, but AmEx is likely to ask for it back soon.
<thom> infinity: heh
<daniels> infinity: ouch.
* infinity looks at the size of his INBOX and winces.
<mdz> infinity: is that AUD, CAD OR USD?
<daniels> mdz: aud
<infinity> AUD, but I paid with a CAD credit card, so a bit more after exchange rape.
* infinity makes a mental note to apply for an AUD credit card soon.
<daniels> can't you juts kick amex really hard?
<daniels> although you really want a mastercard or visa, since people actually accept those
<infinity> Yeah, I generally use a MasterCard, I used the AmEx cause it has a higher limit, lower interest rates, and the government accepts it.
<infinity> I can also do a chargeback if they deny my app. ;)
<daniels> haha
<infinity> (Wonder how well that would go?)
<daniels> the words 'federal pound me in the arse prison' come to mind at this juncture
<zul> infinity: they would probably let you come back and then kick you out again
<daniels> (II) NV(0): Unable to detect which CRTCNumber...
<daniels> (==) NV(0): ...Defaulting to CRTCNumber 1
<daniels> (II) NV(0): Using DFP on CRTC 1
<daniels> (--) NV(0): Panel size is 1 x 1
<zul> or what daniels said
<daniels> thank you, nvidia!
<thom> good size!
<infinity> That's almost as big as my craptop's screen.
* ogra suggests Xmag
<daniels> 'i couldn't work out how the hell the screen was wired, so i set up something that couldn't possibly work anywhere.  cheers!'
<mdz> debootstrap has a default mirror?  I didn't realize
<mdz> I thought the third argument was mandatory
<daniels> mdz: suite and location are the only mandatory arguments
<mdz> daniels: I see that now
<infinity> If they were reordered, even suite could default to something reasonable.
<infinity> A bit late for that now, though.
<daniels> oh, nvidia.
<daniels>               pNv->FlatPanel ? (pNv->Television ? "TV" : "DFP") : "CRT",
<daniels> Kamion: ping
<thom> time to rename firefox
<daniels> thom: ?!?
<daniels> oh, to debian-firefox or whatever, thanks to the trademark stuff?
<thom> just firefox
<ogra> thoms-firefox ?
<thom> ogra: heh. more likely to be firefox-really-blows-use-epiphany-instead ;-)
<ogra> heh
<daniels> Riddell: do you guys care about kvim?  it's been totally dropped from vim upstream because it's unmaintained
<daniels> (i'm uploading a new vim that takes 'breezy' as a distribution keyword)
<thom> haha; i'm just building that here
<daniels> thom: i'll fight you!
<daniels> thom: more seriously -- are you basing it off the hoary sources, or the sid sources?
<thom> naw, i'm just doing it locally with hoary
<thom> if you have sid done go for it
<daniels> yeah, the only question is what to do with kvim
<infinity> kvim was dropped upstream for good reasons.
<Riddell> daniels: I'm unsure what to do, I think it would be nice to have something but kvim is unmaintained and yzis is reported not to be ready for use
<daniels> infinity: yeah, but just throwing it out seems a bit harsh to the kubuntu folk, since they explicitly reverted debian's last throwing-out of kvim
<daniels> Riddell: would you be terribly offended if I uploaded vim without kvim?
<Riddell> daniels: but I think that since upstrea don't maintain it and debian don't have it any more it's unrealistic to expect us to have it
<daniels> cool
<Riddell> daniels: of course not, I'm an emacs user :)
<daniels> haha
<zul> ooh...evil
<jdub> hey hey hey crazy kids!
<jdub> aaaaaand GOOOOOD MORNING FREEDOM LOVERS!
<zul> hey jdub 
<daniels> whattup jdizzle
<jdub> my blood pressure!
<daniels> jdub: try a chill pill
<ogra> MORNIN JDUB !
<jdub> i drank a lava lamp
<jdub> it wasn't lava
<dredg> did it taste like happy?
<jsgotangco> good morning
<schweeb> mako: like the blog post, haha
<thom> Riddell: uh, dude. x86 ubuntu cds are on a *seperate* mirror on se.archive
<daniels> hum.  so gcc4 has a new c++ abi?
<maswan> thom: they used to be, we actually removed the redirect yesterday since we seem only to have 30-50MB/s peak demand. :)
<thom> maswan: right, but the stats are still broken
<maswan> thom: right. I now remember that I didn't make apache log in xferstats format, so I'll have to write a perl script to integrate it
<maswan> well, and rewrite some paths and stuff too anyway, probably. as well as resolving IPs, but we already have scripts for that.
<maswan> so anyway, there is  ~4.7TB of x86 ubuntu isos that are missing from those stats, I'll just make a note of that in irc for now. :)
<Lathiat> heh
<dholbach> morning
* maswan reads
<maswan> hmm.. now I have a purpose for fixing the stats soon, to prove Riddell's blog false. ;)
<calc> maswan: what url?
<calc> ah i see it
<ogra> mako ? what about CC meeting ? 
<dholbach> somebody call mako, since sabdfl, elmo and kamion don't seem awake as well :-)
<dredg> dholbach: yeah, maybe having 3/4 in GMT timezones isn't such a hot idea... :)
<dredg> er, BST currently
<Lathiat> maswan: url?
<maswan> planet
<diamond> dholbach: his phone number is available here: http://mako.yukidoke.org/contact.html
<dholbach> somebody could send him an SMS
<jsgotangco> err whats up?
<diamond> jsgotangco: ubuntu community council meeting, due to start about 15 minutes ago ,-)
<dredg> i'll send an sms if nobody else has. don't want to plague him
<diamond> dredg: *nod*
<dholbach> bob2: could you join #ubuntu-meeting if you're here?
<jsgotangco> oooo
<dredg> sent
<aj> are those meetings public?
<dholbach> aj: yes
<daniels> aj: yeah, #ubuntu-meeting.  open to the public.
* aj watches
<dredg> dholbach: no reply.
<crimsun> of course it's probably best if the CC shows up
<dholbach> not a lot to watch atm... with no chair
<dredg> crimsun: i thought we were an autonomous collective?
<infinity> "debian/rules dopatch"... Yeah, that's an intuitive target.
<aj> who's chair? sabdfl?
<dholbach> aj: elmo, kamion, sabdfl or mako could...
<crimsun> aj: mako
<aj> hrm, they're all in pretty similar timezones, where it's all late too
<dredg> aj: i prefer to consider it as early ;)
<ogra> very early....
* ogra mumbles inhuman early 
<fabbione> elmo: ping?
<dholbach> fabbione: seems to have went to bed 2h30m ago :-/
<fabbione> i was hoping he didn't
<jdub> BREEZY-CHANGES MAIL!
<diamond> jdub: -)
<schweeb> someone make the CC meeting happen!
<lamont> jdub: I guess that means I need to understand what the breezy chroot toolchain looks like, so we can start having binaries....
<thom> lamont: i don't think we have such a beast yet :-)
<jdub> lamont: binaries are good ;)
<lamont> thom: that was a longwinded way of me saying that none of the buildd's are currently configured to build anything for breezy....
<fabbione> lamont: so we are go for source uploads, but nobody is building, right?
<Amaranth> are you going to wait on gcc4 for that?
<lamont> fabbione: no clue on the source side, but there are no binaries
<fabbione> lamont: ok
<lamont> Amaranth: I'm waiting for a decision on the gcc4 process to build the chroots
<fabbione> but right now breezy is made of hoary binaries?
<lamont> and sparc would be well advised to do likewise, fabbione 
<lamont> fabbione: yes
<fabbione> ok
<lamont> I guess... :-)
<fabbione> than i think i can flush my queue to breezy safely
<lamont> if it has binaries, they come from hoary
<fabbione> yes there are binaries
<fabbione> and thanks god i kept all i built even before hoary was closed
<fabbione> i thought i didn't
* fabbione hacks the changes files
<fabbione> ls -asl /mirrors/ubuntu/dists/breezy/main/binary-i386/Packages.gz 
<fabbione> 628 -rw-r--r--  1 root root 635865 Apr 13 01:33 /mirrors/ubuntu/dists/breezy/main/binary-i386/Packages.gz
<fabbione> so i guess there are binaries
<jdub> From: Matt Zimmerman <mdz@ubuntu.com>
<jdub> Subject: Breezy suite now open for business
<fabbione> in both cases i can only build old packages
<jdub> Those of you who like to stay on the bleeding edge, update your sources.list
<jdub> and hang on tight.  The next few weeks will be a rough ride. ;-)
<jdub> 
<jdub> lamont: ^ ha ha ;)
<fabbione> jdub: without buildd's is interesting :)
<OddAbe19> wait
<OddAbe19> so are the servers up yet?
<jdub> fabbione: we have magic package making fairies for this release!
<OddAbe19> or are they going up today?
<lamont> OddAbe19: which servers?
<OddAbe19> breeezy
<lamont> OddAbe19: breezy exists in the archive, and source can be uploaded
<OddAbe19> check check, i just didn't recall seeing anything in the mailing list
<lamont> and once a decision is reached (in about 12 hours, by my estimate...) on the gcc4 transition process, etc, then we'll have binaries building
<lamont> mail was sent today from mdz - see above
<OddAbe19> ok, i have to glance around
<OddAbe19> thanks alot
<fabbione> i can't do much anyway
<fabbione> sparc.u.c is not updated
<fabbione> i need to get elmo to move it or fix it
<lamont> fabbione: and going away, if I hear things correctly... (will become another name, with i386, hppa, and sparc binaries...)
<fabbione> lamont: yeah ports.u.c afaik
<lamont> yeah
<fabbione> you mean ia64?
<lamont>  /ubuntu-ports, I think it was
<lamont> er, yeah.
<lamont> ia64, hppa, sparc
* lamont hangs his head in shame at that typo
<fabbione> well that is going to be interesting, since there are people already mirroring sparc.u.c
<fabbione> that is not me
* lamont ran out of livecd's tonight... have to burn another stack
<lamont> trivial to write a redirect for it...
<fabbione> goody
<fabbione> katie did like my upload to breezy
<fabbione> time to mangle the changes and reupload the queue
<jdub> lamont: so hoary-updates stuff isn't building yet either?
<lamont> hrm...
<jdub> a bunch of stuff hit h-c, but my mirror update isn't interesting
<lamont> jdub: will be shortly
<lamont> (it didn't used to exist yet...)
<jdub> heh
<jdub> thanks :-)
<dredg> opinion: which is worse - 3 hrs sleep or no hrs sleep?
<tritium> dredg, 3 hrs, because it's just a tease
<dredg> tritium: yeah, that's what i'm thinking too :)
<tritium> :)
<schweeb> 3 hrs might be good still... anything less than that is a tease for sure
<diamond> dredg: no sleep. i find that even 20 minutes helps, tho you mightn't feel great for half an hour afterwards
<dredg> diamond: i see. sounds nasty
<Lathiat> the real problem is being woken up in the middle of a rem cycle
<Lathiat> 5 minutes can mean the difference between feeling like crap and feeling good when you wake up
<dredg> this is getting too complicated :)
<Amaranth> heh
<Amaranth> 3 hours is too much
<Amaranth> get 45 minutes
<Lathiat> 3 hours is good
<dredg> Amaranth: i typically survive on 2-5hrs/night
<Lathiat> i can live on 3-4 hours
<Amaranth> cat naps, you don't enter rem, you feel refreshed for the next couple hours
<Lathiat> i used to sleep like 3-4 hours for 3 months
<Lathiat> fucked myself after that hah
<Lathiat> couldn't lseep less than 8-10 hours fo rlike 2 years
<Lathiat> ive only just gotten back into being able to sleep a few hours and live through the day
<Amaranth> When I was in school I slept 2-4 hours a night.
<Lathiat> Amaranth: heh thats when i did this
<jdub> maswan: ping
<Lathiat> year 1 i'd stay up till ike 4am
<Lathiat> get up at 7 and goto school
<maswan> jdub: pong
<Amaranth> Now I sleep 8 hours, no matter what (slaps and tornados not included).
<jdub> maswan: hey hey!
<maswan> I'm almost done with converting the stats and putting them in for the next xferstats run btw. :)
<maswan> jdub: greetings, Gdubly One
<Lathiat> maswan: haha gogo :)
<jdub> maswan: thom said there was something funny with the .se ftp stats-- oh
<maswan> ehm. Jdubly
<jdub> maswan: hmm, so what's the deal?
<Amaranth> Gdubly sounds better, more gnomeish :)
<dredg> yeah, once i get to sleep i'll sleep up to 12hrs. getting to sleep is the problem
<Amaranth> We can create a weak clone called Kdubly. :)
<maswan> jdub: I offloaded the x86 install/live cds to a temporary server.
<Amaranth> or vice-versa
<jdub> maswan: aha!
<jdub> maswan: that'd bugger the stats a bit ;)
<maswan> jdub: so there is 4.7TB of those downloads that are missing from the main stats. :)
<Amaranth> that'd explain why kubuntu appears to beat ubuntu
<jdub> maswan: ha ha
<Lathiat> yep :)
<Lathiat> \
<jdub> maswan: livecds too?
<maswan> jdub: yeah
<Lathiat> maswan: i thought you only did the livecd the second time?
<maswan> Lathiat: well, there is a far bit of livecds among those downlaods
<Lathiat> maswan: rightio
<maswan> maswan@miffo-m:~$ grep -c live access.log 
<maswan> 25940
<maswan> maswan@miffo-m:~$ grep -c install access.log 
<maswan> 61754
<jdub> maswan: heh
<lamont> jdub: at least one buildd of each of i386,amd64,ppc is now running hoary-updates
* infinity applies a patch to mozilla's 'libpr0n' and decides that, in itself, is enough reason to hack on mozilla..
<jdub> lamont: thanks!
<maswan> Ok, that should run a while, now I need to rush off to work.
<jdub> lamont: hoary-security?
<lamont> jdub: that was already there
<Amaranth> infinity: There are talks about changing the name, but they've been going on for years.
<infinity> Amaranth : Changing the name would be just plain wrong.  Software development without the occasional bit of levity is terribly boring.
<jdub> lamont: tops
<lamont> jdub: generally speaking, it's best for me to wait for the archive to exist for the release before I turn the buildd's loose on it (since it bitches every 5 minutes if I don't wait.  xN buildd's)
<lamont> and actually, I should go kill the hoary chroots now
<pitti> morning
<thom> pitti: morning!
<dholbach> hey pitti
<fabbione> morning pitti
<fabbione> hey thom
<pitti> Hi thom, fabbione, dholbach 
* pitti whines about having to do an OO.o hog security update half a week after release
<lamont> pitti: if the alternative was doing it the day before release, I'd pick 3 days after... :-)
<pitti> lamont: why, day before CD building had saved lots of people lots of downloads...
<pitti> lamont: it's an obvious two-line patch for 100-killme MB of software...
<lamont> yeah, but it causes much more stress in that final few hours
<smurfix> shit. some idiot named Darryl Clarke deleted the LocoTeams page on the wiki.
<smurfix> Is anybody able to restore it?
<robitaille> smurfix,  and the canadian page as well
<Amaranth> i didn't know you could delete pages
<smurfix> sure you can :-/
<smurfix> robitaille: I don't monitor that ...
<smurfix> He managed to first rename it to DarrylClarke. Stupid.
<pitti> smurfix: maybe get the old version from the history?
<smurfix> pitti: It's *deleted*, I can't get at it any more.
<smurfix> pitti: otherwise that would be easy
<pitti> D'oh; they aren't kept somewhere?
<pitti> http://216.239.59.104/search?q=cache:4ERL0ReqpiwJ:www.ubuntulinux.org/wiki/LoCoTeams+ubuntu+LocoTeams&hl=de&client=firefox
<Amaranth> he deleted it and added a DarryleClark page in it's place?
<pitti> smurfix: ^ that's the google cache, at least the text is intact
<smurfix> Amaranth: you can rename pages
<smurfix> Amaranth: That also updates all the pages referred to
<jsgotangco> we hatses are wiki page even more noww....
<Amaranth> rename it back? :)
<smurfix> Amaranth: It Was Deleted.
<smurfix> Amaranth: ... suppose I could create a new empty one in its place
<jsgotangco> yeah
<Amaranth> I wouldn't
<jsgotangco> he even made links to other pages referencing it
<jsgotangco> doh
<smurfix> ... though it'd be uch easier if an admin could rollback its history
<smurfix> much
<Amaranth> You might wipe the history.
<jsgotangco> has anyone tried recycle_bin?
* Amaranth checks
<Amaranth> seems to have the frontpage?
<smurfix> that's an old frontpage there
<smurfix> ah, I get it
<Amaranth> ohhh!
<Amaranth> not in the recycle bin
<smurfix> nah, subpages of r_bin don't work the way the should
<smurfix> oh well
<Amaranth> got it :)
<jsgotangco> doh
<Amaranth> https://www.ubuntulinux.org/wiki/LoCoTeams
<Amaranth> What else got wiped?
<dholbach> darryl clarke seems to be a BAD bot
<smurfix> I'm trying to get it back now
<dholbach> exchanged nearly everything with DarrylClarke
<jsgotangco> he changed every rerefence to LoCo Teams
<robitaille> Amaranth,  http://www.ubuntulinux.org/wiki/CanadianTeam is one that seems gone
<smurfix> jsgotangco: You can do that easiy just pressing Rename
<dholbach> smurfix: you get the wiki-mails?
<smurfix> dholbach: No, he seems to have made an honest mistake
<smurfix> dholbach: still stupid though :-/
<dholbach> smurfix: shall i forward you a bunch of wiki-changes-mails?
<Amaranth> robitaille: back
<Amaranth> I leave it up to you guys to fix anything else he did to the pages. :)
<smurfix> dholbach: I have the loco* ones
<Amaranth> I think when you rename a page it renames all the references to it too.
<jsgotangco> goodness
<smurfix> Amaranth: exactly
<robitaille> Amaranth,  thanks
<dholbach> smurfix: he also changed your page :-)
<Amaranth> so, not a bot
<smurfix> dholbach: If you have the one where he deleted the locoteams page content, I'd appreciate it
<Amaranth> smurfix: locoteams is back?
<doko> pitti: do you want to add the xhosa translation in the OOo build?
<smurfix> Amaranth: not exactly :-/
<Amaranth> oh, he screwed with it?
<pitti> doko: not in a security update
<pitti> doko: this belongs into -update
<pitti> doko: well, does it require substantial changes in the main OO.o package?
<dholbach> smurfix: doesnt look good :-/
<smurfix> dholbach: getting there
<dholbach> smurfix: ha... got 124 wiki-changes mails from you
<jsgotangco> wow
<jsgotangco> and counting...
<Amaranth> that's just from undoing all darryls changes?
<smurfix> dholbach: you're going to get a few more I'm afraid
<jsgotangco> im afraid so
<smurfix> Amaranth: Well, the thing sends change mails for each page it touches when renaming
<Amaranth> dholbach: wiki-changes would have saved AptGet, wouldn't it?
<Amaranth> smurfix: ah
<smurfix> so anything referring to LocoTeamList is shouting at us now
<dholbach> Amaranth: yeah... but i didnt keep them, once i read the changes, i delete them
<Amaranth> ouchie
<smurfix> especially since I've managed to mistype the page name when getting it back :-/
<Amaranth> This is why I have a gmail account for reading mls. :)
<dholbach> Amaranth: i'm not sure 1GB is enough for this volatile stuff
<jsgotangco> 2GB
<jsgotangco> eheh
<Amaranth> dholbach: Up to 2080MB and counting
<jsgotangco> but it fills up pretty fast if you are subscribed to a lot of the lists
<Amaranth> 2087MB now
<dholbach> my imap-server is fine with that much too :-)
<Amaranth> sure, but your imap-server deletes things for real :)
<Amaranth> o_O 40 ubuntu-devel mails?
<jsgotangco> hmm lots of renaming going...and going..
<smurfix> damn, too many changes, the wiki threw away the history :-(
<smurfix> and since I'm not subscribed to anything named DarrylClarke I didn't get the one where he deleted the list
<jsgotangco> we should really have better access control on the wiki :-(
<smurfix> dholbach: you don't have it do you?
<smurfix> jsgotangco: we really should have *a*better*Wiki*.
<jsgotangco> yessss....we hateses it a lot...
<smurfix> Moin can do real access controls, editable in the page. Me like.
<Amaranth> MediaWiki sound good?
<Burgundavia> mediawiki is php
<jsgotangco> our wiki has so many good stuff but needs a lot of logical information flow
* smurfix hateses PHP
<Amaranth> Who cares about the language if it gets the job done?
<jsgotangco> well
* lamont looks at the clock, decides that maybe it really is bed time
<jsgotangco> php/java taboo in our servers
<smurfix> Amaranth: I am actually amazed that people write stuff that's this good in that crappy a language
<Treenaks> smurfix: dholbach is subscribed to EVERYTHING
<mdke> jsgotangco, what's up with the wiki now?
<smurfix> Treenaks: If he deleted that change mail, it's hot helpful
<mdke> something's been deleted?
<jsgotangco> mdke, Daryl Clarke
<mdke> i'm subscribed, can i help?
<Treenaks> smurfix: true, true
<smurfix> mdke: He renamed the team list page to his own insted of adding his, then he deleted the content
<smurfix> *very* helpful
<mdke> right
<mdke> darryl clarke, 61 edits
<jsgotangco> thats probably a bot
<smurfix> Anyway the whole wiki has 19 subscribers. *One* of them, please, send me the edit to restore the page
<mdke> no its just links updating
<mdke> i'll try
<smurfix> Otherwise I know what to spend the morning on. :-(
<Amaranth> whoa, rms cc'ed ubuntu-devel for an email :)
<smurfix> Amaranth: not the first time, IIRC
<mdke> smurfix, i don't have time to fix it, i have a class: but the subscriptions go to a gmail account, i'll give you the password?
<dholbach> smurfix: unfortunately dont have it anymore :-(
<mdke> i've had a cursory look but can't find it
<smurfix> mdke: gimme
<Zomb> just fyi: http://www.ubuntulinux.org/community shows an almost empty page
<mdke> smurfix, actually you might not need
<mdke> smurfix, check pm
<smurfix> page restored *whew*
<zerokarmaleft> are there any ubuntu devs working with the two debian devs to package mono 1.1.6?
<daniels> zerokarmaleft: i think tseng is working on mono stuff with the debian guys
<zerokarmaleft> k...i'd like to help out if i could getting mono figured out for breezy
<thom> zerokarmaleft: tseng has packages more or less done AIUI
<elbi> when will the breezy branch be usable?
<lamont> elbi: it's accepting uploads now, although no binaries are being built yet
<lamont> doko: awake yet?
<Lathiat> i keep getting these random spikees of like 100M traffic on my wireless interface graphs and i can't figure out wtf they are
<Lathiat> wrong channel
<zerokarmaleft> thom, just the core framework + gtk#, gecko# etc. i assume?  or third-party applications as well
<elbi> lamont: okay, any idea when this process will begin?
<Lathiat> zerokarmaleft: i assume it will all be rebuilt
<maswan> Ok, running a new xferstats
<lamont> elbi: waiting for a decision (due within a few? hours) of what the build tree should look like.. That will be finalized tomorrow US time
<lamont> once that's there, we'll have a plan for what happens how
<doko> lamont: sure :)
<lamont> doko: just figured I'd remind you about toolchain decisions, etc, etc... :-)
<zerokarmaleft> Lathiat, right, i'm just wondering where i could throw some effort
<pitti> amu: ping
<Lathiat> zerokarmaleft: ask tseng?
<pitti> thom: can I please have the openoffice.org build deps in hoary-i386?
<doko> lamont: what was that about the "etc, etc"?
<elbi> lamont: okay. sounds reasonable
<elbi> lamont: last question; are these things discussed in a closed community?
<lamont> doko: probably the question of toolchain ordering for the bootstrap type stuff
<lamont> elbi: all of the discussion I've seen has been in this channel
<elbi> lamont: oh, could be true, but some things isn't happening either here or the public mailinglists, is this in some way correct?
<doko> lamont: ppc64?
<lamont> doko: I have two semil-immediate concerns: (1) what toolchain do I put in chroot-breezy?  (2) what toolchain do I put in chroot-breezy-test
<thom> pitti: done
<lamont> and then what (if any) manually ordered builds must I do to make it really ready to just open the gates and let it go
<pitti> thom: thanks :-)
<doko> lamont: in both chroots the packages I'm currently preparing. in breezy-test, a new gcc-defaults as well
<lamont> doko: for breezy test, I'm happy with manually forcing the symlinks... we don't need to upload a new gcc-defaults pacakge.
<lamont> (since breezy-test doesn't actually exist in the real archive, and therefore can't take source uploads...)
<lifeless> ** (process:26931): CRITICAL **: egg_desktop_entries_add_group: assertion `egg_desktop_entries_lookup_group (entries, group_name) == NULL' failed
<lifeless> during Setting up xpdf-common (3.00-11ubuntu3) ...
<maswan> updated se.releses stats for the last week: http://www.acc.umu.se/technical/statistics/ftp/index.html.en
<maswan> 20 TB of ubuntu-5.04-install-i386.iso love :)
<dholbach> WOW
<Lathiat> nice
<opi> smurfix, ping
<smurfix> opi: 
* lamont sleeps
<thom> 4TB of the same on bittorrent
* Pizbit wonders if that includes the mirrors.
<Treenaks> thom: total, or only the seeds/peers you can see?
<thom> Pizbit: maswan is giving stats for _a_ mirror
<thom> Treenaks: this is the stats from the tracker
<Treenaks> thom: (I'm not familiar with trackers, do they give stats?)
<thom> Treenaks: torrent.u.c:6969
<Treenaks> ah ok :)
<daniels> such a classy port number
<Lathiat> quite
* Pizbit wonders if that includes the mirrors.
<Pizbit> oops, wrong window heh
* Pizbit had his glasses of and cleaning them while hitting uparrow+enter :)
<pitti> daniels: d'oh, purging dbus-1 in favor of libdbus-1-1 breaks tons of stuff...
<thom> pitti: not entirely surprising
<dholbach> hey mvo 
<pitti> thom: of course not, but a clean upgrade path will get funny :-)
<daniels> yeah
<daniels> this is why it's not uploaded
<mvo> hey dholbach 
<dholbach> bbl
<GheRivero> res
<Treenaks> hm, I'm getting "I tried to upgrade but all I got was a brown background when I tried to log in" errors on the -nl list
<Treenaks> 4 already
<infinity> Treenaks : Oddly enough, I had that problem on warty, but not on hoary.
<infinity> Treenaks : Never bothered to figure out why. :)
<mdz> morning
<daniels> morning mdz
<pitti> Hi mdz 
<pitti> mdz: "morning"? you aren't in California any more? :-)
<mdz> how was the CC meeting?
<mdz> pitti: 0100 is morning ;-)
<mvo> morning mdke 
<mvo> morning mdz
<mdz> actually I just say "morning" regardless of the time of day
<mdz> it's simpler
* mvo grumbles about his tab completion
<pitti> mdz: ah, ok :-)
<fabbione> hey mdz
<mdz> mvo: completion_amount = 1
<pitti> mvo: set completion_amount = 0
<fabbione> mdz: basically there was almost no meeting... not enough CC members around
<pitti> :)
<fabbione> mako was there
<mdz> a bad time for the UK
<mvo> thanks mdz, pitti 
<fabbione> mdz: well it is always a bad time for somebody
<fabbione> s/bad/bed :P
<mdz> both bad and bed
<fabbione> yay... last 3 external drivers to update and 2.6.12rc2 is almost ready
<mdz> new ipw2200?
* fabbione loves these insane marathons
<fabbione> mdz: new everything
<mdz> fabulous
<fabbione> mdz: updated everything to the last bleeding edge
<fabbione> break it early..
<fabbione> mdz: we also got a couple of patches upstream in like 10 minutes :)
<fabbione> our precompile on 6 arches tests are very good
<fabbione> mdz: + i updated all the external drivers documentation.. it was missing a bunch of drivers...
<fabbione> that will make it simpler in future
<mdz> have you written some tools to make it easy to convert the drivers into patch form?
<fabbione> mdz: no.. because some of them come as patches, others as tarballs, others need a precompilation beofre becoming a patch....
<fabbione> it's way to complex to write a generic tool
<fabbione> it needs to be done case by case..
<mdz> what a pain
<fabbione> mdz: don't tell me :(
<fabbione> mdz: specially the 2 or 3 that needs precompilation are a mess
<fabbione> because they generate some files at build time
<fabbione> and some are even arch specific
<fabbione> (reason why we still don't have ndis for amd64)
<mdz> ndiswrapper for one arch is too many already ;-)
<fabbione> mdz: heheheh but it has been reported to be working on amd64 so i expect people will ask for it pretty soon
<fabbione> and the really nice thing is that for each driver we update.. it is another rebuild
<fabbione> just to be sure the update is correct
<fabbione> that still doesn't involve that the code is portable
<fabbione> that comes at a later stage :P
<mdz> so now you have documentation for how to update each driver?
<fabbione> mdz: partially yes
<fabbione> mdz: it changes all the time.. so it is kinda a bet on each update
<fabbione> the best practise is to compare the interdiff between the old and the new patch
<fabbione> it will catch 99% of the cases
<mdz> smurfix: I guess I can see why moin disables page renaming by default
<smurfix> well, in zwiki it's far to easy to make a mistake that way
<smurfix> plus the rename feature conveniently forgets to take the pake subscriptions into account
<mdz> I have never had that problem; how does it happen?
<smurfix> s/pake/page
<smurfix> I got an apology email from the perpetrator ;-)  apparently he just hit the wrong button. Dunno how he managed that, they aren't exactly next to each other
<pitti> smurfix: and you get a big fat confirmation dialog in addition...
<jsgotangco> at least we know it was no bot that did that but somehow he did make links
<smurfix> rename doesn't have a confirmation dialog
<infinity> pitti : 25 out of 27 patchsets applied for mozilla.  Just sorting out the last two, as they contain several patches each, in a none-too-organised fashion.
<smurfix> jsgotangco: He fudged around, trying to undo the nonsense, but only made it worse
* pitti hugs and kisses infinity
<smurfix> "Undo" not working across renames apparently didn't help either
<pitti> infinity: so it will become one big update?
<pitti> infinity: that's not too bad from an user's POV, just one download :)
<infinity> pitti : Yeah, looks like it.  Stalling on the "hard" patch was pointless once I went past it. :)
<smurfix> anyway, off to teach a client how not to screw up his Asterisk server again ;-)
<infinity> pitti : I'm hoping to finish up all the patches tonight, and we can spend some time begging people to test that nothing (much) broke.
<infinity> pitti : Probably won't want to upload until we've had several people test for several days, in light of the massive amount of code touched.
<pitti> infinity: yeah, that's sane
* infinity takes a coffee break before diving into the last two evil-looking sets.
<doko> ?Also in this spurt is the Worple Guide which was worpled from the Ubuntu Worple to Worple and is now a permanent feature of the Ubuntu worple worple.?
<doko> interesting review ;) http://mpt.net.nz/archive/2005/04/11/ubuntu
<Lathiat> yes we have all seen it :)
<Lathiat> i agree, disagree and he is wrong on a few points but its definately an interesting read and brings up some stuff that needs attention
<pitti> bah
<pitti> doko: the current Hoary package FTBFS'es in hoary ... *sigh*
<Lathiat> pitti: FTBFS?
<pitti> Fails to build from source
<Lathiat> ah right
<spo0nman> where can i look for a TODO list?
<spo0nman> for ubuntu next release in general or specifics if possible?
<spo0nman> http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals is too general
<doko> pitti: which package?
<pitti> doko: openoffice.org
<doko> where's the log?
<Lathiat> OOo builds? :)
<pitti> doko: I /msg'ed you
<pitti> Morning seb128 
<seb128> hey hey pitti :)
<fabbione> morning seb
<fabbione> all this gcc-4 mess iz a gtk bug
<Treenaks> fabbione: gcc links against gtk now?
<fabbione> Treenaks: yeah...
<Treenaks> wow..
* fabbione hides
<Treenaks> must be the VisualStudio like GUI they're working on
<Treenaks> to make it better
<seb128> fabbione: hi fabbione :)
<fabbione> Treenaks: yeah
<fabbione> ehhe
<seb128> fabbione: gtk is the love :p
<fabbione> seb128: like gamin?
<seb128> fabbione: no no, gamin is a piece of crap :/
<fabbione> seb128: i think it will be easier to rewrite than to fix it.. really
<seb128> fabbione: some gnomevfs guys are thinking to use directly inotify instead of gamin
<fabbione> the idea behind it is very simple
<Treenaks> rewrite it.. again?
<seb128> apparently inotify is really easy to use
<fabbione> seb128: indeed it is
<pitti> seb128: that'd rock, one piece of software less in the stack
<Treenaks> does inotify work on non-local filesystems?
<seb128> pitti: that's what the gnomevfs guys said, just drop the IPC stack
<Treenaks> (and does gamin work on those?)
<fabbione> Treenaks: let me check....
<seb128> Treenaks: I don't think gamin does that
<astharot> ciao
<torkel> Treenaks: do you really want it to work on non-local filesystems?
<fabbione> Treenaks: in theory it can do that
<Mithrandir> I think nautilus currently does polling, but in a busy-wait loop
<Treenaks> torkel: I can imagine some situations
<fabbione> Mithrandir: it does with dnotify, yes
<Treenaks> torkel: though polling rates would have to be reduced drastically (if it's polling..)
<fabbione> Mithrandir: the dnotify backend is a mix with poll
<fabbione> not with inotify
<Mithrandir> fabbione: I'm just saying that I see ~70% CPU usage if I have a nautilus window open over ssh. :P
<fabbione> Mithrandir: ahaha
<Treenaks> Mithrandir: ssh -X nautilus or nautilus ssh://
<seb128> what's going on with breezy and the buildchain changes ?
<Mithrandir> on both my laptop (which is a 1.4GHz P-M) and my desktop (which is an a64 4000+)
<pitti> seb128: you can upload again :-)
<torkel> Treenaks: for some remote/global filesystems (read AFS) it would be a nightmare, unless you can restrict it somehow
<Mithrandir> pitti: breezy is open?
<pitti> seb128: I'm sure you are sitting on 281 packages to be uploaded :-)
<daniels> Mithrandir: breezy is GO
<Mithrandir> yay!
<Mithrandir> CRACK!!!
<Mithrandir> :)
<pitti> dump your crack, folks!
<Mithrandir> is mom and such running too?
<fabbione> yeah but there are no binaries yet... are they?
<Mithrandir> fabbione: it's probably a copy of hoary.
<fabbione> right now yes
<fabbione> but afaik buildd's are not building breezy yet
<pitti> oh right
<pitti> no pmount-0.8
<seb128> pitti: right, I've to upload ... but have we switched to gcc4 ?
<pitti> dunno
<doko> pitti: seb128 is 7bit only, so 281 looks a bit much ;)
<daniels> Mithrandir: no mom yet
<pitti> doko: certainly 7 bits of packages every day? :)
<pitti> and he has a gross lag now
<Mithrandir> he's been steaming off by uploading packages to Debian, though
<Burgundavia> really, if Debian was smart they would bribe Mark into cutting off seb128 upload priv one day out of the week
<pitti> lol
<thom> hah
<seb128> Burgundavia: ?
<Burgundavia> get sarge out in about 2 weeks
<seb128> mouarf :p
<daniels> yeah, because what sarge needs is *more* package churn :P
<Mithrandir> Kamion: does the installer try to use unicode over a serial console too?
<seb128> elmo: glib2.0 sync from debian please
<fabbione> seb128: i think he is going to push the bid red "import * fron Debian" button quite soon
<seb128> oh right :)
<jdub> hey seb128 
<seb128> Morning jdub :)
<tseng> zerokarmaleft: mono will be in breezy by the end of this month
<Treenaks> \o/
<Treenaks> tseng: does that include beagle? :)
<tseng> beagle runs like a champ
<daniels> beagle's already there, yo
<tseng> might manage to get tomboy into sid too
<tseng> dajobe took my package and added the jimmac icons
<jdub> tseng: should i keep updating beagle, or do you want to track it?
<tseng> jdub: you may certainly manage it
<tseng> jdub: its less of an issue now sans policy
<jdub> heh
<jdub> i'm not sure i want to keep tracking it ;)
<daniels> jdub: YOU WIN
<tseng> k, ill take it
<jdub> mwah :)
* jdub goes for more beer
<jdub> daniels: at JSBH :)
<daniels> jdub: bah, I'll drag thom to the better (and original, mofo) JSBH tomorrow night
<daniels> have we really had 14 USNs for warty's kernel?
<tseng> daniels: kernel bugs in the last 6 months have been at a crazy pace
<tseng> alot of those usn's cover multiple cans
<daniels> yeah
<daniels> i've proofread most of them ;) i just didn't realise it was 14
<daniels> utterly batshit insane
<Treenaks> those kernel people should learn to code!
<infinity> I assume they took lessons from the Mozilla people.
<infinity> Or vice versa.
* infinity gives up for the evening before he completely loses it.
<dredg> nah, the people to get lessons from are the ones who write apps like ohh i dunno, phpbb2 or phpmyadmin
<Treenaks> infinity: omg
<Treenaks> dredg: php4 itself
<infinity> pitti : One patchset left, unless you have new CANs since I started. :)
<infinity> pitti : Also, this last patchset contains a small patch we'll need to update hoary's Mozilla (but not firefox) with.
<daniels> infinity: actually, four
<pitti> infinity: which patch?
<infinity> pitti : https://bugzilla.mozilla.org/show_bug.cgi?id=285438
<astharot> ciao
<infinity> pitti : Last patch, check the last few comments.
<infinity> pitti : Was supposed to be fixed in 1.7.6, but someone missed a file.
<pitti> d'oh
<pitti> infinity: okay, great to hear
<infinity> pitti : In the future, someone should track these as they happen.  Backporting one patch(set) at a time is a bit easier than 30ish.
<infinity> Not to mention easier to test.
<infinity> Obviously. :)
<pitti> infinity: by any means
* infinity will be mildly surprised if his builds of moz/tbird/ffox tomorrow don't just crash on load.... Or make the CPU explode or something.
<infinity> pitti : Anyhow, your one-line patch for 1.7.6 should be simple enough. Lucky bastard. :)
<infinity> pitti : That's CAN-2005-401, if you're too lazy to read all the comments.
<infinity> (And who'd blame you?)
<infinity> Anyhow, I'm going to head home and do something to make me stop thinking about C++ and XUL.
* infinity -> gone.
<pitti> infinity: I already marked this CAN as fixed in hoary, since Mozilla claimed that it was fixed in 1.7.6 :-(
<infinity> pitti : Then unmark it. ;)
<pitti> infinity: already done :-)
<infinity> Heh.
<infinity> 'Night.
<pitti> night infinity 
<pitti> infinity: but this is fixed in ffox?
<kent> pitti, so there will be security fixes for Hoary soon? 
<pitti> kent: yeah, mozilla and OO.o
<kent> pitti, ok. I used to track Hoary during the last period of development, so I got used to the update-icon showing every day in the panel. Its been so strange not having to update for some time now.. :)
<pitti> kent: that's actually the ideal state for a stable release :)
<kent> pitti, yeah, i guess so.  But this is the first update since Hoary went final, right?
<pitti> yes
<kent> https://www.ubuntulinux.org/support/documentation/usn/errorreferencefolder_view.    "security notices that affect the current supported releases."  The first one of the list is a bout png, and if you click on its link, it says that it affects only ubuntu wart. But the page with CAN-notices says that it affects current supported releases, and is not Hoary also supported, as is Warty (18 month support, or something right
<kent> ?) 
<kent> Would it not be better if the page with security-notices had also a notice about which distrubution if affects? Right now it sort of looks like a new install of Hoary directly triggers some security-problems.
<kent> Sorry for the spam.  You might shoot me at will..
<pitti> kent: hmm, right, that wasn't necessary during warty...
<pitti> kent: right now all of them only affect wart
<pitti> y
<pitti> kent: this is mentioned in the texts, though
<kent> pitti, yes, for those who looks at the reports, it says which distribution it affects. But some might not do that, and just have a look at the page and draw some conclusions from that. If it was possible, it would be better if the first list could state also which version of ubuntu..
<tseng> daniels: i have an update of dbus-mono when breezy opens
<d3vic3> its open 
<cartman> it is?
<mjg59> Yes
<d3vic3> YEBO !
<tseng> is it broken yet :P
<cartman> thats fast =)
<tseng> if not, I can help
<daniels> tseng: what are you doing to dbus-mono?
<daniels> tseng: i have experimental 0.32 stuff at p.u.c/~daniels/dbus/
<tseng> daniels: unhack
<d3vic3> cartman, no buildd yet, AFAIK 
<tseng> daniels: /usr/lib/mono 4 life
<daniels> tseng: don't we have to wait for the mono packages to do that?
<cartman> d3vic3: argh repos. up yet? ie can I point sources.list to it?
<tseng> daniels: ok we can work on it later then
<d3vic3> yes 
<tseng> daniels: yeah i have the mono packages also.
<Lathiat> breezy is open afaik
<daniels> tseng: oh, rad
<cartman> uhm yeah
<daniels> tseng: ping me when you upload mono and we'll sort it then
<mjg59> Beagle's in breezy?
<tseng> daniels: great
<Lathiat> mjg59: not atm
<tseng> mjg59: beagle is in NEW until we have a new mono
<Lathiat> ahh
<mjg59> Ah, got you
<Lathiat> have we got a new kernel with new inotify yet?
<mjg59> Fabbione is working on the crack
<daniels> we're all working on craaaaaaack
<mjg59> daniels: Except you, who's working on his lca paper?
<fabbione> yeah
<fabbione> i am almost there :)
<cartman> crack is good
<daniels> mjg59: *ahem*
<cartman> when is buildd for breeze supposed to be alive?
<cartman> hoary is not unstable enough for me ;P
<fabbione> cartman: within a day probably
<cartman> fabbione: cool, thanks
<Lathiat> Are there any compilers for linux that can output a windows executable of basic C programs 
<Lathiat> *of a basic
<pitti> daniels: now hal 0.5 actually starts up :-) had to fix an upstream bug and lots of changes, but now it works :-)
<daniels> pitti: sweet
<daniels> pitti: CAN I UPLOAD YET?
<pitti> YES YOU CAN
<elbi> :)
<pitti> daniels: however, please don't upload your current dbus-1 package yet :-) it's still pretty crackful
<daniels> pitti: which parts are broken?
<pitti> daniels: at first build, it linked against the old libdbus-glib in /usr/lib, not in the build dir
<pitti> daniels: "it" -> python-dbus
<daniels> UGH
<daniels> that seriously sucks
<pitti> daniels: and of course it's lacking all sorts of conflicts, provides, etc. for transition
<pitti> daniels: LD_LIBRARY_PATH :-)
<pitti> daniels: then, are you really sure that you want to rename /etc/init.d/dbus-1? 
<daniels> er, isn't LD_LIBRARY_PATH used for runtime?
<daniels> surely we'd need -L../dbus or whatever
<pitti> daniels: erm, sorry, -L probably
<pitti> yeah
<daniels> and, uhm, renaming /etc/init.d/dbus-1 kinda bites
<daniels> i might fake it so it gets kept
<pitti> daniels: why not just keep /etc/init.d/dbus-1? it's a conffile, and if you rename it, you have to do a proper migration
<doko> elmo: ping
<daniels> pitti: because it requires more work than mv {dbus-1,libdbus-1-1}.init :P
<pitti> daniels: exactly
<daniels> pitti: dbus-1.init won't ever start anyway
<daniels> pitti: 'cause it'll test for $DAEMON and bail.  and dbus-daemon-1 got renamed to dbus-daemon.
<pitti> daniels: why did you rename dbus-1 to libdbus-1? actually there should be two packages (one with the daemon, one with the library)
<seb128> thom: around ?
<daniels> pitti: libdbus-1-1
<daniels> pitti: well, I needed to rename it for the soversion change anyway
<daniels> libdbus-1.so.0 -> libdbus-1.so.1
<pitti> daniels: yeah, but why not have an additional dbus-1 package for the daemon?
<daniels> because then stuff that depends on dbus-1 ends up not dragging in ... oh blah
<daniels> dbus-1 depending on libdbus-1-1
<daniels> that is *so* *nasty*.
<pitti> daniels: I don't particularly mind that, but having a new dbus-1 package might ease transition and upgrades
<daniels> yeah
<pitti> daniels: the dependency should be automatic in ${shlib-depends}, shouldn't it?
<daniels> hmph, I'll do that then
<daniels> pitti: yeah
<pitti> daniels: however, these were just some thoughts to ease transition, please just ignore them if you like
<daniels> nah, we need a smooth transition
<daniels> and daemon/lib should be split anyway
<pitti> daniels: btw, libdbus-1.so.1 is for clients, too, right?
<pitti> daniels: if so, then it should be separate, otherwise you would start the daemon if you build a client package
<pitti> daniels: (since it's pulled in as a build-dep)
<daniels> pitti: actually
<daniels> dbus_bindings_la_LIBADD = $(top_builddir)/dbus/libdbus-1.la $(top_builddir)/glib/libdbus-glib-1.la
<daniels> yeah, libdbus-1.so.1 is for clients
<daniels> pitti: i don't see that -ldbus-1 is ever used?
<pitti> daniels: yay, Makefile.am, that's nice
<daniels> pitti: that's what's already there :P
<pitti> daniels: ldd /usr/lib/python2.4/site-packages/dbus_bindings.so
<pitti> daniels: this linked against libdbus-glib-1.so.0 after first build
<daniels> bong
<pitti> and thus did not work
<pitti> daniels: I installed the new dbus-glib, built again, then it worked
<pitti> daniels: this really looks like if it used /usr/lib/libdbus-glib
<pitti> daniels: btw, I think we should collect dbus, hal, gnome-vfs, pmount, and g-volume-manager on p.u.c. and upload them all at once when it finally works
<pitti> daniels: what do you think?
<pitti> amu, Riddell: ping
<Riddell> pitti: hi
<pitti> Riddell: kubuntu needs your love: CAN-2005-1046
<daniels> pitti: i'm just looking at it now:
<daniels>  cc -shared  .libs/dbus_bindings.o  -Wl,--rpath -Wl,/home/daniels/canonical/dbus/dbus-0.32/dbus/.libs -Wl,--rpath -Wl,/home/daniels/canonical/dbus/dbus-0.32/glib/.libs -L/home/daniels/canonical/dbus/dbus-0.32/dbus/.libs -L/usr/lib -L/usr/lib/gcc-lib/i486-linux/3.3.5/../../../ ../dbus/.libs/libdbus-1.so ../glib/.libs/libdbus-glib-1.so -lnsl  -Wl,-soname -Wl,dbus_bindings.so -Wl,-version-script -Wl,.libs/dbus_bindings.ver -o .libs/dbus_bin
<pitti> hey, seb128 now uploads with his @debian.org address :)
<daniels> pitti: yeah, I think we should have a common staging area
<seb128> pitti: doh, thanks for noticing
<pitti> seb128: well, it shouldn't really matter
<seb128> pitti: need to update my ubuntu script :)
<\sh> I'm tired guys
<pitti> daniels: hmm, this actually looks right...
<daniels> pitti: pebcak kthxbye
<pitti> daniels: what went wrong? :-)
<daniels> pitti: you broke the build
<pitti> it built fine, it should FTBFS if something is wrong.. ? what did I do wrong?
<daniels> pitti: i dunno
<daniels> pitti: we could blame thom if you like
<pitti> daniels: I'd like that much better than blaming me :-)
<pitti> daniels: anyway, we can hope that this doesn't happen at the buildd
<daniels> yeah
<daniels> but i dunno
<daniels> i'll see if I can reproduce it
<daniels> totally shouldn't happen tho
<pitti> daniels: the really bad and h4ck1sh solution is a build-conflicts: to itself
<pitti> daniels: but there must be a better way
<pitti> build-conflicts so suck...
<daniels> b-c'ing on dbus-1 (<< 0.32-1) is shit
<pitti> daniels: so shall I convert hal to use /etc/init.d/libdbus-1 now? or will you revert to /e/i/dbus-1?
<daniels> pitti: i'll revert to dbus-1
<pitti> okay, thanks
<mjg59> Kamion: Around?
<pitti> seb128: did you already happen to package g-v-m 1.3?
<pitti> seb128: I like to start with it since I have the new hal running now
<pitti> seb128: I just want to avoid duplicate work
<seb128> pitti: nop, I consider g-v-m to be yours :)
<pitti> seb128: thanks :-)
* pitti starts to package
<seb128> thank you :)
<pitti> seb128: I want this new crack to play around with device encryption
<seb128> you are packaging hal 0.5 ?
<pitti> seb128: yeah, initial version is ready
<pitti> seb128: it's a PITA to upgrade currently (needs some dbus coordination, hold your breath), but once it's installed, it works reasonably
<seb128> cool
<pitti> seb128: I just had to drop ogra's patches for now :-(
<seb128> oh ?
<pitti> seb128: well, and the thing does not recognize my hd partitions at all - let's see what breaks with this
<pitti> seb128: yeah, hal has a completely new architecture, we need to redesign ogra's stuff
<seb128> hum, k
<pitti> seb128: we have 6 months to break it furth^W^W^Wfix it
<pitti> jbailey: ping?
<jbailey> pitti: here!
<trukulo> it's me or ubuntu-devel list is full of bugs insteadof threads of development?
<pitti> jbailey: would it be possible for cdbs, "debclean", to just remove the build-tree instead of trying to unapply all patches, make clean, etc.?
<pitti> trukulo: unfortunately this is the case :-(
<daniels> trukulo: not just you
<trukulo> daniels, pitti: so that's a real problem
<jbailey> pitti: Yes, I've just never done it.  Can you file a bug?
<pitti> jbailey: debian or ubuntu?
<daniels> trukulo: yeah
<zyga> hello
<pitti> Hi zyga 
<trukulo> daniels, perhaps closed devel-list ?
<zyga> is there any # with gpl-savvy lawyers?
<jbailey> pitti: Sadly, ubuntu if you want it looked at quicker.  the debbugs for cdbs is a bit of a maze at the moment.
<zyga> I'm currently in the process of releasing the project I'm working on under GPL
<pitti> jbailey: okay :-) as long as you push it into Debian, too? :-)
<zyga> and I have a few questions
<daniels> trukulo: that would suck :(
<jbailey> pitti: sb would kill me if I didn't. =)
<daniels> trukulo: maybe closed posting, but definitely not closed reading
<zyga> pitti: hi :-)
<trukulo> zyga, ask me if you want, if i can ask, i'll tell you
<trukulo> daniels, i know, i know, but it's a problem with that list
<daniels> yeah
<trukulo> daniels, perhaps closed posting would be good
<trukulo> as you say
<zyga> trukulo: generally there are several issues 
<daniels> jbailey: was the  intentional?
<trukulo> zyga, tell me in private if you want
<zyga> trukulo: the project was created by me and later on by my friend
<trukulo> zyga, then you need the permission of ALL the creators
<zyga> trukulo: (it's not top secret ;-) I can speak here if it's okay with the others
<jbailey> daniels: e?  I don't do e...
<zyga> trukulo: the problem is that while I was working for the institution that sponsored the project
<pitti> jbailey: #9152, TIA
<zyga> trukulo: my friend was doing it as his major in CS 
<zyga> trukulo: we are wondering what to write in each file
<jbailey> pitti: No worries.  I've promised sb some serious cdbs love for UDU, perhaps if our slave drive^W^Wmdz gives us some time I can drag you off to a corner as well to look at what I'm doing with cdbs. =)
<zyga> trukulo: currently we decided to list the institution as the copyright holder
<trukulo> zyga, who is the intellectual property owner? you and your friend? oy did you do that work for a company/institution?
<zyga> trukulo: and each/both authors as.. .authors
<zyga> trukulo: that's complicated
<trukulo> so you need permision of everyone related in the project
<zyga> trukulo: part belongs to the institue
<zyga> trukulo: other part to me
<pitti> jbailey: that'd rock! (we will bribe you to release cdbs2 soon :-) )
<trukulo> so you need agreement of the institute
<trukulo> and yours and your friend
<zyga> trukulo: and other to the university of my friend
<jbailey> pitti: The needed bribe is spare time. =)
<pitti> jbailey: or, rather, make you drunk and make you sign the "I will do it in two days" contract :-P
<zyga> trukulo: the university will cooperate most probably
<trukulo> zyga, that's ok, your friend too
<trukulo> and the institute? did you do that work on work-time?
<zyga> trukulo: but we still don't know if we should list everyone or just the institue
<trukulo> or in free time?
<pitti> jbailey: make it so that debian/rules contains nothing more than "#include /usr/share/cdbs/doitright.mk" :-)
<trukulo> zyga, if it's released in GPL
<zyga> trukulo: in the beginning I worked there
<trukulo> you don't HAVE TO mention anyone
<zyga> trukulo: then the funding stopped and techically it was in my free timne
<trukulo> because it's easy, if it's GPL you have no credit obligation
<jbailey> pitti: Nope, always has to be at least 3 lines.
<pitti> just kidding :-)
<trukulo> BUT, you can say in README or ABOUT, thanks to Insitute and University
<zyga> trukulo: so as long as the institute, the university and us agree it should be okay?
<trukulo> zyga, yes
<jbailey> pitti: #!/usr/bin/make -f , include /usr/share/cdbs2/cdbs.mk, CDBS_MODULES = debhelper autotools =)
<zyga> trukulo: well there is one more issue but I'm not so sure about it
<trukulo> zyga, tell me
<zyga> trukulo: the project was funded by the state
<pitti> jbailey: ah, that's the new boilerplate? nice
<zyga> trukulo: I'm not sure how does that look from the legal side
<jbailey> pitti: Yeah.  Module ordering is handled internally.
<pitti> jbailey: what about "#!/usr/bin/cdbs-make\nCDBS_MODULES= ..." then?
<trukulo> zyga, if university use the founds, and university let you publish it GPL, then there's no rpoblem
<trukulo> because university decides what to do with founds, it's not state responsability
<zyga> trukulo: the university did not fund this at all, but it explicitly reserves all rights to the work published by it's students
<trukulo> zyga, so rights are from university, no problem at all
<zyga> trukulo: the funds came from the state to the institute
<trukulo> rights is what matters here, intelectual property (copyrights)
<jbailey> pitti: Debian policy sais that it must be a Makefile.
<trukulo> zyga, ah, that's another history
<pitti> jbailey: oh, ok
<trukulo> zyga, it's institute owner of the rights or state?
<zyga> trukulo: we are still trying find a lawyer with sufficient knowledge 
<zyga> trukulo: that's still the fuzzy issue
<zyga> trukulo: we think that rights belong to the institute
<trukulo> zyga, i'm spanish, and VERY probably, laws are different here
<zyga> trukulo: but we are still not sure
<Pizbit> zyga: Do they even know?:)
<zyga> trukulo: I know but we hope that since everyone cooperates it's not a matter of if but how this gets GPLd
<zyga> Pizbit: ?
<trukulo> but anyway, it's very UNUSUAL that state told you not to publish that work in GPL
<Pizbit> zyga: Does the institute know if they have the rights or not?
<zyga> Pizbit: the institute is composed of scientists ;-)
<zyga> Pizbit: we simply don't know for sure ;-)
<Pizbit> Surely someone to be in charge heh
<trukulo> zyga, probably the state don't neither
<trukulo> :) so try to release as gpl
<zyga> Pizbit: most people are old and while very inteligent they have very little legal knowledge 
<trukulo> and if there is problem (very rare) contact a lawyer
<zyga> we are trying to do that ATM
<trukulo> zyga, that's my point of view, but i'm talking from spanish legislation
<zyga> I hope this is over soon though
<zyga> trukulo: thanks
<trukulo> zyga, you're wellcome
<zyga> http://www.suxx.pl/poliqarp/license.txt
<zyga> we plan to prepend this to each file
<trukulo> zyga, what is for ?
<trukulo> you don't explain it..
<zyga> trukulo: as I said we plan to prepend that to each source file
<zyga> trukulo: the project details can be found at www.korpus.pl (there's an english version)
<trukulo> thanks
* mvo is away for a couple of minutes to go to the bank
<Lathiat> you can get to the bank and back in 2 minutes?
<zyga> Lathiat: must be one of those brodband folks ;)
<zyga> broadband even
<pitti> sjoerd: ping
* Amaranth goes to bed
<daniels> pitti: i'm going to bed now, but i think we should have a reasonably smooth transition with the packages I just put up on p.u.c/~daniels/dbus/.  didn't change the version number.
<pitti> daniels: cool, will try them out.
<pitti> daniels: good night!
<daniels> night dude
<pitti> daniels: yeah, good time to go to bed :-) sleep well
<pitti> so you are 8 hours ahead of us
<\sh> http://www.ubuntulinux.org/wiki/LocalAptGetRepositories my experiences from last night to this morning...summarized on the wiki
<zyga> mvo: ping
<tle> long time no see ppl
<tle> I found something very interesting with bug #5917
<jdub> hey Safari_Al 
<tle> Ubuntu encounter low res 640x480 with all PC using i810 card
<Safari_Al> jdthood, Hi!
<Safari_Al> erm, jdub, hi!
<Safari_Al> thanks for the email today.
<tle> it'd be nice if u can have a look on it, danield,
<Safari_Al> jdub, gonna miss the 1st half of gnome.conf.au :/
<jdub> Safari_Al: d'oh!
<Safari_Al> jdub, I'm talking at the edulinux miniconf, so that will be good exposure anyway and good fun too I hope
<mvo> zyga: pong
<Kamion> daniels: pong
<Kamion> Mithrandir: I think it avoids Unicode for the installation itself, not sure about the second stage, that may be buggy
<Kamion> mjg59: pong
<Mithrandir> Kamion: the installer?  it uses utf8 on serial console with the slang frontend
<Kamion> Mithrandir: probably a bug then, feel free to diagnose :)
<Mithrandir> Kamion: right now I'm trying to undo some of the damage I've unleashed with new pkg-config versions
<Kamion> right now I'm unfreezing my upload queue :)
<zyga> mvo: have a look at www.suxx.pl/update-manger/patches
<mvo> zyga: nice, thanks
<zyga> mvo: I'll remove the old ones
<zyga> mvo: some thing got mixed in update-manager.in
<zyga> mvo: package version stuff especially 
<zyga> mvo: but as long as you like them they're safe IMHO
<mvo> zyga: I'm looking over it now
<zul> yo
<jdub> seb128: ha ha, clearlooks added to gtk-engines ;)
<zyga> what is a.u.o/bigfile?
<mjg59> Kamion: I'm just about go get lunch, but can I talk to you about custom CD images at some point?
<seb128> jdub: please update gtk-engines :p
<Mithrandir> oh fun
<jdub> seb128: evil man :)
<Kamion> mjg59: yeah
<seb128> :-P
<Mithrandir> I've managed to make a GSList pointing to itself
<Treenaks> Mithrandir: is that hard?
<Mithrandir> Treenaks: not really, but it consumes about 250MB/sec of memory when you try to copy it.
<Treenaks> Mithrandir: *headdesk*
<Mithrandir> I guess anybody trying to build epiphany with pkg-config 0.17.1 is up for a surprise.
<zyga> hmm
<zyga> where did our models go?
<zyga> april calendar is one big blue goo ;-)
<Treenaks> zyga: with hands!
<zyga> Treenaks: are you suggesting that next month they'll make it green with feet instead?
<Treenaks> zyga: who knows
* lamont discovers a lovely timebomb waiting to embrace him in the livecd rootfs build...
<zul> boom
<lamont> every 3 weeks or so, we build a livecdfs that wants to fsck at boot time...  every time...  Gonna have to fix that...
<Kamion> why every three weeks?
<lamont> well, was watching things scroll by, and it said every 21 mounts
<Lathiat> lamont: why don't you just tune2fs -c 0 -- if its ext2?
<lamont> since we reuse the image, etc..
<lamont> Lathiat: that'd be the fix, yes.
<Kamion> ah
* Kamion wonders just how enormous the debian-installer merge is going to be
* lamont thinks more, realizes just what an fsck of the cloop would do to the ramdisk, giggles more.
<Lathiat> lamont: eh?
<Kamion> rsyncability death?
* Lathiat wonders where to find dbus hackers
<Treenaks> Lathiat: #dbus ?
<Lathiat> Treenaks: no #dbus
<lamont> Kamion: nah - I expect it'd touch at least something pretty frequently, resulting in a things moving over
<Lathiat> they must have caught d-bus and buggered off :)
<Treenaks> Lathiat: you could poke sjoerd 
<Treenaks> Lathiat: or pitti
<Lathiat> i just want to know if theyve done implementing objects in the glib api yet
<lamont> then again, it shouldn't actually need to change anything - just read the whole cloop... depends on how smart the cloop code is on not exhausting memory
<mvo> Lathiat: ross bloged about that recently IIRC
<pitti> Lathiat: no idea -> daniels
<Lathiat> more to the point, in 0.23
<Lathiat> mvo: burton?
<Lathiat> ah, so its in 0.32
<Lathiat> oh well
<Kamion> thom: please restart the torrent tracker once it gets the Kubuntu DVD torrents that are currently syncing
<pitti> sjoerd: ?
<Mithrandir> maswan: hmm, could we clean out a bit on ravel?
<ogra> aaaw...http://www.about-linux.com/ubuntu_1-5.html
<ogra> a video tutorial on "how do i remove all nice ubuntu advantages in warty" 
<jsgotangco> warty video tutorials online..that is nice
<maswan> Mithrandir: yes.
<Mithrandir> maswan: I'm cleaning out about 800M of packages from pure64 at least
<maswan> Mithrandir: I'll go clean some of my stuff up.
<maswan> some of the -mw$n stuff isn't needed.
<Mithrandir> maswan: great
<maswan> hmm.. actually, none of it is, because the only reason I kept many aroudn was that they had different state (mostly wrt multiarch), but since I have forgotten what states were involved...
<Mithrandir> heh
<maswan> I think the same goes for the pure64-mw variants, unless you know of anything different there?
* maswan also remembers to umount the bindmounted /home before rm -rf:ing ;)
<Lathiat> haha
<Mithrandir> maswan: no idea :)
<fabbione> yo
<maswan> Lathiat: I've done that before on that machine. Luckily my $HOME was first, and I had a bunch of unpacked kernel trees, so I managed to break it before I clobbered Mithrandir's stuff etc. :)
<fabbione> elmo: ping?
<elmo> fabbione: ?
<fabbione> elmo: would it be possible to get sparc.u.c going?
<fabbione> a 4 times/day pulse would rock
<fabbione> otherwise i cannot even start breezy
<elmo> fabbione: I'll do ports when I can, but atm getting breezy syncing is a higher priority
<fabbione> elmo: yes i really understand that, but i can't even prepare the buildd otherwise.. can you give me at least one pulse?
<elmo> fabbione: done
<fabbione> elmo: thanks
<|QuaD-_> ls
* lamont back in a while - errands in town
<Lathiat> maswan: oops :)
<maswan> Lathiat: the lesson learnt is to always keep half a dozen kernel trees in your $HOME, it gives you time to think and break that rm -rf before it takes out the whole filesystem :)
<Lathiat> rm needs one of those flags not to traverse file systemws
<Lathiat> i thought gnu rm had one
<ross> daniels: ping?
<ross> so the hoary hardware device database tool is broken for me
<ogra> ross ?
<ross> it tried to send to the server, failed to connect. it then said it would save a file to disk, and didn't
<ogra> whoops, is it up to date ?
<ross> a fresh hoary install
<ogra> should be 0.6-ubuntu2 iirc
<ogra> no upgrade from debian or such ?
<ross> nope, i wiped my disk
<ogra> hrm
<ross> i did purge a load of python modules i don't use so it may be incomplete deps
<\sh> hey ogra, finally u awak ;)
<ogra> could you run hwdb-gui from the commandline  ?
<\sh> +e
<mvo> ross: does that mean you have hoary runing on one of your machines? *congrats* then :)
<ross> mvo: yeah, nice to see g-a-i in its native environment :)
<ogra> heh
<ross> mvo: and this time i used lvm so i can make space for a new install later
<ogra> looks cool now (since it has some apps in the tree)
<ross> i had a few install issues, i'll have to hit bugzilla later
<zyga> mvo: hey
<mvo> zyga: hey
<ogra> hi \sh 
<zyga> mvo: I think that the easiest approach is to simply add debian 
<maswan> Mithrandir: better?
<Mithrandir> maswan: a lot, thanks :)
<mvirkkil> ross: Are you planning on doing work on g-a-i? Wondering because I'm working on splitting the different parts (ie apt/synaptic handling) in to separate classes and files.
<zyga> mvirkkil: how do you determine current icon theme?
<mdz> morning
<ogra> hi mdke 
<ogra> hi mdz
<ogra> grr
<zul> hey mdkz
<mvo> zyga: I'll send you a mail then
<zul> grr
<zyga> mvo: great, thanks
<mvo> mvirkkil: would make sense, in the future we may go with python-apts interface
<ross> mvirkkil: yes, i don't plan to drop it
<mvirkkil> zyga: I haven't done any changes to that part. 't uses:  self.icons = gtk.icon_theme_get_default()
<zyga> mvirkkil: thanks, I'm not familiar with gtk :)
<\sh> 2 days off from work, and more work in my sparetime...I'm ill
<mvirkkil> ross: I mean that it will take a few days and will include large and invasive changes (again)
<mvirkkil> zyga: Neither am I :-)
<ross> next week i'll probably review all of the patches i've been sent and merge any hoary changes
<mvirkkil> ross: So merging it with other changes will be painful.
<ross> either wait a bit or be prepared for conflicts
<mvirkkil> ross: I guess I'll be prepared for conflicts. The changes aren't that large compared to the ones I've already made (the large patch in bugzilla).
<mvirkkil> zyga: What are you woking on if you don't mind me asking?
<dholbach> hi
<mvirkkil> dholbach: hi
<ogra> hi dholbach 
<dholbach> hey :-)
<mvo> hi dholbach 
<\sh> dholbach: I set myself on the list for wannabe new member of ubuntu 
<mvirkkil> \sh: What's that?
<justdave> who does admin-type stuff at Canonical these days?  (like if I need to get an employment verification letter showing they employed me last year)  Is that still Jane?
<dholbach> \sh: yeah... already saw :-)
<zyga> mvirkkil: I wan to add pretty user friendly icons to u-m based on desktop files of existing applications
<zyga> mvirkkil: and learn python + gtk at the same time
<\sh> dholbach: finally, i could bash ogra all the day, just because he forced me to play with ubuntu ;)
<dholbach> :-)
<ogra> \sh, nice wikipage
<mvirkkil> zuga: Cool. Check out the icon function in http://cvs.gnome.org/viewcvs/gnome-app-install/src/AppInstall.py?rev=1.2&view=markup (should prbably be called something like getIcon and not just icon)
<\sh> mvirkkil: http://www.ubuntulinux.org/community/processes/newmember
<\sh> ogra: the howto? 
<ogra> yep
<zyga> mvirkkil: cool, thanks
<Mithrandir> justdave: Jane or Claire, I think; probably just send it to Jane and she'll forward it.
<\sh> ogra: check for wrong spelling ;)
<ogra> \sh, thats better done by a native english speaker ;)
<justdave> Mithrandir: thanks
<mvirkkil> ross: How many pathces do you have for g-a-i?
<ross> mvirkkil: just a few pending
<\sh> ogra: hehe for sure ;) but i tell you...my eyes are small, my brain is dead, but I want to finish my vnc2swf...if this is working...we can do a lot of stuff for ubuntu, showing desktop sessions via flash movie...this will be the hell :)
<ogra> \sh, doesnt really convince the amd64 user here :)
<ogra> \sh, (no flash for amd64)
<zyga> ogra: you are very right :)
<\sh> ogra: well...for promotion is x86 enough ;)
<mvirkkil> ross: Do you do your work in the gnome cvs? (ie how do I keep up to date?)
<\sh> ogra: even not with ming?
<\sh> oh ming i prepare just here ;)
<ross> mvirkkil: yeah, gnome cvs
<mdz> Kamion: ping, re: breezy germinate
<ogra> \sh, dunno, i guess with a lot of fiddeling i'd get it to work.... but i dont think flash is worth that
<\sh> ogra: u have a x86 box at home? check http://www.unixuser.org/~euske/vnc2swf/
<\sh> ogra: complete sessions with live sound explanations etc.
<cjb> ogra: You can swf2avi, avi2gif.
<ogra> \sh, http://www.about-linux.com/ubuntu_1-5.html same like this....
<cjb> (Which is how I did http://www.inference.phy.cam.ac.uk/dasher/images/newdasher.gif .)
<ogra> \sh, which makes me sad ....
<\sh> ogra: try with gplflash it's amd64 compatible
<ogra> \sh, since it only shows how to rip out the nice ubuntu imrovements out of your system
<ogra> \sh, i'm really not interested in flash
<mvirkkil> ross: I'd be interested in knowing what the patches are for. Mind sending me them?
<\sh> ogra: no..much nicer...u see a direct session from your desktop :) vnc to your box and record it ;)
<cjb> What we *really* need in an X server plugin that uses damage to record changes to sessions in a really bandwidth-efficient way and allows us to play them back and export them and all kinds of useful stuff.
<ross> cjb: doesn't need to be a plugin, a normal app could do that
<ross> that was the point of damage :)
<cjb> ross: Well, a bit of both.  I guess the perfect way to do this is to have a compositing manager do the recordings.
<cjb> (Since it speaks Damage, will know when to take snapshots to end up with a consistent state, can avoid repainting as much as possible.)
<elmo> MITHRANDIR
<Mithrandir> what have I done now?
<Mithrandir> except breaking pkg-config, but that's being fixed now
<Mithrandir> maswan: run dmesg on ravel
<Mithrandir> elmo: pong?
<elmo> Mithrandir: you uploaded mozilla-thunderbird without an ubuntu version number and with a different .orig.tar.gz from debian's
<Mithrandir> elmo: argh :(
<Mithrandir> elmo: what can I do to fix the damage?  (except not doing it again)
<Mithrandir> (if anything)
<mvirkkil> WOW! http://www.ubuntulinux.org/wiki/WhyYouShouldntUseUbuntu Someone is spamming/trolling. 
<elmo> Mithrandir: I'm not sure atm
<Mithrandir> mvirkkil: at least somebody with a broken caps lock key
<Kamion> mdz: pong
<mvirkkil> Mithrandir: And someone who could use a good beating with the clue-stick :)
<Kamion> mdz: what do you need? I switched the default RELEASE/DIST earlier today
<\sh> hmmm.
<\sh> well.
<\sh> anti-white?
<\sh> mark is not a coloured
<\sh> so...anti-white? 
<\sh> finally anti-buur
<\sh> but not anti-white 
<dholbach> deleted
<Kamion> mdz: oh, I guess you want output on people.u.c/~cjwatson/germinate-output/ too ... doing
<\sh> thx...
<mvirkkil> dholbach: Good. Did you block the ip? Also notice the link on the front page.
<dholbach> oh didnt :-/ hrm
<CarlK> apt-cache show whiptail - Whiptail is a "dialog" replacement.  but it does not provide "dialog" - I think it should include ln -s whiptail dialog - yes?   should I bugzilla this?
<mvirkkil> dholbach: Hmm... I can still see the page.
<mvirkkil> dholbach: Nevermind, the page is gone now
<ogra> i cant, but the search returns taces....
<ogra> traces
<dholbach> mvirkkil: i'm no wiki admin, i can't block ips
<mdz> CarlK: no, it should not provide /usr/bin/dialog; that would unnecessarily cause the packages to conflict, and I'm not even sure that they're 100% command-line compatible
<astharot> ciao
<CarlK> mdz - should 'something' provide dialog?
<mdz> CarlK: the dialog package does
<mdz> Kamion: I'm trying to diagnose why anastacia wants to move a few hundred packages to universe
<pitti> Morning mdz
<thoreauputic> mdz: it appears in Warty at least, the dialog package doesn't exist 
<Kamion> mdz: I diffed hoary/breezy germinate outputs, they were identical apart from kvim
<mdz> thoreauputic: it's in universe
<Kamion> CarlK: whiptail is not 100% command-line compatible with dialog
<thoreauputic> mdz: not here it isn't
<Kamion> debconf has code to do slightly different things depending on which one it finds
<elmo> mdz: I got cron.sync minimally functional, it's not really live yet
<mdz> thoreauputic: in the Ubuntu archive it is
<Kamion> please leave it alone :)
<mdz> elmo: ah
<thoreauputic> mdz: oops, I beg your pardon - it is here after all, sorry
<Kamion> for example whiptail has --scrolltext, dialog doesn't
<CarlK> the whiptail idea was just because i couldn't find dialog, and the description said it would work ;)
<CarlK> ok, us lusers will go back to #ubuntu ;)
<thoreauputic> CarlK: mdz is right - I must have done a typo
<CarlK> no prob
<doko> jbailey: did you remove the ppc64 glibc binaries from p.u.c.?
<jbailey> doko: I did - I realised that they didn't have the libc.preinst hook to make sure that there was a 2.6 kernel running.
<jbailey> doko: Want another set?  I can push them up now.
<jbailey> I was just about to tweak the l-k-h dependancy to 2.6.11.2-0ubuntu1 instead of to -1
<jbailey> (Having watched elmo lart someone for that mistake just moments ago... *g*)
<fabbione> meh 2.6.11 ??
* trulux starts Breezy business
<jbailey> fabbione: Will that cause you grief?
<trulux> fabbione: could we talk on the Breezy goals for the kernel packages?
<trulux> fabbione: after it I will say you rcok :D
<jbailey> fabbione: Generally the defines are the only interesting bit.  glibc always rolls back to previous syscalls.
<Kamion> fabbione: l-k-h isn't part of your packages though ...
<fabbione> jbailey, Kamion: ah ok
<jbailey> fabbione: Upstream recommends that you always use the recent kernel headers even if you're running an older kernel.
<fabbione> trulux: why don't you subscribe to kernel-team and discuss what has been asked teice already ? ;)
<fabbione> jbailey: make sense
<fabbione> s/teice/twice
<trulux> fabbione: ok
<doko> jbailey: could we just install the current packages in the ppc64 chroot, and work from this state on?
<fabbione> trulux: there is a team behind.. i want people to discuss all together
<trulux> doko: also, could we talk on the gcc packages?
<trulux> ok, sorry
<trulux> I like team work, so, it's better even
<trulux> :)
<fabbione> i have the feeling that elmo just imported sid...
<elmo> I've been trying all day
<jbailey> doko: Better to give me 20 minutes.  The version of lkh that I'll be uploading will be a lower version that I was using before (-0ubuntu1 instead of -1), so it would never get rolled back.
<jbailey> elmo: I don't need to run the testsuite on it anymore, though.
<fabbione> elmo: well you succeed to some extents i gues...
<trulux> who is in charge of managing the meetings?
<pitti> trulux: you can announce one yourself as long as it doesn't clash with an existing one
<dholbach> bbl
<doko> jbailey: sounds fine
<trulux> pitti: ok, great
<doko> trulux: did you want to talk about the SSP patch for gcc-HEAD ? ;)
<pitti> trulux: please look in #ubuntu-meeting for the already scheduled ones and add yours
<pitti> trulux: and announce the meeting on u-devel@l.u.c
<trulux> doko: about *many* stuff, I have created the breezy chroots and testing stuff
<trulux> ok
<pitti> trulux: SSP for gcc-HEAD would really *rock* :-)
<trulux> pitti: I'm porting it to 4.0, as I haven't got response from Etoh
<trulux> nor Yoda
<elmo> mdz: cron.sync is fixed
<trulux> so, following Yoda's saying... "don't try to do it, do it or just don't do it"
<trulux> ;)
<mdz> elmo: thanks
<trulux> hey mdke 
<trulux> erm
<trulux> mdz
<trulux> :)
<trulux> mako: nothing from Amaya (yet)
<mdz> elmo: I seeded openoffice.org2 yesterday, but anastacia doesn't want to promote it
<Kamion> that'd be a mirroring problem, I'll investigate
<mdz> mirroring of the seeds? ah
<elmo> why the hell is baz update checking every signature ever. grr.
<Kamion> my fault, incomplete script
<Kamion> was only baz updating warty hoary kubuntu-hoary
<Kamion> mdz: try again
<mako> trulux: ok
<mako> trulux: send her another ping
<trulux> mako: ok
<fabbione> doko: so what is the toolchain bootstrap sequence for the buildd?
<mako> ok.. so i'm hearing that ubuntu was discussed on us television last night
<mako> national television
<jbailey> Neat.  In a positive light?
<mako> 18:26 <@micah> mako: apparantly last night on the TV show "Veronica Mars" two of the main characters had an argument about which is better, OS X or Ubuntu
<mako> 18:27 <@mako> micah: WHAT?
<mako> 18:27 <@micah> the argument was as if you and I had the argument, but on a mainstream TV show ("But Ubuntu is Free Software" "Yeah, but it always breaks!")
<trukulo> mako, any video avalaible on internet?
<mako> 18:27 <@micah> mako: seriously... I was just told that
<mako> i just heard about this
<jbailey> Ahah
<doko> fabbione: do we need one, as long as we don't change the g++ default?
<mako> can someone verify this
<fabbione> doko: well, what does need to be builded and installed in the chroot first, before start batching the builds?
<fabbione> doko: there are already upload queued.. including gcc-4.
<fabbione> doko: so i guess we need that in as first...
<doko> yes, this one and glibc first
<jbailey> I've just uploaded linux-kernel-headers, since it doesn't need any furhter love AFAICT.
<Kamion> $ debian/rules `pwd`/stamp-dir/patch-stamp
<Kamion> meh
<Kamion> jbailey: is there an easier way than the above to just unpack/patch the glibc source tree?
<jbailey> Kamion: debian/rules patch
<trulux> what's the release number for Breezy?
<trukulo> trulux, 5.10
<trulux> trukulo: many thanks, sir
<trulux> :)
<trukulo> trulux, it's easy: year.month (5.10)
<Kamion> jbailey: tried that
<trulux> yep, I'm just about to test a game that a friend gave to me
<Kamion> jbailey: oh, bah, maybe I didn't, OK. :)
<trulux> if something doesn't stop me to have fun for a while
<Kamion> I hate that particular guessing game
<jbailey> Kamion: Oh good.  I was fairly certain I had used it this morning. =)
<Kamion> I tried 'setup', 'source.make', 'patched-source'
<Kamion> then gave up and started trying to read the rules files
<jbailey> YEah.  setup used to be in there, I'm not sure why it's not now, but I haven't hunted it down.
* mvo is away, bb in 2h
<Frafra> hi
<Frafra> exist ubuntu for sparc and/or ultrasparc?
<trukulo> Frafra, no
<fabbione> Frafra: yes
<mdke> heh
<fabbione> it will be available during breezy release cycle
<trukulo> fabbione, i think not, but you know better than me :P
<fabbione> trukulo: i am doing the port.. there is already an archive of packages 
<trukulo> fabbione, ah! then it doesn't exist !! it will exist
<Frafra> 5.10 for ultrasparc?
<trukulo> don't confuse me, man
<fabbione> but it's not good enough yet to be sent around
<fabbione> Frafra: i hope that will be a reality.. yes
<Frafra> :D
<Frafra> good
<Frafra> can i download the unstable version?
<fabbione> Frafra: there are no iso.. only netinstall.. if you can wait a few days.. yes
<Frafra> :D
<Frafra> intresting... :)
<fabbione> we are moving it to a new (and slightly more powerful) server
<fabbione> before making the port available
<jbailey> doko: The new glibc is in http://people.ubuntu.com/~jbailey/glibc/ sorry about the lag.
<fabbione> elmo: ROCKING!
* fabbione hugs elmo a lot
<fabbione> elmo: how is it going with the syncs?
<mxpxpod> so, breezy development has started?
<doko> jbailey, elmo: so we can set up the chroot?
<jbailey> doko: I'm fine with it now.  lkh hasn't made it through the buildd yet, so if you want I can upload a ppc deb for that too.
<doko> jbailey: that would be nice ...
<mxpxpod> jbailey: hey
<jbailey> mxpxpod: Hullo
<jbailey> doko: http://people.ubuntu.com/~jbailey/linux-kernel-headers/ has it now.
<mxpxpod> jbailey: will the linux-headers-2.6.11 stuff from breezy work for hoary?
<mxpxpod> also, are there going to be minor updates to hoary for like metacity 2.10.1 and such?
<pitti> re
<jbailey> mxpxpod: Define 'work for'?
<jbailey> mxpxpod: And no, probably not.
<mxpxpod> jbailey: will I be able to compile a kernel-image
<mdz> jbailey: I'm trying to make sense of the huge pile of Java packages that want to move from universe to main; can you take a look at it?
<jbailey> mxpxpod: With a short release cycle, there's not enough time to be maintaining a backports setup.
<mxpxpod> jbailey: ah, ok
<mxpxpod> so, my best bet would be to switch to breezy ;)
<jbailey> mxpxpod: l-k-h is completely unrelated to the kernel builds itself.  The package will probably be renamed to linux-libc-headers at some point to avoid confusion.
<mxpxpod> jbailey: ah, ok
<mxpxpod> jbailey: is there a "simple" way to take a vanilla kernel and put the ubuntu patches (like wlan-ng) into it?
<Mithrandir> maswan?
<jbailey> mdz: Are you looking at JavaPackagingProgress:
<jbailey> ?
<jbailey> mxpxpod: Dunno.  I try to stay on this side of the syscall layer. =)  IIRC, patches are maintained as .dpatch or something like that - There ought to be some way to easily replace the upstream version.
<mdz> jbailey: no, see the email I sent
<mdz> jbailey: according to germinate, those packages ought to be in main, and not universe, but there's far more than I expect to see
<mdz> and some of it we definitely don't want in main
<jbailey> mdz: This is my first encounter with germinate.  How does it produce this list, missing build-deps and depends for packages that are in main now?
<mdz> jbailey: germinate takes as input the seeds and the Packages files
<mdz> jbailey: it walks the depends and build-depends trees, and outputs lists which incorporate dependencies
<mdz> jbailey: so the output of germinate for the 'desktop' list is all seeded packages, plus all their dependencies (recursively)
<jbailey> Also build-deps?
<mdz> jbailey: all build-dependencies are added to the 'supported' output\
<jbailey> Ah, cool.
<mdz> jbailey: elmo has a tool which basically diffs that against the state of the archive
<mdz> I mailed you part of the output from that tool
* fabbione plays around
<mdz> I assume that some of it is related to openoffice.org2, but we had openoffice.org2 in main for part of the Hoary cycle without it
<ska-fan> mdz == sabdfl?
<mdz> and it seems like a huge amount of stuff (kaffe AND ecj, 4 different jikes packages, jython, etc.)
<mdz> ska-fan: no, sabdfl=sabdfl
<fabbione> or mdz=mdz
<ogra> yeah
<mdz> s/or/and/
<Lathiat> ==, depending which language your brain parses :)
<ska-fan> ok, thanks. No idea how I got that impression :)
<jbailey> mdz: The source packages is basically what's in Hoary at the moment, or is this from the sid merge?
<fabbione> mdz: 2.6.12rc2 is basically ready to go in as update from hoary. We are working on parsing bugzilla for the extra drivers before any upload to see what is sane to pull in before UDU
<Lathiat> fabbione: can i give it a test run?
<fabbione> Lathiat: there are no binaries around sorry
<mdz> jbailey: this is breezy
<mdz> jbailey: (which is basically hoary, plus a few uploads over the past few days)
<mdz> ska-fan: sabdfl has more hair
<Lathiat> fabbione: trivial to build from source isn't it? (i assume kernels are no different?)
<fabbione> Lathiat: + the kernel can still change from what will hit breezy and the aBI too
<fabbione> Lathiat: it's not trivial without the first .diff.gz and the .dsc and the .orig around :)
<Lathiat> heh ok
<fabbione> Lathiat: i will ping you as soon as i have something builded
<Lathiat> fabbione: ok :)
<fabbione> well actually more than you... but you get the idea
<mdz> jbailey: the 'all' file has a column which shows which package pulled in each package
<Lathiat> fabbione: yuh :)
<mdz> jbailey: or if it was listed in a seed explicitly
<fabbione> Lathiat: it also depends what flavour you need
<jbailey> mdz: Ooo, thanks.
<mdz> jbailey: the rdepends/ directory contains a tree showing all the reverse depends for each package
<fabbione> Lathiat: i am not going to get too crazy uploading outside the archive
<Lathiat> 686 (or 386)
<fabbione> Lathiat: ok
<Lathiat> not hassling, jsut thought i'd could give it a shot and see how it goes :)
<mdz> jbailey: e.g., python2.1 is being pulled in by jython, via libbsf-java via ant
<fabbione> Lathiat: inotify works, if that's what you want to know :)
<mdz> jbailey: we won't support python 2.1, so we need to break that chain somewhere
<Lathiat> fabbione: i was trying to avoid asking :) haha
<jbailey> mdz: Yup.  Like I'm sure xerces-j doesn't actually need a build-dep on ash.
<Lathiat> fabbione: but i was just more generally interested in testing it and seeing if theres any problems
* fabbione has some kind of mental control
<fabbione> Lathiat: i am building a 686 image right now.. not sure if i will manage to upload it before my wife is back
<Lathiat> ok
<fabbione> and it has some experimental stuff that might not go in breezy at all
<fabbione> so don't rely on them
<Lathiat> whatever, when you have time, i'm not fussed :)
<fabbione> testing is good.. but i like to set people mind first
<Lathiat> nps
<fabbione> it's a 12rc2 + extra junk + extra royally untested crack
<fabbione> it can hurt
<ogra> yeah, lets wipe our disks ... and burn the chipsets ;)
<Lathiat> fabbione: i bet it can :)
<Lathiat> i'll keep both pieces, don't worry :)
<elmo> doko: still here?
<doko> yep, my flight is tomorrow evening ;)
<elmo> doko: okay, so things keep changing and I've lost track - what do you want installed in the chroot?
<doko> davis:~doko/powerpc64/install/* + jbailey's glibc packages
<elmo> where are  jbailey's pkgs?
<elmo> geez, we were almost 2Gb out-of-sync with sid, source-wise
<jbailey> elmo: http://people.ubuntu.com/~jbailey/glibc/
<elmo> and that's the unmodified packages
<jbailey> elmo: I can move the specific ones to a server if you'd like.
<jbailey> (just need to know where)
<doko> elmo: copied in the same dir
<doko> plus glibc & gcc-4.0 build-deps
<fabbione> doko: is that for ppc64 kernel?
<jbailey> fabbione: This is to get ppc64 capable toolchain into the archive.
<doko> yes, you can start kernel baking, but please let me build gcc-4.0 biarch first ...
<doko> mdz, jbailey: I hope jython isn't a problem for breezy anymore. there's at least some work done to implent something equivalent to python2.3
<elmo> argh
<mdz> seb128,doko: as part of moving to oo.o2 in desktop, should we add oo.o2-evolution to desktop?
<elmo> someone pretty pretty please fix findutils to not trawl bind mounts
<fabbione> doko: i won't start anything until you will tell me that gcc & co is go
<elmo> davis is crawling so many copies of /home it's not finishing in 24 hours
<seb128> mdz: no real opinion on it, I don't know what this package does
<mdz> Description: Evolution 2 Addressbook support for OpenOffice.org
<doko> mdz: yes, seb128: it accesss the addressbook
<seb128> oh, it uses eds
<seb128> right
* jbailey grabs food.
<mdz> elmo: does dev/ino match for the top-level directory?
<elmo> mdz: actually, sorry, it's checksecurity which is causing the problem
<elmo> not findutils
<doko> mdz: GCC, did talk with dan@debian.org about g++-3.3/gcc-4.0 compatibility, it looks like there are no problems (except hppa and maybe sparc). But with this combination we add a third variant to the existing and our target toolchain, so the tests/builds have limited value. So either stick with the current defaults until UDU and do the gcc/g++ switch at the same time, or do it now (which is sub-optimal, because many people are in vaca
<doko> tions next week).
<mdz> a majority of our packages are C programs; there is definitely value in getting them built with gcc-4.0
<mdz> if we switch after the sync, we'll need to do source uploads of every C program to get them rebuilt
<Mithrandir> mdz: note that Andreas Jochens has been building the gcc-3.4 archive for amd64 in Debian with gcc4 for quite a while, so bugs should be filed in Debian for most issues already.
<elmo> mdz: why?
<mdz> elmo: er, unless you want to do thousands of binary-NMUs, or flush the archive?
<elmo> mdz: why do we need to do either?
<elmo> gcc-3.3 and gcc-4 built binaries/libraries (excluding c++) can happily intermix?
<Mithrandir> elmo: they can
<mdz> elmo: to avoid releasing with packages built by gcc-3.3 which gcc-4.0 miscompiles
<elmo> Mithrandir: (I know it was a rhetorical ? ;)
<mdz> so that they would blow up in our face during a security update
<Mithrandir> elmo: I didn't know if it was. :)
<Mithrandir> elmo: but considering you maintain the packages you do, I should learn to shut up
<Mithrandir> bah; *off*
<mdz> or a last-minute change before the release, for that matter
<elmo> mdz: well - there are going to be packages that haven't changed since hoary in sid either
<mdz> not that we ever do those
<elmo> but *shrug* ok
<mdz> elmo: yeah, but like two orders of magnitude less
<elmo> in any event, there's still time, as breezy building seems to be down
<mdz> doko: in what way do the tests have limited value?  for which packages?
<doko> Mithrandir: these bugs are already imported. you can have a look at my assigned bug reports, if you find some of your packages ...
<mdz> elmo: wow, checksecurity is a fucking rat's nest
<elmo> yes :(
<doko> for mixed C/C++ binaries, we have a new possible source of errors, and may see/debug things that we won't release with breezy. we did a test rebuild for haory as well some weeks before the release, so that should be doable for breezy as well.
<mdz> all of the mixed C/C++ stuff will be rebuilt as part of the C++ transition, no?
<doko> yes, we have to.
<mdz> let's go with gcc-4.0 and g++-3.3 then, before we start syncing sid to breezy.  I'd rather have an uncomfortable situation with a few packages, than an uncomfortable situation with many packages
<mdz> if strange things happen, test builds with gcc-3.3 are easy to try
<elmo> sorry, why are we not just doing g++-4 now?
<doko> so we go with gcc-4.0, gobjc-4.0, g++-3.3, gcj-3.3, gpc-3.4 and g77-3.4 as default ?
<zyga> is it possible that ubuntu will become incompatible with debian? (as heard on slashdot)
<doko> elmo: man power during the next week, and maybe no final 4.0 release yet
<elmo> mmk
<kent> zyga, what do you meen "incompatible"? 
<elmo> E: Build-Depends-Indep dependency for gcc-4.0 cannot be satisfied because no available versions of package doxygen can satisfy version requirements
* elmo looks at doko
<elmo> hmm, IWBNI if apt-get had a "do the best you can" for 'build-dep'
<doko> we do have doxygen 1.4.0 ...
<elmo> it's 1.4.1
<elmo> doesn't matter, I'll do it manually as best as breezy can
<elmo> (it's 1.4.1 in the build-deps, I mean)
<zyga> kent: not sure what exactly really, something like many rpm based distros are not compatible and packages built for one will fail on other
<doko> ahh, ok, I remember, yes there are some formatting fixes for the docs, but that should not hurt now ... I'll downgrade the build-dep.
* pitti can already smell the support for encrypted storage in Breezy
<kent> zyga, I would not worry if I was you. If you are not even sure what you are worrying about, then you should just relax.  And as for slashdot,  dont belive everything ;)  There is always a bit of problem using packages built for another distro, and if problems arive, they will be solved :)  And I think its more a problem for rpm-based distros since they dont have their own universe like ubuntu. 
<zyga> kent: I don't believe everything I read on slashdot but I thought it would be wise to ask anyway ;-)
<elmo> boggle - an interactive prompt
<elmo> during an install.  how very... debian.
<elmo> Installing new version of config file /etc/locale.alias ...
<elmo> /var/lib/dpkg/info/locales.config: line 435: syntax error: unexpected end of file
<elmo> jbailey: ^---
<elmo> Preparing to replace locales 2.3.2.ds1-20ubuntu13 (using locales_2.3.5-0ubuntu1_all.deb) ...
<elmo>  libc6-dev depends on linux-kernel-headers (<= 2.6.11.2-0); however:
<elmo>   Version of linux-kernel-headers on system is 2.6.11.2-0ubuntu1.
<elmo> doko: ^--
<jbailey> elmo: /me checks. =(
<theine> does anybody know how to update a thinkpad's bios without windows?
<jbailey> elmo: Ugh, that doesn't fail the install.  I must've missed it before.
<kent> zyga, Im realy not the right one to answere, but I dont think there is a need to worry. If for example, som package wont be able to be used on both Debian and ubuntu, people will make a package for ubuntu and one for debian. Its nothing that cant be solved.
<zyga> kent: the last statement is flawed
<zyga> kent: this is exactly why you have problems with rpm distros, one package for fedora 2, one for mandrake 10, and no packages for everything else  
<zyga> kent: I don't want to exagerate threat to ubuntu (I'm just asking) but I certainly do not agree with you on that
<\sh> can I setup a pbuilder enviroment for two distributions? 1. hoary and 2. breezy?
<crimsun> yes
<stratus> \sh, yes but you can go with debootstrap, dchroot and family too.
<kent> zyga, the only problem i can see is the people who starts to whine becaus some one else have not done their job for them. And i dont meen that that person is you in any way, i just meen that it should not be a big problem to solve, and there for its not a *problem* at all.
<\sh> in this moment I thing dchroot enviroment is better?
<\sh> -g+k
<zyga> kent: I agree on the whining part ;-)
<kent> zyga, but ok, you might have a point about rpm-based distros. But personally I have had no problems this fare, so i see now point in worrying until i do. :)
<\sh> stratus: well....u have the actual breezy files for deboostrap?
<zyga> kent: I came to ubuntu exactly because of this
<stratus> \sh, no sorry.
<theine> wow, debootstrap is nice!
<\sh> ok..then from hoary chroot to breezy ;)
<zyga> anyone who maintains g-a-i around?
<pitti> elmo: in theory, if I would upload a security update with a new package, this would land in NEW. are there any problems that could happen?
<mvo> zyga: well, I hacked on it :)
<zyga> mvo: why does it maintain separate .desktop files?
<zyga> mvo: (and outdated too)
<mvo> zyga: because it needs the information from packages that are not installed (and therefore have no dekstop file on the installed system)
<elmo> pitti: should be fine - will require me to NEW it, but other than that, no
<pitti> elmo: okay, thanks
<zyga> mvo: any chance to pull up-to-date .desktop files from the web?
<mvo> zyga: yes, a planed feature. we need a tool that can extract them automatically
<zyga> mvo: well it is pretty easy to write a shell script to do that
<zyga> mvo: run it nightly on some server but where?
<mvo> zyga: what we plan now is to extract them and put them into a deb package (g-a-i-data or something). I don't think it's very importend to have them in a seperate index file
<zyga> mvo: if you want I can write you one but I'm sure that would be nothing you cannot do :)
<mdz> thom: I need to edit fields.html for bugzilla on macquarie; can you find out where it is and grant me permission?
<zyga> mvo: are you not afraid of one bloated binary package that will be changing over and over just because someone changed/added an icon?
<ogra> zyga, that doesnt happen this easy in the supported set
<mvo> zyga: I don't think it's a big issue. we don't want too many desktop files in that package, otherwise g-a-i will become to crowded. and getting the desktop files from the web will lead to new problems. we either need a index file with all packages or we need a tarball (and then we can go with a package as well)
<ogra> (changing apps or icons)
<zyga> ogra: good point about the supoorted set
<zyga> I'm wondering wether I should use some pre-packaged icons or really extract all info from .desktop files and track their locations
<tortoise_> there's a patch here: http://primates.ximian.com/~sandino/python-glade/#main that gives glade the abilty to create python applications, would it be possible for this to be merged into ubuntu since it is python centric.
<zyga> (Still trying to add icons to u-m)
<dholbach> hey
<ajmitch> hey dholbach 
<dholbach> hey ajmitch 
<mvo> tortoise_: what advantage does it have over using pythons libglade?
<lamont> doko/jbailey/elmo: do I have a cookbook for bootstrapping toolchains yet?
<tortoise_> mvo: it's much easier!
<mvo> zyga: we probably need a common package with the desktop files for g-a-i and u-m
<jbailey> lamont: I'm pausing for food atm.  elmo found one typo and a merge error.  The typo was easy to fix, the merge error I don't see yet.
<lamont> jbailey: ah, ok.
<zyga> mvo: that will keep all unsupported apps from being pretty in u-m
<zyga> mvo: I was thinking about adding a few tabs
<lamont> so y'all will give me a 'build these things and install them, in this order' list?
<zyga> one would list applications (from user's point of view) - with icons and descriptions
<jbailey> lamont: We have a glibc and a gcc to go in for ppc so that ppc64 can be built.  The rest of it doesn't need manual help.
<zyga> other would list libraries (and a list of applications that use them in the details tab perhaps)
<zyga> and the last tab would contain all other updates
<zyga> 99% users will only look/care at the application tab IMHO
<lamont> jbailey: given that _nothing_ is building on breezy now, if I just kick everything free, then bunches of stuff will be built using the hoary gcc... you're saying that's OK?
* lamont expects to at least want to build/install gcc-4.0 and glibc before opening the flood gates.
<jbailey> lamont: Ah, I thought that mdz's message last night meant things were building.
<doko> lamont: do you need a cookbook? we only need it for ppc64, if at all
<jbailey> lamont: But that would explain why I haven't seen the new linux-kernel-headers show up in your build logs yet. =)
<lamont> source uploads are piling up, pending me getting told how to get the toolchain into the right state for said floodgate opening
<\sh> nice my chroot is working
<lamont> doko: so gcc-3.3 is fine for i386????
<mvo> zyga: having icons for most applications in universe will probably get a bit big :)
<jbailey> lamont: Do you need to be handed the source code, or can I ask you to start with the linux-kernel-headers that I've already uploaded?
<doko> lamont: just build 4.0, then I'll have to upload a new gcc-defaults
<zyga> mvo: yes but since u-m cannot install new packages users will most probably already have an icon already
<lamont> that's the sequence of steps I want... when does linux-kernel-headers build? before or after gcc-4.0, etc, etc.
<mvo> zyga: very good point
<lamont> or is it really just 'build gcc-4.0, install that, force the symlinks to happiness, and open the gates'?
<lamont> (except on ppc, where more handholding is needed)
<jbailey> lamont: It's a prerequisite to the new glibc, it should be built now.
<zyga> mvo: and that bring us back to the point of choosing correct icon, bleh
* zyga goes back to api reference
<lamont> jbailey: does it care what compiler it gets built with?
<doko> lamont: glibc's GCC version is hardcoded in the glibc sources, so it does not matter ...
<jbailey> lamont: Nope.
* lamont goes to make sure that (a) it won't autolaunch, and (b) build some breezy chroots
<jbailey> doko: After that, should we install glibc and gcc-3.4 into the ppc chroot, and build glibc?
<mvo> zyga: we cheat in g-a-i, we have a x-package-name or something to make the mapping work
<crimsun> doko: question regarding BreezyToolchainTransition: In the "Time Line" section, you mention " Upload build-essential version 11, depending on g++ (>= 4:4.0)". Is that g++ supposed to be gcc, or are we truly going gcc-4.0 and g++-4.0 ?
<doko> jbailey: hmm, I'd like to start a gcc-4.0 build first, tomorrows is my last work day before UDU
<zyga> mvo: I've noticed that (vimdiff)
<jbailey> doko: That works for me.
<jbailey> I haven't read my gcc-ml yet.  Did they do rc2 already?
<zyga> mvo: I don't like that solution really 
<zyga> ok really back to api now
<lamont> jbailey: so breezy should get linux-kernel-headers_2.6.11.2-0ubuntu1 built against hoary toolchain.  objections from you, elmo, or doko?
<lamont> building then
<doko> crimsun: good point, maybe we'll have two the b-e version bump not before g++-4.0 becomes the default
<lamont> doko/jbailey: l-k-h on ppc too?
<Kamion> lamont: does l-k-h even use a compiler during the build?
<doko> lamont: yes, we should
<Kamion> only for the test suite apparently
<lamont> Kamion: dunno - just being pedantic
<lamont> building on all 3
<lamont> and uploaded on all 3.
<lamont> jbailey: you will have lkh at :33
<fabbione> lamont: did you get the toolchain build order?
<lamont> fabbione: they're pretending to give it to me here and now
<lamont> fabbione: so far it's: build/upload linux-kernel-headers
<fabbione> lamont: thanks
* lamont waits for the doko/jbailey illuminati to tell him what to build/upload next
<fabbione> is that an arch: all package?
* dholbach giggles at lamont
<lamont> fabbione: no
<fabbione> lamont: ok
<lamont> fabbione: in fact, there is no arch: all deb in the build
<fabbione> nah i was wondering of the resulting deb was an arch all
<doko> lamont: gcc-4.0
<doko> then let jbailey return from lunch
<zyga> mvo: hmm this stinks pretty much
<jbailey> lamont: Thanks.
<lamont> doko: curiosity: does -mtune=pentium4 -march=i486 do the right thing, or does the -march override the -mtune?
<zyga> mvo: IconTheme.load_icon needs icon name, first package I've tried has filename (which is probably not the same thing) instead
<jbailey> doko: Are you doing gcc-4 rc1?
<lamont> doko: ppc as well, or !ppc?
<lamont> zyga: wrt the slashdot incompatibility thing... ubuntu has always maintained that you should not mix-n-match binaries from more than one distro: to do so is "fraught with peril" - that's why we have universe.
<pitti> night everybody
<lamont> night pitti
<fabbione> bah
<fabbione> l-k-h is FTBFS
<fabbione> that's a good start
<zyga> lamont: I was more worrying that ubuntu chooses some deeply incompatible (or simply different) way to do something fundamental
<doko> lamont: the curiosity does the right thing
<azeem> I think the problem is rather that independent developers will have to start building packages for both Debian and Ubuntu. Or worse, keep two source packages around.
<lamont> doko: coolness
<lamont> doko: so.. doxygen...
<jbailey> fabbione: On Sparc?
<fabbione> doko: l-k-h bugs to you or jbaley?
<fabbione> jbailey: yes
<lamont> to I just build doxygen_1.4.2-1 with 3.3, or what?
<jbailey> fabbione: To me.
<lamont> (gcc-4.0 is dep-wait)
<doko> yes, I need to change it ...
<jbailey> fabbione: I need access to a sparc to do the cleanups (although I can guess what they might be)
<lamont> you need to change it, or we should just build the current doxygen and get on with life?
<doko> or sync doxygen first ...
<lamont> doxygen is sync'ed, but we've not built it yet
<lamont> any issue with building it?
<doko> no
<lamont> ok
<lamont> and gcc-4.0 build on ppc, or no?
<fabbione> jbailey: can you give me an ETA to get it fixed?
<fabbione> jbailey: take into account that more time it passes less hopes there are for sparc to make breezy
<jbailey> fabbione: Any possibility of getting a chroot?
<fabbione> jbailey: yes, send me a ssh pub key
<doko> lamont: yes, ppc is ok, we don't need biarch on the first upload.
<lamont> doxygen building on all 3
<fabbione> we lost hoary thanks to doko fucking up gcc-4 build-dep for 2 days
<fabbione> jbailey: ^^
<doko> fabbione: ?
<fabbione> doko: never mind.. steaming down
<fabbione> :)
<fabbione> doko: you forgot to bump a versioned build-dep in gcc-4 for hoary
<fabbione> making basically going sparc out of sync for 2 days
<fabbione> (2 rebuils of gcc-4)
<fabbione> = no sparc for hoary
<doko> fabbione: sorry, which one?
<fabbione> it was a libcairo something
<doko> oops, I remember ...
<dholbach> good night
<fabbione> doko: yes.. i told you a couple of times.. :(
<maswan> Mithrandir: yes?
* lamont waits for :03 so he can kick gcc-4.0 again
<fabbione> lamont: are you taking notes of what needs to be done? :)
<fabbione> lamont: sparc is going to lag :)
<doko> elmo: breezy-chroot-ppc64, dpkg-checkbuilddeps: Unmet build dependencies: libc0.3-dev (>= 2.3.2.ds1-19) | libc0.1-dev | libc12-dev (>= 2.3.2.ds1-19) | libc6-dev (>= 2.3.2.ds1-19) libc6-dev-ppc64 doxygen (>= 1.4) graphviz (>= 2.2)
<doko> dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
<doko> dpkg-buildpackage: (Use -d flag to override.)
<jbailey> doko: You're waiting on a fixed glibc.
<doko> doxygen and graphviz, fine, but libc6-dev and libc6-dev-ppc64 ?
<doko> I do?
<jbailey> doko: I've tracked down the bug that keeps you from being able to install it, I haven't tracked down the locales.config bug yet.
<lamont> fabbione: yes.  hppa is also very laggy right now
<jbailey> doko: Yes.  I made a typeo and depended on linux-kernel-headers (<= 2.6.11.2-0)
<fabbione> lamont: ok thanks..
<fabbione> lamont: jb is taking a look at l-k-h.. i guess without that one we can't do anything
<lamont> jbailey: should I expect hppa b0rkage in lkh as well?
<fabbione> lamont: probably..
<fabbione> give it a shot.. it's the only way
<fabbione>  /build/sparcbuildd/linux-kernel-headers-2.6.11.2/debian/linux-kernel-headers/usr/include/asm-sparc/posix_types.h:38: warning: ISO C90 does not support `long long'
<jbailey> lamont: Yes, probably.  I'll take a quick pass and guess where the culprits will be.
<fabbione> lamont: these are the kind of error i am seeing
<jbailey> fabbione: It's the testsuite we have.
<fabbione> jbailey: yeps.. i could see that
<lamont> doko: after gcc-4.0, then what? (not that I'm there yet, mind you...)
<jbailey> Bah, found the pasto.
<doko> gcc-defaults, have to downgrade g++ to 3.3 ...
<lamont> doko: that source is there, just needs to be built?
<lamont> note that we never built a gcc-defaults that uses 4.0, to date... :-)
<lamont> gcc-defaults 1.21?
<Mithrandir> maswan: read dmesg on ravel
<jbailey> Need a little bit of time for ppc glibc to build to hand you, afk while it's doing that.
<fabbione> jdub: ping?
<lamont> jbailey: who was that last to?
* zyga wants win32 style icons embedded in binary files for a moment
<Mitario> hello everyone
<Goshawk> should a library name be: libNAME-VERSION-SONAME ? (for the policy)
<lamont> Total 4360 package(s) in state Installed.
<lamont> Total 2469 package(s) in state Needs-Build.
* lamont cries
<fabbione> lamont: that's about right :(
* MOTU comforts lamont
<lamont>  grep ': Needs-Build' zz.i386 | grep -v iverse/ | wc
<lamont>     285     855   17276
* lamont giggles at MOTU
<mdz> Goshawk: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
<ogra> :-P
<jordi> Goshawk: depends
<jordi> sometimes it needs to be libnameVERSION-SONAME
<jordi> depends on the lib
<Goshawk> ok thanks
<\sh> oh shared libs...yeah its my special ;)
<zyga> \sh: really? I thought it was compatibility shell programming ;] 
<ajmitch> \sh: recovered from your ordeal then? :)
<\sh> hehe
<\sh> after playing 18 around with one shared lib ;) 
<\sh> i tried everything even to make an autotools package out of it ;)
<\sh> but right now, i will go to bed...have to do some serious things tomorrow morning
<\sh> g'night folks...have fun :)
<ogra> night \sh 
<ajmitch> night
<blahrus> might be posted some where, but has breazy devel been started?
<zyga> blahrus: seems so but you might want to hear the same thing from someone more knowledgable
<blahrus> zyga: not really, just wanted to know i I could update  my sources and start fallowing the build and watch for bugs
<zyga> blahrus: what sources are you reffering to?
<Kamion> blahrus: yes, it has been started, and see ubuntu-devel@; no, it's not useful yet (still bootstrapping the kernel)
<Kamion> er, not the kernel, the toolchain
<Kamion> blahrus: it will be VERY VERY UNSTABLE for a bit
<blahrus> Kamion: cool, just wondering didn't want to rush the guys :)
<Amaranth> did the toolchain stuff get figured out?
<Kamion> Amaranth: looks like it's in progress
<Kamion> me, I'm busy resolving the enormous installer merge :P
<Amaranth> d-i changed that much?
<Kamion> lots of mostly small changes on both sides
<Kamion> plus some changes that were made identically on both sides and then intermixed with nearby different changes on both sides so that patch can't tell that it's just an already-applied diff
<Kamion> this is only in the build system and manual, mind you
<KaiL> ..here :)
<KaiL> any developer around? I have 2 small ideas to make ubuntu a lot better.....
<lamont> doko?
<lamont>  /bin/sh ../../src/gcc/../move-if-change tmp-attrtab.c insn-attrtab.c
<lamont> cmp: tmp-attrtab.c: No such file or directory
<lamont> mv: cannot stat `tmp-attrtab.c': No such file or directory
<lamont> make[6] : *** [s-attrtab]  Error 1
<lamont> make[6] : Leaving directory `/build/buildd/gcc-4.0-4.0ds11/build/gcc'
<lamont> make[5] : *** [extra32]  Error 2
<lamont> (amd64)
<fabbione> yay
<KaiL> ..it's about packaging :)
<KaiL> 1. add the kernel-headers as default
<fabbione> KaiL: i think it's better you mail ubuntu-devel
<KaiL> 2. create binary packages for ndiswrapper
<Kamion> KaiL: 1. has been discussed a number of times and decided against
<kent> btw, home come i saw some where today that debian released som RC of its installer, is it not the same ubuntu is using? And is then ubuntu using an installer which debian dont treat as final?
<Kamion> it's on the CD
<lamont> Kamion: working on modutils - just need to see what else is b0rken
<Kamion> kent: it's rather more complicated than that
<KaiL> Kamion: why against?
<Kamion> KaiL: please see the archives
<Kamion> KaiL: the headers are on the CD as a compromise
<KaiL> compromise..?
<Kamion> kent: yes, it's the same; the reason that it's not final is (nowadays) not to do with the installer but to do with the rest of Debian
<KaiL> for around 99% of all wlan users not having them on the CD would make ubuntu totally useless!
<Kamion> KaiL: we don't want to install it by default (bloat, lowest-common-factor arguments, etc., all in the archives), but we include them on the CD so that people who need them have them
<kent> Kamion, becaus debian wants it to be known to work for all the platforms in the world before they treat it as "final", right?
<Kamion> kent: no, you're missing the point
<Kamion> kent: the Debian installer's perfectly fine, it's just that the rest of Debian still needs more work before going stable
<KaiL> and there we come to the binary ndiswrapper.. that would shorten the list of people requireing headers a lot
<kent> Kamion, ok. thanks
<Kamion> kent: the installer has worked on all architectures for something like a year now.
<Kamion> (to varying degrees of workingness over time)
<doko> lamont: pong
<Kamion> KaiL: we already have the ndiswrapper-utils binary package, which is on the CD.
<KaiL> Kamion: that doesn't help to get it working :)
<fabbione> KaiL: we can't ship the binary blobs
<fabbione> the support is there
<fabbione> that's all we can do
<lamont> doko: you saw the gcc-4.0 amd64 issue?
<kent> fabbione, binary blobs? whats a blob? :)
<Kamion> KaiL: people with such cards will usually have CDs shipped by the manufacturer containing the driver they need
<fabbione> kent: ehehe
<doko> lamont: no, only fabio's comment ...
<KaiL> fabbione: if you do a module-assistant on ndiswrapper, you get a .deb
<Kamion> KaiL: dude, ndiswrapper.ko is in our default kernel package
<fabbione> KaiL: and why do you need to do so when the default ubuntu kernel ships ndiswrapper?
<KaiL> it is?
<Kamion> -rw-r--r-- root/root    132844 2005-04-05 14:40:39 ./lib/modules/2.6.10-5-386/kernel/drivers/net/ndiswrapper/ndiswrapper.ko
<KaiL> aha...
<Kamion> (true in warty as well)
<fabbione> and it will be true in breezy too
<KaiL> didn't know - so forget my lines....
<KaiL> only one point left: isn't 1.1 already released? :)
<fabbione> KaiL: it will in a few days. it's already merged in the ubuntu kernel tree
<KaiL> cool
<blahrus> crimsun: you around?
<KaiL> this really reduces the requirement for linux-headers
<KaiL> oh, and a new line for the FAQ: "where is package XYZ?" "enable universe in /etc/apt/sources.list" :)
<mkde> elmo, thanks for that docteam thing
#ubuntu-devel 2006-04-17
<Seveas> omg
<Seveas> who messed with the defaut background? 
<mdke> what's happened to it?
<Seveas> it's so funny - let's wait or all mailinglist people to get upset again
<Seveas> mdke, someone painted in it
<mdke> screenie?
<Seveas> http://paste.ubuntu-nl.org/12055
<mdke> hmm
<Burgwork> hmm, indeed
<mdke> i bet it's "joker" holbach
<Burgwork> might be nice to have a lighter background by default
<mdke> I like a dark one myself, I've been using dapper.png, very nice
<Burgwork> I had one person descibe the current breezy background as "diving down an endless void:
<Burgwork> "
<Burgwork> Seveas, what is that orange bar thing that the top?
<Seveas> Burgwork, the new netstatus applet icon
<Seveas> pretty fugly
<Seveas> but a better one has been promised
<Burgwork> haha
<mdke> Seveas, I haven't had a netherlandish translation of the browser start page, if you fancy the task
<Burgwork> somebody has already complained on ubuntu-devel
<LaserJock> lol
<Seveas> mdke, just replied to your loco-contacts mail
<ajmitch> Burgwork: are you at all surprised?
<mdke> it's quite a sensible complaint
<Burgwork> ajmitch, at this point, never
<mdke> Seveas, ah cool
<Burgwork> good thing the final artwork will be in by the Beta release
<ogra> jordi, do you happen to be around ? 
<ogra> anybody here with a powerpc on dapper who has flickering GL screensavers and would like to test a fix ? 
<ogra> (got no other machine around to build a testpackage, sorry)
<Burgwork> LaserJock, do you just have Mactel?
<sladen> ogra: I can test it from source if you have a debdiff
<LaserJock> Burgwork: yes, for mac
<Burgwork> LaserJock, ah
* LaserJock has never touched a ppc ;-)
<Burgwork> my ex has one, but I doubt she would let be put Ubuntu on it
<ogra> sladen, http://people.ubuntu.com/~ogra/gss/
<ogra> there is the source ...
<sladen> at least she's not your ex-, because you *did*
<Burgwork> sladen, got one of those, do you?
<mdke> Burgwork, that's a yes
<mdke> night all
<LaserJock> cya mdke 
<sladen> ogra: the patch is a bit hackish, but it works.  Shall I upload it?
<ogra> can you add the "closes malone blah" ? 
<ogra> else, sure, lets get that out asap :)
<ogra> i'm happy it circumvents the adding of a GL dependency to gss
<infinity> bddebian: ygraph is FTBFS on all arches -- https://launchpad.net/distros/ubuntu/+source/ygraph/0.15-2ubuntu1
<lifeless> is booting from lvm supported these days ?
<lifeless> ... with grub ?
<ajmitch> lifeless: not that I'm aware of
<lifeless> ajmitch: shame. thanks
<womble> lifeless: No.  Definitely not.
<OrionUser> does ubuntu support Via chipsets?
<HrdwrBoB> ... yes, and this is the wrong place to ask
<HrdwrBoB> try #ubuntu
<OrionUser> i know.... but...
<OrionUser> dude, if they don't know all, you will!!!
<HrdwrBoB> a) it's a stupid question, via are one of the most popular chipset manufacturers
<jamesh> OrionUser: if you try to turn this channel into #ubuntu, the developers will just move important discussion elsewhere
<infinity> Yes, and if every user decides their question is so important they they need to ask the developers directly, we'd never have time to develop a distro for you.
<HrdwrBoB> b) you should try it first, then ask
<OrionUser> ok ok
<HrdwrBoB> c) you should at the very least ask #ubuntu first
<OrionUser> (you , discuss important stuff, ill try not to comment)
<dAndy> Anyone know if apt-get is multi-threaded?
<infinity> dAndy: Context?
<sladen> orionuser: and if it didn't work, file a bug report...
<infinity> dAndy: It can download from multiple sources at once, which is about all the multi-anything you would ever want it to do.
<dAndy> infinity: I tried to strace it (I am getting "connection reset by peer" from my mirror, and am trying to figure out whos fault it is)
<dAndy> infinity: the strace seemed... odd at best
<infinity> You probably want strace -f
<infinity> I suspect the download processes are forked children.
<infinity> Though just a guess, you'd have to look at the code, or ask mvo to be sure.
<dAndy> ah ok cool, that will probably do it
* dAndy also notes that in the trace I just got, apt did gettimeofday() more than 23000 times, that seems odd
<infinity> What?  You've never sat there nervously checking your watch over and over again before? :)
<dAndy> heh, I guess
<sladen> dAndy: it has to update the spinner.... :)
<dAndy> ugh... strace -f makes it both better and worse, this is confusing, it appears to use pipes to communicate to the children or something
<dAndy> hmm, fantastic, as far as I can tell from the trace, it never actuall sends a GET for the package that failed
<infinity> dAndy: Well, it won't send a GET if it can't connect..
<mroth> mjg59: question re: your comment on bug 35174.  by 'next kernel update' do you mean ubuntu packaging of 2.6.15-21, or do you mean upstream 2.6.17 in kernel?
<Ubugtu> Malone bug 35174 in acpi-support "ThinkPad X60 cannot resume from sleep/hibernate" [Normal,Needs info]  http://launchpad.net/bugs/35174
<dAndy> infinity: the webserver receives the GET, sends the file and closes the connection normally
<sladen> ogra: I got that patch down from 208kB to 10kB and nuked most of the automake bollocks
<mjg59> mroth: 2.6.15-21
<mroth> mjg59: i was hoping thats what you meant ;-)
<mroth> mjg59: anything you want me to test from kernel-source prior to that point to help catch stuff early?
<mjg59> mroth: If you're happy building kernels, I have a couple of patches
<mroth> mjg59: i wouldnt say I'm HAPPY doing it, but i can probably muddle through
<mjg59> mroth: Grab the files from http://www.codon.org.uk/~mjg59/tmp/sata
<mjg59> The patch applies against 2.6.15-20, the .c file gets copied into drivers/scsi
<mroth> mjg59: i assume the patch should only affect hibernate, not the 'sleep' problem
<mjg59> mroth: No, should help sleep
<mjg59> I suspect hibernate problems at this point are probably X being unhappy, which is kind of hard to fix with the vesa driver
<mjg59> But we'll see
<mroth> this compile will be the first processor intensive thing i've done on that machine, time to test out the core duo and see if it lives up to the hype
<LaserJock> mjg59: that reminds me, how is the Intel mac work going?
<jdub> mjg59: http://people.ubuntu.com/~jdub/2006/ubuntu-zh.png
<mjg59> LaserJock: About as far as it can get until we can produce HFS+ filesystems
<mjg59> That is, stuff works (including the installer), but there's no way to boot it...
<bddebian> infinity: OK, I'll check it out, thanks
<mjg59> jdub: Very disturbing
<mjg59> Anyway
* mjg59 goes to get dinner
<Keybuk> mjg59: dinner?! what country are you in?
<LaserJock> jdub: nice
<LaserJock> mjg59: ok, thanks for the update
<Keybuk> jdub: doesn't Malcolm look decadent
<bddebian> infinity: Fixed ivtools yet?
* bddebian hides
<bddebian> Uhm, WTF is that
<bddebian> infinity: There?
<infinity> Ish.  On an international call.
<bddebian> I think ygraph just needs an autoreconf, etc.  How do I do that properly for a package?
<mroth> mjg59: my kernel compile was aborted on /usb/net/zd1211/zddevlist.h  for some reason
<mroth> since my assumption is the kernel-source package woudl compile cleanly with no changes made to the config, is this perhaps related to that patch you sent?
<terl> finally! I Have Ubuntu(and Im emulating it in Vmware player on windows!)
<bddebian> Uhm, shouldn't that be the other way around? :-)
<jsgotangco> hrmm
* sladen hands otavio[off]  an /away
<bddebian> aaaahhh
<bddebian> infinity or fabbione: ping?
<infinity> pong.
<bddebian> x11proto-gl-dev replaced xlibmesa-gl-dev?
<Keybuk> what's that word where something is guaranteed to never occur?
<Keybuk> assertion!
* bddebian kills himself
<LaserJock> Noooooo
<infinity> bddebian: No, no, no.
<infinity> bddebian: You want libgl1-mesa-dev
<infinity> bddebian: x11proto-gl-dev is just the wire protocol, has nothing to do with the GL libraries.
<bddebian> I have that but it doesn't give GL/GLwMDrawA.h that xlibmesa-gl-dev provided afaict
<infinity> Is that in x11proto-gl-dev?
<infinity> If so, I suspect libgl1-mesa-dev should be depending on the wire protocol headers, but isn't.
<bddebian> No, but apt-getting xlibmeas-gl-dev said x11proto-gl-dev replaces it :-)
<infinity> You don't understand what "Replaces" means, then.
<infinity> (It means A overwrites some files from B, nothing more)
<infinity> Anyhow, we had no xlibmeas-gl-dev in breezy either, so you're pretty seriously out of date. :)
<bddebian> Well I knew that but I'm getting all fscking confused.. :'-(
<infinity> Right, well, we shipped no GLwMDrawA.h in breezy at all, and most likely don't in dapper either.
<infinity> Whether or not that's a bug, I still need to decide.
<bddebian> It might not be but xmakemol is looking for it :-(
<infinity> Well, we don't ship libGLw at all, so I can't see what good the headers would do.
<bddebian> Do you care that you are going to make me cry? ;-P
<infinity> Oh, wait.  Hold on.
<infinity> No, we really don't.
<infinity> Yay for us.
<ajmitch> excellent
<infinity> When we did, we only shipped it as a static lib.
<ajmitch> how evil
<infinity> So, xmakemol was linking statically to libGLw.a, or it includes the header but then doesn't use it.  Which one is it?
<infinity> I'd rather not reintroduce static-only libraries if we don't have to.
<bddebian> I think it's BS in xmakemol, but I'm not sure yet.  Here's the line of code:  
<bddebian>   /* aro - might not be necessary if using mesa+linux */
<bddebian> #ifdef GL
<bddebian> #include <GL/GLwMDrawA.h>  /* OpenGL drawing area widget */
<bddebian> #endif /* GL */
<infinity> Easy enough to find out.  Remove that, compile it, see if it links, then see if it runs.
<bddebian> Yeah, I haven't gotten that far yet
<infinity> If you really need it, I can turn it back on, but I'd really rather not.
<bddebian> Well I don't "need" it, I'm just trying to bugfix. :-)
<sladen> infinity: while you're around, where did  /proc/bus/pnp  go?
<fabbione> can somebody please explain to me #24817?
<Keybuk> sladen: replaced by /sys/bus/pnp ?
<fabbione> how do i select "share"?
<Keybuk> sladen: in general, /proc/bus/ANYTHING is bad and should go and die now
<infinity> sladen: Like I know.  I don't even have any ISA cards.  But listen to Keybuk. :)
<sladen> Keybuk: /sys/bus/pnp is a bit empty
<Keybuk> in fact, if you're using /proc/[^0-9]  you'll probably get a shock in the upcoming kernel releases
<Keybuk> sladen: update your kernel
<Keybuk> sladen: mjg59 broke it because he wants the whole world to use mactel
<fabbione> never mind
<Keybuk> (kernel pnp subsystem broken by pnp acpi changes)
<Keybuk> infinity: yes you do
<sladen> Keybuk: nice of him.  feh.
<Keybuk> infinity: there's one sitting on your southbridge, taunting you
<Keybuk> sladen: is fixed in current dapper
<sladen> infinity: you have tonnages of pnp.  try on 'lspnp', oops that won't work
<infinity> Keybuk: Okay, okay, I like to pretend the legacy ports don't exist.
* sladen watches the pretty pink piggies flying over head
<Keybuk> sladen: I'm sure I saw a version of lspnp that had been updated somewhere
<calamari> hi
<sladen> calamari: hi.  very nice of you to pop in.  the weather is wonderful don't you think, perhaps we could have a picnic
<calamari> sladen: hehe, kinda dark out, maybe tomorrow?
* bddebian subliminally suggests ivtools to infinity and hauls his antique ass to bed
<bddebian> Gnight folks
<bddebian> Hmm, well apparently xmakemol really wants that stupid header..
<bddebian> ../xmakemol.c: In function main:
<bddebian> ../xmakemol.c:219: error: glwMDrawingAreaWidgetClass undeclared (first use in this function)
<bddebian> Now I'm REALLY going to bed..
<fabbione> infinity: do you happen to know what's the gnome package that procides the "Share Folders" menu in System -> Admin
<infinity> fabbione: system-tools-backends
<mjg59> mroth: Ah. Install gawk and delete that file, then retry the build
<mjg59> (stupid zd1211)
<mjg59> Keybuk: US
<fabbione> infinity: thanks
<mjg59> sladen: Uh, yes. pnp has lived in sysfs for a while. cat /sys/bus/pnp/*/id
<Keybuk> mjg59: what you doing over there?
<mjg59> sladen: Sorry, cat /sys/bus/pnp/devices/*/id
<mjg59> Keybuk: Linux power management summit
<Keybuk> mjg59: fun?
<mjg59> Keybuk: Starts in the morning
<mjg59> I currently think it's 6AM and all my joints ache from being stuck in economy for 11 hours
<sladen> mjg59: doing that lists 1 device.  and not the other 20
<Burgundavia> mjg59: where in the US are you?
<mjg59> sladen: Without knowing what hardware you have, I'm afraid I can't really comment further
<mjg59> sladen: (And no, the change isn't anything to do with me)
<mjg59> Burgundavia: Santa Clara
<Burgundavia> hmm, California
<mjg59> It's damn wet here
<jsgotangco> heh
<neuralis> mjg59: wrong end of the country. if you wind up at the other side, appreciation for your laptop work will be demonstrated in beer form.
<mjg59> neuralis: Probably not for a year at least, but noted :)
<dholbach> good morning
<Burgundavia> hmm, Fedora is not planning a single install cd, nor resizing in the isntaller
<pitti> Good morning
<dholbach> heya pitti!
<pitti> hi dholbah
<pitti> and dholbach, too :)
<dholbach> :-)
<Keybuk> morning berpitti and dhugbach
* dholbach hugs Keybuk
* Keybuk hugs back
<pitti> hey Keybuk 
* pitti hugs Keybuk 
<lamont> pitti: you saw that I fixed a belocs-locales-bin bug, yes?
<LaserJock> womble: ping?
* Keybuk hugs pitti 
<Keybuk> I still haven't fixed my bugs :-(
<LaserJock> womble: unping
<pitti> lamont: yes, I read it on -changes
<pitti> Keybuk: do you hope to ever fix them all? :)
<Keybuk> pitti: yes. all the bugs.
<Keybuk> all bugs will be fixed
<Keybuk> By Order
<_ion> Beginning with #1?
<_ion> That would be nice.
<pitti> Keybuk: it would be interesting to see if the process of bug fixing converges to 'bug free' in infinite time :)
<pitti> so far we seem to get more bugs than we fix
<robitaille> we should request for LP to have a nice graph of bugs versus time to see how good/bad we are doing
<Burgundavia> pitti: 100+ a day
<Burgundavia> new, that is
<Keybuk> SHIT KEEPS FALLING!
<robitaille> Burgundavia: we have actually ~300 less open bugs than 2 weeks ago.
* robitaille blames it on too much bug triage :)
<Burgundavia> far far too much
<Burgundavia> we are trying to pass the 10k mark
<ajmitch> robitaille: that request was put in months ago :)
<ajmitch> bug #2633
<Ubugtu> Malone bug 2633 in malone "Graphing & reporting of bug activity" [Wishlist,Confirmed]  http://launchpad.net/bugs/2633
<robitaille> anyone knows if there is a way to find the exact version of a Daily Live CD after it has been burned? 
<_ion> keybuk: SHIT = SHIT_0 + v_0 t +  g t
<Keybuk> md5sum
<Keybuk> C6H12O6(s) + 6O2(g) -> 6CO2(g) + 6H2O(g)
* _ion totally forgot that Unicode also contains a subscript zero: 
<_ion> No need for LaTeXish markup in that case.
<robitaille> ajmitch:  thanks.  nice to see that it has already been requested
<Keybuk> hmm
<Keybuk> ooh
<Keybuk> CHO(s) + 6O(g) -> 6CO(g) + 6HO(g)
<Keybuk> almost prettier
<Keybuk> CHO(s) + 6O(g)  6CO(g) + 6HO(g)
<Keybuk> :p
<_ion> :-)
<Keybuk> but can anyone guess what it is?
<_ion> Alcohol? :-)
<pitti> _ion: no, that's C2H5OH
<Keybuk> not even close
<pitti> Keybuk: is it a Benzol ring or a straight molecule?
<Keybuk> pitti: nope, the  should give you a clue you're looking at some kind of change
<pitti> Keybuk: well, you burn something, of course
<pitti> Keybuk: I wondered about what  CHO is
<pitti> Keybuk: could be 'Glucose' (that's the word we use in .de)
<crimsun> starts with an 'r'
<freeflying> pitti: malone #39246
<Ubugtu> Malone bug 39246 in language-pack-kde-zh-base "kdelevop3's mo missed in language-pack-kde-zh-base" [Normal,Unconfirmed]  http://launchpad.net/bugs/39246
<Keybuk> yup
<Keybuk> chemical burning of glucose
<Keybuk> or, to be more poetic, an explosion in a custard factory :)
<pitti> Keybuk: or, less poetic, the process in your body cells :)
<Keybuk> indeed
<pitti> (sure, it's slightly more complicated than that, but the final result should be that)
<pitti> crimsun: 'r'?
<infinity> Keybuk: I'm puzzled by your last sysvinit upload.  Or I'm misreading the changelog..
<Keybuk> infinity: what puzzles you?
<crimsun> pitti: aerobic respiration
<Keybuk> oh
<Keybuk> heh
<pitti> crimsun: ah :)
<Keybuk> I can see what might puzzle you
<infinity> Keybuk: Are you actually mounting /var/{run,lock} elsehwere, or is this just some "move them somwhere during maintainer scripts" hack?
<Keybuk> during the "LOOK OVER THERE!" hack
<infinity> Ahh, kay.  Fair.
<Keybuk> the one during the boot when we might be mounting /var anyway
<infinity>  /tmp wasn't a good enough playground?
<Keybuk> it upset people with NFS roots that 30 thin clients were all trying to make and remove the /.var.run directory at the same time
<Keybuk> /tmp could be mounted in mountall as a tmpfs
<_ion> Hehe. http://politics.slashdot.org/comments.pl?sid=182776&cid=15106712
<Keybuk> I get the kinds of corner cases that Escher dreamed abouyt
<pitti> freeflying: so, you mean that kdevelop.mo is wrong, it should be kdevelop3.mo?
<Keybuk> "Hey!  I know I parked that mount here somewhere, WHERE'S IT GONE?"
<infinity> Keybuk: And it the user has no devshm?  Are you explicitely mounting it yourself?
<freeflying> pitti: ya
<Keybuk> infinity: explicitly mounted in mountdevsubfs
<Keybuk> of course, I can't just use /dev because they might have removed udev (well, they miiiight)
<pitti> freeflying: hmm, but that's the domain that kde-i18n-* has
<pitti> freeflying: so it seems that this is a kde-i18n-* bug, will reassign
<freeflying> pitti: heh, thx
<infinity> Keybuk: Yeah, but that's not the same script that mounts your stuff.  And init scripts are conffiles.  So, I could rightly say "I don't want no devshm in mountdevsubfs" and then somehow break your var{run,lock} hacks.
<Keybuk> infinity: those people are idiots
<infinity> Keybuk: And it's certainly not obvious to me that disabling the former breaks the latter.
<infinity> Keybuk: It's not intuitive that "not mountind /dev/shm leads to /var/{run,lock} not working"
<infinity> Keybuk: So I'm not sure we can label them idiots for it.
<Keybuk> the directory has to exist for half the system to work ;)
<Keybuk> at least those bits using shared memory
<Keybuk> if it's not mounted, it'd still work
<Keybuk> it just happens to be a conveninent probably-a-tmpfs
<pitti> erm, since when there's no 'Subscribe' item on a Malone bug page any more???
<infinity> Keybuk: Then you should at least make sure the directory is there, if you intend to use it.
<Keybuk> pitti: if you're already subscribed
<pitti> ah, heh, true; thanks, Keybuk 
<Keybuk> infinity: tbh, I don't think I care about this particular case that much :D
<Keybuk> "user edits system startup script and gets broken startup"
<Keybuk> that would go in the great big REJECTED! bin in the sky :p
* infinity shrugs.
<Treenaks> But I have the RIGHT to edit those scripts! They're in /etc!
<infinity> I've not noticed /dev/shm being all that frequently (or at all) used, despite claims it's required.
<infinity> But SysV shared memory is much more common than POSIX shared memory.
<Keybuk> infinity: it isn't that frequently used
<Keybuk> Treenaks: yes, and you get to keep both parts when you break it :P
<infinity> You see a maze of Makefiles, all alike.
<infinity> Your head explodes.
* infinity shakes his head.
<infinity> Hacking Mozilla (well, Thunderbird today) sources always makes me whimper.
<Keybuk> infinity: giggle
<Keybuk> want something funny?
<Keybuk> comment out that /dev/shm line
<Keybuk> boot
<Keybuk> and your computer will still think /dev/shm is mounted anyway
<Keybuk> yay /etc/mtab being utterly unrelated to /proc/mounts
<HrdwrBoB> yes
<HrdwrBoB> that's the most retarded thing ever.
<HrdwrBoB> well... ok, it's not, but it's still stupid
<HrdwrBoB> why /etc/mtab can't be a symlink to /proc/mounts or something similar
<infinity> It is on many people's systems. :)
<Keybuk> HrdwrBoB: /proc/mounts doesn't have some random piece of information someone cares about
<Keybuk> I can't remember what though
<HrdwrBoB> heh, seems to be MORE in mounts
<HrdwrBoB> screek:/home/matt/files /home/matt/movies/downloads nfs rw,addr=203.10.72.160 0 0
<HrdwrBoB> screek:/home/matt/files /home/matt/movies/downloads nfs rw,v3,rsize=32768,wsize=32768,hard,lock,proto=udp,addr=screek 0 0
<Keybuk> mounts appears to be missing the user=scott bit from my removable-disk mount
<HrdwrBoB> though mounts has extra crap and it has / as just 'rootfs' because of the pivot
<Keybuk> pitti would know about that
<HrdwrBoB> but the basic gist is, why the hell is mtab an editable real file
<Keybuk> HrdwrBoB: heh, I thought the only bit of extra crap was /dev/.static/dev and /proc/sys/fs/binfmt_misc ?
<Keybuk> what's wrong with this picture?
<pitti> HrdwrBoB: the last time I tried the symlink, it broke gnome-vfs or so, but I don't remember any more
<Keybuk> (gdb) break apply_blacklist
<Keybuk> Breakpoint 2 at 0x4032f5: file ../modprobe.c, line 720.
<Keybuk> (gdb) run -v -n --first-time pnp:dPNP0800
<Keybuk> Starting program: /home/scott/work/ubuntu/module-init-tools/module-init-tools-3.2.2/build-tree/module-init-tools-3.2.2/obj/modprobe -v -n --first-time pnp:dPNP0800
<Keybuk> insmod /lib/modules/2.6.15-20-amd64-k8/kernel/drivers/input/misc/pcspkr.ko
<Keybuk> Program exited normally.
<pitti> Keybuk: heh, blacklisting isn't called at all? :)
<Keybuk> pitti: indeed
<sivang> morning
<pitti> Keybuk: that's a function I greatly miss in gdb, too: 'Show me why this function was never called' :)
<pitti> hi sivang 
* sivang hugs pitti 
<sivang> mornign Keybuk 
<Keybuk> pitti: wouldn't it be great
<Keybuk> it's probably vaguely possible if you turned on coverage actually
<Keybuk> then it shows you the flow-path through your program
<pitti> Keybuk: well, but it still sounds like 'explain_bug' :)
<Keybuk> oh wow
<Keybuk> modprobe ignores blacklist for aliases in config files
<Keybuk> why the bollocks does it do that?
<jordi> ogra: hrm, I don't have the ppc here
<fabbione> W T H
<fabbione> who did automatically replace my custom desktop background????
* fabbione starts waving his max size cluebat
* _ion whistles while looking innocent.
<sivang> fabbione: I was just as shocked
<Treenaks> fabbione: it's called "branding"
* fabbione wants somebody's head seved on a silver dish
<sivang> Treenaks: branding? :)
<sivang> so that's how they call it these days...
<fabbione> Treenaks: wrong.. that's NOT respecting user setting.. it's a bug...
<Treenaks> sivang: http://en.wikipedia.org/wiki/Brand
* pitti restarts session to find out whether it happens to him, too
<sivang> Treenaks: I thought we already has a brand name, no? :)
<Treenaks> sivang: A name, sure.. but you need to SHOW it, and the logo, to build a brand!
<sivang> Treenaks: hehe
<pitti> fabbione: hm, I got a new splash screen, but my background stayed as it was
<fabbione> pitti: my bg was replaced while upgrading to dapper as 10 minutes ago
<sivang> pitti: I got a new splash screen and a new bg
* _ion takes a look at his ion3 background... Still the same color. :-)
<Yagisan> G'day. Can anyone here reproduce Bug #38060 , it sure would be nice to print in dapper.
<Ubugtu> Malone bug 38060 in gs-esp "es-gsp crashes on various input causing a faliure to print" [Normal,Unconfirmed]  http://launchpad.net/bugs/38060
<dholbach> the file was replaced, ubuntu-artwork-<release> is not done yet
<towolf> salve, against which pkg should i file a bug about my internal modem and usb mouse being dead after resuming from sleep?
<fabbione> towolf: linux-source-2.6.15 if you are running dapper
<towolf> fabbione: wait, i'm seeing two bugs already about the dead mouse
<towolf> fabbione: but i can revive the modem by restarting /e/i/sl-modem-daemon. should that be acpi-support instead?+
<fabbione> towolf: mostlikely yes
<pitti> towolf: oh, I get the dead mouse after hibernate as well
<towolf> pitti: do you use evdev?
<pitti> towolf: that module is loaded, yes
<towolf> pitti: i think you have to voluntarily actiate it in xorg.conf: "driver" "evdev"
<sivang> oh man, http://hardware.slashdot.org/hardware/06/04/11/1655257.shtml
<pitti> ah, bug #34066
<Ubugtu> Malone bug 34066 in linux-source-2.6.15 "usb mouse dead on resume" [Normal,Unconfirmed]  http://launchpad.net/bugs/34066
<Treenaks> Burn your pentiums!
<pitti> towolf: that worked fine in breezy...
<sivang> Treenaks: yeah , scary
<Yagisan> sivang: that has been available since the i386. SMM is just the new name for the unreal mode bug that has been kept for compatibility reasons. 
<sivang> Yagisan: what do you mean 'unreal mode' ?
<Yagisan> sivang: you would already need ribg-0 access to "exploit" it anyway
<Yagisan> sivang: real mode + 4GB segments
<Yagisan> sivang: also called flat real mode
<Treenaks> unreal mode is cool :)
* Treenaks pets his macro assembler
<Yagisan> s/ribg-0/ring-0
<Mithrandir> hmm, would it be useful to have Mailman set Mail-Followup-To on sounder and ubuntu-devel if it wasn't set by the poster already?
<sivang> Yagisan: ah
<sivang> Yagisan: so only someone with root and access to ring-0 could xploit, doesn't seem so easy to exploit if you're on linux and has good password or disabled root :)
<slomo> Keybuk: the unsyncable boo is caused by my last name? just make the "" a "oe" :)
<Yagisan> sivang: you basically can't use it unless you already owned the system, and believe me, there are easier ways to own a system.
<pitti> Riddell: piung
<pitti> Riddell: and ping, too :)
<Keybuk> slomo: unfortunately the error comes from the tool we use to do syncs
<slomo> Keybuk: that's bad :( i need that sync for another upload :(
* sivang tries to recall where you can set cdrecrod's wait time before operation start to 2 seconds instead of 10 by default.
<sivang> this is starting to get annoying
<fabbione> mdz: please take a look at my last comment on #17446 when you have time.
<mdz> fabbione: I don't see any comments from you on #17746; are you sure that is the right bug?
<fabbione> 17446 sorry
<fabbione> and you are not exactly supposed to be awake at this time either :)
<seb128> fabbione: bug #17446
<Ubugtu> Malone bug 17446 in mesa libgl1-mesa-dri "[dri/glide]  not ported to new swrast API" [Normal,Unconfirmed]  http://launchpad.net/bugs/17446
<seb128> fabbione: if you write it that way the bot is nice and people can be lazy and click on the URL :)
<fabbione> seb128: you lazy french boy :P
<seb128> ;)
<pitti> fabbione: can you please take a quick look at bug 34208?
<Ubugtu> Malone bug 34208 in Baltix "offer to set higher screen resolutions if autodetection fails" [Normal,Unconfirmed]  http://launchpad.net/bugs/34208
<pitti> fabbione: would it be possible to configure higher resolutions in xorg.conf (but still default to 1024x768) if autodetection failed?
<pitti> fabbione: it's a small thing, but many users don't know how to fix resolutions other than with the gnome tool
<fabbione> pitti: i will need to think about it. that means changing a default that is known to be sane
<pitti> fabbione: no, I'm not talking about chaning 1024x768 as default fallback resolutionn
<pitti> fabbione: just about adding more resolutions like 1280x1024 and 1600x1200 as *possible* resolutiosn
<fabbione> pitti: that means changing the default to the debcon question
<pitti> fabbione: so that you get higher resolutions offered in System -> Setttings -> Resolutions
<fabbione> it also changes a bunch of other stuff too...
<pitti> fabbione: so if autodetection fails, and the user knows that his monitor can do 1280 or 1600, he can manually set it
<fabbione> pitti: i grasp the problem.. there are other issues in doing that
<pitti> fabbione: that's why I ask you, I have no idea how intrusive that would be
<fabbione> pitti: the change itself is a one line
<fabbione> the problems are multiple with changing that default
<pitti> so too dangerous for dapper?
<fabbione> mostlikely
<pitti> the common thing amongst the failures known to me is using a DVI cable
<pitti> not sure whether autodetection is generally broken with DVI, or whether it's card specific
<pitti> but anyway, it happens often enough
<fabbione> pitti: it's a card issue usually, that doesn't know exactly how/what to check when we issue the ddcprobe
<jmg> who is the ubuntu kernel maintainer?
<jpatrick> jmg: BenC, I think
<dholbach> kernel-team@lists.ubuntu.com?
<jmg> jpatrick: thanks
<Diziet> seb128: Do you still need help with your epiphany dpkg problem ?
<seb128> Diziet: no, that's fine, Keybuk replied to my questions, thank you for asking :)
<jpatrick> what happened to libggzmod-dev in Dapper?
<Tm_T> I could ask the same about libortp0
<Tm_T> ;(
<pitti> jpatrick: the package was simply removed
<jpatrick> pitti: was there a reason?
<jpatrick> I need it for a build-dep on another package
<pitti> jpatrick: usually it's because it was removed from Debian; we do it, too, if the package isn't required by anything
<Tm_T> I wonder how much it takes to get back libortp0 to ubuntu AND Debian
<pitti> Tm_T: that's a different case; the current linphone lib has a new API
<jpatrick> pitti: packages are in Alioth..
<pitti> Tm_T: i. e. it's libortp2 now
<Tm_T> pitti: yeah, and it doesn't work with jingle
<Tm_T> pitti: it _must_ be libortp 0.71
<pitti> Tm_T: can't find that package
<Tm_T> pitti: exactly
<Tm_T> pitti: it was in breezy
<Tm_T> and awhile after it
<jpatrick> pitti: could i upload a new package of it?
<pitti> Tm_T: hm, if it relies on a very old version, then it's probably abandoned upstream?
* ogra shakes head about bug 39244
<Ubugtu> Malone bug 39244 in edubuntu-meta edubuntu-desktop "PS2 KB extension problems on start up" [Normal,Unconfirmed]  http://launchpad.net/bugs/39244
<pitti> Tm_T: can't find it in breezy either
<ogra> how the heck am i supposed to fix keyboard extension cable issues ? 
<Tm_T> pitti: abandoned upstream? no way =)
<pitti> ogra: by sheer willpower :)
<ogra> hehe
<Tm_T> pitti: http://code.google.com/apis/talk/about.html
<Tm_T> pitti: problem is, without correct libortp, no wayto get jabber jingle voice chat compiled with Kopete
<Tm_T> ;(
<Tm_T> and next chance will be possibly next year
<pitti> Tm_T: is it so hard to port to the current API?
<Tm_T> pitti: afaik it is
<Tm_T> pitti: well, google side is doing it
<Tm_T> also some third party patches available
<Tm_T> which doesn't do any good =)
<Tm_T> pitti: if no other way, we prolly set up third party repository for these Kopete stuff
<doko> Diziet: any news about the firefox/fonctconfig problem? if not, I would like to revert your fontconfig change
<Tm_T> pitti: to (K)Ubuntu and Debian
<freeflying> doko: hi
<doko> freeflying: hi
<freeflying> doko: have you got the patches I mail you for OOo
<Diziet> doko: Go on, revert it.  I'm doing a new ff today and I won't get round to it until after Easter.
<doko> Diziet: ok, I'm including the rationale in the changelog
<doko> freeflying: what's your email?
<freeflying> doko: zhengpeng.hou#gmail.com
<kaled> any ubuntu-core-dev members present to check a simple request?
<doko> freeflying: did you test these patches with a recent OOo build in dapper?
<doko> freeflying: all the patches to freetype won't have any effect, we are using the system freetype.
<freeflying> doko: haven't yet , dare not build it , last build cost me 14hrs  :)
<doko> many patches just comment out code (#if 0), no comments, how does this interact with other languages?
<freeflying> doko: the author have built it , has binary package ,but in rpm fromat 
<doko> freeflying: I can't just make a build for chinese, the build has to support all languages. If you want to integrate these patches, please let me know.
<freeflying> doko: I wanna have a test , but dare not build it , it's too time consume
<doko> freeflying: just the first time, if you use ccache, then it should be done in 4-6 hours
<Tm_T> ugh
<dholbach> can somebody please NEW bakery2.4?
<ogra> oooh, will we get cake from you today ? 
<ogra> :)
<dholbach> ogra if it goes through new, there'll be glom 1.0 :)
<dholbach> dunno if that's good enough to count as a "cake" :)
<ogra> to glom: steal/filch ? 
<ogra> hmm
<ogra> you bake it to steal it from us ? you evil man :)
<ogra> (presumably secretly while giving a hug)
<pitti> Riddell: any news from kdeprint? I'm currently preparing 1.2rc2 which works pretty well
<Riddell> pitti: no the guy hasn't got back to me
<pitti> ok :(
<Riddell> I told him we needed a response by yesterday, so I guess he doesn't have time even with a bounty
<pitti> ok, let's make that an agenda point in tomorrow's distro team meeting
<Riddell> yeah
<Kamion> dholbach: done
<Kamion> dholbach: your diff is weird though, it regresses config.guess and config.sub to five-year-old versions
<Kamion> -timestamp='2005-05-15'
<Kamion> +timestamp='2001-07-12'
<dholbach> hu... I wonder why that happens
<dholbach> Kamion: I'll investigate - thanks.
<sivang> see you later folks
<fabbione> bug #39244
<Ubugtu> Malone bug 39244 in xserver-xorg-input-keyboard edubuntu-desktop "PS2 KB extension problems on start up" [Normal,Unconfirmed]  http://launchpad.net/bugs/39244
<fabbione> i don't think this can be X related at all
<ogra> fabbione, i complained after getting up already
<ogra> :)
<fabbione> ogra: ?
<ogra> * ogra shakes head about bug 39244
<Ubugtu> Malone bug 39244 in xserver-xorg-input-keyboard edubuntu-desktop "PS2 KB extension problems on start up" [Normal,Unconfirmed]  http://launchpad.net/bugs/39244
<ogra> <ogra> how the heck am i supposed to fix keyboard extension cable issues ? 
<fabbione> oh
<ogra> <pitti> ogra: by sheer willpower :)
<ogra> we should add that as comment :)
<fabbione> ogra: rejected..
<ogra> :)
<jsgotangco> heh
<elmo> fridge, kubuntu and planet going down for 5 minutes
<elmo> (err, sorry and edubuntu and theopencd)
<highvoltage> elmo: the edubuntu site is just proto.edubuntu.org, www.edubuntu.org should be fine, for the record :)
<highvoltage> (i think)
<elmo> highvoltage: right
<heno> Mithrandir: so I can see the access stuff in the seed list, but it's not on the live CD or its manifest list
<heno> it's on the install CD list though under 'pool'
<heno> not sure what 'pool' is, shipped seed?
<TheMuso> heno: Are you referring to the latest daily CD image?
<heno> TheMuso: yes
<heno> I tested it today
<stub> Launchpad will be going down in 15 mins for the regular code update and hardware maintenance. Estimated downtime will be 40mins. Scream now if this is a major problem.
<zul> heylo
<heno> some of the settings work, but the packages are not installed
<TheMuso> I don't usually get a sync of the latest dailies till early in the morning.
* TheMuso manually syncs.
<janimo> Mithrandir: hi, you were saying xubuntu live cds are being prepared today?
<Kamion> heno: pool/ is everything, all packages on the CD
<Kamion> installer+minimal+standard+desktop+ship
<stub> Update: Launchpad going down in 20 mins. Estimated downtime still 40 mins.
<Kamion> heno: Mithrandir added the accessibility packages to desktop, so my guess is that it just needs an ubuntu-meta upload to cause that to be pulled into the live CD
<Kamion> I'll do that now
<heno> Kamion: cool, thanks
<heno> Kamion: I see that dasher has been added somewhere along the way. That's not something that we activate with one of the boot options though
<heno> I don't mind seeing in desktop, but it's not a high priority, FYI
<slomo__> Kamion: hi... as the sync script currently has a problem with non-ascii names like mine... am i allowed to upload a fakesync for one package? another package i want to upload is currently waiting on this and i want to clean my local upload queue ;)
<Kamion> elmo: is the UTF-8 fix in the sync script likely to be a quick thing?
<Kamion> heno: talk to Mithrandir, I guess, I'm just being random admin at this point
<heno> Kamion: sure, np
<elmo> Kamion: err, how do you mean?
<Kamion> elmo: see down near the end of bug #39055
<Ubugtu> Malone bug 39055 in boo "UVF Exception: boo 0.7.0.1921 -> 0.7.5.2013" [Normal,Unconfirmed]  http://launchpad.net/bugs/39055
<elmo> Kamion: this is a different problem than the one before
<elmo> probably easy to fix, esp. since lp is currently mangling announces anyway
<elmo> Kamion: btw, subscribing me to a bug doesn't really work, since LP sends me so much spam (I assume as a LP admin), that I'll invariably miss it :(
<Kamion> ah
<Kamion> I'd figured it was better than not subscribing you and expecting you to telepathically see it
<_ion> http://ploum.frimouvy.org/?2006/04/06/103-may-19th-the-open-discussion-day-19-mai
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | Flight 6 released | Soyuz suspend during LP Upgrade
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | Flight 6 released | Soyuz suspended during LP Upgrade
<bddebian> Heya folks
<highvoltage> heya bddebian 
<bddebian> Hello highvoltage
<mdke_> Riddell, I've done a new version for kubuntu-docs in our dapper branch (version is 6.06-4) - i noticed that it was installing a lot of images which don't get used: the binary package should now be 250K instead of 11M. I've tested it, seems to work. Do you fancy testing/uploading later on?
<Riddell> mdke_: yeah, sure
<Riddell> those images were for the old quickguide I think, I was menaing to check if they were actually used in the desktopguide
<mdke_> Riddell, great, thanks
<mdke_> yeah, they don't afaics
* ..[topic/#ubuntu-devel:Kinnison] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | Flight 6 released | LP upgraded, report issues on #launchpad
<Seveas>    * Removed espresso from live-i386, live-amd64, live-powerpc, live-
<Seveas>      ia64, live-sparc, live-hppa
<Seveas> que?
<Seveas> Espresso being abandoned? ;)
<janimo> Seveas: it;s pulled in by espresso-gtk
<janimo> no longer explicitely seeded that's all
<janimo> or espresso-qt
<CarlFK> Kamion: I still have that box with the 2 hda5 in fstab - any interest in the current state, or should I try todays dapper?
<Kamion> CarlFK: sorry, I need more context
<CarlFK> Kamion: about a week ago I filed a bug... looking it up
<CarlFK> dapper install resulted in 2 hda5 lines, box wouldn't boot - asks for root pw...
<CarlFK> hmm, maybe it only made it to the mail list...  I don;t see a launchpad entry
<CarlFK> looking at mail....
* Kamion can't find it in your reported bugs list in lp either
<jsgotangco> whoa LP bling
<CarlFK> (2:44:37 AM) Kamion: CarlFK: well according to your partman log the installer  /dev/hda5 is swap, so perhaps something is very confused, I don't know
<CarlFK> thats about as far as it went
<CarlFK> then I went away for a week
<Kamion> sorry, I honestly can't remember and I don't have the IRC log handy - what day was that?
<CarlFK> I posted to the dev mail list on 4/4, so it was probably the 4/3
<CarlFK> but nothing was ever figured out.
<CarlFK> http://dev.personnelware.com/carl/temp/Apr03/d/etc/fstab
<Diziet> I'd like an opinion about wording for a message.
<Kamion> I don't even have the time to investigate all the bugs people file let alone starting on random posts to mailing lists, I'm afraid :)
<Kamion> The requested URL /carl/temp/Apr03/d/etc/fstab was not found on this server.
<CarlFK> dam
<Diziet> If you look in ff's Tools / Extensions you see the langpack you have installed.
<CarlFK> while I was away I screwed up my dns
<Diziet> It currently says `Update not supported (install location is read only)'.
<Diziet> I want to change this to something clearer, but of course I don't want to make it too long.
<Diziet> `Handled by Ubuntu system update (install location is read only)' ?
<CarlFK> http://67.163.39.124/carl/temp/Apr03/d/etc/fstab
<Kamion> "Handled by system package manager" perhaps
<Diziet> That's quite good.
<Diziet> I still need to have `(install location is read only)' to avoid it incomprehensible lies if you've done something strange.
<Diziet> At least with that phrase the lies will be comprehensible.
<CarlFK> Kamion: i would have put it in lp, but had to  pack my suitcase ;)
<Kamion> (...)> agreed, just couldn't be bothered retyping it
<Kamion> CarlFK: I can't find the reference anywhere in the IRC logs on http://people.ubuntu.com/~fabbione/irclogs/, so perhaps it was in an unlogged channel or in a /msg
<CarlFK> Kamion: it was in #u-bug 
<Kamion> anyway, yeah, give me a few minutes to dig through the debug
<CarlFK> will do
<Diziet> Kamion: Thanks.
<Kamion> you're welcome
<CarlFK> Kamion: if you want to see 'everything' (not much) from last week -  ubuntu-devel@lists.ubuntu.com,  Apr 04, Subject: hda5 mounted - e2fsck: aborting"
<Kamion> oh, wow, that's a really cool bug
<CarlFK> heh
<CarlFK> can I quote you?  I think that is the only time I have heard a bug called that ;)
<Kamion> sure :)
<Kamion> I think I know roughly what's up, just trying to track down the exact offender
<pitti> Riddell: yay, I just talked with a friend of mine, he'll look into the kdeprinter cups issue
<Riddell> pitti: oh?
<Riddell> who:s that?
<pitti> Riddell: you don't know him probably, Michael Hofmann
<pitti> Riddell: (mh21 in launchpad)
<Kamion> CarlFK: what's happening is, /dev/hda5 was originally ext3, and the installer automatically marked it to be mounted on /media/hda5
<Riddell> pitti: does he know much about kde and/or cups?
<pitti> Riddell: I told him about our troubles, and since he has some free hours anyway, he wanted to give it a shot
<Kamion> CarlFK: then you told partman to make it a swap partition instead
<pitti> Riddell: actually not, but he's very good at hacking in general (he learned to fix gnome bugs in no time and such)
<CarlFK> Kamion: that sounds reasonable. 
<Kamion> CarlFK: but partman forgot to clear its notion of the current filesystem for /dev/hda5 (acting_filesystem), which is what the fstab.d generator scripts look at
<pitti> Riddell: I don't expect him to rewrite kdeprint in a clean way :), just change the internal API hacks to some different hacks to match the 1.2 API
<Kamion> CarlFK: so partman thought it was both swap *and* mounted on /media/hda5
<Kamion> fix should be pretty straightforward if I'm reading this right
<Riddell> pitti: worth a shot, point him my way if he has any questions
<pitti> Riddell: will, yes
<pitti> Riddell: *crossing fingers* :)
<CarlFK> Kamion: good chance i got the "you have not assigned a swap part, are you sure?" message 
<CarlFK> Kamion: or I was thinking of that message and assigned swap just so I wouldn't get bothered by the message
<Kamion> CarlFK: not according to the syslog, which should have shown partman-basicfilesystems/no_swap being asked if that were the case
<Riddell> pitti: apparantly Cristian of kdeprint does not have a machine to install kubuntu on so would need an NX machine or something
<CarlFK> Riddell: I have installed a full os on this free thing: http://www.vmwarez.com/2006/02/livecd-player-virtual-machine.html
<CarlFK> Riddell: I have not done any GUI stuff, so I can't say what the performance would be like, but I hear it is "fine' and it should be more than enough for testing things
<Kamion> (http://cdimage.ubuntu.com/vmware/Ubuntu-5.10.zip)
<HiddenWolf> Now they just need to package player nicely. :)
<CarlFK> can the player be put in Universe?
<Kamion> universe is for free software only; *maybe* multiverse, but that would require a redistribution licence from vmware
<Kamion> I think some discussions have been taking place, although I'm not certain
<wasabi> Lets not distribute VMware.
<wasabi> Lets solve it properly: https://wiki.ubuntu.com/ThirdPartyApt
<wasabi> This has been a public service announcement.
<Kamion> WOO working espresso on powerpc
* pitti hugs Kamion 
<Kamion> (about time, say you all)
<Kamion> pitti: still may not work for *you*, given you've been tickling different bugs ...
<Kamion> but at least now I know that the bootloader installation works
<pitti> Kamion: right; I'm fairly sure I selected correct partitions, but I have to try that again with the screenshot
<seb128> pitti: what happened to cups which made it working correctly again when it was all broken some days ago? :)
<seb128> pitti: I mean upstream, not the Ubuntu package
<pitti> seb128: rc1 -> rc2 apparently fixed a shitload of butgs :)
<seb128> so you and upstream are friends again? :)
<pitti> seb128: I didn't ask mdz for UVF approval yet, I want to give out a test package before
<seb128> right
<pitti> seb128: let's say I don't hate him any more :)
<seb128> but previous week you mentionned they are doing such a bad job that we want better revert
<seb128> so that's weird it changed that much since
<pitti> seb128: but it works really well now, and with rc2 we are back on track for getting upstream support again for bugs
<pitti> seb128: yes, I was impressed, too
<pitti> seb128: now reverting or upgrading depends on kdeprint
<Kamion> apart from the way it doesn't boot (although the bootloader itself is working, because it can boot another of my filesystems
<Kamion> )
<Kamion> I wonder why that is
<mdz> Kamion: what is the workaround for bug 36022?
<Ubugtu> Malone bug 36022 in launchpad-upload-and-queue "change-override can't handle pockets" [Major,Confirmed]  http://launchpad.net/bugs/36022
<Kamion> mdz: "get Kinnison to prod the db by hand"
<Kamion> mdz: we only have one case where we've needed this so far, and making change-override.py work is apparently a lot harder than expected. Kinnison's already done the db tweak for us for python-vte
<mdz> Kamion: ok, so it just needs to be uploaded? is mvo doing that?
<Kamion> mdz: python-vte doesn't need an upload either, it's done
<ogra> ugh, i just thought my firefox is badly broken, but its the new LP ui
<Diziet> E [12/Apr/2006:16:07:43 +0000]  [cups-driverd]  Unable to open driver directory "/usr/lib/cups/driver": No such file or directory
<Kamion> mdz: oh, you mean the upgradeer
<Kamion> ?
<Diziet> Is this known to be broken ?
<mdz> Kamion: my understanding is that the upgrader needs a newer vte
<mdz> oh, I see, it has been updated relative to breezy
<Kamion> yeah
<mdz> I expected a ~breezy version
<Kamion> python-vte | 1:0.11.15-0ubuntu2 | breezy/universe | amd64, hppa, i386, ia64, powerpc, sparc
<Kamion> python-vte | 1:0.11.15-0ubuntu3 | breezy-updates | amd64, i386, ia64, powerpc
<mvo> mdz: I uploaded the backported update-manager a couple of minutes ago
<Kamion> hmm, I guess this will all have landed in unapproved
<mvo> yes
<mdz> mvo: you checked that there had not already been a -0ubuntu3 version?
<Kamion> I'll do some queue processing
<Kamion> mdz: I double-check that when processing unapproved anyway
<mvo> mdz: for libgksu1.2-0? I thought I did, let me check again
<Kamion> oh, apparently I didn't double-check enough in this case
<Kamion>  vte (1:0.11.15-0ubuntu3) dapper; urgency=low
<Kamion> it's been superseded since though, so I guess we live with the small confusion now
<mvo> mdz: does it confuse the archive tools if there had been a identical version in the archive in the past? 
<mvo> mdz: for vte, I didn't backported the complete thing, just the two (small) patches that are required for the upgrade tool
<Kamion> mvo: no
<Kamion> in fact the archive currently fails to reject even if the version is in another distrorelease in the archive RIGHT NOW
<Kamion> (I have a bug open about that!)
<mvo> so this is about the convention for uploads to -updates? Is this documented? I was only able to find the policies for security updates
<Kamion> it's not particularly documented for -updates in particular - I thought it was fairly obvious that versions should be unique though
<Chipzz> mvo: ping ;)
<Kamion> conventions are haphazard, personally I prefer versions of the form -0ubuntu2.1 if the versions in hoary, breezy, dapper are distinct
<Kamion> IMHO you only need to put breezy or 5.10 or whatever in the version number when hoary/breezy/dapper updates would otherwise clash, and it's best to keep version numbering simple where we can
<Kamion> hmm, I think I sort of agree with mdz in the case of update-manager though - when doing a full backport, ~backport1 isn't the most helpful version number suffix
<mvo> I'm not disputing that they should be distinct :) I was just wondering if we had something "writen down" already
<Kamion> not AFAIK, sorry
<mvo> Kamion: I think I start something (initially very short, based on this conversation). Does "ImportantUpdateProcedures" sound reasonable? (we have SecurityUpdatesProcedures" already
<mdz> mvo: I don't think it does, but it certainly confuses me :-)
<mdz> mvo: documentation is an excellent idea
<mvo> mdz: yeah, sorry for this, I start a wiki page about this now
<wasabi> So when's dapper out the door? :)
<mdz> wasabi: http://wiki.ubuntu.com/DapperReleaseSchedule
<doko> pitti, jbailey: got new OOo translations: as-IN, ml-IN, or-IN, ur-IN, mr-IN. which of these can we support?
<mdz> fabbione: how are you feeling about the state of X for beta?
<fabbione> mdz: it's getting better a bit at a time
<fabbione> clearly man power to help would help
<fabbione> because we also need to find the fixes for the bugs people are triaging
<Chipzz> mvo: so, are there any outstanding issues after my last patches?
<janimo> mvo, hi. is there a list with the preferred order of inclusion of languages on the CD?
<janimo> there;s plenty of space on the xubuntu cd so I'd like to put as many langpacks as possible
<pitti> doko: why shouldn't we be able to support some of then?
<pitti> doko: s/then/them/
<janimo> and associated support packages
<Kamion> mvo: this is an odd backport of update-manager, it seems to be totally different from the package with a similar version in dapper
<Kamion> mvo: I think we've now established a meaning for "backport" which is "the same source built on an older release", so having radically different source called "backport" is rather confusing
<LaserJock> Kamion or mdz, would it be ok to file bugs to get some new packages synced from debian (not in Ubuntu) or removed from Ubuntu and assign them to ubuntu-archive?
<Kamion> LaserJock: yes
<doko> pitti: ok. btw, should I just copy the locale generation chunks from the -base packages into the ooo-l10n packages?
<Kamion> LaserJock: but don't assign them to ubuntu-archive, just subscribe ubuntu-archive, please
<LaserJock> Kamion: gotcha, will do
<pitti> doko: you can if you want, but I thouhght they should be generated in l-support-*?
<HiddenWolf> where did the pony on the fridge go?
<ogra> you cant have it !
<doko> pitti: but they are not? just getting complaints from users.
<pitti> doko: yes, it's still on my list
<pitti> doko: if it's urgent, I'll do it tomorrow
<doko> pitti: please not before cups is fixed ;-)
<pitti> AARGH
<pitti> doko: I have an idea about all these new bugs: I forgot to put 54_cups-config_modeldir.dpatch  in to 00list :/
<pitti> doko: that should only affect very few printers, though
<doko> but does this explain the "garbage" strings?
<pitti> not really
<pitti> doko: do you get them, too?
<doko> yes
<pitti> hm, it worked well for me, I have to reinstall a clean dapper and debug this
<doko> the patch is not really needed, I modified gutenprint to work without it
<pitti> yes, and the symlinks are still in place anyway
<pitti> doko: it only affects the ppds shipped by cups
<doko> with bug 39272, no printer is actually used
<Ubugtu> Malone bug 39272 in cupsys "server-error-internal-error while adding printer with gui" [Normal,Unconfirmed]  http://launchpad.net/bugs/39272
<Diziet> 39727 seems quite like my just-reported bug 39319
<Ubugtu> Malone bug 39319 in cupsys "Cannot add new printer" [Unknown,Unknown]  http://launchpad.net/bugs/39319
<_mvo_> Kamion: https://wiki.ubuntu.com/ImportantUpdateProcedures, remarks welcome
<pitti> doko: btw, please feel free to look into that cups thing; we should fix it for the beta
<HiddenWolf> _mvo_: no page there. :)
<HiddenWolf> oh, wait, comma
<doko> Kamion, mdz, infinity, elmo: please could somebody make the following cupsys package versions available: 1.1.99.b1.r4929-0ubuntu6 1.1.99.b1.r4929-0ubuntu5
<pitti> doko: btw, I'm just importing our cupsys changes into a branch of Debian's package, so that'll be easier in the future
<pitti> doko: (svn branch, that is)
<Kamion> doko: I have no idea how to extract those from launchpad
<Kamion> I imagine they're still in the librarian somewhere
<Kamion> try #launchpad
<Burgwork> mdz, is there anything that needs to be done to move that flash intro stuff forward?
<Kamion> Is anyone on the art team here? I sent a message to ubuntu-art@ about getting an icon for espresso, but it's stuck in the moderation queue
<mdke> Kamion, looks like silbs is the admin of the list, not sure if there are more moderators
<mdz> Burgwork: it's doomed
<mdz> the software stack just isn't there
<mdz> we'll do it for another release
<bddebian> So if survex-aven depends survex (=1.0.39) and I make 1.0.39ubuntu1.  Do I really need to make the depends 1.0.39ubuntu1?
<Burgwork> mdz, ah, ok. Dapper+1 it is
<Kamion> mdke: silbs is on holiday
<bddebian> Or is it more correct to do (>=1.0.39) (<<1.0.40)?
<mdke> Kamion, oh right. maybe henrik or dholbach will know, they are quite active in that team
<Kamion> mdz: I just read through the ue-gnome-ui spec; there's very little left of the mandatory stuff before I can call it implemented, as far as I can see
<Kamion> mdz: I think only the icon is left
<Kamion> mdz: would you mind glancing through it and see if you agree with that assessment, or if there's something glaring you still think is missing?
<dholbach> Kamion: I can't approve the mail, but I could send it for you, if you click on the "remove my mail from the queue" thingie? (sorry, that's all I could do)
<elmo> I can approve it, don't bother
<dholbach> oh ok
<Kamion> bddebian: there's a Makefile in survex/debian/ which appears to be supposed to generate the control file with an updated version (and other things)
<Kamion> weird package, (= ${Source-Version}) is the normal way to do that
<Kamion> elmo: thanks
<bddebian> Kamion: So should I "fix" it or what do I do?
<Kamion> bddebian: I think you update the changelog and run 'make' in the debian/ directory
<Kamion> bddebian: but that's just a wild guess
<bddebian> Gah
<Kamion> in fact no
<mdke> dholbach, any luck on -docs?
<dholbach> mdke: LaserJock wants me to wait a bit
<mdke> argh
<dholbach> mdke: i didn't attempt to do it yet
<mdke> LaserJock, how long?
<bddebian> Kamion: ?
<Kamion> bddebian: update the changelog, do a build (enough to make it run ./configure), 'make -C debian control', and clean
<dholbach> mdke: do you have to have the upload done in a bit?
<Kamion> bddebian: I think
<LaserJock> mdke: just a minute
<Kamion> bddebian: if that doesn't work, you'll have to work it out for yourself :)
<bddebian> Kamion: You aren't instilling me with a lot of confidence :-)
<mdke> dholbach, today if possible, there are some new translations which i want to get to rosetta. But I'm happy to wait on LaserJock for a bit
<Kamion> bddebian: I'm not trying to ;)
<dholbach> ok, i'll do it today - say in an hour or something
* bddebian gets no love
<dholbach> mdke: are you happy with that?
<mdke> LaserJock, an hour enough?
<LaserJock> mdke: I was thinking 15 min. ;-)
<dholbach> ok, an hour
<dholbach> see you then :)
<dholbach> *wave*
<mdke> dholbach, thanks a lot
<dholbach> de rien
<mdz> Kamion: I will have a look, but I really need to do an install with recent espresso to confirn
<mdz> Kamion: do the current dailies have the latest bits?
<Tonio_> hello everyone
<Tonio_> just wanted to know if it was still possible to upload NEW packages after tomorrow's freeze ?
<bddebian> Heya again Tonio_ :)
<Tonio_> hey bddebian :)
<Tonio_> or may I upload that wengophone toonight after getting it reviewed very quickly :)
<Tonio_> bddebian: any reponse on that point ?
<bddebian> Tonio_: I don't know, sorry :-(
<Tonio_> bddebian: no pb ;)
<Kamion> mdz: current daily has everything but the changes in https://lists.ubuntu.com/archives/dapper-changes/2006-April/009253.html
<robertj> is there a procedure for submitting new quotes for the wiki?
<robertj> It's kinda lame having a quote from sabdafl up there
<Treenaks> sabdafl? sabdfl and daf in one?
<Treenaks> robertj: quotes on the wiki?
<Treenaks> where?
<robertj> https://wiki.ubuntu.com/RecentChanges
<LaserJock> robertj: not seeing it
<mdke> robertj, just add them to the page
<mdke> LaserJock, at the top
<mdke> robertj, https://wiki.ubuntu.com/FortuneCookies
<robertj> ahh
<dieman> hah
<dieman> awesome
<mdke> you can have them appear anywhere, pretty cool
<LaserJock> neato
<Lure> doko: my firefox fonts look strange after last fontconfig update (under Kubuntu)
* robertj nukes sabdafls quote
<doko> Lure: then change the config as described in the fontconfig upload
<Lure> doko: will try - should we change firefox package to do proper config out-of-box?
<mdke> mjg59, ping?
<doko> Lure: sure, send a patch, or find a way, that firefox itself does the fonst substitution (i.e. Times -> DejaVuSerif, Helvetica -> DejaVuSans)
<mdke> JaneW, around?
<dholbach> LaserJock, mdke: ready to go?
<LaserJock> I am, mdke?
<mdke> dholbach, you bet
<dholbach> rock on... which url was that?
<mdke> https://docteam.ubuntu.com/repos/branches/dapper
<elmo> Kamion: dude?
<dholbach> mdke: looks like it went *REALLY* quick :)
<mdke> dholbach, the all-new slim ubuntu-docs :)
<dholbach> "to make dholbach happy" :)
<dholbach> mdke: i don't have to strip directories from it, do i?
<mdke> dholbach, yeah, you can do.
<mdke> dholbach, it'll get rid of the kubuntu stuff
<dholbach> ok
<dholbach> thanks
<wftl> Kamion: If you are around (or somebody else wants to pipe up), will the Espresso installer be on the Kubuntu desktop live CD as well?
<dholbach> wftl: something comparable
<wftl> dholbach: Thanks. Good to know you will be able to install from both live CDs.
<dholbach> mdke: WOW!!!
<mdke> :)
<dholbach> mdke: i mean .... WOW!!!
<dholbach> mdke: 15MB -> 741K!
<mdke> we cleaned up
<dholbach> mdke: i'm happy to do MINUTELY uploads now :-p
<mdke> heh
<dholbach> just kidding, but it'll make things easier and quicker :)
<mdke> that's nothing compared to kubuntu-docs: the _binary_ went from 11MB to 250K
<dholbach> NICE
<dholbach> uploaded
<mdke> thanks a lot
<LaserJock> waaay cool
<dholbach> my pleasure :)
<lemsx1> anybody knows about segfault in ping ?
<lemsx1> only when pinging addresses that will be resolved by winbind
<lemsx1> $> cat /etc/nsswitch.conf | grep hosts
<lemsx1> hosts:          files dns wins mdns
<mdke> lemsx1, you could try the bug tracker?
<lemsx1> there are 2 wins server's defined in /etc/samba/smb.conf
<lemsx1> mdke: i know that was an issue before. i have many dapper boxes running side by side. only one is having these problems
<mdke> lemsx1, if one box isn't working, it's still a bug
<mdke> maybe someone else has had your issue, and reported it
<lemsx1> ouch, the other box did the same now
* lemsx1 searching malone
<Burgwork> fabbione, neuralis either of you around?
<dholbach> night guys
<mdke> night dholbach 
<dholbach> night mdke
<wftl> Is there an Ubuntu channel for artwork development?
<mdke> wftl, #ubuntu-artwork, or similar
<dholbach> or #ubuntu-art or #dapper-look
<lemsx1> mdke: i've already reported this bug 32614
<Ubugtu> Malone bug 32614 in samba winbind "segfault when not joined to the domain" [Normal,Unconfirmed]  http://launchpad.net/bugs/32614
<lamont> seb128: re metacity bug (upstream) 152004) - please don't let strict be anything other than what we have it as in ubuntu.  If it must change because upstream thinks it's the right thing to do, please give me 'really-strict-dammit' or some such.  kthxbye
<lemsx1> mdke: but i don't remember what i did to fix it... though ping is segfaulting on both boxes, the one that has winbind running and the one that does not. wbinfo works on the box that has winbind running
<lemsx1> messy
<seb128> lamont: <seb128> elijah: so to make it clear. I think "old behaviour" by default, with a "strict" option trying to be smart and a "never" option for people who prefers that to bugs would be really nice
<seb128> <elijah> I'll probably avoid the 'never' option right now.  But, I did ask Ron to make the 'focus_new_windows' key a string, so that adding things like 'never' (or maybe even 'always') could be done easily
<seb128> <seb128> I'll probably patch the Ubuntu package for the "never" mode though, so I don't have to have "old school" coworker complaining about GNOME window manager daily
<seb128> lamont: that was discussion with upstream :p
<lamont> seb128: thanks
<seb128> np ;)
<lamont> remind me that I owe you $BEVERAGE next time, eh?
<seb128> cool, yeah will do, don't worry ;)
<Kamion> elmo: yes?
<bddebian> Ugh, cernlib's rules file is ugly
<_ion> http://thedailywtf.com/forums/68115/ShowPost.aspx
<mdke> mjg59, JaneW, unping
<Chipzz> bug 36988
<Ubugtu> Malone bug 36988 in glibc "Posix first_weekday is 7" [Normal,Fix released]  http://launchpad.net/bugs/36988
<lemsx1> mdke: i couldn't fix the problem... dunno what it is
<lemsx1> mdke: it has to do with uid mappings in the smb.conf file and perhaps the samba passwd db being empty
<mdke> infinity, gah, postfix doesn't depend on libsasl2 or libsasl2-modules, you naughty man
<trappist> mdke: shouldn't those be recommends?
<mdke> trappist, yeah, I removed them from the server guide in the meantime
* mdke puts them back
* Kamion discovers an enormous list of Linux keysyms and names hiding in the keymapper source
<lamont> mdke: that's right.  you don't have to have libsasl2 installed in order to use postfix.
<lamont> it does suggest it though
<mdke_> lamont, sure, I'm not criticising the policy
<lamont> and they should be suggests, not recommends
<trappist> I guess I don't know the difference
<mdke_> sure. I was just gently ribbing infinity about something else
<trappist> they're none of the above on debian, unless stuff like postfix-ldap requires them
<trappist> postfix does show up in apt-cache rdepends libsasl2.  I give up.
<lamont> trappist: uh....
<lamont> postfix in dapper is exactly the same source as debian...
<wasabi> any average time for NEW lately?
<desrt> from UNCONFIRMED?
<trappist> and apt-get remove libsasl2 does take postfix with it
<Kamion> wasabi: day or two
<trappist> lamont: oh, I was looking on sarge, sorry
<wasabi> k
<desrt> woh /me is in the wrong place
<Kamion> though Easter will probably reduce response time
<lamont> trappist: sarge... I seem to remember a debian release with that name....  but it's kinda old, no? :)
<trappist> lamont: in debian years it's just an infant :)
<trappist> mdke: iow, postfix does seem to depend indirectly on libsasl2 and libsasl2-modules
<trappist> which (correct me if I'm wrong) means they shouldn't be suggests
<mdke_> trappist, I dunno, I'm just thinking about the guide. Installing one doesn't install the other, that's enough to tell me that the guide is wrong
<trappist> do you already have the libsasl2 stuff installed, then? dozens and dozens of packages seem to depend on it
<Kamion> any Thai folks here?
<lamont> trappist: how does postfix normal operation fail to work without them?
<Kamion> I'd like to know which of the seven available tis-* consolefonts would make a good default
<trappist> lamont: it doesn't.  I'm looking at apt-cache rdepends
<Kamion> tis-phaisarn is the closest in look to our normal console font (glyphs in ASCII look identical)
<Kamion> so that would probably make it preferred in my book - but I don't know how readable it is to Thai speakers
#ubuntu-devel 2006-04-18
<lamont> trappist: hrm... /usr/share/doc/postfix/SASL_README.gz should mention libsasl2 and friends
<trappist> lamont: doesn't seem to exist here
<lamont> trappist: postfix-doc
<trappist> ah.
<lamont> trappist: actually, I'll just add it to README.Debian
<lamont> or does it make more sense to put it in SASL_README?  hrm.
<Kamion> 23:53 < Kamion> though Easter will probably reduce response time
<Kamion> er, I meant "increase response time". make worse. whatever.
<trappist> I like README.Debian, if only because I'm probably not the first person to peek at /usr/share/doc/postfix and think to install postfix-doc, and probably most postfix users (who are actually setting up mailservers) will want the sasl goodness
<trappist> *and not think to install postfix-doc
<lamont> 6.  TLS/SASL support is enabled, but sasl2-bin and libsasl2-modules are not
<lamont>     installed by default.  See also /usr/share/doc/postfix/SASL_README.gz in 
<lamont>     the postfix-doc package.
<lamont> +For Debian and Debian-derived distributions, the simplest way to enable SASL
<lamont> +support is to install the (suggested) sasl2-bin and libsasl2-modules packages:
<lamont> +  apt-get install sasl2-bin libsasl2-modules
<lamont> +
<lamont> +See also /usr/share/doc/postfix/README.Debian for other variations from the
<lamont> +instructions below.
<lamont> trappist: how's that sound?
<trappist> perfect :)
<Riddell> mdke_: whree iks your new kubuntu-docs package?
<mdke_> Riddell, https://docteam.ubuntu.com/repos/branches/dapper/
<mdke_> Kamion, awake?
<Kamion> mdke_: not for much longer, but yeah
<mdke_> Kamion, ok, it's quick
<Kamion> mdz: er. are you intentionally the only bug contact for /products/launchpad-upload-and-queue? see bug 39355
<Ubugtu> Malone bug 39355 in launchpad-upload-and-queue ""Thank you" message in upload acks badly capitalised" [Minor,Unconfirmed]  http://launchpad.net/bugs/39355
<mdke_> Kamion, just tried the install cd (F6), tried to resize my ntfs partition, entered 4 GB as the size, it kicked out and took me back to the screen with no changes and no error message. I tried 8 GB, it worked. known?
<Kamion> not known to me at least
<mdke_> the bug is the lack of error, presumably I have more than 4 GB on the partition or something
<Kamion> file a bug on partman-partitioning please
<mdke_> Kamion, what can I attach?
<Kamion> it might be a duplicate; I intend to go through partman's use of ntfsresize before dapper, but haven't had time yet
<Kamion> mdke_: /var/log/syslog and /var/log/partman from the installer
<mdz> Kamion: it looks like product bug contacts don't work like package bug contacts; there can be only one
<mdke_> Kamion, ok thanks.
<mdz> there wasn't one, and I added myself because I wanted to be copied on bugs
<Kamion> mdz: that wasn't the case until very recently
<Kamion> I'm sure
<mdz> I wonder if the registrant is copied by default, and I'm suppressing that
<Kamion> or maybe not actually
<Kamion> I guess it was just "Launchpad Developers"
<mdke_> Kamion, do I need to copy those logs now, or do they exist after I complete installation?
<mdz> Kamion: that's the registrant
* Kamion subscribes Launchpad Developers manually
<Kamion> mdke_: they're in /var/log/installer/ after installation
<mdke_> Kamion, thanks very much. Good night
<Riddell> mdke_: kubuntu-docs uploaded, thanks
<mdke_> Riddell, yay! thank _you_
<mdz> Kamion: confirmed
<mdz> Kamion: I've gone back and subscribed launchpad developers to the relevant bugs
<mdz> and cleared the bug contact
<Kamion> thanks
<Kamion> have you filed a malone bug about the misbehaviour, or shall I?
<Kamion> I think you probably have more information
<wasabi> What's this Channel term which is being thrown around in relation to apt sources?
<mdke_> I think it's used to mean "repository"
<wasabi> Hmm.
<lifeless> its a source of packages
<wasabi> So basically a pretty word for an apt repository.
<wasabi>  Cool. I shall adopt it. :0
<lifeless> i.e. one suite in a apt-sources line
<lifeless> (IIRC)
<lifeless> niemeyers python tool to install stuff uses it
<mdke_> i think gnome-app-install uses the term a fair amount
<wasabi> I need some gapti test users. ;)
* mdke_ runs away
<jono> hey
<Riddell> Kamion: kde espresso good to merge
<bddebian> Heya folks
<infinity> mdke: Uhm, yes it does.
<infinity> mdke: If you're not seeing apt pull in libsasl2 when you install it, that's because (drum roll...) it's already installed.
<infinity> lamont: Did you actually check the dependencies of your own packages before confirming mdke's statement that it doesn't depend on libsasl2? :)  It does.  (And in Ubuntu, that also means it depends on libsasl2-modules, since libsasl2 depends on -modules in Ubuntu)
<bddebian> infinity!!
<infinity> Yes dear.
<bddebian> Just Hi.
<bddebian> So I added two dh_installs and a dh_desktop to dx and now it fails on dh_shlibdeps..  Any ideas?
<infinity> build log?
<bddebian> Gah, it takes forever to build :-(
<infinity> Well, "it fails on dh_shlibdeps" doesn't mean much without some output to go with it.
<bddebian>  cp /usr/lib/dx/bin/dx can't stat file or something like that
<bddebian> I'll build again :-(
<mhz> jdub: ping
<infinity> shlibdeps doesn't copy files at all, so that failure would be elsewhere (like, in the dh_install calls)
<bddebian> infinity: I know, that's from memory.. :-(  I'll shut up now
<whiprush> Riddell: ping.
<bddebian> infinity: Still here?
<infinity> bddebian: In and out and such, but yes.
<bddebian> So it wasn't dh_shlibdeps
<bddebian> dh_installman -pdx
<bddebian> dh_installchangelogs -pdx -plibdx4 ChangeLog
<bddebian> dh_install -pdx debian/dxicon.xpm usr/share/pixmaps
<bddebian> cp: cannot stat `./usr/lib/dx/bin/dx': No such file or directory
<bddebian> dh_install: command returned error code 256
<bddebian> make: *** [binary-arch]  Error 1
<infinity> Right, well that seems pretty self-evident to me.
<bddebian> But I don't know where the fsck that /usr/lib/dx/bin/dx path is coming from?
<infinity> From debian/dx.install?
<bddebian> These are the only 3 lines I added and it builds fine without these:
<bddebian>        dh_install -pdx debian/dxicon.xpm usr/share/pixmaps
<bddebian>         dh_install -pdx debian/dx.desktop usr/share/applications
<bddebian>         dh_desktop
<Chipzz> bddebian: does debian/dx.desktop refer to /usr/lib/dx/bin/dx maybe?
<bddebian> Yes, that path is in dx.install but why would it work without those three lines?
<Chipzz> maybe dh_install does a sanity check on your desktop file
<Chipzz> and if your desktop file is broken
<Chipzz> it can't copy a file that's not there?
<bddebian> bdefreese@archive:~/devel/dx/dx-4.3.2/debian$ desktop-file-validate dx.desktop
<bddebian> bdefreese@archive:~/devel/dx/dx-4.3.2/debian$
<Chipzz> I meant broken wrt the path of the dx exe
<infinity> bddebian: Why are you calling dh_install twice?
<infinity> Oh, nevermind, I see the problem.
<infinity> bddebian: Or, maybe I don't.
<infinity> bddebian: I'd have to see your rules file.  I'm just fumbling in the dark without it.
<bddebian> Of course now saying this, I don't know why I didn't just put them in dx.install anyway
<bddebian> Sometimes being stupid can REALLY be annoying :-(
* bddebian probably goes back on infinity's shitlist :-(
<infinity> That implies you were ever removed. :)
<bddebian> I was just going to say that :-)
<bddebian> :'-(
<infinity> (Also, relax dude.  Stupid mistakes happen.  It's more annoying to whine about being stupid than it is to just take your lumps and move on)
<bddebian> I don't suppose you've had time to check out ivtools?
<infinity> I'm trying to get some stuff done for Beta and UI freeze, so no, but I'll get to it after that.
<infinity> Universe stuff has a lot more leeway, so I can do my good samaritan work after I'm done crunching on main.
<bddebian> Heh, no worries
<bddebian> Anything I can help out with?
<infinity> Not unless you happen to know the Thunderbird codebase inside out and backwards.
<bddebian> Uhm, no, sorry
<bddebian> Gnight folks, thanks infinity
<dholbach> good morning, HAPPY HUG DAY! :-)
<infinity> Is it another hug day already?
<dholbach> yeah!
<dholbach> every two weeks
<dholbach> this time we're trying to help out BenC
<dholbach> BenC: you'd better turn up in #ubuntu-bugs soon - this is *your* hug day! :)
<infinity> Idle for 12 hours... That's not a good sign. :)
<Burgundavia> BenC is Eastern US, no?
<infinity> Indeed.
<Burgundavia> which makes it 1am there
<infinity> So it does...
<janimo> infinity: hi, any news on xubu live?
<Burgundavia> infinity: new crack for you! ati just released drivers for x1x finally!
<janimo> dholbach: hi, is bugday in the kernel channel today?
<infinity> janimo: It's taking a backseat to me trying to shove some last-minute Thunderbird stuff in, then I'll do it.
<dholbach> janimo: hug day is in the #ubuntu-bugs channel
<neuralis> evolution just ate my calendars. it ate my calendars!
<infinity> Burgundavia: So I heard.
<Burgundavia> neuralis: a /server page on the ubuntu website, in the same vein as the /Website/Desktop currently being developed on the wiki. Think you could find time to work on something like that?
<neuralis> unlikely in the near term
<Burgundavia> ok
<neuralis> but i'll post to u-s and ask for those budding team members to spend some of that youthful exuberance on helping out.
<Burgundavia> that would be cool
<infinity> X Server may fail to load when using an ATI Radeon X1x00, 512MB product with certain motherboards. Further details can be found in topic number 737-22056
<infinity> Go ATI.
<Burgundavia> I am about to move that desktop page to the main site
<HrdwrBoB> infinity: and the X1X00 is slower than X800XL and 6800xx w
<janimo> dholbach: regarding the gnumeric-gtk split, if debian maintainer keeps silent what do you think of patching ubuntu before debian?
<janimo> I think we have a delta now with the newer versions already
<dholbach> janimo: we tried to merge every now and then, so it should be ok around now
<janimo> oh, I see. so hi is active ;)
<janimo> he
<neuralis> Burgundavia: do you know of any decent calendaring software.. that a) works and b) doesn't eat your calendars?
<Burgundavia> neuralis: calendar.google.com?
<neuralis> offline.
<Burgundavia> I would use dates, which uses eds as a backend, but has a nicer frontend
<neuralis> Burgundavia: package?
<Burgundavia> debian maybe
<Burgundavia> neuralis: I have to revamp the front page of the ubuntu website to say something like "Discover Ubuntu... \n on the Desktop on the Server on the Laptop"
<neuralis> in general, i've found a bunch of awkward desktop regressions on dapper; i need to find time to file a bug salvo.
<neuralis> Burgundavia: yep
<Burgundavia> it is in my "for dapper release" timeframe todo list
<infinity> neuralis: File early, file often.  We're getting close to the point of no return where many of the bugs just can't get fixed.
<neuralis> infinity: i haven't slept in close to 2.5 days for trying to stay on top of everything that's going on; i quite literally mean "no time" :/ but point taken, i'll try and get around to this tomorrow perhaps.
<infinity> Argh, since the last LP style rollout, I can't scroll with arrow keys anymore.
<Burgundavia> the new menus are cool, but the theme needs work
<infinity> neuralis: Trust me; I can relate.
* Burgundavia wonders why there is a massive cross post between ubuntu-users and desktop-devel
<infinity> mdz: A UVF exception for the new fglrx (which FINALLY supports the X1xxx series) would be lovely.
<lamont> infinity: uh... I know that postfix doesn't have a direct dependency on *sasl*
<infinity> lamont: It has a direct dependency on libsasl2.
<infinity> lamont: At least, the package does, via shlibdeps.
<lamont> ah, right
<lamont> yeah... it does at that
<infinity> And libsasl2 pulls in libsasl2-modules (in Ubuntu, at any rate, that bug really should be fixed in Debian)
<lamont> must use brain.
<infinity> And sasl2-bin is not required, afaict, to do SASL/TLS auth.
<lamont> right - just to manage it. :-)
<infinity> So, it should all go, out of the box.
<infinity> Now, I'll go back to my filty exim4-using cave. :)
<lamont> mind you, my list of potential-enhancements for postfix is to make SASL a loadable module, rather than hard-included.
<infinity> lamont: Would that break it out into another package?
* lamont attacks level 774 of kobodl
<lamont> infinity: yeah, just like postfix-ldap et al
<infinity> lamont: If so, then that package would still get the shlibdeps, if not, then postfix would still get it.
<infinity> Either way, telling people to install the library is redundant. :)
<lamont> yeah
<lamont> ah, right
<pitti> Good morning
<infinity> (And my argument is that it's just plain confusing... "Why do I need to "apt-get install apache2 apache2-common mime-support libmagic1 libc6 ... to make apache work?  Ubuntu is dumb!")
<infinity> But for whatever reason, our users seem to hand out this sort of advice on a regular basis, since it makes you look cooler (I guess?) than just saying "apt-get install apache2" or "apt-get install postfix"
<infinity> Riddell: How would you feel about fixing debtags to not take a bazillion hours to timeout in the face of no network?  That's a killer for kubuntu installaiton time on a machine with no external access.
<infinity> Riddell: Not to mention the livefs build time. :)
<infinity> * note: "a bazillion hours" may be hyperbole.
<lamont> infinity: you mean it only really takes 1/2 of a bazillion?
<infinity> Maybe even a quarter of a bazillion.
<pitti> doko: do your cupsys changes repair the weird chars in the log and PPD installation?
<doko> pitti: I don't know yet, just adding the symlinks and moving some more files around
<robitaille> pitti:  any update on the Firefox 1.0.8 security upgrade?  (I got asked about it at work today)
<pitti> robitaille: tarballs should be released by MOzilla today
<robitaille> so it will be in Breezy soonish?
<pitti> robitaille: but I doubt that we can push out the update today, it's a hell of a lot of work and needs some testing, too
<pitti> robitaille: yes, around Tuesday or Wednesday, I'd expect
<pitti> robitaille: many people already complained about releasing new security updates right before a 4-day weekend :/
<robitaille> that's great news.  Breezy's firefox has been vulnerable for a while now to a few things
<pitti> robitaille: yes, sorry for that, but these tarballs were promised for the start of March :/
<robitaille> Personally I gave up waiting and installed 1.5 on my Breezy home PC :)
<Burgundavia> Mozilla, ah fun
<Kamion> Burgundavia: BTW, please don't assign bugs to ubuntu-archive - subscribing ubuntu-archive is fine
<Kamion> (39395)
<Burgundavia> Kamion: ah, sorry. I blame dholbach
<Burgundavia> well remember for next time
<dholbach> Burgundavia: ?
<Burgundavia> dholbach: I asked what I should do with sync requests. You said ubuntu-archive
<dholbach> yeah, but I didn'T say anything about subscribing/assigning
<Burgundavia> hmm, indeed
<dholbach> :)
<doko> bad pitti!
<pitti> doko: ?
<doko> :-)
<doko> the fontforge package contains a buggy de.po file, which is not installed by intent, but pkg-striptranslations knows "better", grabs it, and installs it.
<doko> causing the fontforge crash with locale de
<dholbach> fix the de.po! :)
<doko> dholbach: dude, first find that damn thing ;-P
<pitti> Kamion: oh, wow, I just wanted to add some CVEs to the sync bugs, but you were faster. Thanks :)
<doko> pitti: so the outcome for language specific bugs is: please remove the language-pack-<lang>-* packages and try again ...
<Kamion> pitti: well, go ahead and add the CVEs anyway, of course ...
<pitti> oh, I'll just add them to ubuntu-cve instead, they are more useful there
<janimo> pitti,dholbach for adding dh_iconcache to xfce cdbs class, file a bug or upload myself?
<pitti> janimo: that's yours, so just go ahead
<dholbach> yeah, just DOIT!
<janimo> ok, just wanted to make sure we avoid simultaneous uploads with same version and different changes, as it soemtimes happens :)
<dholbach> yeah :)
<doko> <doko> pitti: what is rationale to strip po files, which you do not find in debian/?
<sivang> morning 
<infinity> Kamion: How do you feel about a UVF exception for a new fglrx that finally supports the X1xxx series? (or do you want me to bug mdz?)
<infinity> Kamion: Also, your console-data upload is FTBFS on all arches with PC kemaps (so, everywhere but powerpc)
<sivang> infinity: that could add support for the T/X/60's ? :)
<infinity> sivang: In the non-free driver, yes.
<infinity> sivang: We may also manage to shoehorn in support in the free driver before release, but that'll still be another week or two of fiddling.
<sivang> infinity: I see, yes, I've asked mjg59 and he said that would have to be fiddling with the mode changes code or so.
<mvo> sivang: the x60s run all with the i810 driver AFAIK
<sivang> mvo: for thos that don't use ATI maybe?
<infinity> Err, yeah, I think all the X60s are Intel video.
<Kamion> infinity: I'd rather leave fglrx to mdz; I don't have much experience with it
<Kamion> infinity: thanks, I'll prod console-data
<mvo> sivang: I think there is no model with a ATI (for the x60)
<infinity> But most of the T60s are ATI.
<mvo> yeah
<sivang> oh :
<mvo> especially the interessting ones with the xsvga screens
<mvo> :)
* infinity pats his high-res screen.
<infinity> Anyhow.  It's long weekend time for me, kids.
<infinity> fglrx update will have to wait until Tuesday.
<sivang> mvo: Well, I've already gotten my T43p with 1400x1050 as infinity recommended, and although fglrx is buggy with this V3200 it's sweet as can be :)
<janimo> Kamion, since there's space left on the xubuntu cd which language package do you think I should add besides what is on the ubuntu CD?
<sivang> (but good to know about this so when people ask me if we suport the new ones, I can say technically yes :))
<janimo> infinity: xubuntu live will wait till Tuesday too?
<dholbach> infinity: have a good time! :)
<sivang> infinity: laters dude
<mvo> sivang: is it a 14" model? 
<sivang> mvo: yes, very light, even with the 9cell batt
<Kamion> janimo: there's a standard ordering, check with pitti who has a script to help
<mvo> sivang: nice
<janimo> thanks
<infinity> janimo: Most likely, yes.  This is my first vacation in a long time, and I intend to actually take it. :)
<janimo> infinity: ok, have a nice weekend :)
<infinity> janimo: You'll have live stuff in time for beta, though.
<janimo> ok, I just wanted to test out espresso, but I hope it'll just work :)
<sivang> mvo: the first one I got (that you saw me with over Montreal) was similar, only had 2.0G CPU, but when I arrived in .il and had problems (mainly ots of dead pixels) I realized I had not been given the internatinal warranty I paid for, so I returned it and got one her ein .il, which costs higher but at least is an official IBM inventory part number and has all the warranty etc.
<sivang> mvo: a happy ending for me at last :)
<pitti> doko: *confused* we don't stip po files, what do you mean?
<pitti> Riddell: GOOD NEWS!!!1!
<doko> pitti: but you generate them
<janimo> pitti, which is the order in which language-packs and support files are to be put on the cd?
<sivang> mvo: do you recall where to set cdrecord wait time? infinity noted to me that patching is not neccessary, as you can set the wait time to a minimum of 2 secs.
<doko> from the po file that you extract
<pitti> doko: hm, I'm afraid I'm confused, can you please try to explain it again to a neandertal?
<pitti> janimo: http://people.ubuntu.com/~pitti/bzr/langpack-o-matic/langpacksize
<janimo> pitti, thanks
<pitti> janimo: this is a script that calculates the cumulative size of Ubuntu or Kubuntu langpacks
<mvo> sivang: let me have a look
<pitti> janimo: you might find it useful on its own, but in the header there's the list of priority languages
<janimo> pitti, are all those shipped in ubuntu/kubuntu/edubuntu?
<pitti> janimo: *-pack, yes, however, we only ship l-support-en, since support is huuuuge
<janimo> pitti, some of the support could fit on xubuntu (someone asked for zh)
<mvo> sivang: right, there is a --gracetime options it seems, minimum is 2
<janimo> pitti, is shipping any of these is not recommended even if there is space?
<pitti> janimo: sure, your CD should be much smaller, feel free to use the space for l-support ;)
<janimo> :)
<dholbach> hey seb128!
<pitti> janimo: no, ideally we would ship all language-{pack,support}-*, but we just can't
<pitti> hey seb128 
<janimo> OOo may go on the cd too after all just not default
<seb128> hi dholbach pitti
<doko> pitti: ugh, ugh, huba huba .;-) .. fontforge includes a buggy de.po, which it does not use, does not build a corresponding .mo file and does not install it doing a make install. nevertheless pkg-stripstranslations does find the de.po file, builds the corresponding .mo file and includes this in the language packs.
<pitti> doko: aaah
<pitti> doko: me understand, me will apply club to fix
<pitti> doko: however, the easiest way would to just trash the file during package build; putting such special cases into the langpack import is neither nice nor robust
<doko> pitti: bug 39408
<Ubugtu> Malone bug 39408 in Ubuntu "pkg-striptranslations strips files it should not find" [Normal,Unconfirmed]  http://launchpad.net/bugs/39408
<pitti> doko: oooh, wait
<pitti> doko: you mean that de.po file is in debian/?
<pitti> doko: my langpack importer ignores debian/
<doko> pitti: the thing is that you have to find these files. 
<pitti> doko: carlos and I specifically agreed to just take all po files and worry about their filtering in the langpack importer, not in pkgstriptranslations
<doko> pitti: no, it's in the package source, but you cannot find a corresponding .mo file in debian
<pitti> doko: that way we can change our minds without rebuilding all packages
<leo__> hi , is it possible to have the live cd skip all the "debian-installer-alike" questions so it directly boots into gnome? preseed?
<pitti> doko: 'in debian' -> in the source package directory 'debian/'?
<pitti> oh, phone
<doko> pitti: ~lamont/public_html/translations/20060406/fontforge_0.0.20051205-0.1ubuntu2_i386_translations.tar.gz
<pitti> doko: ok, I see the tarball contents here
<Mithrandir> janimo: I did?
<pitti> doko: so you mean that ./source/fontforge-20051205/po/de.po is broken?
<sivang> hmm, Ian is not around ?
<janimo> Mithrandir: assuming you are answering my question of yesterday :)
<janimo> you answered the guy asking about persistence on xubuntu cd
<doko> pitti: yes, and rosetta should not import it, because there's no corresponding .mo file
<Kamion> leo__: sure, you should be able to preseed debian-installer/locale and kbd-chooser/method, shouldn't be much else that gets asked
<Mithrandir> janimo: yes, but that was a "about this time" not as in "this second".  Kamion probably knows the exact state.
<pitti> doko: if the po file is broken in a way that msgfmt cannot build a mo file from it, then I agree, langpack-o-matic should just ignore it
<janimo> Mithrandir: ok, actually infinity is in charge, wil be done by beta
<pitti> doko: however, if it has wrong translations and such, then the file shuold just be removed on package build; centralizing such special cases is a pain
* sivang -> breakfast
<pitti> doko: and adding code for 'oh yes, that package *generally* builds mo files from, er wait, maybe this subdirectory of po files?, but just not for these two languages' won't be funny
<Mithrandir> janimo: well, there's the livefs builds which are infinity's domain and there are the cd builds which are Colin's.
<infinity> Yay, confusion. :)
<infinity> Though, I may end up setting up the Xubuntu LiveCD builds right after I do the livefs builds.
<doko> pitti: but you can decide that from just looking at the tarball, don't you?
<infinity> I have a feeling Colin will be... Busy.
<leo__> Kamion: you rock
<Mithrandir> janimo: note that livefs != live cd.  Live fs goes on the live CD.
<pitti> doko: well, I can for the fontforge case, but can you find an algorithm for that that doesn't break for multiple domains and such?
<janimo> ok. I was not aware of that distinction.
<Mithrandir> infinity: you think Kamion'll be busy?  Never seen that happen. :-P
<infinity> :)
* Kamion <-- slacker
* pitti hands Kamion another cocktail
<infinity> Kamion: You're not meant to have time to watch IRC.  BACK TO YOUR CUBE, HACK FASTER.
<infinity> Kamion: *whip*
<doko> pitti: no, don't change anything for fontforge, just regenerate the language-pack-de after the next upload
<pitti> doko: was there a bug about that s/Oki/Okidata/?
<Kamion> Riddell: merged and pushed, thanks
<pitti> doko: I can manually stick a new de.po for fontforge into it, and rebuild just this one, yes
<doko> pitti: All other ppd packages have as manufacturer Okidata, not Oki
<pitti> ah, ok
<pitti> doko: hm, I'll apply that /usr/share/ppd/ symlink right in Debian
<Kamion> infinity: yeth, mathter
<doko> pitti: the greek lp has to be rebuilt as well
<pitti> doko: for fontforge?
<doko> yes
<pitti> doko: ok, I'll roll out update packs for greek and de in the near future
<doko> pitti: but please ignore fontforge's utf8.pot (or carlos should do)
<pitti> doko: any chance that the package could build a valid pot file? carlos needs one anyway
<doko> pitti: already fixed ;-)
* pitti hugs doko
<mdke> infinity, my bad then, must have been something else not working
<mdke> infinity, sorry for blaming you, perhaps I wanted sasl2-bin
<pitti> doko: I finished my first shot at cupsys 1.1.99.rc2-0ubuntu1
<pitti> doko: can I ask you for testing them and building me i386 packages?
<pitti> doko: http://people.ubuntu.com/~pitti/packages/cupsys/  ; sources are up, amd64 debs are scp'ing
<heno-live> Mithrandir, Kamion: posting from the live CD with the high contrast theme by default. It seems to work well :)
<pitti> doko: I did a quick upgrade test from current dapper and a fresh reinstall, and everything works well for me
<doko> pitti: will do
* pitti hugs doko
<heno-live> Now I just have to test the other versions. Thanks for your great work on this!
<pitti> doko: if I have i386 debs there, I'll ask on u-devel for some broader testing
<pitti> doko: all debs are up now
<Kamion> heno-live: great, thanks
* Kamion is fixing a complicated espresso issue on powerpc - we have to have both powerpc and powerpc64-smp kernels on the live filesystem, but we only want one on the installed system
<Kamion> fortunately I already have all the code needed to figure out which kernels are unsuitable and all the code needed to remove the packages - I just need to glue it all together
<Riddell> whiprush: pong
<heno-live> btw, Espresso looks good in high contrast mode
<Riddell> pitti: hmm?
<heno-live> next, we'll see if will speak to the screen reader
<Mithrandir> heno-live: yay. :-)
<pitti> Riddell: I talked to that friend of mine, and he says fixing kdeprinter is not at all complicated, at least not to get it running
<pitti> Riddell: he already did some small hacks, after that kdeprinter worked just fine
<Treenaks> great, new fglrx with (claimed) X1000 support
<Riddell> pitti: got a patch for us to try?
<pitti> Riddell: btw, can you test printing at all ATM? I have 1.2rc2 packaged at http://people.ubuntu.com/~pitti/packages/cupsys/
<Riddell> pitti: ooh, even amd64 debs, how did you know? :)
<pitti> Riddell: I don't have it yet, I have asked him
<pitti> Riddell: I only have amd64 here :)
<pitti> Riddell: he's building one
<MidMark> hi guys, only one question: there was a recent update (1-2 days) that break user's passwords? I cannot boot anymore to my dapper
<MidMark> cannot login sorry
<pitti> Riddell: I only have amd64 here :)
<pitti> Riddell: anyway, there are still some issues, but his patch should make printing work at all
<pitti> Riddell: he'll write something up and prepare a reasonable patch; could we give him the bounty if that's successful?
<pitti> MidMark: hm, not really; maybe your keyboard layout changed? there were some keyboard-related changes recently
<MidMark> pitti: but my password is without special char, and I cannot login
<pitti> hm
<pitti> MidMark: does logging in on a text console work? (Ctrl+Alt+F1)
<MidMark> ok sorry I have understand the problem
<MidMark> pitti: wait 1 minute I will explain, probably a bug... don't know now
<Riddell> pitti: sure, I'd be happy with htat
<Riddell> that
<MidMark> package to add user was updated?
<pitti> MidMark: well, yes, doko did a small fix for handling symlinks
<Riddell> sudo /etc/init.d/cupsys start
<Riddell>  * Starting Common Unix Printing System: cupsd                                                                                                cupsd: Child exited on signal 11!
<Riddell> hmm
<pitti> Riddell: bummer
<Mithrandir> dholbach: the homepage link in libsexy's description is wrong.  The new one is http://www.chipx86.com/wiki/Libsexy
<pitti> Riddell: anything in error_log? can you get a backtrace with sudo gdb --args /usr/sbin/cupsd -f ?
<MidMark> pitti: because I have added a new user, and I *think* to have added a password to this new user, after that I *think* that dupper have changed the password of my user and not in the new user...
<pitti> MidMark: no, we never change passwords
<dholbach> Mithrandir: thanks, will change that
<MidMark> pitti: probably was my fault, it's strange, but possible...
<pitti> MidMark: hm, if you boot in rescue mode and change your password with 'passwd yourlogin' to a known good value again, can you login again?
<Riddell> pitti: http://kubuntu.pastebin.com/657295
<pitti> MidMark: please, before you do that, make a copy of /etc/shadow and /etc/passwd to compare afterwards
<dholbach> Mithrandir: done
<pitti> Riddell: thanks
<MidMark> pitti: now I login with my old user and new password (that is why I cannot login) and changed the two password, now all is ok again, but I don't know why I wanted to change the password of my new user and instead I have changed passw of my existing user
<MidMark> pitti: don't know if is it clear...
<pitti> MidMark: AFAIUI that was just a confusion due to in advertedly changing the wrong user's password, and no bug then?
<mdke> seb128, have you had any reports about syntax highlighting not working on gedit?
<pitti> Riddell: http://mh21.piware.de/cups-noasync.patch
<seb128> mdke: no
<seb128> mdke: what file format?
<mdke> seb128, docbook xml
<pitti> Riddell: pretty hideous hack so far, but works for him; it basically circumvents the problematic part of the code (it's not that important anyway)
<seb128> any example of such file to try?
<mdke> seb128, shall I file it directly upstream?
<mdke> seb128, sure, hang on
<seb128> mdke: let me have a look first
<MidMark> pitti: don't know, I remember that I have changed the new password and NOT the old one, but I'm not so sure... you have said that password aren't touched in the last update, so don't know what to think
<pitti> Riddell: written explanation will follow; he quickly explained on the phone
<mdke> seb128, svn checkout https://docteam.ubuntu.com/repos/branches/dapper/ubuntu/desktopguide/C/ ?
<mdke> seb128, oh actually
<mdke> seb128, just use something on your system: /usr/share/ubuntu-docs/ubuntu/desktopguide/C
<MidMark> pitti: I can try to reproduce the bug, if it is a bug and not a mistake
<pitti> MidMark: yes, please, that would be nice
<MidMark> pitti: ok I'll try now...
<mdke> seb128, common-tasks.xml or something
<seb128> mdke: yeah, does the same here, I'm looking on it
<mdke> seb128, thanks, lemme know if you want to do anything. Also, I remember seeing a bug on gedit about using the gnome system-wide monospace font, did that get rejected?
<mdke> I think that's a good default to have
<seb128> I don't think it got rejected no
<mdke> i'll go and search for it
<seb128> mdke: k, I've the bug fixed
<MidMark> pitti: ok I understand what was the problem, and I think it is a kind of bug
<MidMark> pitti: I will explain in details...
<seb128> mdke: /usr/share/gtksourceview-1.0/language-specs/xml.lang the mimetype list should have "application/docbook+xml"
<seb128> mdke: I've fixing that forwarding upstream right now
<mdke> seb128, you rock
<seb128> thank you ;)
<mdke> seb128, the bug is #2961 for the font, but it's marked as fixed... but it's not ;)
<mdke> i closed it, in fact
<mdke> perhaps it's come back
<MidMark> pitti: I think it is a kde related bug, should I have to explain in kubuntu-devel or also here?
<Riddell> MidMark: hmm?
<pitti> MidMark: best thing would be to file a bug
<pitti> or bother Riddell :)
<MidMark> ok I'll explain here, I'm 90% sure is a kde bug
<Riddell> pitti: recompiling from your cups source gets rid of the segfault
<pitti> Riddell: cool
<MidMark> kde-bug: I have created a new user (I have kubuntu) with kde: users and groups and clicked ok, then I have clicked again to my new user, go to password, and set a new password, then I clicked to my existing user (another one) and the tool remember that I was in password changing part AND ALSO remember the password that I have typed in the previuos user, so I think I have clicked OK (instead of Cancel) and the program changed
<MidMark> pitti, Riddel: is it enough clear? I have tried another time and it is exactly like this
<seb128> MidMark: please use launchpad or an another chan for bugs like that
<MidMark> ok, have you the link in your hand?
<pitti> https://launchpad.net/distros/ubuntu/+filebug
<MidMark> pitti: thanx
<Riddell> MidMark: hmm, confirmed, that's quite nasty
<MidMark> pitti: I have only a bugzilla account in ubuntu, it works with the same login&passw or I have to register another time?
<mdke> MidMark, you need to register on launchpad to use almost all ubuntu services now
<MidMark> mdke: so I cannot use bugzilla account in launchpad?
<MidMark> Riddel: I create a bug report ok?
<mdke> MidMark, erm. give it a try, it might have been imported.
<Kamion> a launchpad account was probably created, but the password may not have been set
<mdke> MidMark, search for your email address at https://launchpad.net/people (that will tell you if you have an account)
<Kamion> see https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-January/000051.html
<MidMark> kamion: ok now I proceed with transition
<pitti> Riddell: hm, wrt your crash, is anything wrong with your resolving of 'localhost'?
<pitti> Riddell: I can see that the httpGetHostname() function isn't very robust, I'll add some checks to it
<Riddell> pitti: localhost is in /etc/hosts
<pitti> Riddell: and your /etc/hostname is, too?
<Riddell>  /etc/hostname is the name of the computer
<pitti> Riddell: I guess gethostname() failed and left the returned hostname uninitialized
<pitti> Riddell: I'll fix and pass to upstream
<pitti> doko, Riddell: how's 1.2rc2 looking so far, apart from the absence of authentication in the web interface?
<pitti> that friend of mine just tried it, too, worked reasonably for him
<Riddell> pitti: fails equally with kdeprint
<pitti> Riddell: oh, even with the patch I sent you?
<Riddell> pitti: havn't seen that yet, still going through my morning's e-mails :(
<pitti> Riddell: I IRCed it to you
<pitti>  <pitti> Riddell: http://mh21.piware.de/cups-noasync.patch
<Riddell> oh, how did I miss thta
<Riddell> ok, let me try it
<pitti> <mdke> seb128, docbook xml
<pitti> <pitti> Riddell: pretty hideous hack so far, but works for him; it basically circumvents the problematic part of the code (it's not that important anyway)
<pitti> Riddell: it basically skips the asynchronous check whether cupsys is running; it doesn't seem to be vital, it works fine if cupsd runs and I was told that it behaves sane if cupsd isn't running
<pitti> Riddell: so, the real solution would be to replace that with a proper thread which calls the CUPS API and reacts appropriately
<pitti> but that's sth for upstream
<doko> pitti: it does work with my OfficeJet & hplip 0.9.7
<pitti> yay
<doko> didn't check with 0.9.6, waiting for mdz to check out 0.9.7
<pitti> doko: can you put your i386 debs somewhere in the DC?
<doko> sure, wait ...
<mdke> pitti, mmm?
<pitti> mdke: ECONTEXT
<mdke> pitti, heh k
<mdke> by the way, is it worth filing bugs for the font changes in firefox/epiphany recently? or are these intentional?
<giftnudel> mdke: were they dejavu and are now different?
<mdke> giftnudel, i have no idea, they are suddenly ugly. previously they were similar to breezy, I think
<giftnudel> mdke: look here http://blogs.gnome.org/view/jamesh/2006/04/06/0 , this might be related
<Treenaks> That page still has weird ligatures, though my fonts are set to the defaults now
<mdke> giftnudel, I don't understand it enough. All I know is that everything is ugly :/
<mdke> so, it's a bug, rather than intentional?
<giftnudel> I think the switch was intentional, but the result not
<jamesh> mdke: what does "fc-match sans-serif" print?
<mdke> jamesh, DejaVuSans.ttf: "DejaVu Sans" "Book"
<Treenaks> DejaVuSans.ttf: "DejaVu Sans" "Book"
<jamesh> mdke: what sort of ugly are you talking about, btw?
<Treenaks> jamesh: Very badly antialiased fonts, too high, and not wide enough (or of the right height, but not wide enough)
<mdke> jamesh, just poor readability
<mdke> yeah, what Treenaks says
<jamesh> but different to what is described here? https://launchpad.net/distros/ubuntu/+source/firefox/+bug/37828
<Ubugtu> Malone bug 37828 in firefox "Text rendered incorrectly in presence of ligatures and justified text" [Normal,Unconfirmed]  
<giftnudel> dejavu has an issue with ligatures (special characters for combinations like ft which should provide better readability) 
<giftnudel> which is the bug ...
<jamesh> giftnudel: more specifically, firefox has an issue with ligatures and DejaVu provides ligature OpenType tables ...
<giftnudel> oh, ok
<mdke> i don't know what ligatures are
<giftnudel> my explanation abovE?
* mdke looks
<Treenaks> jamesh: http://www.xs4all.nl/~mvdstree/screenshot.png
<Treenaks> jamesh: yes, it's different from 37828
<mdke> yes, different to that
<mdke> the fonts are simply too high, and poorly focused
<jamesh> mdke: a ligature is a single glyph that represents multiple characters
<jamesh> mdke: e.g. there are glyphs in the DejaVu Sans font to represent the character sequences ff, fi, ffi, fl, ffl
<mdke> my problem is quite well represented by Treenaks' screenshot, I don't have problems with character sequences
<Treenaks> mdke: http://blogs.gnome.org/view/jamesh/2006/04/06/0 does have the 37828 problem for me (in the word 'verified', for example)
<mdke> i'll do my own screenshot
<Treenaks> jamesh: ^^
<mdke> Treenaks, i don't see that bug.
<jamesh> Treenaks: sure.  The theme there uses the default sans-serif font with justified text
<jamesh> which is enough to trigger rendering problems on dapper
<Treenaks> jamesh: hmm.. it uses standard 'sans-serif'? what does planet use then?
<mdke> http://www.mdke.org/images/badfonts.png
<jamesh> Treenaks: the default sans-serif font with left aligned text
<Treenaks> jamesh: the font got smaller with today's update..
<doko> pitti: sorry forgot about http://people.ubuntu.com/~doko/print/
<pitti> doko: cool, thanks; I'll copy the cups debs to my people page and ask for more testing 
<doko> pitti: wait, some questions ...
<doko_> pitti: E [13/Apr/2006:13:31:53 +0200]  [cups-driverd]  Unable to open driver directory "/usr/lib/cups/driver": No such file or directory
<doko_> ?
<doko_> E [13/Apr/2006:07:35:42 +0200]  cupsdLoadAllClasses: Unable to open /etc/cups/classes.conf - Datei oder Verzeichnis nicht gefunden
<doko_> E [13/Apr/2006:07:35:42 +0200]  LoadAllSubscriptions: Unable to open /etc/cups/subscriptions.conf - Datei oder Verzeichnis nicht gefunden
<doko_> E [13/Apr/2006:09:14:47 +0200]  cupsdLoadAllClasses: Unable to open /etc/cups/classes.conf - Datei oder Verzeichnis nicht gefunden
<doko_> E [13/Apr/2006:09:14:47 +0200]  LoadAllSubscriptions: Unable to open /etc/cups/subscriptions.conf - Datei oder Verzeichnis nicht gefunden
<doko_> E [13/Apr/2006:12:49:10 +0200]  [cups-driverd]  Unable to open driver directory "/usr/lib/cups/driver": No such file or directory
<doko_> E [13/Apr/2006:12:50:01 +0200]  CUPS-Add-Modify-Printer: Unauthorized
<pitti> doko_: all but the last warnings aren't interesting (the files just haven't been created yet, but will be if you use the web interface)
<pitti> doko_: I get the last one as well, but it works fine; I assume it first tries to add the printer, is told that it needs auth, provides auth, and tries again
<Riddell> pitti: definate progress, I can add printers and it prints fine now.  on first start it still gives an error "can't list printers" when cups has no printers defined yet, and there's a compile error in kdeprint/cups/ipprequest.cpp where it uses _ipp_free_attr
<Riddell> enrico: is it possible to have debtags not take ages to timeout on installation with no network?
<pitti> Riddell: cool, that's at least promising
<pitti> Riddell: mh21 also told me about a list of other things that need to be cleaned up (like restarting cups, starting/stopping printers, etc.)
<pitti> Riddell: i. e. kdeprint often manually constructs URLs, but they don't work if the local Unix socket is used, etc. pp.
<Riddell> yeah, kdeprint hasn't been properly maintained for a while now :(
<Riddell> pitti: I'll probably upload a kdelibs with this half-fix today to see if it works for other people, does your friend have a name I can put to acknowledge him?
<pitti> Riddell: Michael Hofmann
<Riddell> thanks
<pitti> Riddell: but as I said, this is not his final patch
<pitti> Riddell: just a first shot to get it working at all
<pitti> Riddell: but sure, it's certainly better than the current package, so go ahead :)
<Riddell> sure, but I need to upload kdelibs anyway so no hard in slightly un-breaking stuff while I'm at it
<enrico> Riddell: the new debtags already does it
<enrico> otherwise, you'll have to patch libapt-front
<Riddell> enrico: right, suspected that might be the case, thanks
<enrico> the fetcher used, BTW, is the one from libapt-pkg
<Riddell> yeah, I saw that
<enrico> Riddell: I implemented non-network update in debtags to work around this problem
<enrico> I'm sorry you're stuck with an older version
<enrico> I can try to assist you with a backport, if you want
<enrico> I mean, a backport of this feature only
<Riddell> that would be cool
<enrico> Riddell: needs a bit of coordination
<enrico> Riddell: today I'll be afk most of the day (and evening)
<enrico> Riddell: tomorrow I'll be on a plane
<enrico> Riddell: the day after tomorrow is easter saturday
<Kamion> ("Holy Saturday" - Easter Saturday is the following week)
<Kamion> (in English terminology anyway)
<enrico> Riddell: can you send a mail to libapt-front-devel@lists.alioth.debian.org pointing to the ubuntu packages you're working on?  I can pick it up from there and try to work out what minimal patch can solve the issue
<enrico> Kamion: thanks
<Riddell> so easter saturday is 8 days after easter friday?
<Kamion> no, one day after. Tomorrow is Good Friday
<Riddell> oh, so it's actually still a week until easter proper?
<Kamion> ? no, three days to Easter Sunday
<Riddell> gosh, this church stuff is so confusing
<enrico> Kamion: after easter sunday is easter monday, but after easter monday isn't easter tuesday, right?
<Kamion> Holy Thursday, Good Friday, Holy Saturday, Easter Sunday <-- Easter proper, Easter {Monday..Saturday}
<enrico> Kamion: ah, ok
<enrico> Kamion: there's Palm Sunday as well?
<enrico> Kamion: a month before easter, isn't it?
<jjesse> holy thursday is also maundy thursday depending on relgion
<Riddell> Kamion: while I have your attention, could you promote kmailcvt to main?  it's from kdepim and all deps are in main
<Kamion> no, Palm Sunday was the Sunday just past, also called Passion Sunday
<jjesse> palm sunday is the sunday before easter
<enrico> jjesse: ok
<enrico> jjesse: when's ipod sunday?
* enrico ducks
<Kamion> Riddell: done
<jjesse> enrico: is that the day you buy me an ipod?
<Riddell> Kamion: and can you add the kubuntu espresso .desktop file to be copies to ~/Desktop on the live CD?  it should be quite useable now
<Kamion> jjesse: more depending on country I thought - that was an English thing
<enrico> Riddell: from tomorrow late night to the 24th morning I'll be in Manchester
<enrico> Riddell: if needed, we can phone each others :)
<Kamion> Riddell: if Mithrandir's around today, send him a casper patch
<jjesse> maundy thursday is episcopalian (sp??) and lutheran
<Treenaks> 'calendar' helps ;)
<Riddell> Kamion: where do I find the casper repository?
<Kamion> jjesse: it's common phrasing among all denominations here (England)
<Kamion> Riddell: http://people.ubuntu.com/~tfheen/bzr/casper/trunk/
<Riddell> Kamion: thanks
<jjesse> Kamion: intersting i was not aware of that
<enrico> jjesse: and Pungenday, the 30th day of Discord in the YOLD 3172 for discordians :)
<pitti> doko: ok, I'll attack the locales in l-support-* now
<doko> cool, like I can upload OOo on Tuesday again
<pitti> Kinnison: AYT?
<Kinnison> pitti: yes
<pitti> Kinnison: I need to upload all 73 language-support-* packages
<Kinnison> pitti: same drill as before?
<pitti> Kinnison: maybe we should better handle that quietly
<pitti> Kinnison: depends on how much work it is for you
<Kinnison> pitti: not much at all. As before, prepare a dir with all the uploads and I'll rsync it
<pitti> Kinnison: but the changelogs are uninteresting, and 73 is quite much spam
<pitti> Kinnison: so, there we are: rookery:/srv/language-packs.ubuntu.com/dapper/sources-support/
<pitti> Kinnison: it contains the source packages and signed .changes
<Kinnison> cool
<pitti> Kinnison: thank you!
<pitti> doko: so, there you have :)
<Kinnison> pitti: processing now
<Kinnison> pitti: seems to be okay
<pitti> yay
<Kinnison> enjoy :-)
<Kinnison> They'll be in the 14:00 (UTC) cycle I guess
<doko> is there a way to see, if an init script is started during the boot process (to avoid starting another daemon, which will be started later anyway)?
<pitti> Riddell: I'm sure I already asked, but I forgot: any chance to drop/change the imlib build-dep for kdegraphics? it's the only package that wants imlib in main, and imlib in turn holds gtk1.2 in main
<bddebian> Heya folks
<Riddell> pitti: imlib 2 seems quite different, kdegraphics doesn't compile with it
<pitti> hm, ok
<Treenaks> so.. KDE depends ons GTK?
<Riddell> Treenaks: build-dep I assume
<Riddell> Treenaks: although scim brings in a bunch of gnome libraries :(
<heno> Mithrandir: there are a few things that need tweaking on the live CD WRT AT (as might be expected). What pkg should I file that against, casper?
<Kamion> heno: generally, yeah, unless it's obviously something where some other individual package's defaults can be improved
* pitti will unseed gtkglarea5-dev now, since nothing actually uses it and it keeps gtk1.2 in main; speak NOW if you object :)
<heno> Kamion: ok, cool. Yeah one is obviously a gok bug, but the rest are config things
<heno> thx
<doko> pitti: the cupsys init script is missing a reload action (available in unstable)
<pitti> doko: I know
<pitti> doko: reload doesn't work as non-root
<pitti> doko: and reload is optional by Debian Policy (force-reload must exist, and it does)
<mvo> hm, update-manager for breezy-updates seems to be not build yet, I wonder if there is a problem with the uplaod
<Kamion> mvo: I haven't approved it yet because as I said yesterday I don't especially like the version number; you're calling it FOO~backport1 when the source package is very different from version FOO
<Kamion> generally anything identifying as "backport" should be pretty much the same as the backported thing
<mvo> ok
<mvo> I'll rename it ~breezy1 and reupload?
<Kamion> is it intentionally very different?
<mvo> yes
<mvo> the complete SoftwareProperties code remains the old code, because the interaction between the it and synaptic changed in dapper
<mvo> and I don't want to mess around there
<mvo> so the complete SoftwareProperties/ part is essentially 0.37, but the UpdateManager/ bits are from 0.41
* mvo thinks that this is a clear hint that the package/bzr archive should be split
<Kamion> ah, I see
<Kamion> -Description: Ubuntu 6.04 "Dapper Drake"
<Kamion> +Description: Breezy 6.04 "Dapper Drake"
<mvo> *cough*
<mvo> right
<Kamion> that looks wrong :) and 6.04 should be 6.06 now
<mvo> :)
<Kamion> also the filename "ReleaseAnnouncement" is misspelt - dunno how hard that is to fix
<Kamion> (as Anouncement
<Kamion> )
<mvo> oh, thanks
<mvo> Not hard at all to fix
<Kamion> there are some junk .moved files in the tarball
<Kamion> debian/changelog~.moved.moved.moved :-)
* mvo coughs
<Kamion> bzr is a bit funny like that
<Kamion> I think the rest is fine, so reupload with ~breezy1 and I'll nudge it through
<Kamion> sorry for the delay on feedbac
<Kamion> k
<mvo> no problem and thanks for this review!
<Kamion> distro team meeting in #ubuntu-meeting now, in case anyone's forgotten
<KaiL_> ah, new ATi-Drivers for X1300-X1900
<mdke> Treenaks, #39447 has the readability issue with the fonts
<mdke> bug #39447
<Ubugtu> Malone bug 39447 in fontconfig "New fontconfig update degrades appearance of fonts" [Normal,Confirmed]  http://launchpad.net/bugs/39447
<Treenaks> I see
<janimo> doko, about how much space does OOo take up on the install CD?
<janimo> is openoffice.org by itself enough for a working install?
<janimo> I see there are other recommended packages
<doko> janimo: $ apt-cache show openoffice.org-core|grep ^Size
<doko> Size: 29659168
<janimo> doko, so -core package is enough for a working install?
<doko> you have to do that for all related packages, probably you'll arrive at about 80MB
<janimo> ah
<doko> you may want to include openoffice.org-gcj
<janimo> so 80M, does that include the gtk interface?
<doko> $ apt-cache show openoffice.org-gnome|grep ^Size
<doko> Size: 207354
<janimo> doko, I don;t know much about OOo, just thinking it may be good to put in on xubuntu CD if there is space left
<doko> sure
<janimo> doko, does that in turn bring all gnome libs in not just gtk right?
<janimo> the description mentions g-vfs
<janimo> hmm, yes
<doko> $ apt-cache show openoffice.org-gnome|grep ^Depends
<doko> Depends: libatk1.0-0 (>= 1.9.0), libbonobo2-0 (>= 2.8.0), libc6 (>= 2.3.5-1), libcairo2 (>= 1.0.2-2), libfontconfig1 (>= 2.3.0), libgcc1 (>= 1:4.0.2), libgconf2-4 (>= 2.11.1), libglib2.0-0 (>= 2.8.5), libgnomevfs2-0 (>= 2.12.0), libgtk2.0-0 (>= 2.8.0), liborbit2 (>= 1:2.10.0), libpango1.0-0 (>= 1.10.4), libstdc++6 (>= 4.0.2-4), libstlport4.6c2, libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxi6, libxinerama1, libxrandr2, libxren
<doko> der1 (>= 1:0.9.0.2), openoffice.org-core (>> 2.0.2)
<janimo> thank, yeah I was thinking aloud :)
<janimo> is it really ugly without the gtk stuff?
<mdke> I'd like to file a bug about vi being the default text editor: what package handles those defaults?
<Treenaks> mdke: the packages themselves do, using the alternatives system
<janimo> doko, would I also need the trasnsitional packages which are in ubuntu ship seed?
<mdke> Treenaks, so it's a bug in "vim"?
<Treenaks> mdke: no, it's a feature ;)
<Treenaks> imho
<pitti> vim++
<pitti> :)
<doko> janimo: you would save 190 bytes per package ;-P
<mdke> Treenaks, oh please.
<Treenaks> mdke: Dropping to the shell is a bug. Not being able to cope with the shell is not a bug.
<mdke> vim may be good, but it's not a good default
<janimo> doko, I know :) but is it needed for some update scenario?
<janimo> anyway I'll put htose then if OOo goes on the cd
<mdke> Treenaks, that's dreamland, as you know. There is a middle ground between those two things
<Treenaks> mdke: fix the problem, not hack the solution
<doko> sure, for update from breezy
<janimo> ok
<mdke> Treenaks, right now, there is no gui to handle cron, that I know of. it's a common thing for a new user to drop to the command line and edit the crontab. Now, the new user has to learn vim basics to do it
<mdke> that doesn't make a lot of sense
<Treenaks> mdke: How do you know it's a common thing?
<Treenaks> mdke: Most new users I've seen don't know cron _exists_
<Treenaks> mdke: and there's gnome-schedule
<mdke> Treenaks, because we're often asked to deal with it in the guide. Especially doing a command on each boot
<janimo> Kamion, are livecd mem requirements >128M now?
<Kamion> janimo: I have no idea offhand
<mdke> Treenaks, anyway, that is one example of many. There are loads of command line tasks that intermediate users want to know, without having to learn ":wq" to do it
<Kamion> mdke: I'm sure we always intended the default editor to be nano, and I'm sure it used to be nano too
<janimo> ok, since ogra said people run it on 256M in the context of talking about low mem :)
<Treenaks> mdke: tell them to 'nano blah'
<mdke> Kamion, yeah, it was
<Treenaks> mdke: problem solved
<ogra> janimo, yes, but i wanted to hear if 256M is low or not :)
<mdke> Treenaks, no... because lots of programs use the default editor, without you calling the name of the editor on the command line
<ogra> seamms nobody measured the minimal requirements yet
<mdke> crontab is an example, there are others
<janimo> ogra, 256M is a lot :)
<mdke> Kamion, so do I file the bug on "nano"?
<Kamion> mdke: dunno whether nano or vim is at fault, but I suppose nano is a good start
<mdke> Kamion, alright. Thanks!
<ogra> janimo, 256M is the smalles "normal" machine i have around here (the smaller ones are thin client hardware without local CDRom)
<bddebian> Yeah, that "bug" blows
* bddebian hugs his nano
<Kamion> you can always boot with mem=128M or whatever to test
<janimo> ogra, the machines around here are 64, 192 and 512 all with cds. I'd still prefer 256 to not be considered low ;)
<Kamion> don't have to actually pull out memory sticks
<janimo> sure
<janimo> or qemu
<Yagisan> ogra: I have a box here with 112MB
<ogra> Yagisan, as a "non thin client" ?
<Kamion> if you have a box on which qemu is actually bearably fast, more power to you
<Yagisan> ogra: not yet
<ogra> heh
<janimo> Kamion, actually is about as fast as the low-end machines that are to be emulated :)
<janimo> that is slooow
<Kamion> d-i doesn't take five minutes just to get to the first screen on any real machine I've ever used it on
<mdke> Kamion, it's at bug #39469, thanks
<Ubugtu> Malone bug 39469 in vim "Nano is not the default editor, and should be" [Normal,Unconfirmed]  http://launchpad.net/bugs/39469
<janimo> Kamion, hmm it was not quite as slow here. 1,73 Ghz laptop
<bddebian> mdke: You haven't fixed that yet? :-)
<janimo> although I'll need to try the qemu kernel accelerator sometime
<pitti> mdke: hm, so vim is prio 20, vim-gtk/gnome is prio 40, nano is prio 40, too
<pitti> mdke: did you get plain text mode vim, or gvim?
<jjesse> vim is the default for kubuntu as well which i wish was nano
<jjesse> it used to be nano for kubuntu
<mdke> pitti, plain text. Just installed from flight 6 yesterday and upgraded.
<pitti> hm, I get text mode vim here as well
<jjesse> it threw me off when i tried to commit docs via svn and didn't remember the sequeence to quit vim :(
<ogra> doesnt gvim fall back to vim if DISPLAY isnt set ? 
<mdke> bddebian, I'm better at filing bugs than fixing them :/
<bddebian> Heh
<jjesse> mdke: same for me :)
<ogra> pitti, try "gvim ./blah.txt" on a console, it will complain about DISPLAY and fall back to vim ...
<mdke> that must be the reason
<pitti> ogra: no, 'command not found' :)
<mdke> actually no
<mdke> it isn't installed
<ogra> oh, k
<pitti> ogra: so, I don't have gvim installed, nano *should* be prefered *boggle*
<Kamion> mvo: so, how does this startup notification thing work then?
<Kamion> ideally without depending on gnome libraries, otherwise janimo will hurt me
<mvo> Kamion: how is espresso currently started? both gksu and the panel support startup notification out of the box 
<Kamion> is it just a matter of putting StartupNotify=true in the desktop file?
<Kamion> desktop file
<vuntz_> Kamion: it works this way in most of the cases, yes
<Kamion> excellent, easy then
<Kamion> does KDE support that too?
<vuntz_> (at least for standard GTK+ apps)
<vuntz_> I believe
<Kamion> I thought it was a GNOME library that handled sending the remove message back to the WM
<mvo> Kamion: how do you become root in espresso?
<Keybuk> anyone need me for anything?  going to go back offline and carry on debugging this network issue
<Kamion> mvo: gksudo in the desktop file, at least it will be once I go back to using gksudo (it was broken earlier, if you remember)
<mdke> Keybuk, is it a bug if my network interfaces are named differently in dapper than in breezy (swapped)?
<Riddell> Kamion: startup notification has been in KDE for years, you get a little bouncing mouse cursor
<mdke> Keybuk, (they seem to work)
<Kamion> Riddell: same method, StartupNotify=true in desktop file?
<Riddell> Kamion: no, it's on by default for all programmes, I've not heard of that .desktop syntax before
<Keybuk> mdke: not really, it means your /etc/iftab file wasn't correct in breezy
<vuntz_> Riddell: it's in the spec :-)
<Keybuk> I've asked mvo whether it'd be possible to fix that in the upgrade tool
<mvo> Kamion: hm, if you use gksu, it should work out of the box now
<vuntz_> " If true, it is KNOWN that the application will send a "remove" message when started with the DESKTOP_LAUNCH_ID environment variable set (see the Startup Notification Protocol Specification for more details)."
<mvo> Keybuk: I haven't looked at it yet :/
<Kamion> mvo: with or without StartupNotify=true in .desktop?
<mdke> Keybuk, okay, thanks
<mvo> Kamion: without
<Keybuk> mvo: I suspect the easiest thing is to drop me an e-mail telling me where to put the code <g>
<Kamion> ok, I'll test it
<vuntz_> Riddell: KDE should definitely put this in the .desktop file if it doesn't do it
<mvo> Kamion: I just rsynced the image, looking at it now
<vuntz_> Riddell: GNOME won't use startup notification if the line is not there
<mvo> Keybuk: yes that might be easiest :)
<sivang> anybody in for a package review and sponsered upload to universe of a HUB that's ready tp be presented to users and testing? :)
<Kamion> mvo: works, but it's a bit odd, the panel entry is "Grant Rights"
<mvo> Kamion: if you use "gksu" instead of "sudo" in the desktop file it works for me
<mvo> Kamion: oh
<mvo> Kamion: yeah I guess I should add a option for this
<Kamion> which makes me go "huh? I clicked on 'Install System Permanently'"
<Kamion> mvo: can gksu find the desktop file it was invoked from?
<Kamion> also I'm using gksudo rather than gksu, is that wrong?
<mvo> Kamion: sort of, it has a --desktop option, but you need to give it a full path IIRC
<mvo> Kamion: well, gksu and gksudo really are the same on a current ubuntu system, we use a gconf key to make gksu behave like gksudo 
<vuntz_> mvo, Kamion: use "--desktop %k" then :-)
<Kamion> tried --desktop, still says "Grant Rights"
<mvo> vuntz_: rock, that sounds cool
<mvo> Kamion: it won't display anything else until it learns that, this startup notification stuff is a pretty recent feature
<Kamion> mvo: right, thanks for the help - committed
<mvo> Kamion: cheers, I made a note to make this message a bit more sensible
<Kamion> mdz: do you think I should remove espresso's scary warning page for the beta?
<Kamion> or just make it a bit less scary? it's had the same text since pretty much the first upload
<sivang> okay, anyone, please ping me when you can, the source is at http://muse.19inch.net/~sivan/HUB/
* sivang wonders if Ian should be here at all, or already at a vacation.
<mdz> Kamion: bit less scary, mention prominently that it's a beta release and not final
<mvo> is it known that brltty asks a debconf question on install/upgrade?
<mdke> mvo, I dunno if the right person knows about it or not, but if you need a confirmation, it does here too
<tritium> I noticed that last night also, mvo
<Kamion> sivang: Ian's on vacation
<bddebian> Heya tritium
<tritium> Hi bddebian :)
<tritium> bddebian: you've been active on ubuntu-science!
<sivang> Kamion: ah I see, wheren is e supposed to come back?
<Kamion> mvo: I think that's addressed by the new version in dapper, but it doesn't seem to have built
<bddebian> tritium: Yeah, all I can fix are missing .desktop files :-(
<tritium> bddebian: a very good thing to do!
<bddebian> Yeah, but it would be nice if I could do something a little more substantial :-(
<tritium> bddebian: the sum of all you've done is quite substantial
<bddebian> pfft, but thanks
<sivang> mdke: the hebrew translated ffox start page on his way to you
<mdke> sivang, ok. thanks
<Riddell> hello mh21 
<mdke> sivang, got it, thanks
<mh21> Riddell: hi, took me a while to get gaim with irc going
<Riddell> mh21: I hear that you are going to be the saviour of kubuntu
<sivang> mdke: thank the guy who did it , erez :)
<mh21> Riddell: :-), did the patch work for basic kde printing?
<Riddell> mh21: yep, printing seems to work good now
<Riddell> mh21: but it still complains when no printers are defined that it can't get the list from cups
<Riddell> mh21: and there's a compile failure that I worked around by commenting it out
<Riddell> (I was building against pitti's rc2 packages)
<Fjodor> Does anyone know J. Bailey's nick? I sent him a mail with a patch for glibc some time ago, and would like to hear whether it will be included (haven't heard from him)...
<Riddell> jbailey
<mdke> Fjodor, jbailey
<mh21> Riddell: hmm, it worked for me while just making the kdeprint/cups directory, what failed?
<Fjodor> Thanks. So he isn't here right now...
<mh21> Riddell: I will look into the no-printers issue
<mdke> Fjodor, he's not in this channel...
<Riddell> mh21: kdeprint/cups/ipprequest.cpp
<Riddell> mh21: use of _ipp_free_attr(attr2); near the bottom
<Fjodor> Oh, fair enough :-) Does he hang out on IRC at all?
<Riddell> that's a private function and presumably it doesn't exist any more
<mdke> Fjodor, yes... he's on now
<mh21> Riddell: right, a have a second small patch from kde svn that fixes this
<Fjodor> Great, thanks
<Riddell> mh21: oh, cool
* Kinnison pokes rookery
<Kinnison> go faster damnit
<Riddell> mh21: by the way it's been suggested that canonical might be willing to pay a bounty for this, you'd need to talk to them first if you want to claim that
<Kinnison> Anyone here got a full source mirror on a machine I could get a shell on?
<Kinnison> I need to do an analysis and I don't have a source mirror here and I appear to have lost connectivity to the canonical DC
<mh21> Riddell: this would be nice, I think I will talk to pitti about it when he comes back from his easter shopping
<sivang> mdz: HUB is ready to be presented to users and receive lovely bug reports ;-) , I recalled you said it would be okay to upload it to universe when it comes to that stage, just making sure since universe is in FF.
<lemsx1> hello all
<lemsx1> when unicode_start starts in my system it stops the boot process
<lemsx1> i had to go to TTY2 and press ENTER for it to continue
<KaiL_> ..who killed the web-server?
<lemsx1> does anybody has an idea why that happens?
<Seveas> lemsx1, this channel is not for support
<lemsx1> Seveas: this is a problem in dapper, not a support but a development question (i'm working on splashy)
<lemsx1> Seveas: this problem doesn't happen with breezy
<mdke> KaiL_, if you're referring to apache, you can report bugs in the bug tracker. If you're referring to an Ubuntu website, the servers are down at the moment.
<KaiL_> the second ;)
<mdke> KaiL_, they are back now
<\sh> elmo / znarl: www.kubuntu.org port 80 is down ... 
<pitti> Riddell: re
<pitti> Riddell: I read the scrollback; mh21 will come to me in about an hour, then we'll talk about the plan for KDE and so
<Riddell> pitti: cool
<Kinnison> pitti: did those langpacks work?
<pitti> Kinnison: didn't check, apt-get updating now
<pitti> Kinnison: yep, sources looks fine, some binaries still need to be built
<Kinnison> pitti: coolio
<Kinnison> ciau
<lemsx1> ok, i think i understand why the boot process is stopped now
<lemsx1> when /etc/environment sets up the console to UTF8, unicode_start will be called
<lemsx1> and at the very end of that file a char sequence is sent to /dev/vcs/* console files
<lemsx1>  /bin/echo -n -e '\033%G' > ${DEVICE_PREFIX}${vc}
<lemsx1> that prevents the system from starting. one has to go into TTY2 and press ENTER for it to continue
<lemsx1> the temporary solution for this is:
<lemsx1>  /bin/echo -n -e '\033%G' >& ${DEVICE_PREFIX}${vc}
<lemsx1> which sends the echo redirect to the background
<phaidros__> what might be wrong if bootsplash is gone and console terminals remain black (but X come up) after complete old kernel removal?
<sebpayne> i've installed flight 6
<sebpayne> and dist-upgraded to the latest stuff
<sebpayne> and some of the wallpapers from the Examples folder have gone
<sebpayne> is that on purpose?
<Burgwork> sebpayne, they have moved into ubuntu-artwork
<sebpayne> are they still installed?
<mdke> sebpayne, yeah, it's on purpose.
<sebpayne> mdke, thanks
<sebpayne> mdke, just that they are no longer there and it seemed a nice touch
<mdke> sebpayne, well the example-content stuff is for showing off programs, and wallpapers aren't examples for any programs
<sebpayne> mdke, i see
<sebpayne> mdke, is there the possiblity of a wallpapers pckage?
<mdke> sebpayne, I personally hope so. the wallpapers haven't gone into ubuntu-artwork, at the moment
<sebpayne> mdke, awesome, thanks
<mdke> sebpayne, there is a gnome-backgrounds package, if someone were to make an ubuntu-backgrounds package, i think it would go down well
<sebpayne> mdke, just something simple to get rid of the cranes
<sebpayne> mdke, i've had experience with package making - who should i see?
<sebpayne> mdke, i could try and help
<mdke> sebpayne, henrik@ubuntu.com can give you the wallpapers, I'll dig out a bug number for you
<mdke> sebpayne, bug #37852
<Ubugtu> Malone bug 37852 in example-content "wallpapers don't belong in example-content" [Normal,Fix released]  http://launchpad.net/bugs/37852
<mdke> i don't know anything about packaging, maybe you can just adopt the gnome-backgrounds style, or something similar
<sebpayne> thanks guys
<sebpayne> mdke, i'll just stick with plain brown :-)
<mdke> sebpayne, I'll send you dapper.png, if you like
<sebpayne> mdke, awesome thanks - sebpayne@gmail.com
<mdke> ok
<sebpayne> mdke, just the whole idea of polish, polish, polish would be great with some tastefully selected backgrounds
<sebpayne> mdke, there are some very crude ubuntu ones i've seen
<mdke> sebpayne, sure. henrik will definitely have some good stuff for you
<sebpayne> mdke, it'll be fun to get back into ubuntu gain
<mdke> sebpayne, are you the same as spayne?
<sebpayne> mdke, yes :-(
* mdke nods
* dholbach leaves too - have a good time
<dsas> sebpayne: Are you the guy who wrote the iFolder howtos?
<sebpayne> dsas, ages go, yes
<sebpayne> dsas, do they need updating?
<dsas> sebpayne: I don't suppose you'd mind updating them for Dapper?
<sebpayne> dsas, not at all
<sebpayne> dsas, there are novell repos now so it should be a lot easier
<dsas> sebpayne: I'm not sure, I think I read about simple-server being changed on someones blog.
<sebpayne> dsas, simple-server no longer eists
<sebpayne> dsas, the full server is now availble with SSL and web admin
<dsas> sebpayne: that may be what I read. 
<sebpayne> dsas, i'll get to work now
<_ion> http://media.revver.com/broadcast/19542/video.mov
<dsas> sebpayne: Plus I'm considering setting it up to share my laptops homedir and it'll be easier if someone has updated the documentation for me ;)
<sebpayne> dsas, ha ha ha :-)
<dsas> sebpayne: Is this 'full server' still simple?
<sebpayne> dsas, now there are packages, even more so
<sebpayne> just an apt-get away
<Amaranth> grr
<Tm_T> ahha
<Tm_T> removing gdm fails
<Tm_T> 'invoke-rc.d: initscript gdm, action "reload" failed.'
<Tm_T> something wrong in package, right?
<Tm_T> I try reinstall an remove
<Tm_T> nah
<Tm_T> ohwell, there's always hammer
<KaiL_> idea to make installing the proprietary drivers a bit more obvious (and so reduce questions, because people fail while installing the versions from the vendors):
<KaiL_> if we detect an nvidia-card, install (not activate) nvidia-glx and add a script to enable it to the desktop
<KaiL_> same for ATI fglrx, except there this scipt doesn't exist jet
<Yagisan> KaiL_: would that be on every desktop ?
<Yagisan> KaiL_: for all users ?
<KaiL_> Yagisan, not on those with an intel-graphics chip ;)
<KaiL_> the idea is just to show the users HOW to enable those drivers
<KaiL_> and to avoid, that they try to install the drivers from nvidia.com or ati.com and fail
<Yagisan> KaiL_: It's not something I'd like to pop up on my ubuntu ltsp client desktops, just because the server has an nvidia video card
<Treenaks> What if I buy a new card, from a different manufactuerer?
<KaiL_> Treenaks, for now that's a situation, that ubuntu doesn't handle at all
<Yagisan> KaiL_: I personally think it should be enabled on install if possible
<KaiL_> Yagisan, those drivers are very often not suspend save
<KaiL_> not to forget the GPL-fanatics
<Yagisan> KaiL_: I've never tried suspend, so I don't know.
<KaiL_> i do it very often, esp. on laptops, as it's more or less the only thing, which fails
<Yagisan> KaiL_: perhaps something that pops up on first reboot, like oem mode ?
<KaiL_> Treenaks, normally at least parts of the xorg install config should be re-run on every reboot
<KaiL_> I'd like to see an rather easy solution to do this after some testing - and btw. use the same way to DISable those drivers
<KaiL_> another idea might be a menu entry for the enable/disable script
<Yagisan> KaiL_: OK, System -> Administration -> Accelerated Video Drivers
<KaiL_> yes, something like that
<Yagisan> KaiL_: turns on/off nvidia/ati and anything else
<KaiL_> for the first only switches ati/radeon <-> fglrx or nv <-> nvidia
<KaiL_> currently problems while installing those drivers are one of the most common support problems
<Yagisan> KaiL_: might need to be vesa <-> proprietary for some newer cards
<KaiL_> Yagisan, nop. If we detect an ati-card, it'll be always the ati driver
<KaiL_> if this doesn't work, there is a fallback planned, so it's not required to set vesa manually
<Yagisan> KaiL_: even their current generation cards ? (my last ati was a 7200)
<KaiL_> Yagisan, afaik the fallback is not implemented yet, but the config still sets a vendor related driver
<KaiL_> I only don't know about matrox Parhelia, for which ubuntu doesn't ship the proprietary driver and the "mga" one will never handle them
* Yagisan sighs. dbs-edit-patch failed.
<KaiL_> ...ok, and at least flight4 used vesa for intel 915
<mjg59> KaiL_: That's a bug
<KaiL_> mjg59, fixed since?
<mjg59> No
<mjg59> It will be at some point
<KaiL_> even more interesting, that I had an freeze while starting X on an FSC Amilo M1450 with i915...
<KaiL_> might be, that the chip is not fully vesa compatible?
<KaiL_> that was with flight6
<Tonio_> hi all
<bddebian> Hello Tonio_
<Tonio_> hey bddebian
<Tm_T> KaiL_: agree, it's big problem that users try install drivers from ati.com or whatever and fail
<KaiL_> Tm_T, on #ubuntu-de we need about half the time for such problems
<Tm_T> KaiL_: script idea is good, also some kind of "desktop FAQ" in desktop could be damn good
<KaiL_> ..the other harf are bad install howtos on printer vendors pages ;)
<Tm_T> KaiL_: in desktop as icon to web page or something
<KaiL_> imho great idea
<Tm_T> ;)
<Tm_T> spending almost 24/7 in irc helping ubuntu (l)users has done its work in me ;)
<Mithrandir> Riddell: please file bugs for stuff you want to get into casper, don't just upload, kthxbye.
<bddebian> casper?
<Yagisan> bddebian: live cd stuff
<bddebian> Ah
<KaiL_> Tm_T, now we only need to explain that to the related developers ;)
<Tm_T> KaiL_: haha, or do it our own in silence ] ;=
<KaiL_> well, that doesn't bring this script on the CD
<Tm_T> KaiL_: I'm more to "FAQ" than script but...
<KaiL_> do you think, the users read FAQs?
<Tm_T> KaiL_: force them
<KaiL_> how? if they asg about the drivers, it's mostly too late
<Tm_T> in first login that FAQ opens and say in big red letters "READ THIS!"
<Tm_T> well, 99% skip it but they asks it themself
<Tm_T> trouble I mean
<KaiL_> as I said - if they already tried to install the driver, it's to late
<KaiL_> then they already created useless workload for them and for the support
<Tm_T> KaiL_: true
<Tm_T> KaiL_: but if they already skipped first step of support, that FAQ, they aksed that workload
<Tm_T> and... well, I'd say script and FAQ then =)
<KaiL_> yes
<Tm_T> I can't understand how people think to move to new system without reading anything
<KaiL_> FAQ not only for this question, but also for other common questions, which might come up AFTER the release
<Tm_T> "I wan't that 'ok' button, I don't care how system works"
<mdke> you guys might want to talk about this in #ubuntu-doc
<Yagisan> Tm_T: I can. one word. lazy.
<mdke> it's kinda off topic for this channel
<KaiL_> the script to shorten THIS problem
<KaiL_> mdke, the FAQ is off-topic, the script on-topic ;)
<Tm_T> Yagisan: then why new system? if you're lazy, you stick in old
<mdke> KaiL_, well, it's all off topic really
<Tm_T> indeed
<Tm_T> KaiL_: FAQ for everything ofcourse
<Tm_T> and I stop here ;)
<KaiL_> -> #ubuntu-doc
<Tm_T> mdke: I would but I can't join #ubuntu-doc without losing some other channel
<mdke> Tm_T, that's ok, the guide already exists.
<KaiL_> Tm_T, huh? how that? ;)
<Tm_T> KaiL_: channel limit of freenode =)
<Tm_T> mdke: yes, but it's not in desktop, that's the point ;)
<Tm_T> oh well
<mdke> Tm_T, it's in the desktop
<Tm_T> it is?
<KaiL_> mdke, an FAQ, which can be updated after the release, is easy accessible and is localised exists?
* Tm_T doesn't use Gnome btw
<mdke> KaiL_, a guide. no, yes, yes
<Tm_T> I do know nothing about defaults
<KaiL_> I start to hate my Acer laptop
<Tm_T> KaiL_: you can have mine in chance, 486sx with 4M ram
<KaiL_> bah... not usefull for testing
<KaiL_> but really good does this not work - hangs on booting
#ubuntu-devel 2006-04-19
* ..[topic/#ubuntu-devel:jbailey] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | Flight 6 released | LP upgraded, report issues on #launchpad | Beta freeze has begun.
<Kamion> mdz: oh, wow, setting a busy cursor while moving from page to page makes espresso feel so much more responsive even if it takes exactly the same amount of time
<Kamion> (it turned out to be easier and safer than I expected)
<sabdfl> Kamion: good find
<sabdfl> "ubiquity"
<Tm_T> indeed
* Tm_T hopes we get nice and well working KDE-equiv done soon ;)
<Riddell> Tm_T: of what?
<Kamion> Riddell reckons he's making good progress; I must confess I haven't had time to try it myself
<Tm_T> Riddell: espresso, that's what you're doing right?
<Riddell> Tm_T: yeah, you should try it, it's working well
<Tm_T> Riddell: ah, I will, tomorrow maybe ;)
<Riddell> still plenty to do of course
<Riddell> qtparted needs a bit of a session
* Tm_T has now excuse to install Kubuntu to one of his friends pc =)
<Tm_T> muhaha
<Tm_T> "whoops, I didn't know livecd can do that"
<Riddell> Tm_T: careful, it's a beta installer, it might wipe the whole hard disk
<Tm_T> even better
<Tm_T> that helps me fix bug 1 ;)
<Ubugtu> Malone bug 1 in Baltix "Microsoft has a majority market share" [Major,Confirmed]  http://launchpad.net/bugs/1
<bddebian> Howdy folks
<mdke> hi bddebian 
<nekohayo> okay I have a suggestion/question, don't know who to speak to: why not remove the "lock screen" option from the gnome "system" menu? Since that option is now in the ubuntu logout dialog? just a thought.
<mdke> I'd rather it was the other way round
<mdke> i use the lock screen from the menu quite a lot, but never in the logout dialogue
<bddebian> Any chance someone can give me some pointers on install.. vs. dh_install vs <pkg>.install ?
<bddebian> I'm having issues on a couple of packages
<azeem> dh_install uses <pkg>.install (if available) to figure out what to put where
<bddebian> Well I've been having good luck with dh_install by itself but 3 packages are kicking my butt because they encompass multiple binary packages
<bddebian> But dh_install -p<pkg> isn't putting them in the right places either :-(
<azeem> then maybe the <pkg>.install files have syntax errors
<Kamion> put DH_VERBOSE=1 in the environment and dh_install will tell you exactly what it's doing
<Kamion> it also sometimes happens that you get screwed over by an exported DH_OPTIONS that conflicts with the -p you give explicitly
<bddebian> Of course all three of these packages take FOREVER to build :-)
<Kamion> you can just run the relevant dh_install commands by hand
<Kamion> dh_install is idempotent so you can do that freely even after the build's over/failed
<Kamion> debian/rules binary is generally idempotent, too - you can run it independently of build, and multiple times
<bddebian> Here's another one:
<bddebian> cp debian/dxicon.xpm debian/tmp/usr/lib/dx/
<bddebian> install -d -m644 debian/dxicon.xpm debian/tmp/usr/share/pixmaps/
<bddebian> install: `debian/dxicon.xpm' exists but is not a directory
<bddebian> Doesn't like the trailing / ?
<Kamion> somebody didn't read the install(1) man page
<Kamion>        -d, --directory
<Kamion>               treat all arguments as directory names; create all  com
<Kamion>               ponents of the specified directories
<bddebian> Oh shit, I meant -D
<bddebian> grr
<Kamion> that install command means "please create the directories debian/dxicon.xpm and debian/tmp/usr/share/pixmaps/"
<Kamion> -D sounds a bit more likely, yes
<bddebian> Crap and dx takes forever ...
* bddebian begins to cry again
<Kamion> use debian/rules binary, don't rebuild the whole thing
<Kamion> well, fakeroot debian/rules binary
<bddebian> Can I do that if I used -tc?
<azeem> what is -tc?
<Kamion> no; don't do that
<nekohayo> mdke: either way I would be happy... just don't have it as a duplicate for nothing however :)
<bddebian> azeem: tail clean
<Kamion> if you care about package build times it's a rather self-destructive option to use
<azeem> oh, never heard of that
<bddebian> Hmm, well that explains a lot
<bddebian> And of course dx doesn't clean up after itself properly :'-(
<bddebian> thanks for your time azeem and Kamion
<Kamion> np
<bddebian> Can I wildcard with install?  I.E.  install -D -m644 debian/*.desktop debian/tmp/usr/share/applications/ ?
<Kamion> yes
<bddebian> sweet
<Kamion> the shell expands that to multiple source arguments
<bddebian> Does this look valid?:
<bddebian> install -D -m644 debian/*.desktop debian/$(cdbs_curpkg)/usr/share/applications
<Kamion> sure
<Riddell> Kamion: kde espresso good to merge
<Kamion> ok, I'm sort of giving up on fixing the reboot button in GNOME anyway
<Kamion> gnome.ui.Client does not love me
<Riddell> Kamion: I remove gtk from kdb_chooser, I checked quickly with gtkui but you might want to confirm that it really isn't used
<Riddell> Kamion: are we going to remove the NoDisplay on the .desktop files for the beta?
<Kamion> yeah, that's fine, it was a leftover
<Kamion> Riddell: suppose we could
<Kamion> espresso should remove itself from the installed system now
<Kamion> merged and pushed
<Kamion> and NoDisplay=true removed too, thanks for the suggestion
<bddebian> Frickin' A, finally.. Thanks again Kamion and azeem!
<Kamion> aha, gnome-session-save --kill --silent
<Kamion> NEED BIGGER HAMMER
* bddebian hands Kamion a sledge
<Kamion> right, God willing, that's the last espresso upload needed before beta
<Kamion> now just a quick investigation of that console-data build failure and maybe I can go to bed
<bddebian> Ack, I cannot get a desktop file in dx to dave my life.. :'-(
<Kamion> oh, drat, will probably need a new upload for translations anyway
<Kamion> oh well
<sabdfl> Kamion: can you rename espresso pre-beta?
<Kamion> sabdfl: I brought that up in the distro team meeting, and mdz said post-beta
<sabdfl> ok
<Amaranth> rename it to what?
<sabdfl> ...
<sabdfl> drumroll
<sabdfl> ...
<Kamion> which makes some sense since I have one working day left before the beta (Wednesday)
<Kamion> ubiquity
<Kamion> damn, should've removed "Espresso" from the title bar; I removed it everywhere else, I think
<sabdfl> never mind... it's looking great
<sabdfl> will file bugs post-beta
<Kamion> I might as well fix that now
<bddebian> Kamion: If you get a second.  If rules is dumping everything in debian/tmp/foo/bar, how do I make install package specific?
<Kamion> bddebian: sorry, it's 3am, I probably can't explain it coherently
<Kamion> but typically either you install straight to debian/<packagename> for each one, or you install to debian/tmp and then use dh_install to split out to multiple packages
<bddebian> Well I have dh_install -ppaw++ but it isn't working.  Anyway, sorry, go to bed :-)
<Kamion> sabdfl: ok, "Espresso" should now appear nowhere in the UI, GTK at least (I'm not going to attempt to modify the KDE one just now)
<Kamion> title bar is "Install System Permanently" instead
<Kamion> (matches desktop icon name)
<Amaranth> ubiquity?
<Amaranth> the installer is omnipresent?
<bddebian> heh
<bddebian> No, I am omnipresent ;-)
<Amaranth> well, i can't prove you wrong... ;)
<bddebian> :-)
<Kamion> Amaranth: the idea is more that it helps Ubuntu to be omnipresent
<Kamion> c.f. bug #1
<Ubugtu> Malone bug 1 in Baltix "Microsoft has a majority market share" [Major,Confirmed]  http://launchpad.net/bugs/1
<Amaranth> Kamion: ah, neat
<Amaranth> baltix?
<Kamion> side-effect of multiple tasks on the one bug
<Amaranth> yeah, i see that
<Kamion> ubugtu doesn't quite know which to pick
<Kamion> also, ubiquity is just a really good word, and has phonetic similarity to Ubuntu without causing branding troubles
<Kamion> (that similarity being why we wanted to rename from "espresso")
<Burgundavia> mako: you around?
<desrt> Burgundavia; you got told off on p.g.o incase you didn't notice :)
<Burgundavia> desrt: yes, but the abiword people agree with me
<desrt> oh
<desrt> that's good, at least
<Burgundavia> besides, tbh, it is a dobey, who isn't known to be the most polite
<desrt> someone closed your favourite bug on launchpad a while ago :(
<Burgundavia> yes, I saw that
<Burgundavia> can't win 'em all
<desrt> bad aditude
<mako> Burgundavia: yes
<mako> Burgundavia: when do you leave?
<Burgundavia> mako: tomorrow morning. In about 8 hours
<Burgundavia> I come back sunday night, PDT
<mako> Burgundavia: ok
<Burgundavia> mako: did you get my pm?
<Lathiat> hrm, gnome-power-managers battery icon isnt so good
<Lathiat> i've got 48% and it looks like i have <1/3r
<Lathiat> and is yellow which usually means about that
<neuralis> Lathiat: the g-p-m icons don't go well with the rest of the icons, either; it's rather cartooney. ideally we could get the whole set replaced, but i'm not sure if the ubuntu-artwork guys are working on it.
<sebpayne> are there going to be some new OOo icons for dapper?
<_ion>   mgapdesk: Depends: xserver-xfree86 but it is not installable
<Lathiat> neuralis: i dont mind that so much
<Lathiat> and now im on 30% and thats red
<Lathiat> no sure thats the best set of marks
<mdke> Lathiat, i have to say, that is the most irritating bug in dapper for me right now.
<hile> Lathiat: and when the battery charge goes from 49 to 51 percent it suddently shows green icon which looks like 70% full...
<mdke> but I think that the gpm maintainer is not going to fix it
<mdke> so i switched back to the gnome applet for battery monitoring
<mdke> Lathiat, if you wanna comment, it might help: https://launchpad.net/malone/bugs/32921
<Ubugtu> Malone bug 32921 in gnome-power-manager "battery monitor is red even when I have over 30% battery left" [Minor,Unconfirmed]  
<mdke> but anyway, the gnome applet icons are much nicer, and it has a preference to show the percentage on the panel, so I prefer it anyway
<hile> yeah, me too think percentage is much more useful 
<mdke> hile, get busy and comment on the bug, they won't fix it unless a few people are annoyed by it, I reckon
<hile> btw, do you know which part is now locking my screen when I unplug ac-adapter? it's really annoying and I see no option to switch it off (looked at /etc/acpi files with no luck)
<Lathiat> haha nice bug
<mdke> hile, probably gnome-power-manager again :/
<hile> for me it's ok to lock screen when lid is closed, but _not_ when AC-adapter is unplugged
<hile> yep, it's gpm  (killed the process and tried again)
<mdke> I have the opposite, my screen doesn't lock when it should :)
<hile> funny, after restarting gnome-power-manager it does _not_ lock it anymore
<hile> maybe the bug has been fixed but I've been just running old process ;
<Lathiat> haha
<elkbuntu> surely there cannot be 108 upgrades that are detected with dist-upgrade/upgrade but update notifier doesnt alert one about...
<mdke> elkbuntu, you're right, sounds like a bug
<elkbuntu> let me check if the notifier is even going...
<elkbuntu> it is indeed running
<mdke> elkbuntu, it's a bit sluggish here too. I've just updated my sources and the icon is greyed out
* mdke waits
<mdke> ah, now it's gone red
<elkbuntu> well i did apt-get update before checking dist/upgrade and notifier hasnt shown its face yet, and i did the command like... um... 5 mins ago
<elkbuntu> usually it shows within a minute
<mdke> hmm, works here. maybe file a bug?
<mdke> or look for one already open
<elkbuntu> yeah will when i finish helping in +1
<elkbuntu> mdke, i believe it is this: https://launchpad.net/distros/ubuntu/+source/update-notifier/+bug/38922 .. are either of the developers listed there in here?
<Ubugtu> Malone bug 38922 in update-notifier "Does not show up on Gnome Panel" [Normal,Unconfirmed]  
<mdke> elkbuntu, no, he goes by the nick of mvo. Maybe taking a holiday today, it's a holiday in many countries
<elkbuntu> hmm, maybe it's not that, list permissions are correct...
<glatzor> ping smurf 
<_ion> Yay.
* _ion got mga_hal_drv to work with xorg 7
<glatzor> _ion, could you provide some details? :)
<_ion> glatzor: I'll post information later today, ok?
<elkbuntu> mdke, ooh just noticed that update-notifier was one of the updates... so i installed it and i now at least have a greyed version of it in the taskbar
<elkbuntu> mdke, and yay, it's telling me i have updates
<Riddell> Kamion: can you merge and upload kde espresso?  should be good now for beta
<Riddell> or I can upload
<mdke> elkbuntu, good news
<elkbuntu> mdke, i never thought to look at -what- the updates were before. i only had like 4 hours sleep last night so that might have been the cause of that misjudgement ;)
<Riddell> oh, it's easter, Kamion will be on holiday
<Riddell> I'll just upload then
<Kamion> Riddell: can I do it?
* Kamion happens to be around
<Kamion> only 'cos I'm trying to find somebody to repair my car today though
<Kamion> Riddell: BTW it's not quite accurate that I haven't had time to make the breezy update CDs (although obviously there's some of that element too); I'm waiting on some archive infrastructural fixes before I can get the necessary updates in
<Kamion> Daniel's been on that, and I'll probably kludge something together on the katie side if necessary
<Kamion> (reading https://lists.ubuntu.com/archives/kubuntu-users/2006-April/004871.html)
<Kamion> Riddell: actually, I've got to do other things - I'll merge, but go ahead and upload it yourself
<Kamion> just make sure you've done debian/rules update and that there aren't extraneous diffs in d-i/source/, obviously
<Riddell> Kamion: sure
<Kamion> ta
* Kamion accepts mvo's breezy-updates update-manager upload; let the fun begin
<mdke> ooh cool
<martin1976> Hi, I do not know if this is a german room or not, so we are in english, can anybody help me at reconfiguration/finding/reinitialisation of my lancard ?
<martin1976> I nee some system reconfiguration commands
<irvin> martin1976, pls join #ubuntu for user help/support
<slomo__> martin1976: or #ubuntu.de for german support
<martin1976> thats where I came from, there is nobody able to help me.
<azeem> martin1976: then maybe try the forums or mailing lists
<bddebian> Howdy folks
<azeem> this channel is not the right place, sory
<martin1976> then  let me say, dont you know the term usability ??? 
<azeem> sure
<azeem> martin1976: but user support is not the same as software usability
<TheK> martin1976, here it's more the problem of reading, not of using ;)
<TheK> "devel" means "development", not "support"
<martin1976> If so help me !!! If the software isn't goog, then this way. I have tried hard to browse the web, but all I got was really unhelpful
<TheK> for that there is #ubuntu or in german #ubuntu-de (where I'd like to help you)
<azeem> martin1976: please ask in the appropriate channel
<azeem> martin1976: you won't get help in here
<martin1976> ok see you there
<azeem> ask later or tomorrow again, maybe somebody can help you then
<TheK> slomo__, btw. it's ubuntu-de, not .de ;)
<slomo__> TheK: both exist ;)
<TheK> * #ubuntu.de #ubuntu-de :Forwarding to another channel
<TheK> or both is the same ;)
<lemsx1> hello all
<lemsx1> happy easter for all
<TheK> 2 days to early, or?
<lemsx1> yep ;-)
<lemsx1> today's good friday only ... but, who's going to be online for the next 2 days :-P
* bddebian probably will be :_)
<xhaker> nm-applet doesn't launch, ** (nm-applet:7814): WARNING **: Icon nm-vpn-lock missing: Icon 'nm-vpn-lock' not present in theme
<mdke> xhaker, bug tracker
<xhaker> mdke: i'm trying to get more info before i file the bug
<mdke> xhaker, looks to me like you have enough
<Lure> xhaker: it is already submitted and the workaround is there (just to not recall bug id)
<xhaker> Lure: that was my next step :) and sorry for the duplicate bug i filed just before about sylpheed-claws-gtk2 imap..
<xhaker> i mean.. sorry to droege
<sivang> re all
<bddebian> Heya sivang
<sivang> hey bddebian , has anyone seen dholbach ?
* sivang wonders if everyone is on vacation on something. the house looks quite :)
<sivang> bddebian: will you be comfortable to get another MOTU , revew my HUB package and upload if appropriate? (hmm, slomo__ is here as well, good :) )
<bddebian> sivang: Comfortable?  We need as many as we can get :-)
<sivang> bddebian: ehehe
<jbailey> sivang: Yes.  It's easter. =)
<Chipzz> so, are there any easter eggs in ubuntu? ;)
<sivang> jbailey: at least you are here :) 
<sivang> jbailey: yes, I now realize that. Shame I was in holiday preperation myself during the last 2 days, and only now got some time to find someone to upload HUB for me to universe. Gotta have it in universe now that's it's presentable to users, to get bug reports etc and get it as stable as can.
<jbailey> sivang: Mind the beta freeze. =)
<sivang> jbailey: right, thing is that this is for universe for a start, and if you recall (I recall you attended that status report meeting) mdz once said in one that I can go on in universe, I wonder if that stands as universe FF expection.. =)
* sivang realizes he may have to mind beta freeze if parts of universe are put on the DBD
<sivang> s/DBD/DVD
<jbailey> YEah, I don't know the rules about universe, etc.
<sivang> jbailey: do you know if mdz is on easter holiday until tuesay as well ?
<Mithrandir> sivang: it's a new package or update of an existing one?
<sivang> Mithrandir: new package :-/
<Mithrandir> sivang: well, then it can go in nonetheless.
<jbailey> sivang: I don't, sorry.
<sivang> jbailey: np, thanks anyways.
<bddebian> Heya jbailey :)
<sivang> Mithrandir: Is it a problem if something new is uploaded to universe while in beta freeze?
<jbailey> Heya Barry
<Mithrandir> sivang: I can't see it being a problem.  It won't disturb what's there already.
<sivang> bddebian: so, would you like to take a look at it? review it? maybe you and slomo__ could give it a quick review so I'll know if there are close encounters stuff to fix before it cab be uploaded ?
<CarlFK> Kamion: ping: "The file needed for preconfiguration could not be retrieved from http://dev.personnelware.com/server.cfg."  but my append line has preseed/url=http://dev.personnelware.com/preseed-josh.cfg - so where is "server.cfg" coming from?
<bddebian> sivang: I'm in the middle of a bug at the moment but I'll try
<slomo__> sivang: later... i'm currently busy with something else
<sivang> Mithrandir: are you able to approve such and upload to universE? I don't want to cause any trouble, so please let me know if you think I sould wait to after easter.
<sivang> slomo__: sorry to bug you, I understand.
<Mithrandir> sivang: I'm on vacation now so I would prefer to wait.
<sivang> Mithrandir: okay , thanks anyway, I'll wait then :)
<slomo__> simira: np :) i'll put it on my todo list... which package is it btw? ;)
<sivang> slomo__ , bddebian : so it's no hurry, let me know when you can.
<sivang> bddebian, slomo__ : can I email you guys with url to the source so you might take a look when you have time?
<slomo__> sivang: sure... slomo@ubuntu.com
<Toadstool> heya here too, what do you think of bug 36505? Do I keep on working on lintian?
<Ubugtu> Malone bug 36505 in lintian "Ubuntu Lintian shouldn't do the nmu checks" [Wishlist,In progress]  http://launchpad.net/bugs/36505
<sivang> bddebian: what's yours?
<bddebian> sivang: ?
<bddebian> Oh, bddebian@comcast.net
* sivang prepares an email
<sivang> bddebian , slomo__ : sent
<netstar> You might want to disable auto loading of the hostap wireless driver.  The latest x86 kernel will hang unless I pull my pcmcia card out.  Removing hostap from modules fixes it however.
<netstar> plus it isn't the driver most people would want
<mjg59> netstar: In general, it's more functional than orinoco_cs
<mjg59> If it's hanging stuff, then we have a bug to fix
<netstar> I'll recreate the conditions tomorrow and send a report
<mjg59> Ok, thanks
<v3rmap> I'm trying to install gtk2 dev libs on Dapper flight 6, but hit some errors:http://pastebin.com/659830
<v3rmap> Any suggestions would be very helpful.
<Riddell> v3rmap: you need to try and work out why apt doesn't want to install the packages mentioned
<sivang> bddebian, slomo__ : let me know if my email hit you
<slomo__> sivang: it did ;)
<sivang> cool
<sivang> I hope I don't gross/scare you guys off with my horroble code :)
<slomo__> sivang: if you want it to be a native package use "0.0.1ubuntu1" or even "0.0.1" as version number
<bddebian> sivang: I got it
<sivang> slomo__: well, sladen noted to me to make it like this, so it would be like a native debian package, and when we will syn it from debian, we won't have problems.
<sivang> slomo__: hence the ubuntu0-..
<sivang> slomo__: sorry, I meant, x.x.x-0ubuntuN
<slomo__> sivang: you are upstream, yes? so make it "0.0.1" :) i don't see any problems with debian here... if there are changes needed for debian you will make them and raise the version number anyway ;)
<sivang> slomo__: and so we will have one version number for both debian and us?
<sivang> slomo__: and yes, I'm upstream for this :) /me runs 
<slomo__> sivang: yes... and when it's in debian as 0.0.2 for example and there have to be ubuntu specific changes we get 0.0.2ubuntu1 (or 0.0.3 when you update it in debian and sync)
<sivang> slomo__: hmm, so I wonder what sladen was concerned with when he suggested me to make this as if the original version came from debian, and add the 0ubuntu1..
<slomo__> sladen: ping?
<v3rmap> Riddell, I couldn't figure it out. I'll ask on ubuntu-motu and see if someone has an idea.
<v3rmap> I just installed libgtk2.0-dev package on Ubuntu. It seems that the gtk headers are not added to the list of the standard include files and so I get lots of compilation errors. I tried adding several gtk include directories using the -I /usr/include/gtk2.0... syntax. Did I miss an installation step?
<crimsun> v3rmap: please join #ubuntu
<v3rmap> Ahh sorry folks. I see this channel is not for support.
<bddebian> Anyone know if AC_CHECK_TCLTK() is valid?
<milli> don't mean to be a pain, but ATI just released a new fglrx driver (8.24.8) that supposedly supports the X1600 chip in my new T60p...
<milli> it is not immediately obvious to me how to update linux-restricted-modules with this new driver...
<fabbione> milli: scheduled for after easter
<fabbione> even developers deserve some time off for world wide holidays
<milli> np, ty  ;-)
<milli> it's just sad that I have to run with VESA drivers... it's slower than my old laptop (3yrs old)
<Treenaks> fabbione: no! they should work even harder, to compensate for the non-working people! *takes whip out of storage*
<Treenaks> fabbione: :P
* fabbione larts Treenaks with a big bat
<CarlFK> Kamion:  you broke my hands-off preseed file ... it keeps asking for which HD and what timezone ...  
<fabbione> milli: just wait a few days please.
* milli jumps out of the way
<milli> fabbione: np, thanks
<phlaegel> fabbione: you're the ubuntu lvm guy, right? (I just ran in to bug #38007)
<Ubugtu> Malone bug 38007 in lvm2 "pvmove coredumps" [Normal,Unconfirmed]  http://launchpad.net/bugs/38007
<fabbione> phlaegel: did you read the  pvmove documentation before running it?
<phlaegel> yeah... the man page and lvm howto
<CarlFK> dapper ubuntu-server - should it be installing 386 or nvidia-kernel?
<CarlFK> I thought it did 686 (but it isn't) and I don't think a 'server' should be messing with video 
<fabbione> phlaegel: add more info.. like size of sda5, sdb4 and how much was allocated on sda5.. stuff like that
<fabbione> pvmove has always been considered "risky"
<CarlFK> well, it isnt 386 either: Apr 14 11:58:37 debconf: --> SUBST base-installer/kernel/failed-install KERNEL linux-386 
<CarlFK> Apr 14 11:58:37 base-installer: error: exiting on error base-installer/kernel/failed-install
<fabbione> CarlFK: stop flooding the chan and file a bug
<phlaegel> fabbione: was just talking to someone in #lvm, and it looks like the lvm stuff in dapper is too old for 2.6.12+
<fabbione> phlaegel: no, lvm in dapper works just fine. i did ask for info in the bug. please attach them and tuesday i will look at them
<Kamion> CarlFK: sorry, but I'm not paying much attention here over Easter; file a bug if you like. However I do NOT ever guarantee that we won't break previously-working preseed setups from release to release. You will have to adapt your preseeding based on new questions being asked.
<CarlFK> no prob
<Kamion> it's probably partman-auto/disk or something like that in this case
<phlaegel> fabbione: will do
<Kamion> CarlFK: and for the record, no, *I* didn't break that :P
<CarlFK> I am actually trying to reproduce the ext3 and swap on hda5 thing and ran into 3 more issues 
<Kamion> although I did encourage Fabio to do so because we needed it for espresso, and I think he was right to do so
<bddebian> Morning Kamion ;-)
<CarlFK> the plan was to install, then run ... the thing that gens a preseed file based on the current install and see what I needed
<CarlFK> but the kernel/failed-install is making that difficult ;)
<Kamion> no idea about that, sorry
<Kamion> you've removed all the probably-useful context before it in your paste ;)
<CarlFK> http://dev.personnelware.com/carl/temp/Apr14/b/
<Kamion> oh no, you're not sucking me into looking at it now on holiday :)
<CarlFK> Im trying not to acutally, but it his hard :)
<CarlFK> actually, don't look now
<CarlFK> there is a good chance my hacked up preseed file is to blame 
<CarlFK> so enjoy Easter
<CarlFK> I will do a 'normal' install and quietly report anything on lp
<highvoltage> ew. the lines on top of lp is ugly.
<HiddenWolf> no offense, but you're hardly quiet about it CarlFK :)
<HiddenWolf> highvoltage: amen. :)
<highvoltage> HiddenWolf: :)
<CarlFK> well, now that I know K is trying to enjoy holiday...
<HiddenWolf> I've seen him state that a few times today. ;)
<TTT_Travis> I am trying to install kernel modules and this is what I get I know very little about this stuff so yeah: http://pastebin.com/660183
<tseng> lamont: your beagle patch is applied upstream, thanks alot
<KaiL> hmm, we should set firefox to clean the downloadmanagers list at least on exit, maybe even after download ends
<KaiL> that would help us to work around the #1 crasher on linux
<poningru> is ubuntu doing any soc projects?
<poningru> http://code.google.com/summerofcode.html
<HiddenWolf> sure hope so
<dsas> poningru: They did a few last summer, not sure how much good they got out of it though tbh, Manu Cornet stayed and contributed after.
<poningru> yeah and his was good
<poningru> I read couple of blog posts where people didnt like the soc
<poningru> so wondering if ubuntu is doing it again this year
<poningru> whats up
<poningru> sorry wrong channel
#ubuntu-devel 2006-04-20
<bddebian> Anyone alive that knows xmkmf?
<crimsun> define "knows".
<Kyral> *shudder*
<Kyral> Say that near me again and die....
* LaserJock goes back to sleep
<LaserJock> bddebian: which package are you working on?
<Kyral> I thought you were sleeping
<LaserJock> well, it almost put me to sleep but I managed to awaken myself with a dose of Python
<LaserJock> I'm trying to make a nice Python environment on my Windows laptop
<bddebian> LaserJock: xfishtank at the moment :-)
<bddebian> crimsun: Well it's generating an X11R6 path and I don't want it too :-)  The package is also looking for stddef.h but it doesn't look in usr/include/linux which is where it is
<Kamion> stddef.h is more usually got from gcc's private include directory
<Kamion> e.g. /usr/lib/gcc/powerpc-linux-gnu/4.0.3/include/stddef.h
<Kamion> that should be automatic unless it's doing really stupid things with include paths
<bddebian> Hang on I'll paste bin it
<Kamion> (i.e. you have to work hard to turn that off in gcc)
<mdz> Kamion: is debian-cd intentionally a person rather than a team?
<mdz> oh, sorry, I confused debian-cd with ubuntu-cdimage
<Kamion> right, ubuntu-cdimage is a team, debian-cd is an imported person
<bddebian2> stupid POS phone
<bddebian2> Anyway, here is a shot of the xmkmf error:
<bddebian2> http://paste.ubuntu-nl.org/12262
* Kamion would be inclined to find an imake expert to punt to rather than trying to dig into it myself
<robertj> I've got a really bad crash and I've narrowed it down to something nasty on my desktop that nautilus doesn't like
<robertj> mv'ing ~/Desktop to ~/Desktop/olddesktop made it happy but opening olddesktop in Nautilus causes bad things to happen
<robertj> aha
<robertj> there is a deadly .gif image that generating a nautilus preview for causes bad things to happen
<robertj> can someoe download http://www.music.uga.edu/wip/deathgif.gif into ~/Desktop/somefolder and tell me if it causes Nautilus to crash?
<ozamosi> robertj: jupp, it does
<robertj> ozamosi: Dapper I assume?
<ozamosi> yes
<robertj> Anyone got a breezy system handy to test with?
<ozamosi> But nothing happened untill I hovered it...
<robertj> ozamosi: didn't matter for me, it just took a few seconds
<bddebian> Damnit, why can this thing not find stddef.h.. whacky
<defendguin__> https://launchpad.net/distros/ubuntu/+source/network-manager/+bug/37110   is there any possibility of this making it into dapper?
<Ubugtu> Malone bug 37110 in Baltix "no NetworkManager VPN Connection Plugins installed or available in ubuntu" [Normal,Unconfirmed]  
<cartel_> hunger: you there?
<cartel_> sabdfl: hello!
<jadaz87> hello everyone i was wondering how can i shutoff services on the livecd while it is extracted on my hard drive ;-)
<jadaz87> i can customize what runs after i install ubuntu with sysv-rc-conf but i was wondering what do i do to conf the livecd so that they are already disabled
<jadaz87> i am following the livecdcustom wiki
<jadaz87> anyone? lol
<bddebian> jadaz87: Have you asked in #ubuntu?  I don't know the answer and there aren't too many people in here tonight.
<mdke> jadaz87, for support, you'll always have better luck in #ubuntu
<bddebian> mdke!!
<jadaz87> oh ok i did not think anyone in the #ubuntu whould know since it was not the develop channel
<mdke> bddebian, mm?
<bddebian> mdke: How's your automake foo? :-)
<mdke> bddebian, have you got me confused with someone else?
<bddebian> I don't think so?
<mdke> I don't know anything about automake
<bddebian> Damn
* enyc meeps at doko ;-)
<bobulator> hey there does anyone know much about amharic support for scim? im having trouble switching keyboards around...
<mdke> infinity, hi. Is your t43 suspending to ram/waking from suspend properly? mine is really cranky, often it fails
<giftnudel> mdke: how does it fail?
<mdke> giftnudel, it freezes. I don't know how to be more specific than that
<giftnudel> ok
<mdke> giftnudel, just filing a bug now
<mdke> it's at bug #39660
<Ubugtu> Malone bug 39660 in acpi-support "Suspend to RAM is doing some cranky things on T43" [Normal,Unconfirmed]  http://launchpad.net/bugs/39660
<bddebian> Morning
<simira> evning
<HiddenWolf> Hey guys
<HiddenWolf> does ubuntu-desktop depend on the accesibility stuff now?
<HiddenWolf> dist-upgrade is asking which braille-engine I'd prefer.
<ompaul> HiddenWolf, it does, brltty at least
<HiddenWolf> ompaul: I see why, great thing, but it shouldn't bother users who don't need it.
<fabbione> HiddenWolf: you will  see the questions only on upgrades from dapper to dapper. probably breezy -> dapper
<fabbione> not on install
<Mithrandir> fabbione: they shouldn't be there by default.  I have a bug assigned to me for that.
<fabbione> Mithrandir: ah ok...
<fabbione> can we actually autodetect them?
<Mithrandir> USB we can, serial we can't.
<fabbione> ok
<HiddenWolf> fabbione: ah, ok
<fabbione> we will need to work on this serial usage on dapper+1
<fabbione> because there are too many pkgs that tends to do autodetection on serial
<fabbione> and mess up stuff
<fabbione> specially when you have GPS on serial or console on serial
<Mithrandir> fabbione: it should just default to USB and we're fine.
<Mithrandir> that is, default to USB and not display the question by default
<fabbione> ok
<jpatrick> who do I have to ask to get kmediafactory into multiverse?
<crimsun> you need a demotion of it?
<jpatrick> crimsun: yes
<crimsun> (I'm presuming for additional codec support)
<jpatrick> yep :)
<crimsun> is jriddell aware? If so, ask kamion when he returns from Easter.
<jpatrick> ok
<robertj> what software powers the ubuntu wikis?
<HiddenWolf> moinmoin
<HiddenWolf> afaik
<sabdfl> yes, its moinmoin
<zul> heylo
<sabdfl> hey zul
<lamont> tseng: rock
#ubuntu-devel 2006-04-21
<sabdfl> hey lamont, happy easter!
<lamont> you too sabdfl 
* lamont wanders off to deal with a few tasks of the day
<highvoltage> happy easter, ubuntero's!
<bddebian> Easter?  Aren't you all long-haired hippy commie athiests?
* bddebian hides
<womble> bddebian: Yes, but even long-haired hippy commie athiests like chocolate.
<bddebian> Ah, hehe
<womble> And that's really what we're all celebrating today
<bddebian> highvoltage: Can you check your system for bitstream fonts?
<highvoltage> bddebian: sure
<bddebian> I think it's using tetex-ttmf
<bddebian> Err texmf-tetex
<highvoltage> bddebian: well, i have the ttf-bitstream-vera package installed
<highvoltage> bddebian: what should I check?
<bddebian> Where is that?
<bddebian>  /usr/share/fonts/truetype/ ?
<highvoltage> there are 11 font files in /usr/share/fonts/truetype/ttf-bitstream-vera
<bddebian> How the heck can kde and xfce be treating them differently??
<bddebian> Hmm, default font is supposed to be adobe-courer-
<bddebian> courier even
<highvoltage> really? weird that they chose a non-free font.
<bddebian> Does kde provide it's own fonts at all?
<pygi> To everyone around here: Happy easter to you, and everyone you care for :)
<bddebian> You too pygi, thanks
<[Chameleon] > pygi: thanks, same to you and yours.
<mdke> bddebian, i've heard you say a bit that you're the master of desktop files, would you fancy uploading the patch on bug #39507, by any chance?
<Ubugtu> Malone bug 39507 in gxine "HIG compliant menu entry" [Normal,Unconfirmed]  http://launchpad.net/bugs/39507
<bddebian> mdke: Sure thing
<mdke> bddebian, awesome, thanks muchly
<bddebian> Thank you
<bddebian> :-)
<tseng> what is up bddebian 
<bddebian> tseng: Looking at bugs I can't fix apparently.  You?
<tseng> not much
<bddebian> Ack, another fucking xmkmf package
<glatzor> _ion: ping
<\sh> happy easter everyone
<fabbione> hey \sh
<fabbione> thanks same to you
<\sh> hey fabbione, how it's going :) 
<fabbione> \sh: as usual and you?
<fabbione> i am glad to see you around
<ajmitch> hi fabbione 
<fabbione> hi ajmitch 
<fabbione> ajmitch: no T2000 yet?
<\sh> well...I'm living somehow next to the sewers of my city...but _I will survive_ :)
<ajmitch> they're in the server room
<ajmitch> I just need access :)
<fabbione> ajmitch: http://www.stdlib.net/~colmmacc/category/niagara/ <-
<ajmitch> it's a little slow being easter
<fabbione> yeah i can imagine
<ajmitch> thanks
<fabbione> \sh: i am sure you will.. you can be a strong head ;)
<ajmitch> that will help a lot, I think :)
<fabbione> ajmitch: oh yeah
<\sh> fabbione: dickhead you mean, right? ;)
<fabbione> \sh: well i wanted to be nice.. you know :P
<\sh> fabbione: come on...be straight :) nice people I know enough :) 
<fabbione> \sh: ahahha dude.. you know me.. i can't be straigh on a public IRC channel or there will be a queue of lawyers outside my door ready to sue me
<\sh> I finally start to get back to see some things more funny now....
<\sh> fabbione: don't worry...I can't even pay a lawyer :)
<fabbione> ahaha
<fabbione> but others can!
<fabbione> brb
<neuralis> fabbione: i'll have a t2000 running ubuntu-server here in the next month, most likely 
<fabbione> neuralis: i have mine here .. did you see the pics?
<fabbione> http://people.ubuntu.com/~fabbione/office/
<\sh> neuralis: I saw og marciels blogentry about the linuxexpo :) and how you made a fool out of him :)
<fabbione> i still need to add the last changes to it
<fabbione> but that's basically the setup
<neuralis> fabbione: haha, love the leather jacket in the empty office :)
<neuralis> \sh: nah, it was all in good fun
<\sh> neuralis: I know :) how was it anyways...looked really huge this fair
<fabbione> neuralis: i am running even ubuntu-desktop on the T2000 :) with vnc..
<fabbione> neuralis: a 24 CPU's desktop is kind of nice :)
<fabbione> anyway.. brb
<ajmitch> neuralis: nice, what are you going to be doing with that?
<neuralis> fabbione: i'm getting a bit envious here.. mine will only be 8-core
<neuralis> \sh: i didn't like it. didn't see anything interesting, really.
<neuralis> ajmitch: mail+web+shell for all the university's student groups, currently handled by a farm of wacky hardware that's getting difficult to manage.
<\sh> neuralis: oh...and how was og in person? I really envy you that you finally met him :) 
<ajmitch> neuralis: nice, I've got 4 of them to get running at uni
<ajmitch> (eventually)
<neuralis> ajmitch: yeah, we're getting our feet wet with this one, and will then consider getting more
<neuralis> ajmitch: the performance seems to be a bit underwhelming in comparison to opterons, from what i can tell
<ajmitch> depends on the workload
<ajmitch> my home box is probably faster in a number of cases
<neuralis> \sh: i only chatted with him for a few minutes, and i hadn't spoken to him before, so i can't tell you much more than that he seemed like a really nice guy
<ajmitch> except it doesn't have quite as much RAM
<\sh> neuralis: well...he entered the ubuntu community just because he read an article about ubuntu from me on the planet...funny thing :)
<fabbione> neuralis: 8 cores = 32 CPU
<fabbione> neuralis: mine has 6 cores
<neuralis> \sh: that's pretty cool.
<\sh> btw....is anyone familiar with kamions cdimage scripts? I'm just fighting with them
<neuralis> fabbione: hm. how does that work? i thought it was 1 real cpu (chip), up to 8 cores, each running up to 4 parallel threads, no?
<fabbione> neuralis: 1 real CPU that comes in 3 model. 4/6/8 cores. each core is 4 threads, but the OS see each thread as one CPU
<neuralis> fabbione: right, like intel's HT. i thought sun had a 3-CPU model T2000 out, so when you said 24 CPUs, i thought 24 cores.
<fabbione> nope
<fabbione> it's only 1 CPU
<fabbione> the T1 is not SMP
<fabbione> you can't plug more than one T1 in a box
<neuralis> fabbione: also, i have some cooler hardware in the office, but nothing nearly as cool as your stuff at home.
<fabbione> the T2 will override that
<fabbione> T2 is due to 2007 
<neuralis> fabbione: ah, got it.
<fabbione> with 16 cores and SMP
<Lathiat> whats the t2000 for?
<neuralis> fabbione: i even have the 1U keyboard/mouse unit with integrated TFT ;)
<Lathiat> like, development, or?
<fabbione> neuralis: i will get that next week :P
<fabbione> neuralis: i have another 2/3 full boxes of stuff to take
<fabbione> neuralis: i didn't have time to go and fetch them
<ajmitch> Lathiat: nethack, I think
<fabbione> Lathiat: it's the model name
* Lathiat laughs at ajmitch 
<neuralis> fabbione: very nice.
<Lathiat> fabbione: i know.. like.. do you have it for developemtn or actual use or?
<Lathiat> im jealous :)
<fabbione> Lathiat: development
<Lathiat> fabbione: cool
<neuralis> fabbione: this was my old testing rack: http://solarsail.hcs.harvard.edu/~krstic/old-office/
<fabbione> neuralis: neat
<fabbione> also the c35xx.. that one is nice :)
<neuralis> 3500xl
<fabbione> oh there is a 36xx below..
* fabbione is jalous
<fabbione> yeah
<neuralis> >:)
<fabbione> it's gigabit
* fabbione wants
<neuralis> yep
<neuralis> had a lot of trouble with it, though -- doesnt't support VLAN IDs over 1000
<fabbione> but i can use the 2Gb SAN switch to do IP :P
<neuralis> s/t't/'t/
<fabbione> neuralis: afaik none of the Cisco switches do
<fabbione> 1000 is the upper limit
<neuralis> fabbione: they most certainly do.
<neuralis> fabbione: nope.
<fabbione> hmm ok
<fabbione> did you try a more recent version of the software?
<neuralis> yes, but i think they never landed the functionality into the ios for this switch.
<fabbione> bugger
<neuralis> which was a little bit difficult, given that my outside fiber feed requires the use of vlans 1048-1051
<fabbione> eh
<fabbione> mdz: you around?
<mdz> fabbione: barely
<fabbione> mdz: ok :) any objection for a UVF exception for silo-installer? from 1.02 to 1.03. There are only translation updates.
<mdz> fabbione: none
<fabbione> mdz: thanks
<neuralis> fabbione: can you post whatever instructions you sent to colmacc somewhere?
<fabbione> neuralis: there were no instructions at all. just a reinstall.. he was unlucky enough to install while archive was not installable
<fabbione> and the system was left inconsistent
<ajmitch> and the netboot fun? it has to be done with rarp & tftp?
<fabbione> yes
<fabbione> like any other sparc
<ajmitch> ok
<fabbione> he just didn't know OBP at all
<fabbione> probably the only difference with the new OBP is tftp bradcasting
<fabbione> so what you do is:
<fabbione> boot net0:$ipaddressoftftpserver
<fabbione> where net0 is the interface is 0
<fabbione> so change it if you don't use that one
<fabbione> but i do run tftp-hpa here
<fabbione> and it works just fine
<neuralis> strange that he had problems, then.
<ajmitch> thanks
<\sh> hmm...if I have all files from archive.ubuntu.com for i386 (debs, and the installer files in dists/) I should be able to run build-image-set without any problems, right?
<fabbione> neuralis: not really.. archive for dapper is uninstallable sometimes
<_ion> glatzor: ICMP destination unreachable
<\sh> or do i need also this conf.sh stuff from debian-cd?
<neuralis> fabbione: i meant with tftpp-hpa
<fabbione> neuralis: well probably tftp-hpa doesn't answer broadcast requests..
<fabbione> neuralis: so the OBP needs to be told where to download the image
<neuralis> i see.
<glatzor> _ion: hi, would like to share with me the steps that are required to get the hal library running?
<mendred> hi is there any way to NOT use vga16fb with usplash? i want it to load radeonfb instead
<glatzor> There is no way to search for strings in rosetta?
<_ion> glatzor: Sorry, i'm very tired now. I'll post the instructions as soon as i have some energy.
<glatzor> _ion: no problem. 
<glatzor> mendred: this is a development only channel
<glatzor> Please ask your question at #ubuntu
<mendred> glatzor: sorry abt that..did that..have been hunting for an answer for days now..so thats why posted here..
<glatzor> no  problem. you don't see much acitivity on this channel at weekends either. 
<mendred> incidentally are there any plans of using upower in ubuntu in the future?
<mdke> morning Kamion, happy easter
<\sh> happy easter kamion :) 
<Kamion> morning, happy Easter
<\sh> Kamion: just fighting with your cdimage scripts and debian-cd....
<Keybuk> Kamion: happy easter
<fabbione> hey Keybuk 
<Tonio_> hi everyone
<Tonio_> Keybuk: do you have any plans for the vpn modules and network-manager ?
<neuralis> Tonio_: not for dapper.
<Tonio_> Keybuk: I tested them and it seems to work fine, so having them at least in universe could be interesting
<Tonio_> neuralis: what about universe in that case ?
<Kamion> \sh: ... waiting for you to ask me a question ...
<fabbione> Kamion: perhaps he just likes to fight :
<fabbione> :P
<\sh> Kamion: ah later...when I finally found out what update-local-packages is doing :)
<\sh> and why it's not working :)
<Kamion> you can comment it out if you don't have any local packages, if you like
<Keybuk> Tonio_: send patches; in particular I believe the VPN stuff doesn't work because we don't run bind9
<\sh> ah thx :) that would be my last try actually :)
<Tonio_> Keybuk: concerning the vpn stuff, I was able to connect to my company's openvpn server, quite easily
<Tonio_> Keybuk: I don't run a bind9 server too....
<Tonio_> Keybuk: the only difference was maybe I didn't use nm-applet, but knetworkmanager
<Tonio_> Keybuk: I used the packages we can find on revu, I don't think there are specific patches in them....
<Kamion> \sh: try patch-243 that I just committed; should make it not care if $CDIMAGE_ROOT/local/packages is missing
<fabbione> ssh sunfire -X
<fabbione> shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
<fabbione>    Linux sunfire 2.6.15-20-sparc64-smp #1 SMP Sun Apr 16 10:57:49 CEST 2006 sparc64 GNU/Linux
<fabbione> ???
<\sh> Kamion: cool...but germinate is now complaining about a missing file...
<\sh> dists/dapper/restricted/binary-i386/Packages.gz'
<Tonio_> Keybuk: may I ask you what are those dns problems you find using vpn modules ?
<\sh> Kamion: after Downloading dapper_restricted_Packages file ... a traceback ... think there is a missing file, or I'm missing something
<Keybuk> Tonio_: the fact that any custom dns the vpn needs won't be saved
<Kamion> \sh: you sure your mirror's complete?
<Tonio_> Keybuk: as far as I know, this is an openvpn limitation
<Tonio_> Keybuk: you can read the documentation on that point, it only works with windows clients
<\sh> jesus no :)
<\sh> as I said I was missing something :)
<Kamion> I should probably make cdimage be a bit more robust against restricted being missing, mind you
<Tonio_> Keybuk: I had the same problem using the command line openvpn client here...
<Kamion> feel free to file bugs on the ubuntu-cdimage product if you like; I'll be out for most of today
<Tonio_> Keybuk: technically, the vpn component for network-manager gives the same result here that it gives with the CLI client...
<\sh> Kamion: the debian-installer dir was missing
<\sh> Kamion: I used the plain debmirror and some hand-ish ncftp downloads :)
<Tonio_> Keybuk: that's why I don't think there are issues with it actually... limitations are due to the server
<\sh> the rsync is actually quite slow...and too much for my diskspace :)
<jpatrick> Kamion: can you demote kmediafactory to multiverse? Thank you
<Tonio_> Keybuk: http://openvpn.net/archive/openvpn-users/2005-02/msg00324.html here is a topic talking about that limitation...
<\sh> hmmm..but now it should be complete
<Tonio_> jpatrick: just reviewed kscope, little problem with the kdepotpath patch ;) it is incomplete :)
<jpatrick> Tonio_: oh, dear, a tag late
<\sh> damnit grmpf...no missed again something
<Kamion> \sh: ah right
<Kamion> jpatrick: done
<jpatrick> Kamion: thanks, will it rebuild automagically?
<Kamion> jpatrick: dunno; if it doesn't, ask infinity for help
<Kamion> I don't have buildd privileges
<jpatrick> ok
<\sh> Kamion: debmirror is not mirrorring the udebs, right?
<Kamion> \sh: it does if you include main/debian-installer and restricted/debian-installer in --section
<\sh> Kamion: ah...ok...i found one error..which is not raised by me...just tested it by hand :)
<\sh> Kamion: run-germinate....it stops because it doesn't find the restricted stuff in the scratch dir, when I copy the files manually from ftp/dists/dapper/restricted to the correspondant scratch dir, and then run-germinate it works...
<\sh> Kamion: doing it again via build-image-set, it failes, just because i think it deletes the whole scratch dir
<Kamion> please file a bug with a transcript of the error
<\sh> ubuntu-cdimage was the sourcepackage, right?
<Kamion> product, not source package
<Kamion> i.e. https://launchpad.net/products/ubuntu-cdimage/+filebug
<\sh> yeah..product :) got it :)
<\sh> well, executing run-germinate manually everything is fine :)
<robertc> Keybuk: around ?
<robertc> (or anyone familiar with the initramfs)
<sivang> nre all
<sivang> re, even
<robertc> hi svang
<sivang> hey robertc , what's cracking? :)
<sivang> lifeless: ah, that's better :)
<\sh> happy easter sivang, if there is something like that in israel :) 
<lifeless> well, as I have initramfs segfaulting, I'm not sure it is :0
<sivang> \sh: Stephan! It's been long, yes we have Passover , but not as much holiday as I wished to hack on stuff :) 
<sivang> \sh: is everything alright? how are you doing? you've been away for a while..
<ajmitch> evening lifeless 
<lifeless> hi ajmitch 
<sivang> happy easter ajmitch , and all
<lifeless> jbailey: I don't suppose you're up ?
<lifeless> who else can I heckle.
<ajmitch> sivang: and happy easter to you also :)
<sivang> thanks ;)
<lifeless> is devicemapper builtin or not ?
<lifeless> ahha
<lifeless> dm-mod was not loaded
<lifeless> so evms fails
<lifeless> so my root fs was awol
<Keybuk> lifeless: filesystem uses both evms and dm?
<lifeless> evms uses dm
<Keybuk> doesn't the evms local-top script load dm-mod?
<lifeless> apparently not
<Keybuk> if root=/dev/evms/* anyway
<lifeless> its timing out on 'waiting for root file system'
<lifeless> dm_mod isn't in /proc/modules
<lifeless> if I modprobe it and run evms_activate, its there, but I need to pivot manually
<\sh> Kamion: how can I see a progress for the cdbuild?
<lifeless> which I haven't figure out how to do yet ;)
<Keybuk> lifeless: what's your root= ?
<lifeless> /dev/evms/lvm2/roblvm/root
<Keybuk> lifeless: just press ^D
<lifeless> hmm
<lifeless> different this time
<lifeless> dm_mod is loaded. (wasn't on  my previous test)
<lifeless> .nodes is missing from /dev/evms
<lifeless> evms_activate populated it
<lifeless> ctrl-D - seems to be booting.
<lifeless> what can I do to help here ?
<Kamion> \sh: tail -f the log file
<\sh> Kamion: which one? 
<lifeless> bug 34209 has similar symptoms to me
<Ubugtu> Malone bug 34209 in linux-source-2.6.15 linux-image-2.6.15-17-k7 "2.6.15-17-k7 doesn't boot on Athlon 2000+" [Major,Unconfirmed]  http://launchpad.net/bugs/34209
<lifeless> but no details
<\sh> Kamion: ubuntu-daily-20060416.11.log this is the latest and tells me "syncing ubuntu mirror" :)
<Kamion> \sh: mirror sync progress goes in rsync.log
<\sh> Kamion: yes...but the cd is building :) and I don't find anything in the logfile about it :)
<lifeless> Keybuk: ok that booted fine. Appears to be that evms_activate is just not being run.
<\sh> log.list2cds?
<Keybuk> lifeless: that's run in the evms local-top script
<Keybuk> scripts/local-top/evms
<Kamion> \sh: well it should all go in whatever the current log file is, I don't know what else to tell you
<lifeless> Keybuk: I'm happy to do multiple reboots now to help debug
<Kamion> look at /proc/whatever/fd for the build-image-set process to find the log file
<lifeless> but this is my server, so I'm happy to do them *now*, but not once I get logged in and happy again.
<\sh> Kamion: i found something in log.list2cds :) 
<\sh> -- Starting to add packages to the CDs ...
<\sh> CD 1 will only be filled with 0 bytes ...
<\sh> lol
<lifeless> should I reboot and use break=top ?
<Kamion> then something is wrong between germinate output and debian-cd
<Kamion> I can't tell you exactly where - you'll need to dig
<\sh> i'm digging already :)
<Keybuk> lifeless: I'm virtually not here now, I'm afraid
<lifeless> Keybuk: yah, I realise its sunday
<\sh> but I think it has to do with the error i reported
<lifeless> Keybuk: I've added all I know to the bug report I mentioned before
<lifeless> and if someone makes a date with me, I'm happy to do a debug session on this
<Kamion> \sh: update to my fix - you should have mail
<sivang> Kamion: is it you I need to bug in order to get permission for someone to upload on my behalf a first HUB package?
<sivang> (I know we're in beta freeze, but I want this to get uploaded to universe)
<\sh> Kamion: cool :) I'll update :)
<Kamion> sivang: no, any MOTU can do it
<notlifeless> Keybuk: thanks for your time - appreciate it
<sivang> Kamion: okay, thanks.
<_ion> Cool, /me just noticed breezy already contains the version of update-manager that allows one to upgrade to dapper.
<Kamion> sivang: beta freeze is not all that relevant to new packages in universe; even if we decide it is, I can always not let it out of NEW until it's OK
<sivang> Kamion: okay, good to know then.
<\sh> Kamion: looks like he didn't create the *.packages file in scratch/ubuntu/daily/tmp/dapper-i386/
<\sh> argl
<\sh> boot-i386 is only running on i386, right?
<siretart> how to activate the ubuntu-installer's 'expert mode'? I'd like to choose my mirror, and I find it unobvious to enable that
<Kamion> press F6 for other options, press F6 again to switch between normal and expert mode
<Kamion> (in gfxboot)
<siretart> aah, ok, then that's too obvious for me :)
<bddebian> Morning
<sivang> morning bddebian 
<sivang> bddebian: hows' easter? :)
<bddebian> Heya sivang, just got up :-)
<bddebian> How about you?
<sivang> bddebian: fine, already at work, had a terrible train travel this morning :)
<sivang> bddebian: people were stuffed 3 times of what the train could relaly carry
<sivang> bddebian: we drove all way down to the south with the over weight alarm screaming :)
<bddebian> Ugh
<sivang> yeah
<Tonio_> slomo_: thanks for the yakuake diffstat ;) didn't have time to attach it myself ;)
<slomo_> np
<Tonio_> slomo_: I don't have the same diffstat than you.....
<Tonio_> which file did you apply it on ?
<slomo_> i took your debdiff and made a diffstat out of it
<Tonio_> slomo_: 16 files changed, 761 insertions(+) I only have this
<slomo_> huh?
<slomo_> do you use diff -Naur old-version new-version | diffstat ?
<slomo_> don't forget the -r parameter
<Tonio_> ...... I missed the good original version, sorry ;)
<slomo_> np :)
<Tonio_> old-version wasn't the good file ;) now I have the same than you ;)
<\sh> sollte eigentlich auch unter dapper laufen :)
<\sh> bah..wrong channel
<slomo_> \sh: oh... hi stephan :)
<\sh> hey slomo
<joelbryan> Hi sivang!
<joelbryan> sivang: your working on Home User Backup right?
<sivang> joelbryan: yes sir
<joelbryan> sivang: please check out https://wiki.ubuntu.com/UbuntuHomeBackup
<joelbryan> sivang: it's a backup tool for ubuntu, it's quite simple.
<sivang> joelbryan: hmm, is this an already ready code?
<joelbryan> sivang: yes, ubuntu-home-backup-0.1.tar.gz
<sivang> joelbryan: have you checked out https://wiki.ubuntu.com/HomeUserBackup before ?
<jpatrick> looks like Kubuntu's Keep program
<joelbryan> sivang: yes, I like the idea. that's the model I used.
<slomo_> cool now we have two backup programs ;)
<sivang> hrm, yeah 
<sivang> well, I'd hope to more collaboration, I'm sure you did not try to contact me about that..
<sivang> it seems we did some of the stuff twice, which is a shame. How do you handle multivolume backups?
<sivang> joelbryan: nonetheless is looks very cool and slick
<sivang> :)
<sivang> oh, I see you used perl , bash , C , mine is using only python actually.
<joelbryan> sivang: do you have a release?
<joelbryan> sivang: FTP is still WIP
<sivang> joelbryan: Well, I am going to make one today or tomorrow :)
<joelbryan> and got really screwed up with "new files only", I'm using cp -you with that.
<sivang> joelbryan: are you handleing multi volume backups? error checking for cdrecrod status and midphase failures?
<sivang> joelbryan: what do you think of python? ;-)
<joelbryan> sivang: it's cool! very nice PL.
<_ion> I used to think python rules, but then i learned ruby and realized how ugly python really is. :-)
<joelbryan> sivang: everything in it is using default, like nautilus-cd-burn etc.
<sivang> _ion: I think it's exactly the opposite :)
<sivang> joelbryan: ah, I'm using cdrecord directly
<joelbryan> sivang: I like to work on collaboration with this project, just found out that you made the HomeUserBackup too.
<joelbryan> sivang: what multi volume choices do you have?
<joelbryan> sivang: what mediums do you use?
<sivang> joelbryan: yes, that would be cool, could use some feedback and help from another person , we could explore borrowing and exchanging ideas , or maybe merge/translate stuff to python, if you'd forgive my python zealoutness :)
<joelbryan> yes, me too, I'm zealous about ruby, I'm on the process of writing a GUI GTK+ Glade like app that generates Ruby codes
<joelbryan> someone stole my python book back in college, that's just stop me from thinking about it. anyways, just got really interested with Dive into Python, it's very cool docu.
<sivang> joelbryan: sorry, was on the phone
<sivang> joelbryan: yes, it's a very cool book to learn python from :)
<sivang> joelbryan: so anyways, currently I support all the disc medias, and USB keys (although USB/Extenral HDs ahs not been tested fullly)
<joelbryan> Is your app very similar to the drawings?
<joelbryan> I mean, the drawings in the Design category in HomeUserBackup
<sivang> joelbryan: I use dar as the backend archiver, a very secure and proven piece of program - http://dar.linux.free.fr/
<sivang> joelbryan: ah, well, I should put new screenshots :) based on the design, but to accomodate the implementatio I had taken my route with regards to the desgin as Ubuntu's resident UI specialist was too busy to add more then that drawings he did :)
<sivang> joelbryan: I hope to get a pakcage into the archive the next coming hours, so stay tuned I'll ping you up to get it and test drive :)
<sivang> joelbryan: realizing backup archive creation is a task too critical to be handleing in a such short time on my own, I Set foot to use dar instead.
<joelbryan> sivang: how do I create .deb package with my archive too?
<sivang> joelbryan: I must say I have achived rather nice integration with it and my python frondend, but it wasn't without lots of trial and error and hard work. Bascially, you can guess my program is using other programs undeneath to do the real job.
<sivang> joelbryan: You need to create a debian package out of it, which is different per archive. I see you'er using autotools and GTK, ask around in u-motu about CDBS for that, there are arelady packaging stanzas for that AFAIK
<joelbryan> Oh I love GTK+
<sivang> joelbryan: join #ubuntu-motu
<joelbryan> rocks my world!
<joelbryan> ok
<sivang> joelbryan: here as well :)
<sivang> joelbryan: also, I still don't have FTP backup support, I concentrated manily on medium backups for now, since most newb users wouldn't want or use ftp backups.
<joelbryan> yes, I think I'll hide the ftp widget in my app too, having a hard time implimenting it.
<sivang> joelbryan: so do you support multi volume backups?
<joelbryan> sivang: I'll collaborate on your app too when your release is ready.
<sivang> joelbryan: cool! :-)
<joelbryan> sivang: tell me about multi volume backup?, got no idea what it is.
<sivang> joelbryan: ah, when you're backup is more then one medium in size, you need to split it to slices and back each one to a different cd
<joelbryan> I think nautilus-cd-burn has that feature
<joelbryan> I depend on it
<sivang> joelbryan: for differential snapshots, I have one diff CD (which is remained multi session) where you add a snapshot ontop of the other  per each new diff against master snapshot I create.
<joelbryan> I use mkiso, err.. does mkiso included on ubuntu main?
<sivang> joelbryan: sort of a backup CD kit I create for the user :)
<sivang> joelbryan: yes
<sivang> joelbryan: I'm using it as well, but I don't depend on n-c-b , you could use n-c-b to create the iso no?
<sivang> joelbryan: (instead of directly using mkisofs)
<zyga> is there any recent unusual SDL bug activity?
<joelbryan> sivang: nope, do you know how to use nautilus-cd-burn to create ISO files?
<sivang> joelbryan: I've seen in the source somewhere it has a small API for that, I evaluated n-c-b but in order to make dependencies as smalla as I can I choose to do stuff myself instead of depdending on it. For places where n-c-b might not be installed, or required to not be installed.
<joelbryan> sivang: I like to use n-c-b to create ISO files, but it only got --source-iso=STRING as an option.
<sivang> joelbryan: ah, well, look at the code, it has somewhere a simple api for creating isos, as it uses it for itself to create an image of files you drop into the cd-burner nautilus window
<bddebian> Why does packages.ubuntu.com not let you search dapper?
<bmonty> bddebian: it works for dapper
<bddebian> It does?
<bmonty> yup
<bddebian> Under contents of packages?
<bddebian> I don't see a dapper option
<bmonty> you can use packages.ubuntu.com/[package name] 
<bmonty> or you can pick dapper from the search form
<bddebian> I want to know what is supposed to proved /etc/X11/config/cf stuff
<bddebian> Err provide even
<bmonty> ahh
<bmonty> I see what you are saying
<bddebian> :-)
<bmonty> same problem here :)
<bmonty> bddebian: I guess you could use dpkg
<Chipzz> bmonty: not it does not
<bddebian> But only for what I have installed right?
<bmonty> yeah
<Chipzz> the "Search the contents of packages" section does not allow you to select dapper
<bmonty> Chipzz: yup
<Chipzz> which can be pretty annoying ;P
<bddebian> Yep :-)
<bmonty> bddebian: http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=%2Fetc%2FX11%2Fconfig&searchmode=searchfilesanddirs&case=insensitive&version=dapper&arch=i386
<bmonty> try that :)
<bddebian> Nice
<bddebian> Now, who in main is going to fix those files? ;-P
<bddebian> Ah, Malone Bug #28707
<Ubugtu> Malone bug 28707 in imake "ProjectRoot set incorrectly" [Minor,Confirmed]  http://launchpad.net/bugs/28707
<bddebian> fabbione: ping?
<fabbione> bddebian: ?
<bddebian> fabbione: You made a comment to the bug above.  Do you know if it is going to get done?
<fabbione> did you read my comment before asking?
<bddebian> Yes
<bddebian> Oh, I missed the after part :-(
<\sh> lol
<fabbione> so what is not clear about "We will fix it after dapper"?
<bddebian> So what are supposed to do about packages in Universe that are using /foo/X11R6/bar that break?
<bddebian> Move the files in rules?
<\sh> Kamion: I hope it's not an easter egg, but do i need the source files (.dsc,.tar.gz, eventually .diff.gz if not native) for the cdbuild mechanism?
<fabbione> bddebian: yes. fixing that bug makes half of main unbuildable
<fabbione> and in most cases apps still do the wrong thing
<fabbione> even with that path fixed
<bddebian> Fruck, OK
<bddebian> Should I just not touch those packages?  Such as xclip, etc?
<fabbione> fix them
<fabbione> or leave them broken
<bddebian> How?  They run xmkmf in the rules so they pick up that path
<bddebian> cp/mv in rules?
<fabbione> how it's up to you
<bddebian> This is the part I still don't get.  I keep hearing how we don't want to stray too far from Debian, then folks suggest fairly radical changes..
<bddebian> I'm not whining, I'm just never sure what to do.  Seems like when I step too far I get swatted with the clue bat :-)
<\sh> bddebian: please...it's universe, if you don't want to fix it, leave it and wait for dapper+1, or fix it, and merge/sync it later in dapper+1 
<fabbione> \sh: ++
<\sh> that's what I said long time ago, when this debian ubuntu bla started..we have to make sure, that the packages are working, or we focus on debian, and stay close, and not better
<bddebian> I'm game either way I just want to "do the right thing"
<\sh> there is no "right thing"...decide for yourself...if you think it's worth it, do it, give the user a working package...if you think it's a waste of time for this package, and it will be solved later on, leave it, forget it, drink a beer :)
<\sh> I mean, that's universe, 30 people against thousands of packages...I bet, the packages win :)
<bddebian> :-)
<\sh> bddebian: actually it's the real life...you can go left or go right...there is no middle way...one way or the other, someone will bash you or something will happen...you only have the duty to face the consequences :)
* \sh sounds like Morpheus or the Oracle
<bddebian> heh
<\sh> "You already made the choice, you are only here, to understand why you made it"
<\sh> and to be honest, to create a live cd for gentoo was much easier then this cdimage/germinate/debian-cd thingy here..but I will crack it...and finally understand :)
<bddebian> :-)
<bddebian> Time to go, thanks \sh, fabbione
<zyga> \sh: nice speech!
<\sh> hehe...now I can say it without being burned by someone with the flamethrower :)
<\sh> couple weeks ago, I said the same, and I got burned :)
<highvoltage> win 20
<_ion> lose 15
<highvoltage> hehe
<\sh> actually it's 18kg i lost :)
<highvoltage> _ion++ [ an optimist] 
<zyga> \sh: getting burned is why you are doing it in the first place
<zyga> you wanted to get burned... bla bla bla ;] 
<\sh> zyga: I don't do it in the moment anymore :) I don't have the rights anymore :)
<_ion> My weight has been 62.51.5 kg for several years. :-)
<zyga> chmod +s \sh
<\sh> :)
<zyga> bah
* zyga gets back to writing a kernel
<\sh> my weight was 80...I lost 18 makes 62 now...bei 180cm height..I'm the Kate Moss of all Ubunteros :)
<highvoltage> zyga: a kernel for what?
<\sh> hurd 5.0
<zyga> highvoltage, \sh: heh, no :)
<zyga> right now for quemu running i386
<zyga> :)
<zyga> just for fun as someone said
<zyga> it's not unix like and will never ever be able to run any C code 
<zyga> so wish me luck ;-)
<giftnudel> \sh: i'm of the same height, and I weigh even less ;)
<fabbione> bah you all suck
<fabbione> i am 1:80 and 120 KG
<fabbione> that's probably why they call me big fabio
<zyga> I'm 85 and 176 or so... geez ASL on #-devel :D
<fabbione> you are 85 years old.. and weight 176kg?
<fabbione> dude.. congratulation
<zyga> hehe ;] 
<zyga> rotfl ;] 
<zyga> I weight 85 kilos if that wasn't explicit enough
<\sh> fabbione: wait until you come to germany...I'm trying to go back to 75-80 kgs...it's my best weight..now I'm feeling terrible
<fabbione> \sh: i am gaining a lot of weight because i did quit smoking
<fabbione> \sh: i was 105 when we did met
<\sh> fabbione: you did what? quit smoking? how can you? smoking is good against this "I want chocolate" feeling :) 
<fabbione> \sh: yes... i did it...
<fabbione> it's about 2 months now
<fabbione> + one week
<\sh> congrats :)
<fabbione> it's damn hard
<zyga> fabbione: keep up the good thing
<fabbione> i still wake up in the morning with the "ME WANTS SMOKE MUCH NOW IMMEDIATLY"
<fabbione> but they say it goes away after a few years
<\sh> serious...that's good :) I stopped 4 years ago for 3 months...and after those 3 months...I couldn't help myself and started again
<\sh> fabbione: it's the all day habit
<fabbione> yeah i knw
<\sh> you wake up..the first thing: a cigarette and a black coffee..yummy...good for the stomach
<fabbione> i feel 14 years old again..
<fabbione> you want to try to smoke.. you want to try to have sex... etc..
<_ion> sh: ICD-10 / F17.2
<\sh> well, it steels you 2 years of your life...but damn who cares anyways ;)
<\sh> _ion: whatever it is:)
<fabbione> \sh: i am doing it only for my wife and kid..
<_ion> sh: Google. ;-)
<\sh> fabbione: do it for you...(and for your kid) wife has always the chocolate ;)
<zyga> \sh: cheers for your elder years when you wish you didn't smoke
<\sh> zyga: well...what elder years, when I make it 65 it's old enough...:)
<zyga> grampa \sh why are you so yellow and making hissy sounds
<zyga> ah, it's because I didn't care about the last two years of my life and brats like you ;-)
<zyga> (no offence)
<\sh> because, son, I ate those yummy gitanes tobacco roles :)
<zyga> parents in law are smoking like a chimney machine
<zyga> I hate that
<_ion> http://www.visualsunlimited.com/images/watermarked/227/227359.jpg
<zyga> heh
* zyga keeps right-clicking on links
<zyga> a bad behaviour from xchat with useless link handling
<\sh> and now you are using kde and konversation and it just works :)
<zyga> no, I'm using xchat-gnome and it just works :-)
<\sh> bleh :)
<zyga> hehe
<\sh> http://code.google.com/soc/ Ubuntu is missing..who is responsible? :)
<Chipzz> who is the mysql maintainer? :P
<\sh> mysql AB :) 
<zyga> hmm
<zyga> a widget has just turned green 
<zyga> has anyone experienced something like this?
<zyga> using ubuntu theme obviously
<fabbione> zyga: what widget?
<zyga> fabbione: a standard gtk+ button
<zyga> in banshee, c# itunes clone
<zyga> after giving the button mouse hover it turned back normal
<zyga> but it was fully green before that
<fabbione> i think there is a very very fishy bug in gtk
<zyga> so this has happened before
<zyga> the button turned green after becoming insentsitive
<zyga> it was focused AFAIR
<zyga> but I'm not sure
<zyga> I removed one song from the playlist
<zyga> and it got disabled (the write CD button is active as long as you have selection handy)
<zyga> BAH!
<zyga> now it's blue!!!
<zyga> screenshot
<zyga> where the heck is the screenshot tool?
<zyga> half of the button is normal again
<zyga> got it
<zyga> http://ubuntu.suxx.pl/2006--1/bugs/fishy-gtk-bug-with-widgets-color-change
<fabbione> wow... Bolero from Ravel
<fabbione> !
<zyga> :)
<fabbione> i still have the LP somewhere in italy!
<zyga> not everyone is listening to trashy modern music :)
<fabbione> i don't
<fabbione> i listen to a 20 years old heavy metal :)
<fabbione> almost.. 20
<zyga> I like classics and movie scores
<fabbione> pink floyd, hard rock, heavy metal..
<fabbione> it depends what i need to hack usually ;)
* desrt puts on the beaty and the beast (disney) soundtrack
<fabbione> eheh
<fabbione> we should make radio.ubuntu.com
<fabbione> where we can send our feeds.. or something
<fabbione> but that would require some fees i think
<zyga> :)
<fabbione> for copyright and crap
<desrt> seems like a good way to get a smackdown notice from the song police
<zyga> we should make iUbuntu or .Ubuntu
<fabbione> exactly
<zyga> that would just kick the linux distro world straight int the ass
<zyga> (p2p manner would be cool)
<fabbione> p2p won't save you anyway
<fabbione> the problem is not how you redistribute it
<fabbione> but that you are actually redistributing it
<zyga> like every server install could ask the administrator: would you like to provide %1 of your resources for community 
<zyga> blah blah kind of thing
<zyga> fabbione: I'm not talking about the radio thing
<zyga> I know that music needs fees
<zyga> but a distributed .ubuntu service would be really interesting
<fabbione> oh that super shared drive or alike?
<zyga> even for developing the required technology on ubuntu servers for beta-testers
<fabbione> 3 things are clashing
<zyga> fabbione: not just that, idisk + services = .mac
<zyga> bundled services make it worthwile
<zyga> while
<fabbione> i don't think there is anybody with enough time to implement something like that in our team
<fabbione> even if there is the knowledge in the house
<zyga> I don't know the team so I cannot say much here
<zyga> but making lots of in house tools could be unnecessary
<zyga> what we'd really need is the reliable, scalable and secure idisk replacement
<zyga> the services could be foss stuff with ubuntu branding and that's just what we do
<fabbione> yes and do you have an idea on much tech is required just to make that?
<zyga> yes, that's really hard bit
<fabbione> you need something like GoogleFS
<fabbione> oh wait.. but that one is proprietary ;)
<zyga> well someone is going to do it, and when they do they'll get the fruits
<fabbione> if they do it fully opensourced, it will take only a few days to have it in all distros
<fabbione> don't you think?
<zyga> not quite
<fabbione> it will be a metter of running the service on what platform
<zyga> remember, the services count
<zyga> and the services are mostly web-based or based on web tech
<fabbione> yes but you approached only the idisk issue before...
<zyga> so while anyone could put gnu-disk in, it' be just that
<zyga> yes, I agree then
<fabbione> so i am looking at one thing at a time
<zyga> it's hard but not impossible
<fabbione> it's already there.. just not opensourced
<zyga> there are folks out there with brains to do it :)
<zyga> foss folks
<fabbione> yes
<zyga> it's not top priority for anyone though I guess
<fabbione> given enough trust even pigs can fly... not sure we want them to
<zyga> hehe
<zyga> nice quote
<fabbione> it's not mine..
<_ion> Thrust, you mean?
<fabbione> _ion: yes
<zyga> ion engines attached to pigs ... sorry it somehow matched in my mind :)
<fabbione> zyga: that quote is from Alan Cox when somebody announced ATA66 "standard"
<_ion> Hehe.
<fabbione> "hey we can run IDE as twice as fast!"
<_ion> Appropriate.
<fabbione> and in 2006 we are still fighting with DMA and ATA1GHZ
<zyga> sorry for my ignorance but what's wrong with ATA?
<zyga> (especially at that time)
<_ion> What isn't? ;-)
<zyga> beats me 
<fabbione> zyga: tell me something good about ATA?
<fabbione> it's a badly designed protocol
<zyga> I still run my baby hosted and i/o is something I don't handle yet :)
<fabbione> it has tons of limitations and issues because when they wrote the specs, they were not clear
<fabbione> so as of N years after
<fabbione> you still file bugs on "Why the kernel can't enable DMA?"
<zyga> unclear specs = lots of different implementations?
<fabbione> zyga: yes
<zyga> sweet :)
<zyga> I like the linux kernel
<fabbione> that gets down to:
<fabbione> - poorly written BIOS
<fabbione> - broken ATA controllers
<fabbione> - broken ATA devices
<zyga> I consider it the greatest available source on how to get the hardware working
<fabbione> - sucky driver for even more sucky cheap hardwawe
<fabbione> hardware even
<zyga> is sata protocol-compatible with ata?
<zyga> just curious
<fabbione> no
<fabbione> there are adapters with mini-chips to attach an ATA device to a SATA controller afaik
<fabbione> old ATA = PATA (Parallel ATA)
<fabbione> SATA = Serial ATA
<fabbione> SATA is closer to scsi protocol somehow
<fabbione> all these cheap abberrations will end up reimplementing SCSI at the end
<fabbione> the only real true I/O protocol
<zyga> then again we hit the market chooses what's cheaper 
<zyga> or 90% of right with 10% of price is better
<zyga> maybe 60% and 40% in this case ;-)
<fabbione> right.. but it's all speculation at the end
<fabbione> because for that X % better price
<fabbione> you spend NX trying to get your hw going "fast" in DMA
<fabbione> and stuff like that
<fabbione> assuming that the next time you attach a device, you will not have to dismount and reconfigure the entire IDE chain
<fabbione> because there are devices that can't live on the same IDE controller
<fabbione> or stuff either doesn't work or it goes south 
<zyga> fabbione: not me, the poor guys and gals who make the soft I'm running
<zyga> maybe me in this ackward particular case but that's irrelevant, the buyers don't really see :)
<fabbione> well but you get the general idea
<fabbione> i also run IDE stuff..
<fabbione> somehow i have to
<zyga> as the bottom line let's rejoice in the fall of PATA and the rise of SATA :-)
<fabbione> well not really.. i am saving up to buy a bunch of FC-HBA controllers :)
<zyga> what for? (note: I'm ignorant about what that's for actually)
<fabbione> FC-HBA are fiber controllers.. somehow similar to ethernet
<zyga> ah
<fabbione> but they can "speak" differnet protocols
<fabbione> (i am making it simple now)
<zyga> so now we wait for cheap-o-replacement of myrinet and such stuff :-)
<fabbione> like SCSI and IP
<fabbione> they can do up to 8Gbit/sec
<fabbione> so basically i can get rid of networking and storage in one go
<fabbione> and get everything centalized :)
<zyga> just wait till the 25$ a-oem-box 10GB eth hits the street then
<fabbione> with access ot the storage up to 200MB/sec (disk speed is the limit here)
<fabbione> nope..
<zyga> nice HW anyway
<fabbione> it's not the same :)
<fabbione> different standards..
<zyga> yes but for the general population it'll be ohh, look 8Gb vs 10Gb
<fabbione> 10GB Eth is still an ethernet
<zyga> silly as that
<fabbione> yes i know..
<zyga> not to mention ohh look 2K$ a piece vs 25$ a piece
<fabbione> find me a cheap 10GB switch that supports zoning/vlans and stuff like that
<zyga> and with windows sticker too ;-)
<fabbione> ahah
<zyga> fabbione: heh :)
<zyga> I don't do hw really, I'm mostly incompetent 
<zyga> though the new job is showing a chance to learn :)
<fabbione> i don't much hw either. not anymore...
<fabbione> i used to do a lot when i was working for computer shops
<zyga> (we're running tons of tons of multicasts/broadcasts on 100Mb lan and have recently recovered from the strain
<zyga> recent trips to the server room was productive
<zyga> s/was/were/
<fanopnaic> who am i supposed to contact regarding distro-specific bugs in gnome-terminal, which doesn't use malone?
<Chipzz> fanopnaic: bugs are *extremely* *rarely* distro-specific
<Chipzz> fanopnaic: as a matter of fact, except for the launchpad stuff, gnome-terminal is not patched at all
<fanopnaic> ok, this is my bug at gnome.org: http://bugzilla.gnome.org/show_bug.cgi?id=338509
<Ubugtu> Gnome bug 338509 in general "g-t does not eat up the previous/next tab sequence when on the edge of the tab bar" [Normal,Unconfirmed]  
<Chipzz> how is this relevant to dapper? dapper has 2.14.0
<fanopnaic> I am running dapper and it has 2.14.1
<Chipzz> yes
<Chipzz> hrrrm misread the bug report
<Chipzz> anyway
<Chipzz> I don't see how this *can* be distro-specific
<Chipzz> ubuntu doesn't change any related code
<Chipzz> http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-terminal/gnome-terminal_2.14.1-0ubuntu1.diff.gz
<fanopnaic> I saw that, is this the diff to the debian source or the original source?
<crimsun> original upstream tarball.
<_ion> Why does the default /etc/avahi/avahi-daemon.conf contain "use-ipv6=no"?
#ubuntu-devel 2006-04-22
<mdke> who knows what there are two packages for nvidia-glx and -legacy? Why not a single package?
<Seveas> mdke, -legacy is an older version of the driver
<Seveas> the newer versions don't support older cards
<mdke> Seveas, I know. My question is why the drivers are not included in the same package
<Seveas> because they use the same filenames iirc
<mdke> there would be some obvious advantages to doing so, and I believe this is done by other distributions
<mdke> apparently gentoo ships them together, for example
<mdke> if that's true, can "same filenames" be the answer?
<Seveas> apt-file lists says there are lots of files with the same filename
<Seveas> so for Ubuntu that is the answer, dunno how gentoo does it
<jdong> Seveas: they have a symlink handling script... opengl-update
<jdong> i.e. "opengl-update nvidia", "opengl-update nvidia-legacy", "opengl-update mesa"
<jdong> and it creates the appropriate opengl symlinks
<jdong> the ebuild instructs users to run the script after emerging nvidia drivers
<Seveas> would be the same as an alternatives group on Ubuntu
<jdong> yeah, basicaly
<Seveas> interesting approach
<jdong> and we should be able to auto-detect/determine whether we need legacy or new drivers
<jdong> (a bit complex with multiple cards, but nonetheless possible)
<mdke> that sounds saner than having separate packages, and an extra -settings package
<jdong> ugh, yeah, especially now that one of the nvidia-glx packages includes  nvidia-settings :D
<mdke> quite
<jdong> is it too late to make that change though?
<mdke> oh yeah
<jdong> ok
<jdong> a bit OT, but does anyone know if Dapper i386 runs on the MacBooks?
<jdong> (without a tremendous amount of BootCamp hacking)
<jdong> I noticed a while back we were enabling EFI stuff left and right....
<delire> if you haven't already, a review of dapper: http://www.linuxforums.org/reviews/ubuntu:_a_ramble_through_drake_lake.html
<delire> out of interest has there been any talk of autodetecting cards that support XGL and providing users with an option to run it on install? 
<Chipzz> why would we wanna do that?
<Chipzz> it's not like it's stable or even usable
<Chipzz> compiz lacks several important features/does things wrong
<delire> Chipzz: not for Dapper, in future in general.
<gandalf> why isn't dapper using xulrunner for epiphany?
<Seveas> gandalf, xulrunner wasn't ready in time
<gandalf> its been stable for quite a while
<robertj> delire: it is 100% safe to ignore any "a review of X OS" that comes out < 1 week AFTER OS release
<gandalf> I get the impression that there is a lot of firefox advocacy going on which has gotten in the way of removing it as a dependance for epiphany. Rather than let the user decide the mindset seems to be that firefox should always ben installed
<gandalf> epiphany isn't going to get far if it remains dependent on the installation of another browser to function
<robertj> gandalf: SPEC out a "Uninstall firefox with gnome-app-install" for dapper+1 then
<gandalf>  i'm just curious why there seems to be so much resistance to allowing epiphany to function independently of ff
<robertj> gandalf: it's just release prep
<robertj> gandalf: it's not a conspiracy
<crimsun> never mistake malice for Parkinson's Law
<robertj> gandalf: if anything it's probably just people ignoring any post containing the word epiphany because of all the "Epiphany should be our default browser" posts
<gandalf> maybe, some of the ML chatter just leads me to believe that some people are pushing ff too hard. I can understand why. FF does not really fit in with KDE, and konqueror is pretty solid these days. FF is a better fit in gnome, but still not HIG compliant or as integrated as epiphany. If you make epiphany independent of FF then there will be a lot fewer FF installs on linux desktops
<sabdfl> i would really like to see better FF / desktop integration, for one
<gandalf> won't happen
<Chipzz> gandalf: and yet I like ff *a lot* more than epiphany
<Chipzz> bckspace/shift-bckspace
<Chipzz> tabs taking up less vertical space
<gandalf> sure FF has a lot going for it, but it suffers from a sluggish interface
<Chipzz> tabs shrinking horizontally
<gandalf> there are actually moving to fixed width tabs
<Chipzz> it does, and is still preferable to epi
<Chipzz> epi just lacks a lot of the shortcuts/features I'm used to from ff
<robertj> sabdfl: is there a way to assign a draft spec to dapper+1 currently?
<gandalf> sure, and for those users that want FF it is easy enough for them to select it as an option. Epiphany is covering a difference audience that FF
<Chipzz> gandalf: for users migrating from windows, its still not a good idea
<jdong> better FF performance....
<jdong> right now it's not even funny
<Chipzz> they me be migrating from windows + ff
<jdong> UI redraws are horrendously CPU and time intensive
<Chipzz> and even in windows + ie backspace / shift-backspace work
<gandalf> I use FF on windows because it performs OK, but the linux version is the poor relation for sure. Even the UI looks klunky in comparison
<robertj> I think for most users, firefox is one of their best parts of the Linux experience
<gandalf> no way
<robertj> Web-browsing is a relatively complete use case
<gandalf> The linux version is very neglected, and it's not getting the kind of love the win32 versin does. Understandable though as win32 is one deskop platform, with linux you have a lot more desktop options and so far less integration
<Chipzz> gandalf: while I agree with you that firefox could be better integrated with gnome, epi is IMHO not the solution
<jdong> the integration has improved recently...
<robertj> I use Firefox on Mac daily and so perhaps I'm just thankful for the versions shipped by Ubuntu
<Chipzz> it still does not use stock icons
<gandalf> OK, but epiphany should be compiled to use XULrunner and it should be the default browser if the user chooses gnome as their desktop
<gandalf> just like konqueror should be the default if KDE is used as the desktop
<jbailey> lifeless: Was out for the WE, am back now.  'sup?
<Chipzz> gandalf: *sigh*
<Chipzz> gandalf: as has been pointed out to before, its not compiled vs xulrunner probably because the ubuntu people did not want to introduce new risks by switching to xulrunner this late in the release-cycle
<gandalf> So you saidm I'm taking about a +1 release
<Chipzz> s/out to/out to you/
<lifeless> jbailey: failure to boot with the current kernel, initramfs isn't running evms_activate properly
<Chipzz> s/vs/against/
<robertj> Chipzz: do you have any idea if you can propose a spec target a specific milestone?
<Chipzz> robertj: no, I'm not even an ubuntu developer ;)
<robertj> Chipzz: or if there is even a spec overview page?
<jbailey> lifeless: Ugh, weird.  I don't have an evms setup to test, and am not really involved in initramfs stuff these days.
<jbailey> lifeless: So I don't have a good answer off hand, sorry.
<lifeless> jbailey: np. I got keybuks eyeballs for a bit
<lifeless> and we concluded it was weird.
<lifeless> still needs a fix though, have to manually repair each boot at the moment
<Chipzz> gandalf: you'll have to come up with better arguments if you want epi to be the default browser
<jbailey> lifeless: Huh, weird.
<lifeless> (repair == 'evms_activate'; Ctrl-D)
<Chipzz> gandalf: I'm sure the ubuntu people have very good reasons for having it as a default
<robertj> https://launchpad.net/distros/ubuntu/+specs is the overpage btw
<gandalf> Chipzz: Would you have 'gedit' as the default text editor in KDE?
<Chipzz> firefox is neither gnome nor kde
<Chipzz> bzzzzzzzzzzt, bad example
<Chipzz> next?
<Chipzz> (I use vim anyway, but whatever)
<gandalf> exactly! Firefox should be an elected default. Otherwise you are lumbering users with a sub-optimal experience
<bddebian> Howdy folks
<Chipzz> gandalf: I'm growing really tired of this discussion
<Chipzz> your argument is incorrect
<Chipzz> .
<gandalf> Chipzz: because it does not accord with your view of things? Not really the acid test of validity I feel
<Chipzz> gandalf: no, because your reasoning IS incorrect
<Chipzz> let me show you why
<Chipzz> firefox is not a gnome application, neither a kde application
<Chipzz> lets call it an "X application"
<Chipzz> using firefox on gnome == using an X application on gnome
<Chipzz> using gedit on kde = using a gnome application on kde
<Chipzz> see how that is different?
<gandalf> yes, but the point is FF is not giving the user an optimal experience in gnome or kde so it should not be the default in either. The kind of users that would know about FF are going to be able to set it as default themselves
<Chipzz> no
<Chipzz> firefox is not giving the user an optimal experience *in*your*opinion*
<gandalf> well me and a small army
<Chipzz> epiphany just lacks too many features *in*my*opinion* to be usefull
<Chipzz> oh and btw
<Chipzz> noticed how ubuntu is not the only distro doing this?
<neuralis> the reasons for using firefox instead of epiphany have been debated ad nauseam on u-d. nothing to see here, please move on.
<gandalf> Chipzz: But youknow enough to chnage the browser. Joe Average user is likely going to stick with whatever he gets, and lumping him with FF seems abad decision
<Chipzz> if joe average user is unable to change his browser, he is most likely coming from windows (with either ie or ff) anyway
<Chipzz> for ie it doesn't make a difference, for ff it's what he's used to
<gandalf> raher confusing though as FF is not HIG compliant for gnome
<Chipzz> oh god
<Chipzz> 02:21 < Chipzz> gandalf: while I agree with you that firefox could be better integrated with gnome, epi is IMHO not the solution
<Chipzz> I didn't say it couldn't be improved, did I?
<gandalf> gnome hig has been around for a long time
<Chipzz> but in the end it does not matter what you think or what I think
<Chipzz> 02:38 < neuralis> the reasons for using firefox instead of epiphany have been debated ad nauseam on u-d. nothing to see here, please move on.
<gandalf> like i said before I understand why people are pushing FF, I just think they do it for the wrong reasons
<Chipzz> wrt gnome hig btw
<Chipzz> a lot bigger problem is OOo imho
<Steff_breezy> hi, could somebody please tell me a name of a channel op of #ubuntu, im banned from there for posting off topic content, i want to excuse and participate again
<neuralis> Steff_breezy: seveas is one person to talk to.
<Steff_breezy> ok, htx
<Lathiat> hrm
<Lathiat> what happened to /etc/network/options 
<Lathiat> thats goign to break some msetups
<Lathiat> aah, i see
<Lathiat> usign sysctl.conf, still, that can breaj existing setups that rely e.g. on ip_forward, so there should be some notes about that or someting
<jdong> are the new ipw3945abg cards going to be supported by dapper?
<jdong> specifically, Malone 35215....
<Ubugtu> Malone bug 35215 in linux-source-2.6.15 "ipw3945 driver required for functionality on new Intel PRO/Wireless 3945ABG Mini-PCI Express Adapters" [Normal,In progress]  http://launchpad.net/bugs/35215
<jdong> so, being in progress, does that mean we're going to support it?
<jdong> including the userspace daemon and firmware, so that it works out-of-the-box?
<jdong> it's scary how many core duos are on the shelves nowadays
<jdong> they just exploded in popularity
<sabdfl> jdong: will you get a read on that from benc later?
<jdong> sabdfl: it sounds like a sortof yes.... I've heard at least one of those back two releases ago that didn't make it because of missing pieces ;)
<jdong> but I have confidence in you guys
<sabdfl> 3945 is quite a big deal
<jdong> I understand... which is why I am quite concerned about it
<jdong> other than this wifi card, I think we support el generico core duo pretty well
<jdong> I believe we have the sound card and video drivers for it working, already
<jdong> (I guess a background motive is I'm looking into buying a core duo myself... and want to make sure it'll run Ubuntu!)
<bddebian> heh
<bddebian> Hey it'll run XP/vista, what more could you need? ;-P
<jdong> lol
<jdong> well, I'm gonna go off to bed now
<jdong> great to see you, sabdfl....
<jdong> night
<sabdfl> night
<lifeless> gnight
<Burgundavia> mako: you around?
<neuralis> Burgundavia: hey
<neuralis> Burgundavia: mako and i are here, you around?
<Burgundavia> neuralis: check
<ajmitch> hi neuralis, Burgundavia 
<Burgundavia> salut ajmitch
<neuralis> hey ajmitch
<neuralis> how goes?
<ajmitch> good, just fighting with zope :)
<neuralis> yuck. i won't repeat my opinion of zope :)
<ajmitch> yeah, I remember your decriptions :
<ajmitch> but I'm using plone for a project - pity it's all uninstallable right now
<Burgundavia> mako: about to head to bed. You around?
<Amaranth> mathrick: build-essential is a package you can guarantee is installed on the buildds, thus no package depends on it, needed or not
<Amaranth> \sh!
<mathrick> Amaranth: buildds is what?
<\sh> moins Amaranth
<Amaranth> mathrick: debian and ubuntu and likely everyone else making debian derivatives
<Amaranth> mathrick: it's just...there
<mathrick> Amaranth: but, uh, that's about an end-user oriented package
<mathrick> I couldn't care less what's installed on debian's build machines :)
<Amaranth> yeah, tricky
<mathrick> IMHO, there should be devel-core package
<Amaranth> you can try reopening it and pointing that out, i guess
<Amaranth> devel-core? you mean build-essential? :)
<mathrick> since debuild isn't really the essential dep for someone doing own devel
<mathrick> s/the/an/
<Amaranth> hmm
<Amaranth> i'd think it wouldn't be worth the hassle
<\sh> hmm..anyone an idea if there is a python interface lib for procfs?
<ajmitch> morning \sh 
<mako> Burgundavia: hey
<mako> i'm back home now
<\sh> morning ajmitch :)
<Amaranth> \sh: google turns up nothing useful
<\sh> Amaranth: yeah...google was my first place to look :)
<mathrick> Amaranth: hassle?
<Amaranth> actually, first result?
<mathrick> it's a simple dummy package
<mathrick> s/dummy/meta/
<Amaranth> In the pyNMS package on sourceforge (http://sourceforge.net/projects/pynms) there is a module called Linux.procfs, and in it there is an object called "ProcStat" that lets you get the process info easily (if running on Linux).
<\sh> Amaranth: something with windows and procfs from a external package...which has nothing to do :)
<\sh> Amaranth: yeah...checked it...it's only one class for ProcStat
<Amaranth> ah
<\sh> which is nothing :)
<Amaranth> mathrick: you'd have to keep it in sync with build-essential and such
<mathrick> Amaranth: I would?
<mathrick> isn't that simply a small list of "assumed to be present" build tools?
<mathrick> I really don't care about debian here, I want to compile my stuff
<Amaranth> yeah, like make, auto*, etc
<Amaranth> it'd be easy enough normally but you'd probably have to make it yourself
* Amaranth tends to not make sense at these hours
<Amaranth> so..yeah :P
<\sh> hmmm....
<\sh> am I so damn stupid?
<\sh>  /dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0 
<\sh> this is working for all users to mount a cdrom drive from gnome or kde, right? /media/cdrom0 is plain directory, with 755 as permission settings
<\sh> now I want this behaviour for an samba share
<\sh> /192.168.1.12/mp3      /media/mp3      smbfs   user,noauto     0       0       
<\sh> drwxr-xr-x  2 root root    6 2006-04-15 05:23 mp3
<\sh> and I'm not allowed because of the /media/mp3 directory
<\sh> gnarf
<\sh> so what can be wrong?
<fabbione> \sh: iirc the samba mount points in fstab are different
<fabbione> like \\192.168.1.12\mp3
<\sh> fabbione: no...this works as root and when I have it on auto :)
<\sh> all checked :)
<\sh> i had to set smbmnt to suid
<\sh> to get the mount working for plain users
<\sh> but now
<fabbione> ok
<\sh> shermann@toshiba-laptop:~$ mount /media/mp3
<\sh> Password:
<\sh> cannot mount on /media/mp3: Operation not permitted
<\sh> smbmnt failed: 1
<fabbione> strace it to see what is reporting the error?
<tritium> \sh: have you tried libpam-mount?
<\sh> fabbione: that's what I'm doing next :)
<\sh> mount.smbfs is telling me this...but why and where...i don't even see in strace
<\sh> lstat64("/media", {st_mode=S_IFDIR|0755, st_size=84, ...}) = 0
<\sh> lstat64("/media/mp3", {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
<\sh> geteuid32()                             = 1000
<\sh> tritium: what about libpam-mount?
<tritium> \sh: I use it to auto-mount samba dirs on our network at work.  No need for /etc/fstab or credentials files either
<\sh> tritium: I don't want to automount them :) I want that a user can mount them on demand with their own logins towards the samba server..this works actually as root :) but now for the plain user :)
<tritium> \sh: it's not an auto-mount.  My poor choice of words.  It mounts when I login.
<tritium> \sh: anyway, it may be worth looking at, or not
<\sh> apt-get install libpam-mount?
<tritium> yes, \sh 
<tritium> \sh: I appended "@include common-pammount" to /etc/pam.d/gdm and /etc/pam.d/login, and then setup a ~/.pam_mount.conf file
<tritium> the docs in the package are pretty good
<\sh> yeah...just reading :)
<\sh> restarting session brb
<mako> neuralis: i talked to corey.. he seems cool with whatever
<mako> neuralis: and i just emailed everyone with the suggestion
<tritium> \sh: how did it work out?
<\sh> tritium: in the moment it does nothing :)
<\sh> tritium: I wrote something like this in .pam_mount.conf
<\sh> volume shermann smbfs 192.168.1.12 mp3 /home/shermann/mp3
<tritium> \sh: Did you allow "luserconf .pam_mount.conf" in /etc/security/pam_mount.conf?
<\sh> tritium: yeah...everything setuped :)
<tritium> \sh: perhaps you're missing a few options (or - - - if no options needed) at the end of that line
<\sh> tritium: logfile for this?
<tritium> \sh: I'll query you and show you my .pam_mount.conf
<\sh> kk
<\sh> re
<\sh> hmmm...after kdm login this won't work still...brb
<\sh> but now :) it was kdm-np and not kdm :)
<tritium> \sh: cool :)
<sivang> morning all
<zyga> hello sivang
<zyga> sivang: did you manage to pull those patches yesterday?
<mathrick> zyga: wow, a Pole! :)
* mathrick waves
<zyga> mathrick: hi
<zyga> there are other native folks here from time to time
<mathrick> by native you mean Polish, or just any random $NATIONALITY?
<zyga> the former
<mathrick> I see
<sivang> zyga: will do that today, had to catch a train back home last night, then arrived beat and went to sleep.
<zyga> sivang: I see
<enyc> Question: ?where may I see/find-out information abuot Firefox updates in Ubuntu... note that Mozilla have released Firefox 1.0.8 and 1.5.0.2 (security updates), and that (now) warty/hoary/breezy ought to get patched to 1.0.8 or fixes taken-across.... but mozilla only intend to suppotr the 1.0 series for 6 months (being therefore a problem for future security-updates in hoary and breezy).......
<zyga> enyc: hoary is about to be end-of-lifed AFAIR
<Amaranth> enyc: mozilla's support for 1.0.x is nonexistant
<Amaranth> 1.0.8 was the last release
<Amaranth> zyga: warty
<zyga> Amaranth: ah, right
<enyc> zyga: well... ubuntu 4.10 support ends on 2006/04/30 ... which is a few weeks away...
<enyc> zyga: and firefox security update upstream is _now_ ;-)
<enyc> highvoltage: do you have any notes/information on firefox security updates r.e. 1.0.8-patches for warty/hoary/breezy ?
<highvoltage> enyc: nope
<enyc> hrrm
<enyc> I wonder who looks after such things ;-)
<highvoltage> sorry..
<highvoltage> enyc: the ubuntu security team?
<enyc> hrrm
<enyc> do they have a discussion channel or problems-to-be-dealt-with page or such-like ?
<enyc> or just genera malone bugs blah?
<highvoltage> enyc: note that warty is now unsupported, so it's probably just hoary and breezy that will get the security updates
<fabbione> enyc: no need to panic.. this "problem" has been already discussed in the security team
<enyc> I thught warty support ends on end of this month
<fabbione> warty might get the update
<fabbione> hoary and breezy will for sure
<enyc> fabbione: enyc not panicing but enyc want to nknow where such discussions are ;-)
<fabbione> enyc: there isn't really much to discuss.. if you find a security problem you comunicate it to security@ubuntu.com
<fabbione> usually keep a problem quite to give security teams time to take actions is the best thing to do
<fabbione> instead of spreading panic around people
<enyc> aah k ;-)
<enyc> so how doe s fabb know this has already been discussed by the team?
<fabbione> i am used to be part of the security team
<highvoltage> fabbione: ubuntu's policy is to disclose any security information as soon as it's available, right?
<fabbione> highvoltage: it depends from the problem and it is discovered. It is really a matter of case by case here
<enyc> fabbione: thats sensible
<fabbione> and HOW it is discovered
<fabbione> highvoltage: clearly as soon as there is a fix available, that's made available and USN published
<highvoltage> ok
<enyc> sure. like somebody points it out quietly ;-)   or.. its being talked about all over the place already ;-)
<fabbione> there are more issues than just that
<fabbione> it depends on what kind of security issue it is
<fabbione> and what's the impact
<enyc> i see
<fabbione> it's way more complicated than it looks like
<fabbione> there are also situations in which user foo finds security issue and tells upstream
<fabbione> upstream asks to keep it quite for the time it takes to fix it
<fabbione> because perhaps a fix might require a lot of code rewrite..
<fabbione> but you might find that the issue is just a possible application crash and the application is xeyes
<fabbione> so it's not exactly high impact
<rupert> can someone help mit LUKS and the crypttab?
<Treenaks> crypttab?
<rupert> i just found a forum tread that seems to help, i have the error when /etc/cryptdisks is started,the drive wasnat initialized correct, i will just reboot and when the error ist there i will come back, 
<pygi> Mithrandir: here?
<Mithrandir> pygi: yes, but it's a vacation day for me today.
<zul> heylo
<_ion> hilo
<rcaskey_> is launchpad's userbase currently stored in ldap?
<Mithrandir> I wouldn't think so, why?
<rcaskey_> Mithrandir: I was curious as to how one might go about grafting an openid identity provider onto it
<rcaskey_> thought it might be a good goal for dapper+1
<zakame> hi all
<Lathiat> rcaskey_: its nto really a dapper related goal
<Lathiat> rcaskey_: so dapper+1 is arbitrary :)
<rcaskey_> Lathiat: what's wrong with arbitrary ;)
<rcaskey_> Lathiat: good idea/bad idea?
<Lathiat> rcaskey_: no idea, but its !ubuntu related :) #launchpad perhaps?
<rcaskey_> Lathiat: ahh, did not know there was such a ##beast
<Lathiat> :)
<lemsx1> please apply this temporary fix to logcheck: Bug #29550
<Ubugtu> Malone bug 29550 in logcheck "logcheck cant get lockfile, does not work. (Dapper)" [Major,Confirmed]  http://launchpad.net/bugs/29550
<lemsx1> just adding a new line to /etc/cron.d/logcheck: 1 * * * *       root    test ! -d /var/lock/logcheck && mkdir -p /var/lock/logcheck && chown -R logcheck /var/lock/logcheck
<lemsx1> there are MANY bugs open on that package for the same problem
<janimo> seb128, hi can you get the gdm upload with xubuntu art dependency in before beta?thanks
<_ion> glatzor: "HOWTO: Use the proprietary MGA HAL driver with modular X"  http://ubuntuforums.org/showthread.php?t=161603
<glatzor> _ion: nice
<glatzor> have you already attached your patch to the bug report?
<_ion> glatzor: Not yet. I think i should read some user comments from that forum thread first.
<fabbione> good morning mdz
<mdz> morning
<fabbione> are you in london?
<mdz> yes
<fabbione> ahh
<mdz> and the sun is shining!
<fabbione> amazing!
<janimo> mdz, hi I'd like to get thunar beta1 (released today) in our beta. Is it ok considering the beta freeze?
<sivang> happy easter mdz , fabbione :)
<janimo> and generally xfce 4.4 beta1 is being tagged today/tomorrw
<fabbione> sivang: thanks, same to you
<sivang> fabbione: :) how is london?
<fabbione> sivang: i am not in londong...
<fabbione> london even
<mdz> janimo: your call; it won't interfere with the ubuntu beta
<janimo> mdz, ok thanks
<sivang> fabbione: oops, it's mdz that's in london :)
<glatzor> hi mdz. michael asked me about the status of my dapper bugs. the problem is that i cannot see any milestones in my launchpand.
<glatzor> seems like a permission issue, right?
<mdz> glatzor: no, I don't think so
<mdz> perhaps they are just not visible where you are looking
<glatzor> michael created a lp query and we assigned them to him
<glatzor> mdz: we even compared screenshots :)
<glatzor> i have to leave for lunch. bye
<mdz> the milestones are visible even to users who are not logged in
<Mithrandir> janimo: are you aiming at releasing with the rest of Ubuntu on Thursday?
<janimo> Mithrandir: yes
<janimo> with livecd too hopefully
<Mithrandir> janimo: nice :-)
<janimo> :)
<\sh> bah...where is the gun to shoot me
<\sh> I wonder what's installed on kamions cdbuilding server....
<glatzor> mdz: i show you the screenshot if i am back at home
<mdz> Mithrandir: I just booted the current dapper daily-live in vmware, and there is neither an espresso launcher nor example-content link on the desktop; any idea?
<mdz> Mithrandir: also, it seems that /var/log/casper is gone. where is the log written now?
<mdz> \sh: breezy/i386
<\sh> mdz: hehe..:) I'm just trying to figure out the magic of kamions cd baking magic :)
<\sh> everything is there...it's just not putting the packages into the iso
<\sh> one file which should be filled, is empty...and I don't know how...comparing the cdbuild-logs in kamions public and my logs are not so different..the packages of cause are missing
<fabbione> mdz: today's image might be dodgy. for some reasons the buildd have been offline more than 24 hours. so something might not be exactly as it should be
<Mithrandir> mdz: it doesn't log at the moment, sadly.  I haven't had time to implement it.
<Mithrandir> mdz: but I can reproduce it.  I'll see if it's better tomorrow when I start testing as such, since it's still holiday for me.
<\sh> OUTCH
<\sh> KAMION
* \sh slaps kamion with a big CDIMAGE_INSTALL="when this is missing in etc/config then nothing works" sign
<mdz> fabbione: are they fixed now?
<mdz> Mithrandir: hmm, the logging needs fixing, that's another regression from breezy
<fabbione> mdz: the buildd yes, the images mostlikely no, since it did happen after cron.daily
<fabbione> and i didn't really spend time looking at what might have been broken
<fabbione> it's holidays here too :)
<bddebian> Howdy folks
<_ion> Howdy-ho.
<bddebian> Mr. Hanky? ;-)
<_ion> Indeed. :-)
<Mithrandir> mdz: file a bug.
<mdz> Mithrandir: was already doing so
<Mithrandir> thanks.
<bddebian> Heya LaserJock
<mdz> Mithrandir: btw, mv: unable to rename `/root/home/ubuntu/Examples': Not a directory
<Mithrandir> mdz: hm, trivial fix for that one, at least.
<G0SUB_> jdub: ping
<mdz> Mithrandir: I'll file that one as well, unless you've already fixed it
<Mithrandir> mdz: I just fixed it in bzr, so unless you really want to, don't. :-)
<mdz> ok
<\sh> ok...one enhancement so far...I have 111MB iso image for the installer...but where's the rest ...why is this nasty thing not putting the other packages on the cd
<G0SUB_> \sh: hey! welcome back :)
<\sh> huhu G0SUB_
<\sh> grmpf ....this is a beast...
<\sh> export CDIMAGE_INSTALL=1 works ... ah come on...now it works
<bddebian> \sh!
<\sh> bddebian !
<jdong> where are development kernel sources kept?
<jdong> is there a git/bzr repository somewhere?
<fabbione> jdong: yes there is a git repo
<fabbione> https://wiki.ubuntu.com/KernelGitGuide
<jdong> thank you
<\sh> lol...Larry Ellison, boss of oracle, is thinking about buying Novell, to have an OS, just like MS.
<bddebian> Ellison is a puke
<\sh> and they have to think, if they can cooporate with redhat, after they bought jboss...because now, redhat is in their business (middleware) *rotfl*
<zul> i dont think oracle know how to do an os...properly even..
<\sh> as "the thing" said: don't do drugs !! :)
<\sh> well, novell didn't know it either :) but now..no one is talking about novell netware anymore...;)
<zul> netware rocks!! ;)
<bddebian> Actually I used to like Netware around 3.11
<\sh> well, it's just like you said just now: "BNC networks are the future" ;)
<zul> you only need 4MB of ram as well
<doko_> Kamion, mdz: would you mind updates of gnome java bindings in universe before the beta?
<\sh> zul: well, then should novell invent the "netware fridge - the OS for _your_ fridge..small, fresh and icy"
<zul> hmmm...fridge
<\sh> and in the manual of netware fridge, there will be written: "Plugin your BNC cable but beware of the cleaning lady"
<zul> mdz: ping
<dholbach> Kamion: if you have the time, could you please move tang{o,erine}-icon-theme to main? (pitti approved them and I'd like to do a ubuntu-meta update)
<fabbione> dholbach: did you seed them already?
<fabbione> if so they will appear in one of Kamion's super tools of death
<bddebian> heh
<dholbach> fabbione: i did that, but  ./update   in ubuntu-meta said "Nothing to do." or something
<Mithrandir> aka anastacia?
<fabbione> Mithrandir: yeah probably
<dholbach> fabbione, Mithrandir: so what do I do wrong? I seeded them, but ubuntu-meta's ./update is not happy with it.
<fabbione> dholbach: one second
<dholbach> take your time :)
<fabbione> dholbach: i know why...
<fabbione> i will give you one more chance to think :)
<dholbach> don't excite me even more... tell me! :-)
<fabbione> i am sure as hell that chinstrap != rookery
<dholbach> they are not the same
<fabbione> exactly
<fabbione> so if you did seed the pkgs on chinstrap
<fabbione> you might need to wait that it propagates to rookery
<fabbione> aka people
<dholbach> i waited 2,5 days
<fabbione> where ./update expects the seeds
<dholbach> if that's a weekly cronjob, I might have had bad luck :-p
<fabbione> probably Kamion's script is broken..
<fabbione> it's not the first time it stops mirroring
<dholbach> i'll just try to ping him tomorrow
<dholbach> nevermind... thanks for investigating
<\sh> hmm...can someone say something to xserver-xgl? is it stable and how is the performance on <1.5GHz machines?
<Tm_T> \sh: "stable" but I won't use it until it gets more mature
<Tm_T> atleast I couldnt get it work well with KDE
<\sh> Tm_T: but I can switch between xorg and xgl?
<Tm_T> afaik not fast enough :p
<\sh> I mean, if I install it now, my xorg conf and everything else will not be destroyed by accident?
<Tm_T> should not
<\sh> ok.let's see..how can I activate Xgl? 
<Tm_T> hum
<Tm_T> got that funky message?
<\sh> yepp
<Tm_T> ;)
<\sh> cool thx :)
<Tm_T> \sh: just remind you, I'm slightly agains Xgl, so I'm not good guy to help with it ;)
<Tm_T> or even tell about it
<janimo> dholbach: http://archive.ubuntu.com/ubuntu/pool/universe/t/tango-icon-theme/
<janimo> since it's in universe update does not see them
<Tm_T> \sh: have fun with it, I'm off to sleep ->
<janimo> so even if it's in the seed it is ignired untiul it enters main
<dholbach> janimo: I suppose, asking Colin was the right thing to do, hm? :)
<janimo> yep :)
<dholbach> woohoo! :)
<bddebian> "It's much easier to beg forgiveness, than ask permission"
<janimo> although he is probably notified by anastacia as fabione said
<janimo> dholbach: just checking out murphy's site :) 
<dholbach> haha :)
<dholbach> my brother made it :)
<janimo> nice :)
<\sh> ok..i810 doesn't work at all it seems :)
<zul> yeah i had the same problem..
<bddebian> i810 is a PITA :-(
<coyctecm> i810 works great :)
<coyctecm> with ubuntu 6.04 thought
<\sh> but not with xgl :)
<coyctecm> ok
<coyctecm> sorry i was thinking that this is #gentoo :D
* rcaskey_ files bug #39907
<Ubugtu> Malone bug 39907 in openoffice.org openoffice.org-base "new table wizard crashes on ppc64" [Normal,Unconfirmed]  http://launchpad.net/bugs/39907
<shackan> \sh, xgl runs almost fine on mine
<\sh> which card?
<shackan> i810 ...
<\sh> my combi was: i810, xgl, kde :)
<shackan> well, change kde with gnome and you have my setup
<shackan> (not atm, actually, just tried it for fun a while back)
<rcaskey_> shackan: a few weeks back xgl was working but some window effects were very slow
<rcaskey_> window resizing was _VERY_ slow but the cube animation was very fluid. Some crashes of course..
<shackan> it was usable here, except for the wobbly effect which would slow down with a big window
<shackan> but heh, all I might need it for is the expos-like feature
<bddebian> What package is supposed to create /dev/sequencer?
<shackan> as I tend to clutter my desktop(s) with many windows
<shackan> mh, is there anything to simulate expos in metacity ?
<KaiL> gar, damn Crashfox.... eh, Firefox - chances for 1.5.0.2 in dapper? ;)
<mjg59> KaiL: File bugs, link to fixes
<Burgwork> KaiL, it will happen, due to mozilla's braindead support strategy
<mjg59> Where "fixes" may be "Upgrade to 1.5.0.2", so...
<KaiL> mjg59, do we now need bugs for that?
<mjg59> KaiL: "Firefox crashes when I do this. 1.5.0.2 doesn't" is a bug, yes
<KaiL> reminds me of old mozilla days, where a dey, who found a bug needed to file a bug with a patch, before he could fix it ;)
<mjg59> We're in beta freeze
<KaiL> I don't know, if 1.5.0.2 doesn't crash that often - I only hope it..
<mjg59> There needs to be a compelling reason to change software versions right now
<KaiL> don't have the time to check that now
<KaiL> the security issues found in 1.5.0.1?
<zyga> hey guys
<zyga> has anyone noticed artefacts in the notification popus?
<zyga> I can reproduce them all the time
<zyga> usually a few black pixels out of place
<KaiL> looks like driver issues..
<zyga> KaiL: not really
<zyga> it only happens in the notification popup
<zyga> and only to specific texts
<zyga> it seems that the popup is sized badly so that some text is invisible except for the topmost pixels
<_ion> This tangerine-icon-theme is really nice.
<_ion> I wish it were the default theme in dapper. :-)
<dholbach> _ion: Human falls back to Tangerine
<_ion> I like the Tangerine icons more than the Human icons.
<_ion> But, of course, that's just my personal opinion.
<dholbach> _ion: yeah, but they cover different areas of icons
<dholbach> _ion: http://daniel.holba.ch/ubuntu/ic/ shows which icons are in which set already
<_ion> Well, i wish they copied the directory icon from Tangerine to Human. :-)
<andreasn> _ion: you can select tangrine only in the theme prefs
<_ion> Yes, that's what i have done.
<andreasn> but as dholbach says, some stuff is still missing
* andreasn is working on it
* dholbach hugs andreasn
<andreasn> :)
<morka_> hi all
<bddebian> Hello morka_
<morka_> im curious how does ubuntu treat debian bugs? 
<morka_> (if they affect ubuntu)
<dholbach> good night guys... I'm off - see you tomorrow
<\sh> cu dholbach
<\sh> morka_: e.g.?
<_ion> Night.
<mdke> bon nuit monsieur dholbach 
<morka_> there seems to be an bug affects both debians and ubuntus partman
<morka_> ive seen it on debians mailing lists, trying to search for it in bugzilla.
<\sh> bugzilla? launchpad you mean :)
<morka_> ok, whatever the name of it is:)
<morka_> oh, there are bounties:)
<Surak> bug #39002 is still present after the fix...
<Ubugtu> Malone bug 39002 in nautilus "Can't rename _SOME_ icons when they are on destkop." [Normal,Fix released]  http://launchpad.net/bugs/39002
<Burgwork> Surak, if you are certain you have the latest, reopen the bug
<Surak> I'm getting a today's  build so I can certify everything is fully updated and correct.
<cartel_> hey all
<cartel_> Manoj is listed as mintainer of kernel-package, but he is not the maintainer of the ubuntu package. Who is the real maintainer/packager for this package?
<crimsun> cartel_: core-dev? there's no single maintainer.
<cartel_> crimsun: the maintainer field should be updated as im sure manoj doesnt need any email regarding a package not built by him
<cartel_> crimsun: any core-dev people around?
<LaserJock> cartel_: I didn't think Ubuntu changed the Maintainer field, the changes show up in Changed By, I think
<cartel_> LaserJock: no Changed-By in apt-cache show
<crimsun> because there hasn't been any consensus in Debian about what to do for derivatives' Maintainer fields, it hasn't been changed in Ubuntu. See flamewars on debian-devel from earlier this yera.
<LaserJock> cartel_: it isn't there, but the source package has it
<cartel_> heh
<cartel_> lame
<LaserJock> cartel_: well, currently there isn't a mechanism to seperate the maintainance other than Maintainer and Changed By
<LaserJock> I don't think anyway
<\sh> ok guys...good night ....
<cartel_> LaserJock: surely the Maintainer field should just be updated to reflect the new maintainer
<LaserJock> cartel_: but I think the point is that there isn't a new maintainer exactly
<LaserJock> cartel_: so it gets a little messy
<wasabi> I like how reviews about Ubuntu and stuff talk about how much "faster" it is than Distro X.
<wasabi> Or slower.
<cartel_> wasabi: it's quite noticable
<wasabi> What is?
<cartel_> wasabi: try installing ubuntu on a box next to, say, suse 10
<mikael> Hi, I am trying to use the clock_getres() function but gcc complains about "undefined reference to clock_getres()"; gcc -E test.c shows that the functions are defined but still the linker doesn't find them I am using the most recent dapper you can get
<jdong> is spinning down the hd once every 5 seconds good for the motor???
#ubuntu-devel 2006-04-23
<kmon> may I ask if after the beta release the new ati drivers will be added to dapper?
<mathrick> jdong: umm, no
<jdong> nm, already in malone (33811)
<jdong> kind of concerned me at first :)
<mdke> kmon, no
<jdong> that'd be a good bug to fix :)
<jdong> simple two-liner, but pretty important if we don't want to break hard drives for beta testers
<kmon> mdke: may I ask why?
<mdke> kmon, new drivers don't get added at the last minute, there is quite a rigorous release cycle that Ubuntu adhers to. Check out https://wiki.ubuntu.com/DapperReleaseSchedule for any more details
<kmon> mdke: new nvidia drivers were added not too long ago... and since they provide support for newer ati x1xxx cards and we haven't yet arrived The kernel freeze.... I thought it was a good addition
<KaiL> so better the guarantee, that Ubuntu is unusable on ATI X1xxx-Chips (as also the vesa-fix didn't happen), that a rather small risk, that there are problems on older cards?
<kmon> mdke: anyway, thanks for answering...
<mdke> kmon, if there is just something for the kernel, I suppose the developers might consider it. It would depend on the risk of adding problems. File a bug, and see what they say
<jdong> kmon: does the new update add new chipsets?
<jdong> do we currently support the X1xxx chipsets?
<jdong> they're pretty common on new laptops
<kmon> jdong: yes
<kmon> jdong: https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/linux_8.24.8.html#178987
<mdke> jdong, a few lines up, he said that these aren't yet supported
<KaiL> jdong, currently you end up in blue with X1xxx
<jdong> I see
<jdong> I'd say this is a worthwhile update then....
<jdong> at least to try
<KaiL> means, they are TOTALLY unsupported without the new driver
<KaiL> except vesa, which you need to set manually
<kmon> as a bonus, someone said it fixes issues kdm has with fglrx
<kmon> but I'm not sure about that
<kmon> anyway, I agree with you, it's a wothwile update
<KaiL> kmon, I don#t even know, it ANY update is more worth currently
<mdke> KaiL, let's try and stop being melodramatic about this. Just file a bug, and wait and see
<mdke> maybe there is already a bug about this
<kmon> for the record I haven't found a bug report, so I've filed a whishlist: https://launchpad.net/distros/ubuntu/+bug/39924
<Ubugtu> Malone bug 39924 in Ubuntu "New driver is out 8.24.8 and it supports many new cards" [Wishlist,Unconfirmed]  
<mdke> nice
<mdke> if vesa isn't working as a backstop, that's another bug, I suppose
<KaiL> bug 35194
<Ubugtu> Malone bug 35194 in xserver-xorg-driver-ati "activated but not usable on X1xxx" [Normal,Unconfirmed]  http://launchpad.net/bugs/35194
<KaiL> there we have the wrong default driver
<KaiL> the installer sets "ati" (which doesn't even start)
<kmon> ok, time to sleep.... good night everyone here.
* kmon leaves
<KaiL> for the other problem with modern laptops (intel ipw3945) putting them into the backports might be an idea
<KaiL> overall using backports for updated external drivers would be nice...
<cartel_> Manoj: ping
<jdong> KaiL: I was told by sabdfl last night that 3945 will be in dapper
<jdong> it's being worked on
<crimsun> cartel_: ECHANNEL?
<jdong> he feels it's very important
<KaiL> jdong, even better
<cartel_> crimsun: oops
<jdong> and I'm pretty uneasy about using backports for kernel drivers
<jdong> unless there's some serious coordinating with the -securty branch.... you're gonna end up with a nightmare of broken modules during security updates
<crimsun> if you value your life, don't mention the strings "backport" and "kernel" in the same breath around the kernel team
<jdong> lol
<KaiL> lol
<jdong> crimsun: not even with a "not" somewhere in the sentence?
<jdong> I've only B'd a K once... in the Warty days, for a friend :)
<crimsun> (well, unless it's something backported from >2.6.15 into Dapper's)
<jdong> you sure you don't want 2.6.15-20 for warty? ;)
<jdong> lol
<cartel_> can we get 2.6.16? :)
<Burgwork> cartel_, bi
<Burgwork> no, even
* KaiL rememberes of the 2.6.11 in hoary universe...:)
<KaiL> afaik it doesn't even boot for most people
<Burgwork> KaiL, that is something they are not repeating
<jdong> lol
<jdong> that was entertaining
<KaiL> that's why I only thought about this drivers
<jdong> or that crappy ooo2 snapshot in universe... m79...
<jdong> KaiL: a lot of times you can't isolate just drivers
<jdong> drivers love to patch elsewhere onto the system
<jdong> especially 3945... that thing has a usermode closed source regulator daemon
<KaiL> I don't know, but it should be possible, to recreate the linux-restricted-modules packages and the related stuff with new data afterwards, or?
<LaserJock> hmm, and I wanted a forward-ported 2.4 kernel ;-)
<KaiL> jdong, at most I'm thinking about fglrx and nvidia
<jdong> KaiL: currently, backports is not authorized to modify source packages. What if a security update requires a patch for nvidia or fglrx to compile?
<jdong> then you end up with a screwed situation
<jdong> of backports not being able to keep up with -security
<jdong> and everyone bitches and screams
<jdong> and I lose more years off my life expectancy
<KaiL> at least for a longer future, we need to find a solution, how to update at least important drivers after the release...
<jdong> agreed...
<jdong> even if that means a nasty updater script
<KaiL> else you always have a hole of up to 7, maybe 8 month, between hardware release and using it on ubuntu
<jdong> KaiL: what stops users from updating drivers themselves?
<jdong> we can't be bug-free and bleeding edge at the same time....
<jdong> it's physically not possible
<KaiL> the very complicate system to update them?
<jdong> very complicated?
<jdong> with nivida, it's two commands
<KaiL> yes, there
<jdong> is it that bad for fglrx?
<KaiL> but that's not the normal situation
<KaiL> (not to mention, that you need as least 3 for nvidia)
<jdong> sudo sh nvidia-installer-package
<jdong> ok, fine, apt-get install linux-headers-`uname -r`
<jdong> apt-get remove nvidia-glx --purge
<jdong> maybe there are three
<jdong> :)
<KaiL> wget
<KaiL> and install build-essential
<KaiL> makes 4 lines ;)
<jdong> lol
<jdong> sudo apt-get install linux-headers-`uname -r` build-essential
<KaiL> at least more that "click on the installer", and even that is bad enough
<KaiL> apt-get install, apt-get remove, wget, sh - 4.
<KaiL> now all happy? ;)
<sabdfl> jdong: i don't know about 3945, i hope it is on track, but it's up to benc
<jdong> make a shell script that automates all of them, and distribute it as the next new Automatix :)
<jdong> well, he did say "in progress", so my hopes are up :)
<BenC> ipw3945 is showing a lot of problems because of "yet another ieee80211 stack update"
<jdong> :-/
<KaiL> ugs
<jdong> KaiL, you were saying about driver updates?...... ;)
<sabdfl> hi BenC
<BenC> all of our wireless adapters are using different and sometimes incredibly hacked versions of ieee80211
<BenC> hey sabdfl
<KaiL> jdong, ?
<jdong> not so easy, is it?
<sabdfl> seems insane that there's so little common wireless infrastructure in the kernel
<jdong> BenC: btw, I do appreciate how many wireless adapters we support out-of-the-box
<BenC> ipw3945 will make it into dapper, but it's just not super priority ATM
<jdong> thanks, BenC... glad to hear :)
<BenC> sabdfl: the wireless confcerence going on as we speak will hopefully address that
<KaiL> sabdfl, even worse, that these are 3 versions from intel..
<BenC> softmac and all the rt2x00 stuff, and stock ieee80211 will hopefully be pretty standard in 2.6.18, for dapper+1
<jdong> does anyone know if rt2x00 plays better with preempt and SMP yet?
<jdong> rt2570.. the USB one particularly
<KaiL> another word to raise the aggressions: WPA
<KaiL> something new on that?
<jdong> it does everything from locking to panicing if you breathe incorrectly on the card
<BenC> rt2x00 looked pretty discusting last I checked, so no telling :)
<BenC> disgusting
<jdong> and it was supposedto be the wonderful rewrite, too 
<jdong> lol
<KaiL> it's now in main, ok, but to use it, you'll need to fight with /etc/network/interfaces manually?
<jdong> KaiL: networkmanager deals with it... right?
<jdong> it'd be cool if our /etc/network/interfaces frontend did, too...
<KaiL> jdong, which got kicked out of the live-cd afaik
<BenC> one day I'll make the switch to WPA so I can test all that, but right now I'm still on 128-bit WEP
<jdong> oh?
<jdong> so does the 3945 driver not compile at all currently on dapper?
<jdong> or is it just a matter of packaging/integrating into the ubuntu kernel that's the problem?
<KaiL> or it just killes other WLAN drivers
<BenC> the ieee80211 for 3945 stack needs to be segregated so it doesn't conflict with the stock one in 2.6.15
<BenC> we did that for another wireless driver aswell
<jdong> what is our opinion on the bittorrent 4 license?
<jdong> I get a lot of complaints about BT 4
<jdong> not being in ubuntu an all...
<jdong> and debian-legal seems to hate it
<jdong> is it something that we can get for dapper+1
<jdong> it's undoubtedly way too late now for Dapper to transition to the BT 4 api
<nekohayo> just to make sure I'm not the only one experiencing it (i.e.: PEBKAC), does anyone have direct rendering working currently? Tried on intel, ati and nvidia chipsets
<neuralis> krstic@aeryn:~> glxinfo|grep irect|head -1
<neuralis> direct rendering: Yes
<neuralis> nekohayo: that's intel 915gm
<nekohayo> and you are fully up to date? hmm strange
<nekohayo> I have that on a i915 (I think), a mobile radeon 9600 and a geforce 5200... so I thought it was xorg core or something
<Lathiat> 5200 wont work unless you have binary dirvers
<Lathiat> no idea if a 9600 will work with the open source drivers
<Lathiat> i think it possibly should
<Lathiat> and i thin kthe i915 should work
<nekohayo> Lathiat: nvidia-glx counts as binary drivers?
<Lathiat> nekohayo: yes
<nekohayo> strange thing.
<nekohayo> would there be a way to reset _entirely_ anything graphics related to the ~defaults, like if I did a clean install, to check if that's a configuration problem?
<nekohayo> my xorg.conf did not change at all, it all happened after some updates iirc
<nekohayo> so I don't know if the problem is me, or the packages flight6++
<nekohayo> hmm I'll go try something
<infinity> mdz: Can I get a UVF (and beta freeze) exception for fglrx, so we can get the new fglrx into beta and get it well-tested (It finally has support for the Radeon X1xxx series)
<jdong> infinity: you missed a few hours ago when kail, kmon, Burgwork, and I were talking about it :)
<neuralis> mako: i have a post in the sounder moderation queue, can you please let that through? thanks.
<bddebian> Heya folks
* jmg files a bug on kernel-package
<jmg> BenC: ping
<crimsun> as a note, it's past midnight in his timezone.
<jmg> 00:15
<bddebian> Bah, so :-)
<fabbione> morning
<bddebian> Hello fabbione
<hendry> is there someplace i can see the kdebase changelog on the Web? Can't figure out launchpad
<hendry> https://launchpad.net/distros/ubuntu/dapper/+source/kdebase/+changelog
<hendry> aha, but that's only the last one
<Chipzz> hendry: /usr/share/doc/package_name/changelog.Debian.gz
<bddebian> Gnight folks
<jmg> hi hunger
<pitti> Good morning
<ajmitch> morning pitti 
<ajmitch> how are you?
<pitti> hey ajmitch!
<pitti> great, and you?
<ajmitch> good, thanks :)
<Keybuk> morning berpitti
<Kamion> somebody please tell dholbach when he arrives that I've promoted tangerine-icon-theme and tango-icon-theme
<fabbione> Kamion: thanks i will
<Kamion> Keybuk: I've changed wpasupplicant to important priority now - if you want to move it into the minimal seed, that's fine
<Keybuk> Kamion: ok.  do the debootstrap bits work now then?
<Kamion> the priority change was the only thing needed
<Keybuk> what blocked that?
<Kamion> lp
<Kamion> change-override-ng.py is there temporarily to allow doing priority changes
<Keybuk> cool
<Kamion> can somebody please make sure to fix the brltty debconf prompting on desktop install today?
* Kamion runs
<Mithrandir> Kamion: I'm going to fix it.
<Kamion> thanks
<Mithrandir> Kamion: once we have all the fixes we need in (brltty, at least, I'd like to get a small fix for casper in too), I'll roll cds and ask for testing.  Sounds good?
<_ion> How about adding a menu item that runs dpkg-reconfigure gksudo xserver-xorg with a Gtk frontend to the default Gnome menu in Ubuntu?
<fabbione> _ion: BAD IDEA
<_ion> Whoops, s/(dpkg-reconfigure) (gksudo)/$2 $1/
<fabbione> still bad idea
<infinity> Mithrandir: I have one initramfs upload I need to make before we go labelling things "beta" and having half the world upgrade and break things.
<infinity> Mithrandir: I'll do that later tonight when I get back from dinner.
<Mithrandir> infinity: sure
<janimo> infinity, hi planning xubuntu livefs today?
<fabbione> Mithrandir: 
<fabbione> xorg (7.0.0-0ubuntu29) dapper; urgency=low
<fabbione>   * On fresh installs, if the display is not a lcd/lvds, there are not know
<fabbione>     syncs frequencies for the monitor and the card is mga, do NOT write
<fabbione>     SYNC_RANGES. It appears that mga can cope just fine parting vesa info too.
<fabbione>     (Closes Ubuntu: #19098)
<fabbione>   * Due to a very annoying DRI/DRM bug, make sure to use OldDmaInit when
<fabbione>     writing down the Device section for mga driver. This will make DRI working
<fabbione>     at least for AGP cards. PCI didn't work before and it will keep not
<fabbione>     working since the option does explicitly disable DRI for PCI.
<fabbione>     (Closes Ubuntu: #27442)
<fabbione> they are 2 one liners basically
<fabbione> they sound scary from the description :)
<HiddenWolf> fabbione: tsk, pastebin. :)
<fabbione> HiddenWolf: or i could use dapper-changes directly...
<HiddenWolf> fabbione: that's so, well, efficient. :)
<Mithrandir> fabbione: those only do something if the driver is mga, right?
<fabbione> Mithrandir: yes
<Mithrandir> fabbione: ok, upload away.
<fabbione>           if [ "$DEVICE_DRIVER" != "mga" ] ; then
<Mithrandir> fabbione: do you have any more urgent fixes we need to have or can we stop uploads soon?
<fabbione> if [ "$DEVICE_DRIVER" = "mga" ] ; then
<fabbione> Mithrandir: not in my queue..
<fabbione> there are tons of bugs that need urgent fixes...
<fabbione> these were trivial to get done
<Mithrandir> well, which are blockers for beta.
<fabbione> hi dholbach 
<Mithrandir> dholbach: 08:49 < Kamion> somebody please tell dholbach when he arrives that I've promoted tangerine-icon-theme and tango-icon-theme
<dholbach> hey fabbione
<janimo> Mithrandir: packages not going on the ubuntu/kubuntu cd are ok though right?
<fabbione> Mithrandir: i dunno.. i have 500 bugs on X.. pick one
<dholbach> Mithrandir, Kamion: thanks a lot
<Mithrandir> janimo: well, you should probably freeze xubuntu too if you want to release at the same time as {k,}ubuntu.
<dholbach> good morning everybody
<Mithrandir> fabbione: I read that as "no". :-)
<janimo> Mithrandir: yes, only small updates (docs etc)
<fabbione> Mithrandir: how can you guess? :)
<Mithrandir> fabbione: dude, if you don't have a bug which you can say "we NEED this for beta" then it's not urgent.
<fabbione> Mithrandir: you understood me the other way around...
<fabbione> Mithrandir: the 500 bugs all need fixing before beta...
<fabbione> Mithrandir: so pick one..
<janimo> dholbach: do you know if seb should be around today?
<dholbach> janimo: I think he should
<mvo> Mithrandir: I have a upload with two icon updates pending ... I guess that is ok?
<janimo> thanks
<dholbach> janimo: what is it that you want with him? can I maybe assist you?
<Mithrandir> mvo: just changing two icons?
<dholbach> Mithrandir: i have ubuntu-artwork pending
<janimo> dholbach: gdm upload for adding depends on xubntu artwork
<dholbach> janimo: ah ok
<janimo> otherwise it cannot install w/o network
<janimo> there's a bug open in lp, and the fix is very simple
<mvo> Mithrandir: yes
<Mithrandir> dholbach: as in, ready to upload?
<Mithrandir> mvo: upload away, then.
<mvo> thanks
<dholbach> Mithrandir: nearly, just some small tweaks - how much time do i have?
<dholbach> ...tweaks missing...
<Mithrandir> dholbach: please prioritise it high since I want to get cd building started.
<dholbach> Mithrandir: right, working on it now
<Mithrandir> and since LP needs two rounds from upload to published binary, a missed cron.daily means a lot of waiting.
<dholbach> yeah
<dholbach> i understand
<mdz> Kamion: there's a bug open about brltty; the newest brltty doesn't even have a .config script
<mdz> Kamion: but it FTBFS
<mdz> infinity: fglrx->prefer to wait until after beta, it'll still get tested when people upgrade
<mdz> good morning
<Keybuk> morning mdz
<Keybuk> or, should we say, good late-evening?
<mdz> you should say morning
<mdz> I am in London
<mdz> kicking it UTC+1 style for the beta release
<fabbione> morning mdz
<Keybuk> ahh
<Mithrandir> mdz: seems like we need to have flite1-dev promoted for it to build?
<mdz> Mithrandir: that'd be the simplest solution
<mdz> are the current dailies believed to be worthy of testing?
<Mithrandir> they need a few fixes to go in, but should be beta-beta quality.
<mdz> Mithrandir: do you know what the cause of the missing icons on the live CD is?
<Mithrandir> mdz: not yet.
<Mithrandir> I'm going to merge Riddell's branch first to see what he changed
<Mithrandir> mdz: Riddell broke it, it seems.
<Mithrandir> Riddell: when you're uploading changes in a beta freeze, please do at least test your changes first.  There's no chance of your change ever having worked.
<StevenK> w
<StevenK> Oops.
<mdz> Kamion: can we get a pre-release indicator on the iso9660 volume labels?
<dholbach> Mithrandir: I'll upload ubuntu-artwork with new icons and backgrounds and gnome-session (which needed a one string change to benefit from the new icons)
<Keybuk> mdz: Kamion's on holiday today
<mdz> Keybuk: oh, I saw messages from him in this channel this morning
<Keybuk> mdz: yeah, think he was just logging on over breakfast
* Mithrandir reminds Keybuk that we're in a freeze and that uploads should be approved beforehand.
<Mithrandir> mdz: I have a fix for the casper problem, I'm testing it now, so I might be able to make this dinstall.
<Mithrandir> mdz: can you get flite1-dev promoted (unless you already have, in which case I suspect we just need a give-back of brltty on all arches)
<Keybuk> Mithrandir: that udev upload was pre-approved
<Keybuk> it's an urgent fix we needed for beta
<mdz> (good idea to mention that in the changelog to avoid confusion)
<Mithrandir> Keybuk: ok.
<seb128> Mithrandir, mdz: should the patch from bug #34203 we delayed to after beta CD?
<Ubugtu> Malone bug 34203 in gnome-vfs2 "smb access almost unusable slow in Dapper compared to Breezy" [Major,Needs info]  http://launchpad.net/bugs/34203
<seb128> (debdiff attached to the bug)
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | If your initramfs is broken in any way, please save a copy for infinity | LP upgraded, report issues on #launchpad | Beta freeze has begun, main uploads must be approved by mdz or Mithrandir
<mdz> seb128: patch looks fairly safe, but the problem doesn't seem urgent for beta, do you disagree?
<seb128> doko: could you stop reassigning random crack bugs to me without any comment of why you reassign? 
<seb128> mdz: no, I don't disagree. I'm happy to delay it to after beta 
<mdz> seb128: ok
<Mithrandir> yeah, I agree with mdz; doesn't look urgent, but should absolutely be fixed.  And the debdiff looks harmless enough.
<doko> seb128: ???
<mdz> is pitti not around today?
<pitti> mdz: I am
<seb128> doko: that "<-" fontconfig bug I fixed, you keep assign a cupsys task to me, I neither work on cupsys neither has an idea on how it could be a cupsys bug
<mdz> pitti: ah, good morning
<seb128> s#neither#nor
<pitti> mdz: hey hey, welcome to Europe :)
<mdz> pitti: could you review flite for main, to unblock the brltty build?
<pitti> mdz: of course
<mdz> thanks
<Mithrandir> grr, why does bzr now shelve stuff in .shelve instead of .bzr/shelve or something?
<dholbach> mdz: I'm sorry for the brltty mess - I'd be happier, if we'd roll back brltty or something for now. we'd have to rebuild gnopernicus with the new libbrlapi - that escaped my attention too :-/
<Mithrandir> mdz: http://err.no/patches/casper_1.42_1.43.diff ; looks ok to upload?
<mvo> Ubugtu: bug 39659
<Ubugtu> Malone bug 39659 in ttf-dejavu "ttf-dejavu 2.5 test results" [Normal,Needs info]  http://launchpad.net/bugs/39659
<buttfukc> does anyone here know what easy-ubuntu is
<doko> seb128: I'm now looking at it, it's a bug report, having two tasks. did _you_ look at both when fixing it? maybe it's a bit less effort for you to look at the context, if you're working on the bug report anyway? 
<seb128> doko: there is no cupsys bug afaik, I would just reject it
<seb128> but you seem to disagree since you reassigned that specifically to me
<buttfukc> ompaul: why did you say ubuntu is only used by nerds
<doko> seb128: no, I don't disagree, I just wanted your input. so if your input is "reject", then please do it. there was no input from your side while closing the other task
<ompaul> jdub, care to help our friend with the nice nic?
<seb128> doko: yeah, I didn't notice the cupsys task when I closed it
<buttfukc> no, paul, nobody can help you now
<seb128> doko: my point was you could put a comment saying what you want when reassigning, like "should that task be closed" :)
<pitti> mdz: could need some love in Debian and packging of new upstream version (which is more than a year old), but it looks sane enough; https://wiki.ubuntu.com/MainInclusionReportFlite
<pitti> mdz: I'd like to defer functionality testing to heno
<pitti> mdz: but I hope he tested it already
<pitti> mdz: shall I put it into 'promoted' queue right away?
<buttfukc> does ubuntu support .deb files ?
<pitti> mdz: queue -> done
<pitti> buttfukc: #ubuntu question (and yes, we *only* support .deb)
<buttfukc> oh
<doko> seb128: ok, didn't know if you were complaining about the reassignment, just subscribing lets one miss things more easily (see 25998) ;-)
<mdz> pitti: yes, thanks
<buttfukc> i'm having trouble joining #ubuntu
<BearPerson> might be the nick
<seb128> doko: I read the subscribed mails too, but I've nothing to say on that openoffice bug by example. works fine for me atm (and I don't know if it didn't work fine since I don't use openoffice)
<buttfukc> oh because it's not registered?
<BearPerson> probably rather because it looks like a swearword
<buttfukc> that wouldnt affect ability to join a channel though;
<doko> seb128: then please say just that. it's far easier for you to check this and to start OOo once
<BearPerson> you'd be surprised...
<BearPerson> people being offended by it may place bans
<buttfukc> they have freenode set up so nicks with cuss words in them can't join certain channels? is that a channel mode
<seb128> doko: it's probably on my list of ~190 bugs I've to comment on (according to my unread mails list)
<buttfukc> bearperson: are you in every channel i'm in?
* mode/#ubuntu-devel [+o thom]  by ChanServ
<BearPerson> no
<dholbach> hi thom
<thom> hey
<pitti> hey thom, how are you?
<thom> pitti: good thanks; how goes it? 
<pitti> pretty well :)
<pitti> mdz: ffox 1.0.8 is out with 17 security fixes (no new features); I assume you don't oppose if we upgrade stables to it?
<pitti> mdz: (of course I'll check that its reverse dependencies still work, or update them as well)
<Mithrandir> pitti: since mdz appears to be afk, any chance you could look at http://err.no/patches/casper_1.42_1.43.diff and tell me whether it looks sane to you too?
<pitti> Mithrandir: +    mkdir -p /root/home/ubuntu/Desktop/ -> will the permissions be fixed later?
<Mithrandir> pitti: gah, thanks.
<pitti> Mithrandir: the usplash time out looks good for me; I'm just not sure how the first hunk works (i. e. which other .desktop files the * caught)
<Mithrandir> pitti: none, since it'd need to be /root/[...] .
<mdz> pitti: yes, that should be OK
<pitti> Mithrandir: maybe you should generally use install -d and specify -u and -g
<Mithrandir> pitti: just fixed it
<Mithrandir> (reload)
<pitti> ah :)
<pitti> Mithrandir: so, I can't judge the replacement of the wildcard (espresso-*.desktop), but it looks good anyway
<mdz> Mithrandir: looks fine
<Mithrandir> pitti: it seems to work correctly for me with ubuntu at least.  From inspection, it looks correct for kubuntu too
<Mithrandir> mdz: thanks
* Mithrandir debuilds and uploads.
* BearPerson waves
<seb128> I've a gnome-session patch fixing the descriptions labels (according to what has been described on the ubuntu-desktop list) and some graphical glitches (dialog changing when the labels use an extra line) ... should that be delayed to after beta too?
<Mithrandir> seb128: it's just visual glitches and such?
<seb128> yeah
<Mithrandir> I'd prefer to wait so we can get ISOs made.
<seb128> dholbach wants to get a gnome-session uploaded before beta anyway
<seb128> the artwork change broke one icon of the session dialog 
<Mithrandir> grr, ok.
<dholbach> thanks Mithrandir
* dholbach hugs Mithrandir
<Mithrandir> do you have a debdiff available?
<dholbach> seb128: you want to upload yours and have the debdiff?
<seb128> Mithrandir: http://people.ubuntu.com/~seb128/gnome-session.debdiff is the UI glitches fixing one
<seb128> I'm happy to delay it to after beta though
<seb128> the one from dholbach is that:
<seb128> -+                                      "gnome-logout", 48, 0, NULL);
<seb128> ++                                      "gnome-session-logout", 48, 0, NULL);
<seb128> (changing icon name)
<Mithrandir> I'd prefer to hold the UI glitches one since it's not trivial.
<Mithrandir> the icon name change is fine, though
<buttfukc> ompaul likes it up the butt
<seb128> let's delay the UI changes, that's not a complicated change but UI diff are not trivial to read
<seb128> Mithrandir: ok, fine with me
<seb128> dholbach: go with your upload so
<Mithrandir> seb128: yeah, it doesn't help that it's a diff of a diff.
<dholbach> Mithrandir: i changed it in the patch we have to gnome-session
<dholbach> seb128, Mithrandir: thanks
<seb128> np
* mode/#ubuntu-devel [+b buttfukc!*@*]  by thom
* buttfukc was kicked off #ubuntu-devel by thom (thom)
<dholbach> go thom, go! :-)
<thom> that was quite enough of that, i think
<ogra> hey thom, nice to see you around ! :)
<Mithrandir> does anybody else have any urgent uploads they need reviewed for beta?
<ogra> whats that openoffice mess in my cdimage report  ? is that solved ? 
<ogra> (seems it affects ubuntu as well)
<doko> what mess?
<ogra> http://cdimage.ubuntu.com/edubuntu/daily/current/report.html
<ogra> 22 uninstallables
<ogra> http://cdimage.ubuntu.com/daily/current/report.html
<ogra> same for ubuntu
<Mithrandir> ooo2 is called ooo now, isn't it?
<fabbione> it should be only a leftover from the seeds
<ogra> ah, ok, meta rebuild then
<fabbione> since it's also on -server
<doko> ogra: these are transitional packages now
<ogra> hmm, intresting, my seeds only show ooo2 in supported
<ogra> should that even show up in that report ? 
* mode/#ubuntu-devel [+o fabbione]  by ChanServ
* mode/#ubuntu-devel [+b *!*n=oll@216.48.2.*]  by thom
* butt1fukc was kicked off #ubuntu-devel by thom (thom)
* mode/#ubuntu-devel [+b butt*!*@*]  by thom
<fabbione> thom: shuuush :)
<ogra> heh
* mode/#ubuntu-devel [-o fabbione]  by fabbione
<thom> fabbione: too slow ;-)
<fabbione> i am eating :)
<dholbach> lame excuse :-p
<fabbione> i really am :)
* dholbach hugs fabbione and thom, the channel sherrifs :)
<Mithrandir> ogra,Riddell : I presume you want new livefs builds with the new casper too?
<ogra> sure
<Riddell> Mithrandir: yes please
<Riddell> and appologies if I messed it up when I uploaded
<Mithrandir> Riddell: you did, but I fixed it now and I needed to upload anyway.
<mdz> dholbach: do you have the beta ubuntu-artwork?
<dholbach> mdz: yeah, uploaded already
<mdz> dholbach: ok, am not caught up on -changes yet...ETA for availability in dapper?
<fabbione> Mithrandir: what time do we estimate the pre-beta iso's?
<dholbach> it's "successfully built" according to LP already
<dholbach> mdz: ^
<fabbione> Mithrandir: and i am not AWTY you.. just planning the day around your activities to help testing
<Mithrandir> fabbione: a couple of hours since casper hasn't built yet.
<fabbione> Mithrandir: ok thanks a lot.. i will be back in 4 and start testing.
<fabbione> today we will see if my nuclear power plant can keep everything turned on, long enough to do a bunch test installs :)
<dholbach> mdz: it's up
<mdz> dholbach: just noticed :-)
<dholbach> mdz: the gnome-session change, which will make the logout dialog look nice again will be built soon too
<jmg> BenC: ping
<mdz> fabbione: I'm getting:
<mdz> xserver-xorg postinst warning: not updating /etc/X11/X; file has been
<mdz>    customized
<mdz> presumably due to: cat: /var/lib/x11/X.md5sum: No such file or directory
<mvo> doko: do you know about a problem with the python logging module and fork() ? it seems there is somthing funny going on with it 
<mdz> mvo: did you see my comment on bug #28250?
<Ubugtu> Malone bug 28250 in update-manager "update-manager doesn't remember "automatically close when finished" checkbox state" [Normal,Confirmed]  http://launchpad.net/bugs/28250
<doko> mvo: no
<doko> mvo: please could you recheck with python2.5 (chinstrap:~doko/python2.5)
<mvo> mdz: I'm behind my bug-mail currently (especially ui-bugs) but I can fix this one and remove the checkbox (at least when it is used as a embeded widget)
<Mithrandir> pitti: did you promote flite1-dev or does mdz need to do that?
<pitti> Mithrandir: mdz or Kamion, I only approve it
<Mithrandir> pitti: ok.
<pitti> Mithrandir: infinity or Keybuk should be able to as well
<Mithrandir> pitti: thanks.
<Mithrandir> Keybuk: if you're around, could you promote flite1-dev?
<Keybuk> yup
<Keybuk> Mithrandir: mainified
<jmg> arrrg
<Mithrandir> Keybuk: thanks
<jmg> wtf
<Keybuk> do you want libfilte1 promoted as well?
<jmg> i cant find the bug i filed today
<Mithrandir> Keybuk: preferably, given tha flite1-dev depends on it.
<Mithrandir> that, even
<Keybuk> :o)
<Keybuk> ok, I think that should do it
<Mithrandir> Keybuk: thanks again
<Keybuk> I love how verbose this tool is
<jmg> 39948 - any suggestions on how i can improve on that as a bug report?
<jmg> provide a diff?
<jmg> besides+
<Keybuk> jmg: provide a changelog, etc.
<jmg> ok
<tseng> also worth a note "i tested this on dapper and it works for me"
<jmg> tseng: it needs to carefully get merged i think
<jmg> it works on etch
<janimo> infinity: ping
<jmg> makefiles are nasty as
<jmg> we hates them
<jmg> but ill see if i can cook up a patch
<janimo> seb128, bug 38551 would be good to have before beta, as it causes xubuntu-desktop uninstallable w/o net connection
<Ubugtu> Malone bug 38551 in gdm "gdm should depends on xubuntu-artwork too" [Normal,Confirmed]  http://launchpad.net/bugs/38551
<jmg> how can i get a bug confirmed?
<ogra> jmg, you find someone else who sees it too and confirms it
<jmg> ogra: ktnx
<jmg> *goes to find hunger*
<jmg> Hunger: ping :-)
<seb128> Mithrandir: is that ok to upload a gdm with an | xubuntu-deafult-settings now ?
<jmg> ogra: for a package like kernel-package, is it a good idea to try and go hacking it?
<Mithrandir> seb128: xubuntu needs it for beta, don't they?
<jmg> ogra: or do i leave it to the master?
<seb128> Mithrandir: looks like
<ogra> Mithrandir, yep
<Mithrandir> seb128: can you have it done before the hour?
<seb128> sure
<Mithrandir> run, then.
<mdz> mvo: does the string "Removed with config <package>" come from espresso or an underlying component?
<janimo> Mithrandir, seb128 thanks both
<ogra> i had the same prob with edubuntu, silly me didnt think about xubuntu when i talked to seb about it
<ogra> jmg, no idea, ask in #ubuntu-kernel :)
<mvo> mdz: from libapt/python-apt
<janimo> jmg, that's not the kernel source package itself. btw what you want to modify?
<jmg> wow
<jmg> kubuntu.de really threw their toys out of the cot
<jmg> janimo: read the bug report
<seb128> Mithrandir, janimo: change uploaded
<janimo> jmg, I'd have to guess the bugnumber first.
<janimo> seb128: :)
<jmg> https://launchpad.net/distros/ubuntu/+source/kernel-package/+bug/39948/+index
<Ubugtu> Malone bug 39948 in kernel-package "Please support Xen 3.0.2 by syncing to debian version 10.043+" [Normal,Unconfirmed]  
<ogra> heh, thats rather a whishlist bug for dapper+1 :)
<jmg> ogra: if you're saying it cant go into dapper then i'll hack it
<jmg> :)
<jmg> and make a diff for just the xen stuff
<ogra> jmg, we're preparing dapper beta currently ...
<jmg> ogra. i realise this...
<ogra> feature freeze was weeks (months ?) ago
<jmg> kernel-package, do you understand what this package does?
<jmg> make-kpkg rules
<jmg> it won't hurt dapper release
<doko> janimo: do you still want OOo on the xubuntu CD?
<janimo> doko, if it fits (looks like) yes
<ogra> haha
<ogra> "if it fits"
<janimo> right now I seeded Oo-o but did not bring much in
<jmg> and if too paranoid then i will fork :)
<gicmo> why the heck does ubuntu-minimal debend on wpasupplicant, this is a server, I sure dont need wlan on a server! :)
<jmg> gicmo: you might
<ogra> janimo, youre not seriously talking about iso size, do you ? 
<jmg> gicmo: what if it is a wireless ap? :)
<janimo> ogra, yes
<ogra> heh
<janimo> why? :)
<ogra> :P
<gicmo> jmg: ohh come on ;) you gotta be kidding me :)
<janimo> currently at 445M
<jmg> oh me mehereit!
<ogra> i'm happy if i get more than one language on the CD :)
<jmg> heh
<janimo> besides some planned xubuntu apps it will have space for language-support stuff
<gicmo> jmg: that's for sure not a good reason to have _ubutnu_minimal_ depend on it! :)
<jmg> gicmo: oh
<janimo> all top 10 lang-supports fit as they're around 130M
<jmg> gicmo: i thought ubuntu-server
<doko> janimo: please could you just unpack openoffice.org-gnome (dpkg -x <debfile> /) remove ucpgvfs1.uno.so and gnome-set-default-application, and see if you have any unresolved references in /usr/lib/openoffice/program ?
<gicmo> and where the heck is sebbuild? Haven't seem in ages
<janimo> maybe even OO
<janimo> doko, I'll try.will ping you when done 
<gicmo> jmg: I don't even see a ubuntu-server, just an edubuntu-server :)
<doko> janimo: makes only sense, if you don't have any gnome libs installed
<ogra> gicmo, ubuntu-server is planned for dapper+1
<ogra> or something similar
<janimo> will not have gnome libs installed by default.
<gicmo> ogra: ahh k :)
<jmg> well im all about dapper+1
<jmg> :p
<jmg> but i still want to see xen make it into universe
<janimo> doko, is the gtk integration of OOo tied with other gnome functionality?
<ogra> jmg, and in dapper+1 youre all about dapper+1 ... its always the same with you bleeding edge guys :)
<gicmo> anyway, I still don't see a point in ubuntu-minimal depending on wpasupplicant, I don't need it on the server and I dont want it on the server :)
<jmg> then main for dapper+1
<ogra> err
<gicmo> ogra: bleeding edge is the way to go! :)
<ogra> " dapper+1 youre all about dapper+2" indeed
<seb128> gicmo: hi :)
<gicmo> SEB128!!!!
<seb128> ;)
<gicmo> where have you been hiding!
<jmg> ogra :P
<gicmo> DUDE, I missed you already! :)
<jmg> ogra: not my fault xen3 was too ghetto to get into ubuntu
<gicmo> jmg: hahaha :)
<ogra> jmg, not ours either that upstream didnt accept it earlier :P
<jmg> xen3.0.2 is much better
<jmg> ogra: there is a big problem upstream
<jmg> ogra: xen2.0.6 packages are tough to impossible to upgrade
<jmg> cleanly
<ogra> and we bind ourselves to upstream :) thats why its not in at all yet 
<jmg> ogra: which is why they created a xen3.0 in experimental
<ogra> which we would have done as well if grumpy already existed ;)
<jmg> ogra: but also some spat between pkg-kernel and pkg-xen team
<jmg> ogra: up to krooger to resolve
<mdz> mvo: can we change it?  it's not proper English
<Keybuk> gicmo: just because you don't need it, doesn't mean that others don't
<mdz> mvo: "completely removed" would be better
<Keybuk> wireless-tools is also in minimal, for example
<janimo> doko, I have looked with ldd and those two you mention are the only ones with gnome deps
<doko> janimo: I don't think that the UI is, but we some uno modules depending on gnome
<janimo> there's gconfbe1.uno.so using gconf but
<gicmo> Keybuk: sure, sounds logic, so because of that we could make ubuntu-minimal depend on apache, sendmail, gnome hmm and kde .. because only that we don't need that in minimal doesnt meen that other don't
<Keybuk> gicmo: you don't need sendmail to get internet access
<janimo> gconf is already depped upon by gdm indirectly
<doko> ok, so it should be safe to plit out a ooo-gtk package
<Keybuk> gicmo: minimal is defined as the set of software needed to support the underlying hardware
<doko> janimo: ok, so it should be safe to split out a ooo-gtk package, but keep gconfbe1.uno.so in -gtk
<Keybuk> wpasupplicant is needed to get internet access (e.g. to install other packages) on wireless networks using WPA
<gicmo> Keybuk: yeah but still, there is hardware for desktops and there is hardware for servers, ... and most server for sure don't need friggin wireless to get online
<janimo> doko, great
<doko> janimo: but most likely not for the beta
<mdz> mvo: likewise for 'preparing to remove with config'
<janimo> sure, np
<mvo> mdz: does this look ok http://paste.ubuntu-nl.org/12495 (spelling)?
<Keybuk> gicmo: sure, but it's not like it's even a megabyte of disk space
<Keybuk> it's not even run unless you have a wireless card and WPA configured
<sabdfl> dholbach: *very* happy to see the new artwork package - thanks!
<mdz> mvo: how about 'preparing to completely remove'
<gicmo> Keybuk: sure, but then again, I just don't like having packages installed that I will _never_ need on that box, it installs files on /etc and I want /etc be small and stuff you know :)
<Keybuk> gicmo: we made a decision right at the start that we'd support networking (including wireless) in minimal
<mvo> mdz: http://paste.ubuntu-nl.org/12496
<Keybuk> if you don't want them, just uninstall them; you probably won't want any of the alternate filesystem support tools either
<gicmo> Keybuk: ahh sure, well then I don't like that decision :)
<sabdfl> dholbach: is there a way to automate the artwork cycle i.t.o. mapping what we get from the icon guys into a regular package update?
<gicmo> Keybuk: hmm yeah, the problem then is, that I am will bug seb128 now an then about stuff broken because I dont get dependencies dragged into :)
<jmg> sabdfl: hello!
<Keybuk> if you're going to realllly try for a bare-bones system, you'd probably remove pcmciautils, reiser*progs, xfsprogs, jfsutils, etc.
<sabdfl> hey jmg
<Keybuk> minimal isn't bare-bones; it's the stuff you need installed if you want to complain something doesn't work
<jmg> sabdfl: i have registered xenubuntu.com and .org
<sabdfl> jmg: thanks! would you give those to elmo to administer?
<Keybuk> if you want bare-bones, just install the Essential stuff :)  [defined as deps of dpkg] 
<jmg> sabdfl: can i transfer them?
<jmg> sabdfl: i have an idea for a xenubuntu project, can i talk to you about it?
<sabdfl> jmg: sure
<jmg> sabdfl: have been dealing with malc but he went quiet
<gicmo> Keybuk: well xfsprogs not really, because I am using xfs as the filesystem :)
<jmg> sabdfl: pm? email?
<mdz> doko: did you fix the oo.o2 stuff in ship already?
<gicmo> Keybuk: anyway, thanks for the explanation
<mdz> mvo: much better
<doko> mdz: hmm, what has to be fixed?
<Mithrandir> seb128: I presume it's not a problem if ubuntu gets the old gdm?  I'd like to get going soonish rather than having to wait for a full hour.
<pitti> mdz: JFYI, libbeagle is on the CD; also I'd like to do the ffox upgrade as first priority now and defer the beagle update (unless you object)
<mvo> mdz: I'm preparing a new upload now (apt with the wording fix)
<Riddell> Kamion: ping
<doko> mdz: just looked, this should be dependency packages only
<Mithrandir> Riddell: Kamion is on vacation today.
<Riddell> right, thanks
<mvo> Mithrandir: ok to upload apt with the wording change http://paste.ubuntu-nl.org/12496?
<Mithrandir> mvo: can it wait until after beta?
<Mithrandir> mvo: I agree the wording is a big improvement, but this hardly seems like a blocker?
<mvo> *shrug* it a wording change, it's not exactly a show-stopper
<Mithrandir> mvo: I'd prefer if you could hold it off then, so I could get images built soon
<mvo> ok
<Riddell> Mithrandir, mdz: can I upload espresso to fix malone 39666?  stops crashes when using KDE frontend and non-ascii language
<Ubugtu> Malone bug 39666 in espresso "KDE frontend crashes at page 5 (?)" [Normal,Needs info]  http://launchpad.net/bugs/39666
<fabbione> mdz: is that on install or update?
<Mithrandir> Riddell: looking
<mdz> doko: something is wrong with the font changes that you made
<mdz> doko: the fonts in firefox are much less readable
<mdz> doko: sabdfl has commented on this as well
<mdz> pitti: no objection to delaying the beagle update
<mdz> mvo: thanks
<mvo> mdz: cheers, I'll upload right after the beta 
<Mithrandir> mdz: font issue, is that a blocker?  (I'm not aware what the issue is)
<doko> mdz: I wouldn't say "wrong". does this persist, when you forbid firefox to use fonts requested from the web page?
<mdz> doko: I would say "wrong"; the quality is quite clearly worse after the upgrade than before
<mdz> doko: changing it to ignore the page's fonts improves things, yes
<mdz> doko: but that is not our default, and I don't think it should be either
<mdz> Diziet: do you have some insight here?
<doko> mdz: so we have to decide if ship with a default font that makes document print wrong. I cannot see an alternative at the moment, I asked Diziet if he could overwrite the font selection for firefox. 
<mdz> doko: if the fonts that we use to match fonts specified by web pages are bad, then we should match them to different fonts
<jordi> Kamion: hmm, manpages written in UTF-8, what do you need to make them read correctly with man?
<jordi> Kamion: should Spanish manpages be in latin1 instead?
<Treenaks> *shudder*?
<doko> mdz: we don't have a free font, whith the same metrics, which displays as well as DejaVu/Bistream Vera.
<mdz> doko: here's an example of a page which looks ugly by default: http://paste.ubuntu-nl.org/12496
<fabbione> mdz: in any case /etc/X11/X shouldn't be a blocker since it's a symlink to /usr/bin/Xorg
<doko> mdz: you mean the Serif font?
<mdz> doko: both
<mdz> but yes, the serif one is worse
<mdz> fabbione: no, not a blocker, but a bug
<mdz> doko: why should this situation be any different than in warty/hoary/breezy?  did the font metrics change?
<fabbione> mdz: please file a bug and tell me if it was on install or upgrade
<mdz> fabbione: on upgrade, though surely the problem was not new with the most recent upgrade
* Riddell wonders what Mithrandir is looking at
<Mithrandir> Riddell: sorry, I got distracted.
<mdz> fabbione: I think the whole md5sum mechanism is overcomplicated; all we need to do is readlink and compare to the default value
<mdz> Mithrandir: not a blocker for beta, no
<Mithrandir> Riddell: ok, upload away.
<Mithrandir> infinity: around, and any chance you could drive LP by hand for me?
<fabbione> mdz: it is overcomplicated for Ubuntu. it's not when/if we will add more xservers to the default
<fabbione> mdz: but mostlikely some bits did break because nobody updated them
<fabbione> mdz: and there are tools now that can do that for us.. like ucf
<mdz> fabbione: this has broken for me in many situations over the past releases; usually it is harmless because it leaves the symlink alone in the ned
<mdz> but it always prints errors
<seb128> Mithrandir: yeah, no problem at all for Ubuntu with previous gdm :)
<Riddell> Mithrandir: thanks
<fabbione> mdz: ok i will look at it after Beta.
<fabbione> mdz: i will need to check how the code did change and why
<fabbione> even if the fix seems trivial we don't want to end up during really bad things
<janimo> Mithrandir: are you doing cd builds by hand now, outside what is done by cron.daily?
<fabbione> like leaving a system without /etc/X11/X
<Mithrandir> janimo: yes.
<janimo> is the latter still going till Thu?
<Mithrandir> janimo: I'm going to turn off cron.daily
<janimo> uh, ok.
<Mithrandir> janimo: how so?
<janimo> just did not know, nothing important :)
<janimo> I thought we rely on corn.daily+extra caution only 
<Mithrandir> janimo: nah, we want to make sure the images themselves are good.
<janimo> Mithrandir: ok, then I hold off anything else for xubuntu. only the gdm upload is important, and slightly less the addition of tango in my upload a few minutes ago
<janimo> unless something else if found by testers. So new images also for xubuntu today? I'd like to ask on xubu-devel for testers if so
<doko> mdz: we have a new default font with different metrics (DejaVu). I'm looking at breezy, if I can reproduce the "wrong" look with DejaVu
<Mithrandir> janimo: just tell me when you want me to build the images.
<janimo> Mithrandir: ok, thanks
<doko> mdz: in breezy, evince did select the Times/Helvetica fonts by itself, without any fontconfig interaction (?). Apparently in dapper it does consult fontconfig and chooses the metric-incompatible fonts. seb128, any hint?
<bddebian> Morning
<doko> mdz, seb128: in breezy, poppler didn't consult fontconfig, but had it's own mechanism to get a correct replacement for the Adobe fonts. that's the reason why PDF's are correctly displayed. breezy's version of fontconfig didn't define the aliases for the Adobe fonts.
<seb128> doko: poppler was not using fontconfig before
<seb128> doko: what PDF is not correctly displayed now?
<mdz> fabbione: I'm not sure we should change it for dapper, but it is a source of bugs currently
<stub> Launchpad will be going down in 15 minutes for a regular code update. Estimated downtime is 10 minutes. Wikis will be in read only mode during this period.
<mdz> stub: that's fairly short notice considering that we're preparing a release at the moment
<doko> seb128: http://people.ubuntu.com/~doko/svn-book.pdf if you comment out the aliases (Adobe -> Nimbus) in fonts.conf
<stub> mdz: I can delay if you want. I thought a 10 minute downtime window would be fine.
<Mithrandir> ok, ubuntu live and install cds up.
<Mithrandir> please test them, they might be the beta ISOs
<ogra> Mithrandir, hah, dreams ...
<ogra> that would be the first milestone without a rebuild :)
<Mithrandir> ogra: _might_. :-)
* pitti jigdos and rsyncs
<Mithrandir> ogra: You want live fs-es and cds too?
<ogra> damn, i'm still rsyncing last nights builds ...
<ogra> Mithrandir, let me get up to date first
<infinity> Mithrandir: I'm around now.  Still need driving, or too late?
<Mithrandir> I can start the livefs builds.
<ogra> yep
<infinity> janimo: xubuntu livefs is happening as we speak.
<Mithrandir> infinity: I think the new espresso has trickled through now anyway, but thanks.
<ogra> evenn the isos, i'm done with live rsyncing
<janimo> infinity: thanks!
<pitti> Mithrandir: 0.99.51?
<mdz> stub: now is better than later
<mdz> stub: we've just finished a build cycle, so we can do without upload for a bit while we test this build
<Mithrandir> Riddell: did you get around to uploading the new espresso?
<stub> ok.
<sivang> re all
<mdz> stub: in the future, please plan for more conservative process during release weeks
<stub> mdz: Will do.
<Mithrandir> usplash and casper seems happier now  (as in, usplash till the end)
<mdz> Mithrandir: oh, good
<mdz> Mithrandir: on the espresso reboot as well?
<Mithrandir> mdz: unsure, since I'm just booting the CD.
<Mithrandir> the new artwork looks nice.  Clean, sharp.
<Riddell> Mithrandir: no, doing that now
<mdz> oh, different problem then
<mdz> I've seen some weirdness when rebooting from casper
<mdz> usplash not coming up at all, or hanging in sendsigs
<Mithrandir> mdz: no, usplash used to quit about at the same time as "adding live cd user" due to udev changing the usplash timeout.
<mdz> right, that was fixed in the previous build already
<mdz> or else this machine is fast enough that it didn't happen
<Mithrandir> it wasn't.
<ogra> so do we have new usplash artwork already ? 
<infinity> dholbach: You're aware that the brltty you had synced from Debian has build-deps in universe, right?
<Mithrandir> casper (1.44) dapper; urgency=low
<Mithrandir>   * Reset the timeout after casper-premount has run so we're sure that the
<Mithrandir>     timeout is what we want it to be.  Udev seems to change it too.
* ogra still didnt hear *anything* about artwork)
<Mithrandir> infinity: those have been promoted already.
<mdz> infinity: bug #39332
<Ubugtu> Malone bug 39332 in brltty "brltty needs to install non-interactively" [Major,Confirmed]  http://launchpad.net/bugs/39332
<infinity> Mithrandir: Oh, as in, in the last cycle?
<Mithrandir> infinity: so if you could give-back brltty on all arches, that'd be nice.
<infinity> Mithrandir: It's dep-wait, no giving back required.
<mdz> infinity: (once launchpad is back up, that is)
<Mithrandir> infinity: as in, an hour or two ago, yes.
<Mithrandir> infinity: 'k
<Mithrandir> hmm
<Mithrandir> but that means the live cd is useless since brltty still needs fixing on it.
<Mithrandir> argh.
<Mithrandir> ogra: seems you were right.
<janimo> infinity: AIUI livefs != livecd. is the latter to be expected on cdimage only after I ask, assuming cron no longer builds CDs till beta?
<ogra> Mithrandir, it would have been a miracle if we could go right away :)
<infinity> janimo: livecd images will happen after livefs.  Once I'm sure the one works, I'll wrangle the other.
<Mithrandir> infinity: can you please stop cronned livefs builds?  (We do usually stop them, don't we?)
<infinity> Mithrandir: We usually do, yes, I'll turn them off right now.
<Mithrandir> thanks
<infinity> Done.
* infinity goes back to fiddling with Xubuntu.
<infinity> Scream if you need anything.
<ogra> anything ? 
<infinity> Within reason, realising that it's 11pm here. :)
<ogra> :)
<mdz> ogra: espresso seems to have the same problem that hwdb-client had where you need to move off of the Forward button and then back onto it before it is clickable
<mdz> ogra: did you ever find a fix for that?
<ogra> its a gtk bug (really)
<infinity> gtk, or pygtk?
<mdz> and did you find a fix for it?
<ogra> and no, i didnt
<mdz> what's the bug # in malone?
<ogra> infinity, given that synaptic had this bug even before ubuntu existed, its gtk, not pygtk
<ogra> mdz, bug 14669 i think
<janimo> ogra, a similar bug was in xfce logout dialog but that fiddled with xlib too
* mvo seaches for the upstream bugreport
<ogra> ah, duplicate of bug 22930
<Ubugtu> Malone bug 22930 in gtk "Mouse focus doesn't return until mouse is moved off button" [Unknown,Unconfirmed]  http://launchpad.net/bugs/22930
<jmg> i rejected my own bug :)
<KaiL> some more orange for gdm would be cool ;p
<jmg> hax0r!
<KaiL> ...and nice new icons!
<shackan_> uh, I've observe 22930 myself often, I got so used to it I just consider a minor annoyance and not a bug anymore :)
<shackan_> *observed, even
<jmg> shackan_: confirm the bug then
<mvo> the upstream log looks like it may well take a bit until we see a fix
<giftnudel> this is a nice bug btw, 12 duplicates ...
<mdz> hmm, just did an i386 espresso install, and it doesn't reboot when I click restart in espresso (still) :-/
<mvo> I had a similar problem, it hangs on powernowd apparently
<mdz> I was just rebooting to try to debug
<mdz> mvo: in my case it doesn't even shut down X yet, so I don't see how powernowd could be at fault?
<mvo> oh, I saw the boot-down splash, but then it stopped
<Mithrandir> mvo: did it eject the cd first?
<mdz> I've seen it hang at sendsigs (sending TERM) there
<mdz> but not powernowd
<ogra> why does it shut down at all ? 
<mvo> Mithrandir: don't know, let me check again
<ogra> wouldnt forcing a poweroff/reboot immediately suffice ? its a liveCD
<infinity> Is soyuz actually in upload approval mode, or are we all just on our best behaviour currently?
<Mithrandir> infinity: best behaviour.
<infinity> Check.
<fabbione> mdz: i am not going to change it for dapper, but at least fix the upgrade path from breezy and make that error more quite
<mdz> mvo: I've noticed that espresso doesn't seem to display a progress message when it starts to remove a package, only when it finishes removing one
<mdz> mvo: can that be changed easily?
<mdz> mvo: it hangs a long time saying that it has installed user-setup, when what it is doing is removing a language pack
<Mithrandir> mdz: for me it seems to just not reboot
<mvo> mdz: hm, it should give a message when it starts removing, let me check
<Mithrandir> seems to start shutting down by doing C-A-Backspace, though
<mvo> Mithrandir: the cd is ejected, then nothing happens anymore (the splash is at ~70% down), pressing enter seems to make it reboot though 
<Mithrandir> mvo: that's a known usplash bug, then.
<mdz> Mithrandir: same here
<mvo> IIRC this was a known problem so I may be making noise
<mdz> Mithrandir: the problem is with gnome-session-save
<mdz> (my problem is, anyway)
<mdz> it's correctly using gdm-signal to set the logout action, but then gnome-session-save --kill fails
<mdz> Authentication rejected,could not connect to the session manager
<Mithrandir> probably because it's running as root.
<infinity> Mithrandir: Should we shove the usplash/init fixes in for beta, or just leave it?
<mdz> easily reproduced by gksudo "gnome-session-save --kill --silent"
<Mithrandir> infinity: the press enter thing?
<infinity> Mithrandir: I can probably whip it all up and fix it after I've slept, assuming tonight's test rounds aren't the last.
<bddebian> infinity!!! :-)
<Mithrandir> infinity: they won't be.  I think we'll have a long day tomorrow if we're going to make Thursday.
<infinity> Mithrandir: The "usplash gets killed by init" thing, and any other issues you have (still have breakage due to being on vc8 too?)
<infinity> Mithrandir: Right, well if today's aren't likely to be the final candidates, I'll try to pop some obvious fixes in tomorrow for usability stuff like this.
<mvo> mdz: it may not be easy to change the progress reporting on removal. it seems like the problem is simply that dpkg reads its database and that this takes the time. I have a idea for a fix, but I'm not sure if it will work reliable (testing it now)
<Mithrandir> infinity: if the fix for "init kills usplash too early" is easy, I'd love to have that fix in.
<infinity> Mithrandir: It should be simple enough.  I'll attack it in the morning with a fresh brain.
<mdz> mvo: no, dpkg is definitely already running the maintainer scripts
<Mithrandir> infinity: thanks.
<infinity> janimo: How's your bandwidth?
<janimo> 60kbytes/s
* Mithrandir twiddles thumbs while bzr merge runs.  Or crawls.  Or something.
<mdz> seb128: can you help with this gnome-session-save problem?
<seb128> mdz: what is the issue?
<infinity> janimo: Oh.  So if I spin a Xubuntu livecd for you to test, it'll take a while for you to grab it and give me feedback?
<janimo> infinity: yes, at least 4-5 hours
<infinity> janimo: Oh well, I'll do so anyway.  Which arch do you test on?
<mdz> seb128: the problem is that espresso needs to do g-s-s --kill, but it's running as root, not the user
<janimo> infinity: I can ask in the xubuntu channel though
<mvo> mdz: this couldn't be a issue of apt invoking dpkg multiple times with different arguments? so that it has to re-read the database?
<janimo> I test in i386
<infinity> janimo: You can give me feedback overnight, and when I wake up, if it'll all good, we'll spin for all arches.
<mdz> seb128: so it gets "authentication Rejected", etc.
<janimo> infinity: ok
<Mithrandir> mdz: I'd call that blocker.  Agreed?
<mdz> mvo: run tail -f /var/log/installer/espresso
<mdz> Mithrandir: yes
<Mithrandir> "a blocker", even.
<mdz> we can always roll back to the old behaviour, which I think just ran reboot
<lamont> mvo: is it possible that update-manager isn't tied into nss completely?  (it doesn't like my password, but passwords come from ldap, and the one in /etc/shadow is probably diff than ldap...)
<mdz> that g-s-s stuff is new
<mdz> I don't see how it possibly could have worked for colin
<seb128> mdz: is that possible to call it with su $USER ?
<mvo> lamont: that would be a gksu problem, can you check if gksu/gksudo works for you?
<Gloubiboulga> infinity, janimo, I'd be happy to test the live cd (20 minutes to DL the iso)
<janimo> Gloubiboulga: great!
<mdz> seb128: would that fix it?  or is the environment the problem?
<infinity> Gloubiboulga: Spiffy.  I'll ping you in an hour or two when my backlog of "livecd and buildd stuff" is sorted and an ISO exists.
<mdz> seb128: ok, found a workaround
<Gloubiboulga> infinity, ok
<mdz> Mithrandir: we can do 'sudo -u ubuntu -H gnome-session-save ...'
<mdz> or perhaps just fix HOME in the call
<lamont> mvo: works
<lamont> update-manager_0.42.2ubuntu12
<mvo> lamont: thats strange because update-manager just uses gksu for it's authentication
<Mithrandir> mdz: su - $SUDO_USER -c gnome-session-save ?
<seb128> mdz: hum, running "sudo gnome-session-save --kill" works fine on a betaCD candidate on my laptop
<Mithrandir> hm, no, that'll nuke DISPLAY
<mdz> Mithrandir: I tested it with sudo -H and it works
<lamont> mvo: it's also possible that I consistantly screw up the password when prompted...
<mdz> seb128: really?
<lamont> I'll look at it more
<seb128> yeah, I've just tried
<mdz> seb128: I did "gksudo gnome-session-save --kill" and that failed
<mdz> seb128: this was after running espresso, though I don't see why that would change things
<seb128> mdz: hum right, gksudo breaks it
<seb128> sudo doesn't
<mdz> interesting
<seb128> gksudo probably does some magic, like setting environment variable ... mvo?
<Mithrandir> gksudo nukes env variables unless you pass -k
<slomo_> Mithrandir: what must be given for a main upload exception now? :) i have a small patch for avahi that only changes a binary package from universe
<mdz> gksudo "env HOME=$HOME gnome-session-save --kill" works
<Mithrandir> slomo_: is it urgent to get it into beta?
<seb128> gksudo -k "..." works fine
<mdz> seb128: running all of espresso under -k could break other things, though
<slomo_> Mithrandir: no... just fixes a segfault in a universe package that affects only people on SMP... ok, so i put the first thing into my pending uploads queue :)
<Mithrandir> slomo_: thanks.
<Mithrandir> mdz: just adjusting espresso/frontend/gtkui.do:do_reboot should fix it.
* ogra still doesnt get why we need the shutdown procedure at all ... wouldnt /sbin/reboot -f speed things up and override all the problems ? 
<thom> ogra: i'd be pissed if you did that after i've mounted external filesystems ;-)
<mdz> Mithrandir: yes
<tseng> thom: woo!
<mdz> tricky to get the home dir right without hardcoding a bunch of stuff though
<ogra> thom, still, its a live CD and i guess you get a question if you want to reboot now
<Mithrandir> ogra: no, you don't.
<thom> tseng: dude!
<ogra> Mithrandir, oh
<mdz> using sudo -H is probably easiest
* mode/#ubuntu-devel [-o thom]  by thom
<mdz> testing that fix now
<Mithrandir> mdz: can you upload a fix with that if it fixes it?
<mdz> Mithrandir: espresso does in fact display a confirmation dialog for the reboot
<mdz> with a cancel option
<mdz> Mithrandir: and yes, I will
<Mithrandir> thanks.  I need to go to the shop and find my brother a birthday present now.
<mdz> Mithrandir: who else can turn the CD cranks?
<Mithrandir> mdz: infinity, ogra, Riddell.
<mdz> (infinity is asleep)
<Mithrandir> mdz: anyway, if you upload before 1500, it'll be published by 1530, then binaries built and published by 1630.
<mdz> I have privileges to do it, but I'm out of practice
<ogra> then we cant do livefs 
<mvo> mdz: I can reproduce the problem with the removal now, working on it now
<Mithrandir> I'll be back before then and can start a livefs and iso build then
<mdz> mvo: thanks
* pitti spanks nautilus for crashing on copying > 4GB files
<mgalvin> Mithrandir: how much faster would you say the LiveCD boots compared to the breezy LiveCD (percentage wise)?
<BenC> will it affect the beta if I do a kernel upload within the next hour?
<seb128> pitti: it does that? DOH
<pitti> seb128: just did for me when I copied a DVD image
<mvo> BenC: I'm note sure that this is a good time for a kernel upload (talk to Mithrandir first)
<Keybuk> mdz: biff
<BenC> Mithrandir: ping
<pitti> seb128: the copy is 4294967295 bytes (0xFFFFFFFF) and nautilus crashed at that point
<seb128> pitti: what source type? local file for both?
<pitti> seb128: yes
<seb128> we are discussing a 2Go limitation on ftp atm on #ubuntu-bugs but you are not on the chan
<seb128> could be nice to have distro team people on that chan sometime :p
<seb128> (hint hint :p)
<pitti> I *am* in that channel
<pitti> (well, for 3 seconds *cough*) :)
<seb128> hehe
<ogra> seb128, i had a similar support recently on the -users ML where i thought it was related to the user using userspace nfs, but switching to nfs-kernel-server didnt solve it
<fabbione> BenC: even if you upload now, it won't be propagated to the installer, but it's probably better to wait for Mithrandir anyway.
<fabbione> BenC: does it involve an ABI bump
<fabbione> ?
<BenC> unfortunuately
<mvo> why does the espresso progress window likes to jump to the middle of the screen every few seconds?
<fabbione> BenC: i am afraid it's post Beta
<BenC> ran into a couple of snags during my builds last night, so I didn't get it done like I wanted to
<fabbione> it takes too long to propagate an ABI bump
<infinity> BenC: An ABI bump COULD be hand-massaged through if we had to, but it's probably better to just wait, and do a nice fat upload right after beta.
<infinity> BenC: mdz's already asked me to hold off on an fglrx update until post-beta, so.. :)
<BenC> no problem
* fabbione goes and check the changelog
<infinity> Gloubiboulga: http://cdimage.ubuntu.com/xubuntu/daily-live/current/
<infinity> janimo: ^^^^
<janimo> infinity, just seen it :)
<Gloubiboulga> infinity, downloading :)
<janimo> 367M ?that's so small
<infinity> If one of you can let me know if that even does simple things, like, uhh, boot, then I'll go ahead and do the other arches.
<bddebian> Wow, everyone is here today :-)
<janimo> what's missing wrt install.iso?
<infinity> janimo: I assume your desktop and live metapackages are a lot smaller than ubuntu's.
<janimo> infinity: xubuntu-install.iso is 435M
<janimo> is live generally 70 M less?
<infinity> janimo: install includes the "ship" seed, live includes the "live" seed (but not ship).  They don't really need to be anywhere near the same size.
<infinity> janimo: They're your seeds, not mine, so I dunno. :)
<janimo> infinity: ok thanks :)
<infinity> janimo: Anyhow, keep in mind that everything on the livecd is installed, so don't bloat it out just for the sake of filling the CD.  If your CDs are small because your desktop (with all the useful apps you want) is smaller, then just do the dance of "I have smaller CDs than you, nyah, nyah"
<infinity> janimo: And start seeding lots of langpacks. :)
<janimo> infinity: yes, I'll put lots of langpacks, so maybe no OOo for the livecd then
<seb128> hum
<janimo> so startup time of livecd is proportional with size of packages on it?
<infinity> janimo: Well, no.  Apps that aren't running obviously won't hurt you.
<seb128> fresh install loops on "brltty[3003] : Not a serial device: /dev/ttyS0"
<infinity> janimo: But adding more bling to your user's session and the like would be silly, if you're aiming for "fast and light"
<janimo> infinity: you mean espresso install everything that's on livecd?
<seb128> like it's ~10% time it too me to notice and type that
<seb128> oh
<janimo> in that case no OOo for sure, only in the ship seed
<infinity> janimo: No, espresso is more clever than that.  It installs everything that isn't pulled in by live.
<seb128> no, that's disk being checked due to mount count it seems
<seb128> but there is that label with the % displayed every few sec
<infinity> janimo: I do livefs builds in two passes.  I install minimal/base/desktop, then I do a manifest.  Then I install live and casper, and build another manifest.  Casper diffs those, and uninstalls everything that was pulled in by the second set.
<infinity> janimo: In theory, a d-i installation and a capser installation should be close to identical, if you go with defaults for both, thanks to that crazy hack.
<janimo> infinity: thanks for the details. ok let's see if it boots then and see later what else we put on it :)
<giftnudel> How many CDs do you burn that will then be thrown away?
<ogra> none
<ogra> you know the media with RW in its name ? ;)
<pitti> giftnudel: CD-RW, dude :)
<giftnudel> well, probably better in this case ;)
<giftnudel> everytime I read that, I was wondering ... now I know the mystery
<pitti> eek blank screen on ppc/install on first boot
<seb128> dholbach: my new fresh dapper beta CD install use GNOME as icon theme
<dholbach> seb128: oh :-(
<seb128> mvo: the language selector lists no language
<mvo> seb128: please run apt-get update 
<seb128> as a non-power use I'm stuck with english strings all over the place :/
<seb128> mvo: as a non-power use I'm not supposed to run a command line after installing my dapper :p
<seb128> (just pointing the issue I have as a normal user with the candidate install)
<mvo> seb128: sure, but my theory is that for some reason during the install no apt-get update was run inside the chroot
<seb128> "issues" rather
<seb128> k, so you know about the issue, good
<seb128> let me know if I can be useful at providing logs, details, etc
<mvo> well, no. but I know that no languages usually means -> empty package lists
<seb128> dholbach: there is no /usr/share/icons/Human on that install
<seb128> ups, there is, hum
<dholbach> seb128: do i have to change the value in libgnome2-common's dekstop_gnome_interface.schemas?
<dholbach> s/dekstop/desktop
<seb128> dholbach: no, not that way
<dholbach> seb128: sorry, the icon_theme value
<seb128> use the gconf.defaults for it
<dholbach> seb128: what do you propose?
<dholbach> ah right... but that's the right key, right?
<seb128> wait I'm getting the source package :p
<pitti> Mithrandir: ok, current ppc/install works (with Testing/Short plan), modulo the brltty debconf questions
<seb128> dholbach: yeah
<seb128> debian/libgnome2-common.gconf-defaults
<dholbach> seb128: can you close bug 37489 with that?
<Ubugtu> Malone bug 37489 in ubuntu-artwork "newly added user doesn't see default theme" [Normal,Confirmed]  http://launchpad.net/bugs/37489
<seb128> /desktop/gnome/interface/icon_theme Human
<seb128> dholbach: should I do the libgnome update?
<seb128> or do you do it?
<dholbach> seb128: i'm happy if you do it, that's fine with me
<seb128> dholbach: I don't really care, you are the icon guy, do it :)
<seb128> and close the bug ;)
<dholbach> ok
<HiddenWolf> hey seb128, dholbach, can something be thought up to avoid that an -artwork release updates/overwrites the default background?
<seb128> mvo: do you need any data on that install before I run apt-get update?
<HiddenWolf> That new background scared the heck out of me.
<dholbach> HiddenWolf: it was always the same icon that was shipped, we're planning to do ubuntu-artwork-$(release) soon, but not now
<mvo> seb128: no
<ogra> HiddenWolf, just use a non default wallpaper
<seb128> HiddenWolf: what do you mean? Select your background, that's an use setting
<dholbach> HiddenWolf: s/icon/wallpaper
<seb128> user
<pitti> Mithrandir: since you'll build new images anyway, I'm not yet adding stuff to the test plan matrix, right?
<HiddenWolf> ogra: Doing that now, first time I saw the new sparkle, I thought my screen was corrupt.
<seb128> hum
<seb128> network not configured :/
* ogra hasnt see the new themme yet
<ogra> *seen
<seb128> I had to run "sudo dhclient" to get an IP
<janimo> seb128, dholbach: gnumeric debian packager said he's in principle ok with gtk only patches to the same source, and would take them if they got testing in ubuntu, but right now has not free time to work on it and get them in debain first
<janimo> I'd like you to accepts debdiffs against goffice/gnumeric to make this happen here first
<seb128> janimo: after dapper beta please
<seb128> now is not the right time for such change
<janimo> seb128: definitely, asked in principle for permission
<seb128> no need of permission to send a patch :)
<ogra> :)
<seb128> I'm sure dholbach will be pleased to have a look next week while I'm on VAC :p
<janimo> :)
<janimo> seb128: great
<dholbach> :-)
<janimo> Gloubiboulga: looks like you can send the patches :)
<Gloubiboulga> yep :)
<Gloubiboulga> after the Xubuntu live cd test 
<janimo> sure, no hurry
* janimo concocts a plan regarding switching some gnome packages from cdbs while seb is not looking and enjoying VAC :)
<seb128> I'll read mails daily ,)
<seb128> ;)
* janimo plans to change identity afterwards
<dholbach> janimo: good thinking
* janimo <3 cdbs actually
<ogra> seb128, thats only a matter of hiding it well in the cangelog and you wont even notice :)
<doko> infinity: just upgraded a machine, one with a small /boot partition ...
<dholbach> Mithrandir: are you ok with uploading  http://daniel.holba.ch/ubuntu/libgnome.debdiff ?
<pitti> eeek @ new ffox fonts
<infinity> doko: And felt the urge to file the bug again? ;)
<infinity> pitti: Agreed. :/
<dholbach> Mithrandir: it's a change that defaults new users to the icon love, not the old gnome icon theme
<pitti> most web pages look good, but generated directory listings now appear in some Courier font that looks ugly
<doko> infinity: RAMDISK: ran out of compress data 
<ogra> infinity, yes, doko has fun with that, i also have some reopened ones ... he just cant accept a no ;)
<Diziet> doko: Can you provide a test file for broken fonts ?  I'm trying to get the config and stuff so that we can have right answers all of the time.
<infinity> doko: Yeah, same bug as has already been reported.  It's RC.  I'll fix it before we release, honest.
<mvo> mdz: unfortunately the problem with the removal indication seems to be not that easy to fix because dpkg sends rather confusing state changes sometimes
<Diziet> I mean, a file that came out wrong when printed, with the previous setup (before you reverted the removal of the aliases).
<doko> http://people.ubuntu.com/~doko/svn-book.pdf
<mjg59> Oh urgh.
<janimo> Mithrandir: whenever you have time, please make a xubuntu install cd
<mjg59> doko: The fonts changes are not only ugly, they're poorly hinted
<doko> Diziet: ^^^ that shows the wrong metrics, if you don't ahve the aliases
<mjg59> They have huge colour fringes here
<Diziet> doko: Thanks.
<Diziet> mjh59: You mean in firefox ?
<mjg59> Yes
<infinity> Yeah...
<infinity> What font IS this?
<infinity> http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html
<infinity> It's making my brain hurt.
<doko> mjg59: can fontconfig hint type1 fonts?
<Diziet> infinity: That's quite grim, isn't it ?
<mjg59> doko: I don't know that that's a question that makes sense
<infinity> kerning is all wrong too, and seems to bounce around, depending on random things like line length and moon phase.
<mjg59> Surely it's Pango that pays attention to the hinting?
<Diziet> doko: So which page looks wrong ?
<doko> infinity: you have to give us a png ...
<pitti> infinity: ttf-lao needs to be promoted, it's approved
<doko> Diziet: all of them, look at one page in the text
<pitti> infinity: (for l-support-lo)
<infinity> pitti: Erm, I was pointing at the font firefox uses for that, not the contents of the page. :)
<Mithrandir> mgalvin: approximately twice as fast.
<pitti> infinity: oh, you mean the fonts, not the contents
<Mithrandir> BenC: pong
<pitti> infinity: sorry, ECONFUSED :)
<mgalvin> Mithrandir: cool thanks
<Mithrandir> pitti: cool, but yes, not final images
<mdz> mvo: ok, it should be less significant once bug #39989 is fixed
<Ubugtu> Malone bug 39989 in espresso "Language pack removal is incredibly slow" [Normal,Unconfirmed]  http://launchpad.net/bugs/39989
<Mithrandir> dholbach: I'm not very happy about new uploads now since each upload means a two-hour delay.
<doko> infinity: given that this is a serif less font, fc-match Sans should print the name
<Mithrandir> janimo: running
<seb128> dholbach: I like the new update manager icon ;)
<doko> mjg59: please could you check, if http://people.ubuntu.com/~doko/ttf-dejavu/ looks better for you (in case that you actually use DejaVu)
<mjg59> http://www.codon.org.uk/~mjg59/tmp/ugly.png
<infinity> doko: Has serifs here..
<dholbach> seb128: tell mvo
<seb128> mvo: I like the new update manager icon ;)
<BenC> Mithrandir: unping, going to wait to upload the new kernel
<Mithrandir> BenC: thanks. :-)
<dholbach> Mithrandir: I understand. If there are complications and we have to wait anyway, it'd be nice, if I could do it then - does that make sense?
<mjg59> doko: I have never deliberately chosen to use DejaVu
<Mithrandir> dholbach: yes, then it'd be fine.
<doko> mjg59: that looks like the Nimbus font. is subpixel rendering turned on? 
<mjg59> doko: Yes, subpixel rendering is turned on
<Diziet> Hrm, it seems to be caching it somehow.  Or maybe my X server doesn't have the right stuff in it.
<mjg59> It's a laptop
<dholbach> Mithrandir: ok, I think it's important enough, but it's your call.
<infinity> doko: Yeah, my default proportional font in firefox is "Serif", which is "DejaVu Serif", apparently.  And hideous, for whatever reason.
<ogra> thats definately nimbus
<Mithrandir> dholbach: do you have any other small tweaks like this you need/want to get in, then please tell me now.
<mjg59> doko: Nimbus appears to be the wrong choice here, since it deals with sub-pixel rendering really badly
<dholbach> Mithrandir: not for the moment, no.
<ogra> it doesnt at all
<ogra> its a type1 font
<mjg59> Whatever sans-serif I had before that worked much better
<infinity> doko: Hrm, but it's clearly NOT DejaVu, since if I tell firefox to use that explicitely, it doesn't look like ass.
<infinity> doko: So, fc-match isn't agreeing with firefox.
<pitti> Mithrandir: ppc/live works, espresso still b0rked for me (will do bug fiddling for that)
<doko> mjg59: the old problem, we only have one config system, but want  a) a good font on the display, b) a correct metric font for pDF's and printing
<mjg59> doko: Sure, but unfortunately making webpages look offensive is going to piss off even more people than incorrect PDFs
<infinity> Argh.  Switching firefox from "serif" to "dejavu" and back to "serif" makes it start picking DejaVu instead of whatever hideous thing it was before, so now I can't reproduce the bug.  Awesome.
<HiddenWolf> mjg59: incorrect pdfs are a problem, ugly printing is a sin.
<doko> mjg59: tell firefox not to use fonts specified by the web page
<mjg59> doko: No.
<janimo> Gloubiboulga: so? :)
<mdz> mvo: perhaps it could be fixed in espresso rather than in apt?
<Gloubiboulga> infinity, janimo: works fine :)
<janimo> \o/
<infinity> Spiffy.
<mdz> mvo: before doing the removal, it could put up a new progress message
<mjg59> HiddenWolf: And large colour fringes on webpages are grounds for excommunication?
<janimo> Gloubiboulga:  espresso too ;) ?
<HiddenWolf> mjg59: exorsism. ;)
<Gloubiboulga> janimo: not tested yet, and I can't really test it now :/
<infinity> janimo: Shall I let you tidy up your seeds a bit before we try a second run at generating images?
<mdz> doko: so what are we doing about this for beta?
<Diziet> doko: OK, I now see (trying to reproduce your problem) an apparently-squashed display, where the letters are too close together for their size.  Is that what you mean ?
<infinity> janimo: I need to sleep sometime anyway. :)
<doko> mjg59: depends on your priorities
<doko> Diziet: yes
<mjg59> doko: I think more of our users use web browsers than printers
<doko> and partly overlapping
<janimo> infinity: sure sleep tight, although I am not sure if I change much in the seeds for beta
<mjg59> Now, admittedly, they're both large groups
<janimo> and thanks
<Diziet> doko: Right.  Excellent.
<Mithrandir> I'm off for dinner.
<mjg59> But going from a situation where webpages look good with default settings to one where webpages are headache-inducing with default settings isn't a move forward
<jsgotangco> yum
<dholbach> Mithrandir: bon apptit
<infinity> janimo: Yeah, if you don't change much, you'll just have tiny CDs, nothing wrong with that.  Faster downloads for a smaller system seems nice.
<janimo> right
<doko> Diziet, mdz: in the case of the PDF we want to have Nimbus a replacement for Adobe, for the browser we do not want that. fontconfig cannot differentiate between these requests AFAIK, so we have to make a decision about our priorities, or configure an application to go with our preferred choice.
<Diziet> mjg59: Don't worry, I'm going to make it so firefox gets to use a different font.
<mjg59> Diziet: Ok, excellent
<Diziet> At least, if I can get it to work that is :-).
<infinity> Diziet: Erm, but firefox isn't exactly the only thing in the distribution that displays HTML...
<infinity> Diziet: Trying to fudge it in firefox preferences seems suboptimal.
<mjg59> Oh, yes
<mjg59> It would have to be at the gecko level, not the firefox level
<Robot101> isn't the real problem that fontconfig tries to natively hint fonts which have crap hinting and should be autohinted?
<mvo> mdz: I opened bug #40017 about the remove progress problem
<Ubugtu> Malone bug 40017 in apt "libapt progress reporting on remove/purge needs improvment" [Normal,Unconfirmed]  http://launchpad.net/bugs/40017
<mdz> doko: for beta, the browser is more important
<mdz> it's about one thousand times more visible than printing
<Diziet> infinity,mjg59: Indeed.  I'm trying to make gecko pass something to fontconfig that fonts.conf could key on.
<infinity> Diziet: If you come up with such a hack, be sure to pass it on to me for Thunderbird, since it doesn't use firefox's gecko (yet).
* ogra wonders why we have that nimbus vs bitstream/djvu discussion every release with the same result 
<infinity> I don't suspect it will for dapper, since trying to make it do so introduces too many frightening other issues.
<doko> mdz: ok, so let's look, if Diziet can come up with something for the browser, I'm preparing a patch to revert that fonctconfig change
<Diziet> infinity: OK.
<mdz> doko: sounds good
<infinity> doko: By "revert" you mean "make it like it was in breezy", or "make it one of the crazy things we've had over the last few months"?
<mdz> I've uploaded the espresso fix
<Diziet> `Revert' means `toggle it again' ? :-)
<mdz> the third remaining blocker is the splash-down / eject prompt breakage on the live CD
<Diziet> Both configurations are IMO pretty damn poor.
<mdz> infinity is ostensibly going to sleep; who else can work on that?
<ogra> Diziet, the breezy one worked very good
<infinity> mdz: That was going to be "as soon as I've slept", unless someone else is less patient and wants to do it right now.
<doko> infinity: "the crazy things", whatever you mean
<Diziet> ogra: Except for printing and pdf viewing.
<ogra> not here
<mdz> infinity: what's your plan?
<Diziet> Err, have you tried doko's testcase ?
<ogra> i can print fine on my breezy box and view pdf's just fine
<ogra> s/test/corner/ ??
<doko> Diziet: if you have postscript printer with built in fonts, it's not a problem
<infinity> mdz: I wanted to sleep on it before I decided which was less crackful.  I can either make usplash trap the signals from init and not die (crack), or patch init to skip killing usplash (slightly less crack).
<giftnudel> who has a post script printer? Most people don't.
<infinity> mdz: The latter is probably less surprising the people who try to kill usplash by hand.
<doko> ogra: poppler in breezy didn't look at fontconfig
<mdz> infinity: I'm not terribly concerned about it getting killed at this point, more about the lack of prompting
<ogra> doko, i never had *any* problems with inkjet printers and fonts
<mdz> infinity: if it gets killed, goes to a text console, and casper prompts there, that's good for beta
<infinity> mdz: The lack of prompting is because it's getting killed, afaik.
<ogra> no matter what font i use 
<mdz> the problem seems to be that it's not cleaning up when it's killed
<infinity> mdz: It dies, but the framebuffer is still painted.
<mdz> infinity: it doesn't switch VTs
<doko> Diziet: does gs use the Nimbus fonts as "builtin fonts", or does it consult fontconfig?
<mdz> presumably init is still talking to a text console somewhere?
<doko> mdz: would you consider ttf-dejavu-2.5 for the beta?
<infinity> mdz: That's a reasonable theory.  It's actually talking to the console we're on (that's why hitting <enter> blindly works)
<mdz> if SIGTERM would arrange for cleanup() to be called, I think that would do
<mdz> doko: why?
<mdz> does it fix a blocker?
<mdz> infinity: in fact, I think an empty SIGTERM handler should do the trick, since it'll result in an error return from select(2), which breaks the event loop
<mdz> I'll test
<doko> a) nice dots for seb128, b) less aggressive kerning c) working ligatures in the browser (I did learn, that browsers are important), test page at http://www.gnome.org/~jamesh/firefox-ligature.html
<infinity> mdz: That should probably be done anyway, so it certainly won't hurt to add it.
<doko> mdz: ^^^
<mdz> doko: after beta, please
<mdz> infinity: switching over to vt8 results in a usable text-mode prompt
<infinity> mdz: I'd prefer a nice graphical prompting to hit <enter>, but if you'd prefer that after beta, your fix sounds correct *anyway*.
<doko> ok
<seb128> doko: http://www.gnome.org/~jamesh/firefox-ligature.html works fine with epiphany atm
<mdz> infinity: the nice graphical prompt is definitely pre-freeze sort of territory; I had no idea this was still broken
<infinity> mdz: That's a neat trick, since usplash is running on vc8 to start with.
<Mithrandir> dholbach: actually, I'm fine with that libgnome fix.  We won't wait for it, though, so whether it makes it in or not is a tad undecided.
<infinity> mdz: Yeah, the freeze snuck up on me, I think.  I'm blaming Easter.
<mdz> infinity: hmm, must be switching to vt1 and back then, as I did when hunting for it
<Mithrandir> mgalvin: any chance of you and heno whipping up a "This is shiny in Beta" page?
<mdz> infinity: not sure why that would restore the framebuffer though?
<dholbach> Mithrandir: does that mean, i shall go on and upload and we see if it makes it or not?
<Mithrandir> dholbach: yes
<dholbach> Mithrandir: right-o
<mgalvin> Mithrandir: i am already on it https://wiki.ubuntu.com/DapperBeta
<infinity> mdz: Oh, hitting vc1, then vc8 *should* repaint the FB, yeah.
<mgalvin> and
<dholbach> Mithrandir: done.
<mgalvin> https://wiki.ubuntu.com/EdubuntuDapperBeta
<mdz> dholbach: upload what?
<mgalvin> https://wiki.ubuntu.com/XubuntuDapperBeta
<Mithrandir> mgalvin: way ahead of me, thanks. :-)
<mgalvin> https://wiki.ubuntu.com/KubuntuDapperBeta
<mgalvin> :)
<dholbach> mdz: http://daniel.holba.ch/ubuntu/libgnome.debdiff
<mgalvin> so hopefully we can will have tour of all the betas :)
<mdz> infinity: ok, this is less trivial then
<mgalvin> np
<dholbach> mdz: a gconf key change to default new users to the shiny new icons
<fabbione> bug #39907
<Ubugtu> Malone bug 39907 in openoffice.org openoffice.org-base "new table wizard crashes on ppc64" [Normal,Unconfirmed]  http://launchpad.net/bugs/39907
<infinity> mdz: It may actually be easier to just not let the silly thing die.
<Mithrandir> janimo: xubuntu published
<janimo> Mithrandir: thank you
* infinity -> back in 10 mins.
<mdz> infinity: if we keep it from dying, we just end up with "Shutting down LVM volume groups" and no prompt, no?
<Diziet> doko: I don't think gs generally consults fontconfig but I haven't checked.  It's possible that someone has added some code to do that.  (Not very well-advised, I would say ...)
<mdz> infinity: oh, casper already tries to talk to usplash
<mdz> assuming reading works, yeah, should suffice to stop it from dying.  I'll give it a shot.
<janimo> mgalvin: the xfce4 version should be 'a svn snapshot very close to 4.4beta1, but not quite beta1' as we're between 4.3.0 and 4.3.90.1 :)
<mgalvin> janimo: ok, thanks i will note that :)
<janimo> mgalvin: but latest thunar and exo
<mgalvin> k
<fabbione> siretart: ping?
<Mithrandir> janimo: you need livefs builds too or isn't that set up yet?
<janimo> Mithrandir: infinity just set them up
<janimo> there's a 386 live image which boots at least :)
<Mithrandir> janimo: nice.  You'll ping me if you need something, then?
<janimo> Mithrandir: sure, thanks
<mdz> infinity: conveniently, the fallback from usplash_write QUIT uses kill -9 already. SCORE
* Mithrandir twiddles his thumbs while he waits for lp to publish espresso
<infinity> Mithrandir: ssh triggering on vivies (sparc) and castilla (hppa) should both work, but I'll ask you to refrain from banging out any hppa builds just yet.  I need to run some tests and such, and I just about passed out 5 minutes ago, so I think that means it's bedtime. :)
<Mithrandir> infinity: ok, I'll wait with hppa, then
<infinity> mdz: If you come up with something interesting, I'll read about it on -changes.  If not, nick hilight me on IRC, so I can catch the "it still needs fixing" in scrollback when I get up.
<Mithrandir> mdz: espresso FTBFS on sparc.  Do we wait for fabbione to fix it or should we just go ahead?
<fabbione> Mithrandir: go ahead
<fabbione> Mithrandir: Kamion did it on the fly for me, we can fix it after beta
<fabbione> Mithrandir: pointless to block 5 arches for me
<wasabi> Hey. I uploaded a package a few days ago, and never got a reject or anything. Wondering what became of it.
<wasabi> Might have been my key expiring... not sure. Need to fix it whatever it is. ;)
<wasabi> It should have gone to new.
<mdz> Mithrandir: go
<infinity> wasabi: 20-to-1 odds (without looking) is that you uploaded to "unstable".
<wasabi> Haha.
<wasabi> Checking. I suspect not. ;)
<wasabi> It's an original package.
<wasabi> Nope. dapper.
<infinity> wasabi: Package?
<wasabi> gapti
<Mithrandir> mdz,fabbione: ack
<fabbione> Mithrandir: thanks tho..
<infinity> Erk.
<infinity> Mithrandir: We want the new brltty, right?
<infinity> Mithrandir: It's in binary NEW.
<Mithrandir> infinity: yes, we want it.  Very much so.
<wasabi> Guess nobody's looked in there in awhile. :0
<Mithrandir> infinity: can you process it while asleep?
<infinity> Mithrandir: Right, I better process it, like, now.
<Mithrandir> infinity: uh, publisher running now, isn't it?
<infinity> Yeah..
<infinity> As of 18 seconds ago.
<infinity> Feh.
* infinity grumps.
<infinity> Mithrandir: Do you know if we want it all in main?  (NEW binaries include brltty-flite, brltty-x11, and a library ABI bump.  The latter is, of course, obvious)
<infinity> Ugh.  And the SONAME bump will require building gnopernicus.
<infinity> (nothing else, thankfully)
<infinity> s/building/rebuilding/
<Mithrandir> infinity: I don't think we want them in main, apart from the library.
<infinity> Mmkay.
<Mithrandir> heno's not around to confirm or deny.
<infinity> wasabi: Your upload ended up in the "failed" queue (ie: LP got horribly confused processing it)
<infinity> wasabi: Not awake enough right now to divine why.  Will do later.
<wasabi> k. thx!
<Mithrandir> mdz: I can't see a new espresso upload yet, didn't the fix work?
<mdz> Mithrandir: 
<mdz> Successfully uploaded /tmp/espresso_0.99.52.dsc to upload.ubuntu.com.
<mdz> Successfully uploaded /tmp/espresso_0.99.52.tar.gz to upload.ubuntu.com.
<mdz> Successfully uploaded /tmp/espresso_0.99.52_source.changes to upload.ubuntu.com.
<mdz> -rw-rw---- 1 mdz mdz 224 2006-04-18 08:24 espresso_0.99.52_source.upload
<Mithrandir> mdz: 0.99.52 was uploaded by Riddell
<mdz> (that's UTC-7)
<mdz> GAR
<mdz> Mithrandir: re-uploaded
<infinity> That bug really needs fixing.
<mdz> s/ed$/ing/
<infinity> (Assuming they were both accepted)
<mdz> they weren't
<infinity> Oh, then never mind. :)
<infinity> (The bug still needs fixing)
<mdz> this espresso bug needed fixing even more
<Mithrandir> infinity: LP also needs a constant supply of speed or something so it'll move quicker.  The two-hour turnaround is killing us.
<Mithrandir> or at least me.
<infinity> Mithrandir: Disregard my previous comments about castilla.  hppa builds look good.  I'm just tweaking little now, and will do an ISO.
<Mithrandir> infinity: excellent
<Keybuk> mdz: biff
<siretart> fabbione: pong
<fabbione> siretart: bug #38409
<Ubugtu> Malone bug 38409 in Debian "creation of snapshots fails unpredictably" [Unknown,Unknown]  http://launchpad.net/bugs/38409
<fabbione> is that lvm2 or udev that needs fixing?
<mdz> infinity: we're completely silly; obviously we can't fix this with a signal handler because sendsigs follows up with SIGKILL for an encore
<siretart> fabbione: AFAIU it is a bug in lvm2, which I currently workaround in udev
<infinity> mdz: Right, so having init special-case processes named "usplash" was the second (and seemingly "saner") option, anyway.
<infinity> mdz: Ideally, a whitelist of sorts, so it's not usplash-specific in the longrun, but for now, I'm happy to hardcode the one string.
<Keybuk> fabbione: arguably udev rules bug
<Keybuk> though lvm really shouldn't be managing its own /dev nodes
<fabbione> Keybuk: did you read all the bug already?
<Keybuk> yeah, and the Debian one
<pitti> Kamion: yay, my first successful espresso install!!! ppc still failed, but that was due to reiserfs again (I'll update the bug)
* infinity wills drescher to speed the heck up, so he can go to bed.
<fabbione> Keybuk: you need to teach me how to read the details of 30 pages in less than 3 minutes
<wasabi> One of these days I should try espresso.
<mdz> infinity: a more beta-friendly option would be to chvt about and end up with a text prompt
<wasabi> It just copy the livecd contents over then do package configuration?
<Keybuk> fabbione: heh.  I learned in school
<Keybuk> they spent weeks teaching us; the basic method is to be given an A4 sheet of paper full of text for just a few seconds, then answer questions based on it
<infinity> mdz: That would probably fit easiest in casper, then, right before it does the text prompting for rebooting.
<Keybuk> you get better each time, until you can read enough of the entire thing to answer any question in only a couple of seconds
<mdz> infinity: yeah, is vt8 hardcoded?
<mdz> infinity: if so; chvt 1; chvt 8 should do the trick just fine
<infinity> mdz: Yes, "usplash -c" goes to vc8
<Keybuk> it's also damned handy for reading people's screens before they flip vts
<fabbione> Keybuk: so why does the mremap fails on page 20? :P
<Keybuk> or for playing Buzz on the Playstation and getting double your friends' scores
<siretart> Keybuk: so you think there is a race in udev somewhere? note that the bug isn't 100% reliable
<Keybuk> fabbione: which one?  there were about 100 of them
<fabbione> Keybuk: btw, i didn't claim it is a udev bug, but what i can see that a udev change triggered it..
<Keybuk> siretart: I don't think there's a udev bug
<fabbione> Keybuk: i was teasing your reading skills :)
<Keybuk> it looked to me like lvm and udev were trying to create the same device at the same time, no?
<fabbione> yes so it seems
<Keybuk> fabbione: we haven't changed udev in ages
<Keybuk> at least, not in that kind of way
<fabbione> Keybuk: well i did never test lvm snapshotting either and we got a bug report...
<fabbione> i am only digging into it
<fabbione> is there any reason for udev to stick its nose in /dev/mapper?
<Keybuk> nope
<Keybuk> other than when I wrote the rules, I didn't know whether or not udev was supposed to manage those
<Keybuk> so erred on the side of caution
<siretart> fabbione: testing something nearly useful, you might be interested in this one: https://wiki.ubuntu.com/SbuildLVMHowto :)
<Keybuk> it was easier to make udev manage them, and stop if it it broke
<Keybuk> than it was to make udev not manage then, and put the rules back
<fabbione> Keybuk: i see...
<Keybuk> it hadn't broken until now :)
<fabbione> Keybuk: well it's a strange case.. i am not blaming anybody for it :)
<fabbione> the only reason why i don't use snapshot is because it's not supported in clustered mode
<Keybuk> should udev just not create /dev/dm/[0-9] *
<Keybuk> and still create /dev/mapper/control ?
<Keybuk> or should it create neither
<fabbione> one sec...
<Keybuk> siretart: drop the NAME="dm/%n", bit from your rule and see if that still works
<fabbione> Keybuk: /dev/mapper/control is created also by the lvm init script
<fabbione> but before we do any change we should make sure that "fixing" the udev rule doesn't break / on lvm
<Keybuk> so how does that work in the initramfs? :)
<fabbione> because i don't remember how lvm is managed in initramfs
<fabbione> yeah we were getting to the same conclusion
<Keybuk> in fact, does /dev/dm/* get created by anything _other_ than udev in the initramfs?
<Keybuk> siretart: after you've changed that rule, update-initramfs -u and see if you can still boot <g>
<fabbione> Keybuk: i can test it tomorrow.
<siretart> Keybuk: so the line should look like this? `KERNEL=="dm-[0-9] *"`
<fabbione> it's not something we need fixed for Beta
<Keybuk> siretart: KERNEL=="dm-[0-9] *", OPTIONS+="ignore_device"
<siretart> ok
<infinity> Mithrandir: Okay, looks like the -x11 and -flite stuff for brltty is extra drivers/plugins, and drags in no universe deps, so in the interest of sanity, I'll send them to main for now, and we can deal with it later.
<Mithrandir> infinity: ok
<siretart> Keybuk: I can still create snapshots with that rule
* infinity prepares uploads for the two packages affected by the SONAME bump.
<wasabi> Zzzzz
<siretart> Keybuk: but I can't reboot the system right now, I'm not at home currently. I can test this in a few hours when I get home
<fabbione> Keybuk: the lvm hook is called in local-top (i assume before mount /) and that can probably be fixed easily.. but let me test before we speculate for hours :)
<Keybuk> siretart: ok, let the bug know how it goes then
<siretart> ok
<Diziet> *sigh*   I forgot to prime my ccache this morning.
<fabbione> Diziet: and?
<fabbione> did you run out of disk space?
<mdz> infinity: I implemented the workaround, but it doesn't work, and I don't know why
<mdz> I still get the graphical framebuffer
<Diziet> fabbione: No, I have to wait two hours.
<infinity> mdz: Awesome.  Then you may have to leave it to me when I'm in my own timezone. :/
<mdz> hmm, I wonder if maybe chvt isn't in cache
<Tonio_> hello all
<infinity> mdz: Or ask mjg59 to wax clever about it.
* infinity heads to bed, finally.
<fabbione> Diziet: hint.. slam the ccache on a partition on its own.. it's faster to umount mkfs mount than to do any other operation on that directory
<Diziet> fabbione: That's not the problem.  The problem is that it's not primed so I actually have to wait for ff to build.
<fabbione> oh primed as do pre-builds before you wake up?
<fabbione> gotcha
<fabbione> Diziet: btw.. new FF crashes on sparc..
<fabbione> Diziet: BusError on NSGetModule()
<fabbione> there is a  debian bug open too
<fabbione> but i can't remember the name
<fabbione> it was working not too long ago
<mdz> mjg59: around?
<Diziet> crashes> Joy.
<Diziet> No Java involved ?
<Diziet> (or other random crud found under rocks?)
<mjg59> mdz: Hi
<ogra> Mithrandir, did you do a edubuntu livefs build already ? 
<ogra> (i see an 18.1 in the logs)
<doko> mdz, Diziet: I'm away for the next hours, I've put the fontconfig update on chinstrap:~doko/uploads/
* fabbione -> dinner and 24.. bbl
<Diziet> doko: If I upload a fontconfig I'll be sure to bump the version number :-).
<doko> Diziet: ? 2.3.2-1.1ubuntu8 is the version in the archive ...
<janimo> soumyadip: have you checked the xubuntu isos to see if they have acceptable indian lang support by default?
<soumyadip> janimo, no, unfortunately, I've not been able to test the latest flight 6
<janimo> soumyadip: np, just curious
<soumyadip> janimo, however, language selector still does not install all required packages, especially IMs
<janimo> soumyadip: in xubuntu or ubuntu too?
<soumyadip> janimo, yup
<janimo> if only xubuntu I'll need to have a look
<soumyadip> janimo, I've apt-get upgraded last weekend
<janimo> soumyadip: if you find such issues please file bugs in LP and assign to xubuntu-team
<janimo> thanks
<soumyadip> janimo, ok
<soumyadip> incidentally, has anyone here got scim to work with OO2 ?
<mdz> hmm, tricky
<mdz> during startup, when usplash is killed, we want it to switch back to the original vt when it started
<mdz> during shutdown, we want it to stay on the same vt, because that's where the console i/o is
<soumyadip> well I got it to work on a friend's lappy, but unfortunately, I don't have access to that lappy right now, to be able to replicate the steps
<infinity> mdz: (Yes, I'm still not asleep, argh)... The solution to that (which solves another bug Mithrandir has in his initramfs stuff) seems to be to stop having it switch VCs in the first place, and just run it on VC1.
<Diziet> doko: What I mean is that if I invent an upload it'll be ubuntu10 so that there's only one ubuntu9 floating about - yours.
<infinity> mdz: In a short discussion between me, Mithrandir, and mjg59, this seemed to be a sane and rational thing, and we couldn't really come up with a great argument to keep it on vc8, as it is now.
<mdz> infinity: not very beta-friendly, unfortunately
<infinity> mdz: No, not terribly.
<mdz> infinity: it looks to me like by the time usplash gets killed, vt switching no longer works
<mdz> neither by keyboard or by ioctl
<mdz> I don't know why
<mdz> infinity: can you think of another clever way to get the text restored?
<mdz> maybe switch fb modes or something?
<infinity> Not off the top of my head, but I've not dug deep into the scary that is bogl.
<mdz> the test cycle for this sucks
<infinity> Switching fb modes is a dangerous proposition.  Should never be attempted automagically.
<mdz> I don't even understand why switching VTs restores the text
<infinity> Because the kernel is redrawing what lives on that VC.
<mdz> why does the text live on it, and not the graphics?
<infinity> bogl doesn't write to any particular virtual console, it just write to "the framebuffer".  This can be evidenced it you daemonise it, and watch it keep blindly (over)writing after gdm loads.  (hint: don't do that)
<infinity> So, switching to another VC makes the kernel write that VC's contents to the framebuffer, then swiching again does the same thing.
<infinity> The VC's contents is the text, not usplash.
<mdz> so if usplash is running, and I switch to vt1 and back to vt8, it will clobber usplash?
<infinity> Well, only because bogl detects VC switches and kills itself.
<infinity> If it didn't do that, it would keep writing to your framebuffer, regardless of which VC you were on.
<infinity> If usplash dies (or kills itself), then yes, any VC switch will redraw the framebuffer with that VC's contents, and the usplash image goes bye-bye.
<mdz> there must be some other way to tell the kernel to redraw the screen
<infinity> Basically, you have to sperate the framebuffer (writing to video RAM) from the virtual console (kernel text I/O, which can print to many outputs, serial, framebuffer, etc), and it makes more sense in your mind.
<infinity> And yeah, there surely are other ways to tell the kernel you'd love the framebuffer to be repainted with the current VC, but damned if I can think of one off the top of my head.
<mdz> reset via terminal escape codes doesn't seem to do the trick
<slomo_> libbrlapi1 conflicts with libbrlapi... is this a known bug?
<infinity> slomo_: I doubt it's a bug at all.  The two packages that need to transition are in the queue already.
<infinity> slomo_: Or do you mean "they have file overlaps, but don't declare a 'Conflicts'"?
<infinity> If that's the case, then no, I didn't notice.
<slomo_> infinity: exactly that ;)
<slomo_> they both contain /lib/libbrlapi.so.0.4
<infinity> Right.  Fixing now.
<slomo_> dpkg: error processing /var/cache/apt/archives/libbrlapi1_3.7.2-2ubuntu1_powerpc.deb (--unpack):
<slomo_>  trying to overwrite `/lib/libbrlapi.so.0.4', which is also in package libbrlapi
<slomo_> ok, thanks :)
<lemsx1> infinity: what initramfs bug with usplash are you talking about? i have a bug in an app we are writing that when unicode_start switches the keyboard to uincode it stops the boot process completely. the app is started from initramfs and keeps listenting for keyboard events ESC and F2
<KaiL> slomo, even only contain that file ;)
<infinity> lemsx1: You do unicode_start in the initramfs?
<mdz> looks like blank/unblank should work
<infinity> slomo_: Fix uploaded, thanks.
<slomo_> infinity: np :)
<lemsx1> infinity: no, unicode_start is called by keymap.sh at rcS.d
<lemsx1> infinity: but something strange happens then... the boot process stops completly and my app is just waiting... if i press ESC (to exit the app) then ctr+alt+f2 and press ENTER, the boot process continues
<lemsx1> infinity: i have NO idea how to fix this... i'm thinking it's related to the keyboard being switch to unicode (unicode_stop does the same thing)
<infinity> lemsx1: Could be trickier.  unicode_start and unicode_stop cycle through all the VCs on the system.  That may break your app's assumptions, if it's keeping open file descriptors on a certain VC and can't deal with the switching.
<infinity> lemsx1: At any rate, I'm far too zonked to think much about it, but if you happen to track down anything that's sensible enough to make a bug report of it, I'll be happy to look at it.  Otherwise, catch me at a less busy time (ie: after beta release), and we can chat informally about what's breaking, and maybe why.
<lemsx1> infinity: thanks for the hints (and help offer). i closed all unneeded file descriptors and left only stderr and a named pipe. we will chat later about it then when you are less busy ;-)
<mdz> doko,Diziet: what's the resolution on fonts for tomorrow morning?
<mdz> fixed espresso is accepted, and I have a usplash-vs-casper workaround in hand
<_mvo_> mdz: should I upload a new apt too (with the wording fixes)?
<mgalvin> is espresso supported on edubuntu?
<mdz> _mvo_: sure, why not
<ogra> mgalvin, supported yes, branded, no
<mgalvin> ogra: k thanks
<ogra> (not sure if we manage to get a branding ready)
<Diziet> mdz: Well, I haven't got my fix working.  I have to delve into pango too it seems.
<Diziet> So I think we should go with the reversion of the reverted reversion.
<Diziet> (Ie, make the browser look good and PDFs bad.)
<Diziet> For the beta.
<mdz> Diziet: ok, please go ahead with that fallback then
<Diziet> I think it's just duploading doko's change.  Let me check
<Diziet> Yes, according to the changelog.  Should I review the debdiff or just upload it ?
<KaiL> the website for dapper beta mentiones network-manager? I thought, it got removed?
<mdke_> KaiL, which website is that?
<KaiL> https://wiki.ubuntu.com/DapperBeta
<mdke_> that's not yet been moved to the website
<mdke_> you can submit comments to the author, as he prepares the document
<Diziet> debdiff looks OK, I've uploaded it.
<mroth> when are the CD images going up?  I'm going to torrent them from work to help with the bandwidth, until our IT guys make noise at me anyhow
<wasabi> This whole "select your city" thing in installers needs to follow the dodo
<dholbach> the DapperBeta page has a screenshot with xscreensaver in the menus instead of gnome-screensaver
<mdke_> dholbach, see above ^^
<KaiL> dholbach, and with the old icons
<dholbach> ok ok
<KaiL> ohm, that menu-screenshots overall look like being from breezy, or?
<KaiL> at least the first 2
<mdke_> KaiL, again, there is little point discussing it in this channel, and adding to the noise while the developers are trying to work. The page says how to contact the authors. Feel free to do so
<ogra> dholbach, i have a fix pending for the screensaver menu mess, but there is a bug in gnome-menus that needs to be fixed before
<dholbach> ogra: what's that?
<ogra> dholbach, a menu override file, stolen from redhat, but our gnome-menus (or menu-xdg, not sure) ignore it unless you change the default settings in preferences.menu to be in another order... seb128 wanted to investigate that further
<dholbach> what is that patch for?
<ogra> the patch is for g-s-s to install the menu override file 
<ogra> but its useless unless the gnome-menu stuff is fixed
<dholbach> ok, what does the menu override do?
<dholbach> i don't quite understand
<ogra> dholbach, 
<ogra> <Menu>
<ogra>   <Name>Preferences</Name>
<ogra>   <Exclude>
<ogra>     <Filename>screensaver-properties.desktop</Filename>
<ogra>   </Exclude>
<ogra>   <Exclude>
<ogra>     <Filename>gnome-screensaver-properties.desktop</Filename>
<ogra>   </Exclude>
<ogra> </Menu>
<ogra> it adds a file called gnome-screensaver-hide-xscreensaver to /etc/xdg/me3nus
<dholbach> ok i see
<ogra> so xss is hidden from the menu as long as gss is installed
<ogra> the odd thing we discovered while examining why it doesnt work in our menu system, was that you had to change the order of directives in our (upstream default) preferences.menu 
<ogra> so it seems to lie deeper in the parser or something
<dholbach> yeah gnome-menus is a bit picky about that, I discovered
<ogra> it shouldnt be, thats the point seb128 made
<ogra> wow, NM crashes noisy on the liveCD
<highvoltage> who's that ubuntu guy who looks like "Where's Wally"'s name again?
<mdke> highvoltage, ploum
<highvoltage> that's it, thanks :)
<Tonio_> slomo: ping ?
<slomo_> Tonio_: pong
<Tonio_> slomo: 3 days and no response from Michael Biebl...
<Tonio_> I will wait a bit, but if still no response, I'l not going to wait for dapper+1 :)
<slomo_> Tonio_: hehe he was probably on holidays or something :)
<Tonio_> slomo possible yes :)
<slomo_> i didn't saw him on irc too
<Tonio_> slomo_: let's wait a bit more...
<ogra> Mithrandir, usplash still times out for me on powerpc live
<ogra> (right after readahead, "Preparing restricted drivers ..." is the first thing i see in console mode
<ogra> )
<ogra> apart from that, a completely broken NM on all arches and the regression in the screensize detection edubuntu live looks fine
<crimsun> libbrlapi1 is missing a Replaces & Conflicts on libbrlapi
<crimsun> err, thanks for not reading dapper-changes, Dan
<mdz> ogra: why are you shipping NM?
<mdz> ogra: edubuntu should stay in sync with ubuntu for infrastructure
<ogra> hmm, because i lag on seed merges ?
<ogra> sorry
<mdz> please merge and upload edubuntu-meta
<ogra> yep
<ar0x> hi *
<mdke> infinity, awake?
<ar0x> I just saw that the ubuntu projet was participating to the SoC 2006
<ar0x> is there a list of potential project on ubuntu or not ?
<j^> i have a question regarding implicit linking with libtool, .la files and not working linking; since dependency_libs are not added by the versoin of libtool in ubuntu/debian, whats the right way to do this?
<mdke> ar0x, I haven't seen any announced. stay tuned to the -devel mailing list, I'm sure someone will post it when it is ready
<ar0x> ok, thanks
<ar0x> in fact, I already helped a bit on the ia64 (itarium) port last year with others students of my school (the ESIEE near Paris)
<ar0x> but the "project" was dropped a few month after its begin :(
<zyga> does anyone know of publicly available devel shell on itanium (like sourceforge compile service?0
<ar0x> I don't know
<ar0x> we used to work on machine lended by school
<zyga> I'm trying to build itanium box for a few months but itanium parts are rare on local-ebay-like-service (abit better than ebay)
<zyga> I'm bidding on two cpu's now but I'll still need a mobo :-)
<ar0x> :)
<zyga> ebay has some nice parts but way out of my price range ;P
<Kamion> ogra: no espresso branding will be needed for Edubuntu
<Kamion> mdz: fixing espresso on sparc is trivial if you want me to (debian/rules update which Riddell apparently forgot, upload)
<Kamion> mdz: thanks for the gnome-session-save fix; do you have a bzr branch I can merge, or shall I do it by hand?
* Kamion pulls from Riddell in preparation
<ogra> Kamion, wow, cool, i'd have expected to have to touch at least the artwork 
<Kamion> ogra: I don't expect so; I've made an effort not to talk about Ubuntu
<ogra> thats really great :)
<Kamion> ogra: at worst you might theoretically want a different icon, but it's not particularly Ubuntu-ish as distinct from Ubuntu derivatives
<Kamion> what's the CD status? any cdimage tweaks needed?
<ogra> i havent tried install yet
<ogra> live was fine so far apart from the known breakage
<Kamion> hmm, I see there are some cowboyed diffs on cdimage at least
* Kamion merges
<mdz> Kamion: I didn't use bzr but can mail you a patch
<Kamion> mdz: thanks, that would be good
<mdz> Kamion: we're faced with a bit of a difficult choice at this point
<mdz> Kamion: mailed
<fabbione> Diziet: sorry.. no java.. it's sparc specific the buserror
<mdz> Kamion: anyway, so of our 3 blockers, one is fixed (the patch I just mailed) and two are worked around (usplash and fontconfig)
<mdz> Kamion: I can live with the fontconfig workaround, but I'm torn about usplash
<mdz> I see at least 3 options there
<mdz> 1) release with the workaround (drops back to text mode at sendsigs), 2) revert the workaround and let usplash stay on the screen, frozen, at sendsigs, and change casper not to prompt about removing the CD, or 3) throw in my works-for-me solution which makes splash-down work properly (touches sysvinit, usplash and casper)
<mdz> 1) gives us a cosmetic problem (though a glaring one that is likely to be bandied about in reviews), 2) gives us a usability problem, 3) takes a risk
<Kamion> ugh, hmm
<ogra> but we have still plenty of time if it needs fixage 
<ogra> i'd go with 3
<Kamion> I wonder how much reviews will actually bandy about that cosmetic problem; it's only on shutdown of the live CD, and is similar to the text on startup
<mdz> no, it's on shutdown of the installed system as well
<mdz> or else I'd agree with you
<Kamion> jordi: man page source may not be UTF-8, except for some CJK cases that are handled specially; you have to recode to ISO-8859-1
<mdz> I suppose 4) might be to adapt the workaround to behave differently on the live CD vs. the installed system
<mdz> would involve usplash growing a test for whether it's running under casper
<Kamion> mdz: just to clarify, the espresso "Install System Permanently" -> "Install" change is for final, not beta, right?
<mdz> Kamion: yes
<mdz> no point in breaking all of the translations for beta
<mdz> Kamion: the concern is only that the CD covers match the desktop, and the CD cover decision had to be made
<Kamion> I don't think there are any translations of that string
<Kamion> the desktop file is as yet untranslated
<Kamion> and the string change in the window title was very recent
<mdz> there are translations in the debian/po po files
<mdz> I wasn't sure whether those ended up in the mo file or no
<mdz> not
<Kamion> I think there's a better way to do the SUDO_UID thing FWIW (see poke_gnome_screensaver), but not worth rocking that boat for beta
<Kamion> hmm, you're right, I may be dense
<mdz> Kamion: it's actually $HOME which seems to matter; sudo -H was just the most expedient solution
<mdz> since it probably ought to run under the live cd user anyway
<Kamion> oh, no, if you look closely they're all fuzzy translations
<Kamion> just autogenerated crap
<mdz> if there are no translations, and we need to wait anyway, we might as well make the change
<Kamion> ok, I'll sort out merge mechanics
<Kamion> you still want the CD label change done, right?
<mdz> yes, please
<Mithrandir> ogra: I didn't think I had, no.
<ogra> Mithrandir, ? you had what ? 
<Mithrandir> ogra: built another edubuntu livefs
<mdz> ogra: why is wpasupplicant in standard in edubuntu, but in minimal in ubuntu
<ogra> hmm, but there was a 18.1 from ~14:30 UTC, so probably infinity has
<ogra> mdz, no idea, infinity made the merge i'll look into it ...
<Kamion> it was only shunted to minimal this morning
<Kamion> because it was waiting on an LP fix that happened last night
<mdz> Kamion: yes, but I asked ogra to do a merge less than an hour ago
<ogra> ah, so the merge wasnt recent damned
<Kamion> ah
<mdz> I am starving, what's open late near south ken?
<ogra> i just saw infinitys NM related merge and thought it was ready ... 
<fabbione> mdz: are you at kk or the other hotel?
<ogra> mdz, btw, does you being in london mean we'll see you in wiesbaden ? 
<mdz> I am at the fieldwave office
<mdz> ogra: no
<ogra> :/
<fabbione> mdz: yes i got that..do you plan to spend the night at the office?
<mdz> fabbione: not if I can help it
<fabbione> mdz: there was a nice resturant close to the hotel where we were for the soyuz sprint
<fabbione> but i guess you are not going that direction.. are you?
<mdz> no
<mdz> I plan to get something close by and come back here
<mdz> we are not finished yet
<fabbione> there was something like a McDonald close to the train station, but i guess that doesn't work either for you
<zyga> guys
<zyga> I have an unusual request
<fabbione> zyga: my bank account is... 
<zyga> me and my fiance are getting married soon and we are looking for a nice place to our honeymoon in july
<dholbach> I'd love to know what everybody thinks about, when they try to remember when they heard that sentence before. :-p
<zyga> 1) not too hot/expensive/far from E
<zyga> EU
<mdke> congratulations
<zyga> 2) a nice place/country to go for one week
<fabbione> zyga: south pole.. it's not too hot / it's expensive / it's far from EU
<fabbione> and you can dance with penguins..
<zyga> fabbione: bzzz, not too far from EU
<mdke> zyga, italy
<ogra> croatian adria
<zyga> mdke: isn't italy very hot in summer?
<fabbione> zyga: yes
<fabbione> it's hot
<fabbione> Russia
<sm> south west of ireland, nice and cool
<zyga> we thought about st petersburg
<zyga> really beautiful city, very romantic too :)
<fabbione> dude..
<mdke> zyga, not _that_ hot. when are you going?
<fabbione> mdke: he said july
<zyga> mdke: july
<mdke> ah, missed that
<zyga> we get married on july the #1
<zyga> s/../#1 of july/
<ogra> wow, on release day
<fabbione> zyga: are you going in honeymoon with a dapper cd?
<mdz> zyga: the only ubuntu forum where this would be appropriate is sounder, where by definition nothing is off-topic
<Lure> ogra: we slip for another month?
<ogra> Lure, ouch, blind me
<Lure> ;-)
<zyga> fabbione: heh, no - no computers allowed
<zyga> fabbione: both of us are deep in IT and we have enough computers to be fed up with them on our honeymoon
<mdz> zyga: ...
<zyga> mdz: ack
<mdz> zyga: thanks, we're in a bit of a crunch here
<dholbach> #ubuntu-offtopic might be a good choice too
<mdz> dholbach: oh, I didn't know about that
<ogra> thats there since ages :)
<zyga> thanks dholbach, mdz
<dholbach> mdz: I'm not often in there either, I just observed it being recommended. :-)
<ogra> gah, what a mess 
<ogra> when was a server seed added to ubuntu
<dholbach> ogra: a week ago?
<ogra> gah
<Kamion> I mailed ubuntu-devel@ about it
<mdke> it was posted to the mailing list, I seem to remember
<Kamion> you can harmlessly merge it
<ogra> i cant
<ogra> it clashes with edubuntu-server
<Kamion> oh, edubuntu has a server seed
<Mithrandir> mdz: I believe the tool you're looking for wrt killing all but a few select processes is pkill.  It'd need to be taught about pid matching, though.
<Kamion> just resolve the conflicts back to the edubuntu version then
<ogra> yes, i'm just trying to figure out why *all* my seeds have conflicts suddenly
<Kamion> arguably the semantic clash is a bug in itself, and we should call one or the other something different
<ogra> i was first !
<ogra> :)
<ogra> (i really dont care :) )
<tseng> hm why does the new update icon make me think "reboot"
<mdz> Mithrandir: a) it doesn't support the right boolean operations (we need X && !Y), b) it's in /usr, and c) I already fixed killall5
<tseng> update-manager tray icon
<tseng> to be clear
<Kamion> mdz: CD label change done for whenever the next rebuild is
<Kamion> doing espresso change in a moment, then probably going to bed, so shout if there's anything else urgent
<mdz> Kamion: I'd like to have a new build with the espresso and usplash fixes
<mdz> (the ones which were uploaded a while ago; I'm not fussed about the change you're making now)
<mdz> espresso, usplash and fontconfig even
<mdz> I think they should all be built by now
<mdz> argh, the new brltty causes a conffile prompt on upgrade
* Kamion will try to do a livefs build run
<Kamion> but I'm exhausted and really need to go to bed soon or I can't be productive tomorrow, so I may need to fall over in the middle
<Kamion> I'll let you know if so
<mdz> Kamion: is it possible to queue a CD build to run when the livefs bulid completes?
<Kamion> not particularly easily, unfortunately
<Kamion> it's a twisty maze of ssh
<mdz> my livefs build script allowed for that
<Kamion> send me it?
<Kamion> I've already started the livefs build though, so too late for this time
<mdz> sure, but it's likely not to be up-to-date with the latest machine names and who knows what else
<Kamion> I can queue a CD build with at, I guess
<mdz> it's been a while
<Kamion> I can cope with that much
<mdz> will there be a daily build overnight?
<mdz> (mailed)
<Mithrandir> mdz: no, crontab's disabled.
<Mithrandir> Kamion: I can watch the progress and start a live cd build when it's finished.
<jdong> when init launches daemons, do they obey /etc/pam.d/common-session?
<jdong> I'm trying to set a system-wide 027 umask...
<jdong> for /var/log and such
<Mithrandir> jdong: you can't count on it, no.
<jdong> Mithrandir: how would you recommend I do it, then?
<Mithrandir> jdong: I wouldn't. :-)
<jdong> I basically want to keep prying eyes off /var/log
<jdong> and private /home's
<jdong> homes seem to obey libpam-umask in common-session pretty well
<jdong> but I've yet to test logs
<Mithrandir> libpam-umask doesn't work properly with gdm, for instance.
<Mithrandir> (but that's a gdm bug)
<jdong> hmm
<jdong> is there any reliable way of doing a system-wide 027?
<mdz> jdong: unless you're doing this in a package for Ubuntu, it would be better to discuss it elsewhere
<mdz> we're working on the beta release here
<jdong> mdz: sorry for disturbing you guys. I'll take this discussion elsewhere
<mdz> thank you
<Mithrandir> Kamion: did you set up an at job for live cd builds or should I do it when it's done?
<Kamion> Mithrandir: I haven't yet; I would love you if you could monitor the livefs build process and do a CD build at the end
<Mithrandir> Kamion: I'll do that.  Go crash now.
<Kamion> thank you
<mdz> Mithrandir: what will the build number be?  I'll send a call for testing
<mdz> 20060418.2?
<mdz> or 20060419?
<Mithrandir>  20060418.2 unless it goes on until tomorrow
* ogra grrs at bzr 
<ogra> this push takes forever
<jordi> Kamion: thanks, I eventually figured out
<mdz> Mithrandir: probably best to wait until one of us has sanity-checked it anyway
<Mithrandir> mdz: I can test the i386 version in vmware here, but I can't do an install just now.
<Mithrandir> mdz: we might want to just roll the image and call it a day and test it first thing tomorrow morning
<mdz> Mithrandir: agreed, I'm going to go search for food
<mdz> be back in the morning
<Mithrandir> see you around.
<mdke> Riddell, any chance you've got time for a swift kubuntu-docs upload? We've changed some strings and need to get the pot file to rosetta
<Riddell> mdke: hmm, kindae close to beta
<Riddell> but I do still have another upload to make so I guess that should be ok
<mdke> Riddell, hang on a tic, lemme ask carlos something
<Riddell> mdke: when was the last ubuntu-docs upload?
<mdke> Riddell, if LP works propely, you might be able to just upload the pot file through the web interface, without uploading the whole package
<mdke> Riddell, sunday?
<Riddell> mdke: but then rosetta and the archive are out of date
<mdke> Riddell, true, I don't think that is a big deal, they will resync with the next upload. Up to you
<Riddell> I'll do it
<mdke> Riddell, thanks
<Riddell> one of these days I'll do a docs upload when I'm not about to go to sleep or something and I'll take the time to just script it
* Mithrandir spins new live cds.
<mdke> Riddell, heh :) appreciate it
<Riddell> Mithrandir: ping?
<Mithrandir> Riddell: yes?
<Riddell> Mithrandir: I'd like to get new kubuntu live fs builds and CDs once the packages I just uploaded go in
<Riddell> Mithrandir: is it sensible to enable the cron jobs again so they get done by the time I wake up?
<Mithrandir> Riddell: I can do them first time in the morning and since I'm a TZ ahead of you, they should be there when you get around.
<Riddell> Mithrandir: yep, that's good for e
<Riddell> me
<Mithrandir> Riddell: or ask infinity to do them when he wakes up in a couple of hours.
<ogra> Mithrandir, same goes for edubuntu
<ogra> i'm just preparing a -meta upload
<Mithrandir> ogra: 'k.
#ubuntu-devel 2007-04-16
<RenatoSilva> are you ubuntu developers???
<Hobbsee> RenatoSilva: no.  we just sit here and pretend.  duh
<Burgundavia> some of us are, some of us aren't
<Burgundavia> Hobbsee: ;)
<Hobbsee> hiya Burgundavia, how's it going?
<Burgundavia> back from Texas and sick
<Hobbsee> awww
<RenatoSilva> and sapdfl, where does he is?
<Burgundavia> umm?
<Hobbsee> RenatoSilva: what did you want?
<RenatoSilva> Hobbsee: do I incomodate you, because I'm not ubuntu developer, what kind of talk may I have here??
* Hobbsee wonders what incomodate is
<Burgundavia> RenatoSilva: yes, you can talk here, as long it is on topic
<RenatoSilva> i'm bad in elglish, sorry
<Burgundavia> if you have a bug report, please file it on Launchpad
<Burgundavia> a suggestions for a new feature is a spec
<Hobbsee> ah.  didnt know that word.
<bhale> you might get more help in #ubuntu-br
<RenatoSilva> to "incomodate" is to make something that make someone unconfortable, something non-suitable 
<RenatoSilva> i dunno the correct verb
<RenatoSilva> Burgundavia: about what can i talk?
<Burgundavia> see the topic
<Hobbsee> RenatoSilva: see the /topic
<RenatoSilva> Hobbsee: it's unclear
<Hobbsee> RenatoSilva: right, what did you want to talk about?
<Hobbsee> this channel is for the development of ubuntu, not support
<RenatoSilva> Hobbsee: let's test if my talk is or not on topic
<RenatoSilva> Hobbsee: i want to talk about winmodem support (but don't give me wiki pages, launchpad etc. i'm not a dummy user!!!!!)
<RenatoSilva> Hobbsee: may I?
<bhale> the topic is very clear on this not being for support
<_ion> This discussion has already been 30 lines. :-)
<jdong> _ion: the discussion about discussing?
<_ion> Yeah, that.
<_ion> Metadiscussion
<bhale> if you want to develop more support for winmodems you want to specify it in wiki/launchpad
<jdong> premetadiscussional planning
<bhale> no one called you a dummy
<Hobbsee> RenatoSilva: people here are concentrating on releasing feisty.  winmodem support will not change for feisty, at this point.  i suspect you're out of luck, at least for the next couple of weeks.  what you really want to do is see the ubuntu-devel mailing list, as the dialogue goes on there
<RenatoSilva> _ion: metadiscussion? rsss!!!
<RenatoSilva> Hobbsee: ok, but can you let me make about 2 paragraph-comment about it?
<Hobbsee> if you like, but it probably wont do much, seeing as the devs you're looking for arent ehre, and everyone's busy working on feisty, bug fixing...
<_ion> One could find it humorous that his screen is 75% full of discussion pretty much about can i please make a two line comment about something. :-)
<RenatoSilva> Hobbsee: Jesus! Just let me say, I don't want support, neither to relate a bug
<Hobbsee> RenatoSilva: i realise that...
<RenatoSilva> _ion: ok, so let's go!!! I'll tell you right before you kick me off :D
<bhale> please don't yell.
<jdong> go ahead and say what you want to say....
<RenatoSilva> Fortunately most of I want to say is in this page I've found right today:
<RenatoSilva> https://wiki.ubuntu.com/OutoftheboxWinmodem
<RenatoSilva> I dunno if you fully know that content
<RenatoSilva> Additionaly I want to say that
<RenatoSilva> Here in Brazil, which on the countrary of most of you can think, it's not that whom Buenos Aires is capital...
<RenatoSilva> Well, here...
<RenatoSilva> it's a very important issue, considering the resolution of bug #1
<ubotu> Malone bug 1 in jl "Microsoft has a majority market share" [Critical,Confirmed]  https://launchpad.net/bugs/1
<Hobbsee> RenatoSilva: winmodem support so far has not been done, not because of lack of interest, but lack of active developers.  if you're interested in coding it, or finding a team of people to code it, then that would be great.
<RenatoSilva> there's here a GREAT demand for this support, and it will certaintly spread even more the use of ubuntu around our *million* of windows users
<Hobbsee> RenatoSilva: but waving the magic wand and hoping that it'll be done for you doesnt always work
<Hobbsee> seeing as there are limited resources, and lots of worthy projects that the ubuntu developers want to work on
<RenatoSilva> Hobbsee: this is what i wanted to say
<Hobbsee> RenatoSilva: great
<RenatoSilva> Hobbsee: I want to know I what I say, including Brazil's scenario, is something new to you
<jdong> RenatoSilva: I think most of us are aware that many many countries still run primarily dial-up
<RenatoSilva> Hobbsee: if it's new, only to make you know this, so that you can use it as strategic information, is enough to me
<Hobbsee> RenatoSilva: it's not new.  like i say, it's not a lack of interest in the project - it's a lack of developers.  seeing as most of them arent paid, we cant force them to do particular stuff, unless they're interested.
<RenatoSilva> jdong: what do you mean by aware? volunteerly aware?
<RenatoSilva> Hobbsee: great!!
<jdong> RenatoSilva: aware, as in most of us already knew what you claim. there is nothing earth-shattering
<RenatoSilva> Hobbsee: thank you for useful information, i didn't noticed that!
<jdong> RenatoSilva: winmodem support is indeed important but there do not appear to be a massive rush of developers interested in getting it coded
<Hobbsee> wow, there's even a bounty for doing it, it looks like
<jdong> and work is indeed going into it....
<jdong> https://wiki.ubuntu.com/MainInclusionReportSlModem
<jdong> there are MIR's filed for SmartLink modem support
<RenatoSilva> jdong: sorry for the bad English
<jdong> no sweat :)
<RenatoSilva> jdong: so, are you very interested on it, but limited, is that?
<RenatoSilva> Hobbsee: what about the page I've passed?
<Hobbsee> RenatoSilva: looks good. same answer as above, though
<jdong> RenatoSilva: I would be interested in doing it, if I have (1) the time (2) A variety of softmodems to test on
<RenatoSilva> Hobbsee: it's related to a blueprint, it's a official concern, but the limitation is missing of developers? right?
<ajmitch> jdong: how about hardware documentation?
<Hobbsee> RenatoSilva: pretty much
<jdong> ajmitch: well there are already several drivers out there that are just not preconfigured by default :-/
<RenatoSilva> Hobbsee: thank you very much!!!!
<jdong> ajmitch: I think Ubuntu _can_ do better integrating currently available softmodem drivers....
<jdong> but yeah, it is work
<jdong> and going to be full of hardware black magic
<RenatoSilva> Hobbsee: so if you want, think in Brazil when considering the importance assigned to this "bug", maybe becoming more mainstream makes more developers to be interested on it
<Hobbsee> RenatoSilva: maybe, yes.
<RenatoSilva> Hobbsee: I'm very sad of not being able to help, I thought it was missing of attention with us, but missing is of programmers, and I did not knew taht
<jdong> most missing functionality is due to a lack of infinite developer resources :)
<RenatoSilva> Hobbsee: i think I could make some work onto Martian driver, because I've installed it on my PC and am using it right now
<RenatoSilva> jdong: I did not know
<RenatoSilva> Hobbsee: I've wrote a Portuguese tutorial, and I think I could build a .deb package for an installation out of the box for Lucent/Agere modems, but the problem is exactly time!!!!
<_ion> and the amount of exclamation points.
<RenatoSilva> Hobbsee: unfortunately, my contributtions can be only spporadic, little-time tasks, such as this tutorial I've wrote
<_ion> They probably should go to linux-image or linux-restricted-modules.
<jdong> yeah, there are a lot of time issues involved. Time it takes to put together a high-quality support for hardware ina a distro, and also the time and dedication it takes for years after to make sure it is kept maintained
<RenatoSilva> _ion: sorry!!!!!!!!!!!!!!!
<RenatoSilva> _ion: :D
<jdong> it's little good if it's just put in there and the author disappears
<RenatoSilva> jdong: put what? code or docs?
<RenatoSilva> jdong: should exists 'maintainers'
<jdong> RenatoSilva: code and docs....
<jdong> but the question is _who_ are these maintainers?
<jdong> they do not magically appear out of nowhere
<jdong> it's a major responsibility to undertake
<RenatoSilva> jdong: it should exist maintaners separated specifically to maintainin stuff
<RenatoSilva> jdong: good code dispends the original programmers!!!!
<RenatoSilva> but...
<RenatoSilva> next page
<RenatoSilva> do you know MArtian driver??
<jdong> You mean the Lucent/Agere Mars chipset? (1648)
<RenatoSilva> jdong: no, the driver for it
<RenatoSilva> jdong: i think it's easy to package it as a .deb and put it into hardware detection in the install process
<jdong> ltmodem, right?
<jdong> linux-restricted-modules-2.6.20-12-386: lib/linux-restricted-modules/2.6.20-12-386/ltmodem/ltmodem.mod.o
<jdong> it seems to be in the -386 kernel
<RenatoSilva> i forgot, also I'd like to help with gnome-ppp that is still too simple
<jdong> but not in the -generic kernel
<jdong> I have no idea why...
<RenatoSilva> jdong: it's an alternative driver
<ajmitch> jdong: binary-only driver that can't handle SMP, iirc
<jdong> ajmitch: ah, ok, didn't know that :)
<ajmitch> there's at least 1 or 2 like that
<RenatoSilva> jdong: is that a thing to verify?
<jdong> RenatoSilva: no, I am not familiar with that driver...
<jdong> I have seen ltmodem before
<RenatoSilva> jdong: a moment
<desrt> what is a "validation bug"?
<jdong> "It is known that there sometimes are behaviours such as the one which
<jdong> you observe with ltmodem and smp. Therefore the logical step is to keep
<jdong> ltmodem and temporarily use the single p (UP) kernel, just to make sure if
<jdong> the problem is the ltmodem-smp conflict."
<jdong> but that is dated information
<RenatoSilva> jdong: i don't undertand nothing of what you just said :D
<RenatoSilva> jdong: http://martian.barrelsoutofbond.org/
<RenatoSilva> jdong: del.icio.us it
<jdong> (alpha) Testing. Volunteers are invited. There's no official release yet.
<jdong> it seems to be an alpha driver
<RenatoSilva> jdong: i think it's easy to take martian and embed it in the instalaltion
<jdong> RenatoSilva: if it is shown that martian is more stable or reliable than the existing ltmodem driver, then yes, it could very well go into the kernel
<RenatoSilva> jdong: the martian? sure, but it is working here, except of some strange screws from the device :D
<jdong> that doesn't sound like a great success report
<RenatoSilva> jdong: so it was useful to tell you about it? will you keep it in mind?
<jdong> for something you want included as a part of the Ubuntu kernel
<RenatoSilva> jdong: or it's another place i have to go??
<jdong> I have no decision making power around here
<jdong> you should try the mailing list as a way to get more developers involved
<jdong> and if you can state your findings with the martian driver on the wiki page you linked to, that will help too
<RenatoSilva> jdong: about the screws: was a joking, sometimes when connecting there's strange sounds, but only sometimes, my PC never had frozen because of such driver for example...
<jdong> still... this is a driver... that inserts itself into the kernel
<jdong> it needs to be of a certain quality level before it's wise to ship it by default
<RenatoSilva> jdong: anyway the quality may be verified by inspecting the code
<RenatoSilva> jdong: i don't remeber it I've tried ltmodem, I think I had trouble with it, so that I've tried martian
<jdong> which takes developer resources
<RenatoSilva> jdong: :D
<jdong> :)
<jdong> but yes, RenatoSilva, we aren't going to completely forget about winmodem support...
<RenatoSilva> jdong: a question: what's the difference between ltmodem and sl-modem?
<jdong> RenatoSilva: the situation will naturally get better as these better drivers emerge
<jdong> RenatoSilva: ltmodem is for the Agere Mars 1648C chipset, while sl-modem is for the SmartLink Intel HDA modems
<jdong> different chipsets
<jdong> this of course does not solve the problem with the Conexant HDA HSF modems
<jdong> by far the most popular modems
<jdong> for which no half-open drivers exist.
<RenatoSilva> jdong: I hope very much, for all that I've said, that it become true fast
<RenatoSilva> jdong: wow, great
<RenatoSilva> jdong: btw, I guess I remember why i did not used ltmodem!!!
<RenatoSilva> jdong: it's because it's a hard modem driver, right??? or no??
<jdong> no
<jdong> it is also a driver for the Mars chipset
<jdong> martian seems to be a rewrite of it
<jdong> it also uses the same ltmodem binary blob
<jdong> just a different 'wrapper' around it
<RenatoSilva> jdong: i would try it to see if it works, but i don't want to have re-work in case of re-installin martian
<RenatoSilva> jdong: does ltmodem is installable by apt?
<RenatoSilva> jdong: wow, i 'm not such a low-level programmer
<jdong> it is installable by apt, but only on the linux-386 kernel
<jdong> if you install and boot the -386 kernel, ltmodem should be enabled automatically
<jdong> that is already in Ubuntu :)
<RenatoSilva> jdong: if someday it would be possible, I think it would be interesting to connect statistics in Brazil and world-wide about the most-used modems, I use Agere here but i'm not sure if it's the most-used
<jdong> I used to be a dial-up modem guru/fanatic....
<jdong> I will tell you off the bat the most popular by far are Conexant HSF/HSP's
<jdong> today, in the form of Conexant HDA modems
<RenatoSilva> jdong: so that's why the network > modem item did not worked when i first installed my Edgy, because I'm in a Core 2 Duo
<jdong> second most popular are Agere Mars 1648C
<jdong> and then it's SmartLink
<jdong> the order there between 2 and 3 may be flipped
<RenatoSilva> jdong: also in Brazil?
<jdong> I'd expect so
<jdong> (the main motivation is that Conexant HDA is dirt cheap)
<jdong> it's quite literally connecting the telephone wire to two input leads on the sound card :)
<RenatoSilva> jdong: are you a genuine developer of ubuntu right?  so let me make a question
<jdong> no, I am actually not a developer
<jdong> I actually do, as Hobbsee suggested, hang around and act as one :D
<jdong> (I have several other responsibilities in the Ubuntu community that keep me well busy)
<RenatoSilva> here in Brazil we have a grear virtual community called GUJ (.com.br) in which forum we discuss about Java technology, and currently by these  days we're talking about the importance of Tests in software (junit.org, unit tests, TDD etc.)
<Hobbsee> jdong: and being the master of backports..
<Hobbsee> jdong: that counts as a developer
<jdong> :)
<jdong> ok
* jdong puts on Developer badge :d
<RenatoSilva> some were saying that sofwtare without tests are to put in trash
<jdong> Hobbsee: I promise I'll get a MOTU badge before the summer is over :D
<bhale> you could get one, if you wanted.
<jdong> RenatoSilva: a comprehensive yet accurate test suite is indeed a great thing to have for any piece of software
<Hobbsee> jdong: yay!
<jdong> bhale: I think I still need to put in some packaging work before I qualify :)
<RenatoSilva> so I wondered if this culture of Unit Tests, TDD etc. was particular of Java or if it is used in Linux kernel and distros, for example
<RenatoSilva> does the Linux kernel have Unit Tests?????
<jdong> RenatoSilva: many kernel developers I'm sure have a regression testing suite...
<jdong> RenatoSilva: it is very hard to define unit tests for every subsystem of the kernel
<RenatoSilva> is there something like JUnit for C, such as "CUnit"??
<jdong> RenatoSilva: but I know for sure filesystem developers have a very full testing suite
<bhale> this is drifting further from the topic
<bhale> google says: http://cutest.sourceforge.net/
<RenatoSilva> and Debian too, they test its software for years before release it, which kind of tests they do, I wondered
<jdong> users test and report bugs, bugs are fixed
<jdong> the standard way of testing
<jdong> you can't practically unit test an entire distribution :)
<jdong> try writing a unit test for burning a DVD :)
<RenatoSilva> I told them, If tests are so important that you reject non-testable software, then we shoudn't trust in linux kernel, because they haven't tests
<RenatoSilva> jdong: it would be difficult???
<jdong> yes
<bhale> ubuntu releases go through a documented testing plan
<RenatoSilva> jdong: it's strange, in Java we have not this culture of "hey, it's a beta, help us testing it"
<bhale> can i persuade you to join #ubuntu-offtopic
<RenatoSilva> jdong: we pratically have not "betas", but milestones
<RenatoSilva> bhale: sorry
<RenatoSilva> bhale: I'll stop
<wowow> hey guys
<wowow> anyone here from the installer team?
<Hobbsee> wowow: #ubuntu-installer but there's probably no one awake
<wowow> installing dapper on intel chipset systems is a problem, screen goes all black 3/4'rs of the way through 
<RenatoSilva> bhale: but if was a great information, in offtopic we woudn't find developers (they would ask me what is unit testing :D )
<wowow> ah! well i'll try anyway
<bhale> RenatoSilva: you must understand, it is pretty slow right now.. if we started letting people ask anything, there would be no time to work
<RenatoSilva> jdong: tahnk you for all information, remember of me, softmodems and Brazil, and good luck with Ubuntu development! Thank you everybody!
<wowow> well posted there
<RenatoSilva> bhale: sorry, I finished :D
<Hobbsee> bhale: exactly.
<wowow> just in case no one is awake, would anyone have a clue why on intel chipset mobos the dapepr installer goes blank on all terminals 3/4'rs of the way through? or how to fix this problem?
<wowow> or get around it even?
<RenatoSilva> thank you everybody, see you later!
<Hobbsee> wowow: might be better to run edgy/feisty on that, if it's a core duo
<Hobbsee> or later
<wowow> can't 
<wowow> this is for work
<wowow> we can only run lts
<jdong> wowow: what kind of Intel system?
<wowow> well two separate systems
<wowow> this one is an asus z95f with a core duo cpu indeed
<_ion> wowow: Have you posted a bug report?
<wowow> the others are an asrock mobo with ... *hmm* with core 2 duos on them
<wowow> i would but i'm flying out in about 3 hours
<Hobbsee> wowow: that kernell seems to be a bit old to support the core duo's well - i had the same problem, with graphics
<wowow> looking for wiggle room, then will post 
<jdong> wowow: please do file a bug report....
<wowow> yeah later, i don't have time
<jdong> sure.
<wowow> Hobbsee, ah, *hmm*
<wowow> damnit might not have any choice but to do edgy feisty
<wowow> *grr*
<Hobbsee> wowow: unfortunately, yes.  feisty should be fairly well supported by now
<wowow> lots and lots of updates still, kinda shitty to have regular users have a box like that.  when is feisty due for release?
<Hobbsee> 19th
<Hobbsee> true, but a new kernel has the potential to break a lot of other things.
<Hobbsee> which is unacceptable for a LTS, obviously
<RenatoSilva> next wednesday? nice!
<wowow> ah, *hmm* well maybe we could squeak by
<wowow> Hobbsee, yeah true, i have a canonical support account but its fior 9x5
<wowow> i'll bug them in about a week to see if there is anything that can be backported
<_ion> There shouldnt be many updates for feisty before release.
<wowow> maybe not
<Hobbsee> wowow: you could always upgrade that support if you needed it, too.  *shrug*
<Hobbsee> or make sure you only do the upgrades between 9-5
<wowow> not without my bosses cc and not before i fly out
<Hobbsee> good point
<wowow> Hobbsee, so you say youve seen this before?
<wowow> intel chipset too?
<Hobbsee> wowow: not exactly that - but had heaps of X problems when trying to run dapper on this core duo
<wowow> well i actually have like two installs on core duo laptops ... but those installed magically even with this issue
<jdong> Dapper ran fine on my core duo (centrino) laptop.... but I have too seen many reports of issues
<Hobbsee> wowow: intel 965 graphics chipset
<wowow> i think thats what it is here
<kapputu> hi, have some problems installing cpan modules in feisty
<kapputu> http://paste.ubuntu-nl.org/15900/
<Hobbsee> kapputu: see the /topic
<kapputu> k
* ..[topic/#ubuntu-devel:Hobbsee] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy, #ubuntu+1 for feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Main frozen for release candidate preparation
<wowow> well on the upside, with feisty the power use on the laptop should improve, right?
<Hobbsee> should do, yes
<Hobbsee> booting's a lot faster too
<wowow> cuz this mofo cpu fan is spinning at 100% right now for no reason
<wowow> heh
<jdong> performance will also be better on the core duos
<jdong> and any other shared-cache CPU designs
<wowow> oh i heard that, so the new bootloader is working wonders eh?
<wowow> jdong, nifty
<jdong> lol not really... just optimized boot scripts
<wowow> so what you guys are saying is take a chance, lots of upside
<Hobbsee> wowow: yes.
<jdong> I think Feisty is a good choice :)
<jdong> once it releases
<Hobbsee> wowow: particularly if you've got the canonical support anyway
<wowow> allright, blast it, i was hoping for keeping lts around and doing a company wide upgrade
<wowow> cool, thx for the input, that clears up a few things
<Hobbsee> presumably with the next one you could
<wowow> actually i'm starting to doubt it
<wowow> chipset and cpu designs evolve so quickly, it's impossible to keep a 2 year old kernel current
<Hobbsee> wowow: true, but are you going to upgrade all your machines again after this?
<wowow> not until the next lts is available
<Hobbsee> ie, it'll still support all the old ones - but will you be adding more that you need the later support for?
<Hobbsee> sorry, i meant hardware-wise
<wowow> unfortunately yeah we do every year and in unplanned ways
<wowow> we run stuff for the gov't so they randomly give us dollars to spend or we loose them
<wowow> makes planning VERY difficult
<Hobbsee> ahh
<wowow> albeit linux still makes it easier than dealing with vista
<Hobbsee> true
<Hobbsee> which means you'd have exactly the same problem with any distro, presumably
<wowow> oh totally
<wowow> not complaining about ubuntu at all
<Hobbsee> if you needed the latest kernels each time to support the computers you were buying
<wowow> just a kink in the deployment strategy i guess
<Hobbsee> in that case, i'd guess that you'd want to pick a distro which is good at dist-upgrading, and officially supports that
<wowow> there is only two bro 
<wowow> :)
<wowow> debian
<wowow> and debian + (i.e. ubuntu)
<wowow> :)
<Hobbsee> ie, it sounds like you're not looking for LTS at all - but a good way to dist-upgrade
<Burgundavia> wowow: lts --> lts will certain be supported
<Hobbsee> well, yeah :)
<Burgundavia> certainly, rather
<wowow> no i'm really only looking for lts, i'm being forced to alter my assumptions :)
* Treenaks will probably be running feisty on his shiny new server
<wowow> *nod*
<Treenaks> (because of the hardware support thing)
<Burgundavia> wowow: the next lts will likely be feisty+1
<Treenaks> Burgundavia: +1 or +2?
<Hobbsee> Burgundavia: uh, +2 was the plan
<wowow> really?
<Treenaks> (because +2 was the last I heard)
<Hobbsee> wowow: no.  +2.  
<wowow> ah okay
<Hobbsee> Burgundavia: you've misread the release annoucement or something
<Burgundavia> Hobbsee: which one?
<Treenaks> (that means 2 years between LTS)
<Hobbsee> Burgundavia: the one for gusty
<Burgundavia> ah
<wowow> Hobbsee, well thats a good point.  i guess using festy now in a limited way isn't too bad considering a 12 month wait
<jdong> Hobbsee: gushy.
<Hobbsee> wowow: keep in mind that feisty's still supported - just that it'll only be supported for 18 months.
<Treenaks> jdong: gusty
<wowow> Burgundavia, btw, its me holycow
<wowow> lol
<wowow> i got your email
<jdong> Treenaks: no, gushy. gushy giblets...
<Burgundavia> Hobbsee: you are right, I failed to read the announcement closely
<Hobbsee> wowow: but by the sound of things, you'd need to upgrade way before that anyway, if you're getting new hardware every year
<jdong> :)
<wowow> are you available for a pm a bit?
<Burgundavia> wowow: excellent
<Burgundavia> yep
<wowow> Hobbsee, it's going to be interesting indeed
<Hobbsee> wowow: indeed.
* Mithrandir waves.
<kylem> morning
<Hobbsee> hi Mithrandir, kylem 
<Mithrandir> hiya Kyle, Sarah
<wowow> looks like you guys might be right
<wowow> feisty hasn't thrown a fit yet
* wowow crosses fingers
<wowow> hope i haven't spoken too soon
<wowow> heh
<Hobbsee> lol
<fabbione> morning Mirv 
<fabbione> bah
<fabbione> morning Mithrandir 
<Mithrandir> morning Fabio
<evand> Good morning fabbione and Mithrandir 
<fabbione> hi evand 
<tepsipakki> good morning everyone
<_ion> Hi all.
* Hobbsee declares it not morning :(
* tepsipakki sings Hobbsee a lullaby
<tepsipakki> :)
* Hobbsee argh, no singing!
<Hobbsee> one of the girls at work seems to like singing randomly...
<tepsipakki> I guess she's not that good :)
<tepsipakki> at it
<Hobbsee> oh she might be, but i need her to do some work, dammit :P
<tepsipakki> hah
<Hobbsee> they're either wandering around, singing, chatting...
<Hobbsee> when you want to do that a bit, that's fine...but to only do that, adn not actually do the work that needs to be done...grrr...
<wowow> i agree with you
<wowow> it can make one go postal
<wowow> i too can't ignore patterns
* Hobbsee wonders where the sense of responsibility has gone from young people...
* Hobbsee notes that she sounds like an old woman, now :P
<Hobbsee> Mithrandir: how'd the RC go?  do we have more images to test?
<wowow> lol
<wowow> no beatings no respect
<wowow> i submit there is a 1:1 correleation
<wowow> -_-
<Hobbsee> heh.  i'm not *that* old :P
<Mithrandir> Hobbsee: current images are, well, current.  I believe they are good.
<Hobbsee> Mithrandir: great
<Mithrandir> DVDs are being rebuilt since I forgot about them yesterday.
<Hobbsee> right
<ajmitch> morning Mithrandir 
<Mithrandir> morning ajmitch, evand
<mneptok> oy Tollef
<fabbione> mneptok: you are not supposed to be around.. go away
<mneptok> si padrone.
<wowow> damn, this canadian mirror is soooo slow
<wowow> its gonna take forever for feisty to install
<Hobbsee> Mithrandir: any chance you could tell me why this was rejected?  https://launchpad.net/ubuntu/feisty/+queue?queue_state=4&queue_text=tutos2
<dholbach> good morning
<Mithrandir> hiya Daniel
<dholbach> hey Tollef
<Hobbsee> hiya dholbach 
<Mithrandir> Hobbsee: looking
<dholbach> hey Hobbsee
<pitti> Good morning
<Hobbsee> pitti: heya
<Hobbsee> BenC: any plans to fix https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/106028 ?  or pointers on how to?
<ubotu> Malone bug 106028 in linux-source-2.6.20 "Kvm not installable in feisty" [Undecided,Confirmed]  
<dholbach> Hobbsee: shouldn't the last upload fix that?
<Hobbsee> dholbach: it's not installable now...
<fabbione> it can be fixed in kvm too
<Hobbsee> fabbione: how, though?
<fabbione> Hobbsee: drop the Depends: or change it to a linux-$image
<Treenaks> linux-image-2.6.20-14 Provides: kvm-modules-2.. maybe use that?
<Hobbsee> fabbione: what's the syntax for the latter?
<dholbach> kvm (1:16-1ubuntu2) feisty; urgency=low
<dholbach>  .
<dholbach>    * Revert to kvm-16 to match released kernel.
<dholbach>    * Add epoch.
<Hobbsee> dholbach: we're on .18 now...
<dholbach> Date: Sun, 15 Apr 2007 17:52:01 -0400
<dholbach> epoch
<Hobbsee> oh, i see
<dholbach> http://www.mail-archive.com/feisty-changes@lists.ubuntu.com/msg08215.html
<Treenaks> good.. that means my new server will run Feisty ;)
<Treenaks> ~ 4 times
<Treenaks> at once.
<Hobbsee> Mithrandir: thanks
<Mithrandir> Hobbsee: looks like a manual reject; was it your upload?
<Hobbsee> Mithrandir: wasnt mine.  was on u-u-s
<Hobbsee> Mithrandir: oh. i'd say it's because it was uploaded twice
<wowow> feisty does indeed boot fast
<wowow> neato
<heno> Mithrandir: please PM me the latest md5sums
<dholbach> heno: he updated Testing/md5sums already
<heno> ah, coolie
<dholbach> cd testing - yoohoo :)
<heno> woooooo!
<heno> btw, we have an archive view of the previous testing FWIW https://www.stgraber.org/ubuntu/isotesting/archive
<dholbach> hey mvo
<mvo> good morning
<mvo> hey dholbach
<ajmitch> morning mvo 
<mvo> hey ajmitch
<fabbione> Keybuk, iwj: ping?
<Keybuk> morning
<fabbione> Keybuk: hey dude
<fabbione> bad news
<fabbione> root on lvm on raid is still racy.. i have a machine that can boot this one time yes and two no
<fabbione> i can see the raids are formed properly
<fabbione> but lvm is not started
* fabbione setups access
<Keybuk> please investigate yourself, and see what you can find out
* _ion investigates himself. Will report.
<fabbione> _ion: use at least 2 raids in the setup
<Keybuk> fabbione: you have the fixes for the mdadm race installed, I assume?
<Keybuk> raid definitely did used to be racy
<fabbione> Keybuk: fresh install as this morning
<fabbione> _ion: one raid1 for /boot, one raid1 for lvm -> lvm with 2 lv -> root and swap
<fabbione> but i am sure it's just yet another race somewhere
<fabbione> so you might not see at all
<Keybuk> in theory, there shouldn't be any races
<Keybuk> since lvm is called when the mdadm is assembled
<Keybuk> it could be something like lvm locking out
<Keybuk> and failing rather than waiting
<_ion> fabbione: Sorry, i was only joking. I interpreted the investigate yourself part literally. :-)
<tepsipakki> does anyone know what is the status of UDS sponsorship?
<fabbione> Keybuk: it's possible... it's possible that we need to use the same trick to check the raid status before attempting to enable lvm
<Keybuk> we don't have a trick to check the raid status ...
<Keybuk> in theory, we should just be able to call lvm repeatedly until it works; likewise with mdadm
<fabbione> we added that call to mdadm --$cantremember
<Keybuk> no we didn't
<Keybuk> we added a call to vol_id
<fabbione> oh right.. yeah
<Keybuk> since that works for all volume types
<Keybuk> are there any useful messages on the screen?
<fabbione> nope
<Keybuk> or does it just hit the "try to mount the root disk" without it being there?
<fabbione> checking slowly.. step by step
<Keybuk> is there a three minute timeout?
<fabbione> yes
<fabbione> the timeout is there and i get dropped to busybox
<fabbione> that's where i can see raids are up but lvm isn't
<fabbione> problem is that it doesn't happen always
<fabbione> so it takes a few reboots to trigger stuff
<fabbione> ah there.. reproduced
<fabbione> no errors.. raids are started fine.. lvm isn't
<Keybuk> ok, interesting
<fabbione> waiting to be dropped to busybox
<Keybuk> the fact you hit the timeout is useful
<Keybuk> that means that we're not mistakenly believing the root filesystem is ready
<Keybuk> (which was the mdadm and lilo problems
<fabbione> yeah if i do manually lvm vgchange -a y and ctrl+d it's all good
<Keybuk> the problem is that vgchange isn't working
<fabbione> seems like sometimes it does...
* fabbione wonders
<Keybuk> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", RUN+="wa
<Keybuk> tershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'"
<Keybuk> -- 
<Keybuk> so there's a few possibilities
<Keybuk> 1) the add/change event isn't getting emitted when the md is assembled (probably false)
<Keybuk> 2) vol_id on the md is failing (probably also false)
<Keybuk> 3) vol_id is working, but not detecting an LVM volume group (this would fail every time)
<Keybuk> 4) either vgscan or vgchange aren't picking up the new PV
<fabbione> it's not 3) (just checked)
<fabbione> (initramfs) /lib/udev/vol_id /dev/md1 
<fabbione> ID_FS_USAGE=raid
<fabbione> ID_FS_TYPE=LVM2_member
<fabbione> ID_FS_VERSION=LVM2 001
<fabbione> it's also good for the other raid
<fabbione> if 1 is true, in theory the machine would never boot
<fabbione> but it does once in a while
<Keybuk> http?//wiki.ubuntu.com/DebuggingLvm
<Keybuk> err, fixed a typo on there
<Keybuk> (supress -> suppress_
<fabbione> yeps.. noticed
<fabbione> brb
<keyes> hello
<doko> dholbach, seb128: gnome-terminal started to translate mouse-wheel events into history scrolling, which doesn't work well when there's not a command prompt (another command running). is there a way to disable this?
<seb128> doko: not that I know
<doko> bad ...
<fabbione> Keybuk: are you sure that's the right debugging sequence?
<fabbione> more udevd.log 
<fabbione> another udev daemon already running
<fabbione> init_udevd_socket: bind failed: Address already in use
<fabbione> main: another udev daemon already running
<Keybuk> did you remove the script?
<fabbione> (doing that makes the machine booting)
<fabbione> yes
<keyes> I'm a student for Google Summer Of Code, where can I find my mentor ?
<Keybuk> err
<Keybuk> what gave those error messages?
<doko> keyes: what's your real name?
<fabbione> i mean i did copy/paste what's in the page and vgchange has been executed (i could see that)
<keyes> doko, K?vin Dunglas
<fabbione> Keybuk: whatever wrote in udev.log
<Keybuk> oh, hmm
<Keybuk> so there's a udevd already running when you break?
<fabbione> ahhhhh crap
<Keybuk> and you did break=premount, not break=mount ?
<fabbione> forgot the break
* fabbione sighs
<doko> keyes: please add your first name for the SoC/gmail account 
<keyes> doko, OK, where can I do that ?
<doko> keyes: well, you did apply, so it should be found at the same place
<keyes> ok !
<Riddell> Mithrandir: I take it we're not planning a herd 6?
<Mithrandir> Riddell: that is correct.
<Mithrandir> cjwatson: http://paste.ubuntu-nl.org/15947/ ; reminded as you asked me to.
<cjwatson> Mithrandir: thanks
<fabbione> Keybuk: http://people.ubuntu.com/~fabbione/udevd.log.bz2
<fabbione> Keybuk: running this way did not trigger the race.. lvm was activated
<fabbione> Keybuk: i noticed tons of stuff scrolling on console coming from vol_id
<Mithrandir> fabbione: if there is a workaround for this race, please make sure that gets into the release notes.
<fabbione> Mithrandir: we are still looking at it... once we know what it is, i will file a proper bug
<Mithrandir> goodie
<Keybuk> fabbione: the log without the race isn't very useful
<Keybuk> please keep trying until you cause the race
<fabbione> Keybuk: ok....
<Keybuk> actually, that's not true; the log without the race is useful to compare with a log with the race
<fabbione> tho it might not happen at all with all this manual mangling
<Keybuk> :)
<Keybuk> it should happen
<Keybuk> the only difference is the logging
<fabbione> yeps
<fabbione> ok
* fabbione switches in manual batch mode
<Keybuk> I'd be surprised if it's a sub-second race
<sladen> Keybuk: I haven't debugged it yet;  hibernate here is failing because the swap device is not being linked in  /dev/.../by-uuid/
<sladen> Keybuk: is the uuid of the swap partition ever regenerated, eg. after a failed hibernate, leading to the entry in /etc/fstab and the on-disk UUID not matching?
<cjwatson> Mithrandir: is there a wiki page where I can dump text about that?
<sladen> Keybuk: tried quickly changing   .../65-persistent-naming.sh  to also accept   filesystem|other|swap  though that didn't cure it
<Mithrandir> cjwatson: https://wiki.ubuntu.com/FeistyKnownIssues ?
<cjwatson> thanks
<cjwatson> Mithrandir: done
<ogra> mumble ... why isd my dvd oversized again ?
<dholbach> heno: can we get dvd images on the iso testing page?
* highvoltage wonders if ogra said that again or whether it's an Xchat script that automatically does it ;)
<fabbione> Keybuk: i can't reproduce the race with the debugging procedure.... 
<ogra> Riddell, which linux-* package did you drop to free up space ?
<ogra> highvoltage, i could need a macro :P
<heno> dholbach: yep, 1 min.
<ogra> but at least i dont have to say CD anymore :)
<cjwatson> ogra: I fixed that
<ogra> cjwatson, oh, thanks :)
<cjwatson> ogra: it just needs a DVD rebuild; the health checks are regarding images from before my fix
<cjwatson> ogra: (I dropped kdepim-dbg and kdepim-doc)
<ogra> ok
<heno> done
<Mithrandir> ogra: it's good now anyway.
<ogra> Mithrandir, ok
<ogra> ahuman, yes, i should look at the webpage before judging by the mail i get :)
<ogra> err
<ogra> s/ahuman/ah/
<pitti> tepsipakki: when I let xserver-xorg-video-intel in, I assume I can remove both -i810 and -i810-modesetting?
<pitti> tepsipakki: it Conflicts/Replaces: both, but only provides a transisional package for -i810
<Keybuk> sladen: yes, many things seem to change the UUID
<Keybuk> fabbione: interesting, that implies a sub-microsecond race !!
<fabbione> Keybuk: score... so ... what do i do now to check?
<Keybuk> err, need to find out what is racing what
<Mithrandir> pitti: uh, no.
<Mithrandir> pitti: don't remove -i810.
<fabbione> Keybuk: can you try to ssh keybuk@trider-g7.fabbione.net ?
<fabbione> Keybuk: you should get console on the machine directly..
<pitti> Mithrandir: erm, not that one, of course; sorry
<Keybuk> fabbione: I don't have any time to help you debug this week I'm afraid
<Keybuk> I can look at it next week
<fabbione> Keybuk: yes i understand you are busy but we need at least to file a proper bug to add to the release note...
<Keybuk> fabbione: things you can try: does adding a rule like RUN+="/bin/sleep 1" in 00-init.rules fix it?
<doko> Mithrandir: please could you consider/review http://people.ubuntu.com/~doko/tmp/updates25.diff ? Reversal of two changes on the python2.5 branch. I checked with mvo (using pickling in update-manager) that the update code is not affected. 
<fabbione> Keybuk: checking
<Keybuk> if so, does moving that sleep to just in the mdadm call path, or just the lvm call path, or just the vol_id call path, etc. fix it
<Keybuk> fabbione: also so far I've not heard any further reports on this race, so it may be something with your underlying hardware perhaps?  is this using multipath?
<Mithrandir> doko: does it fix any critical bugs?  If not, -updates.
<fabbione> no multipath involved.. it's just  a plain fresh install.. the disks are local 
<fabbione> the SAN is not connected to this machine
<Keybuk> ok
<doko> Mithrandir: I don't know that it's reported as a bug in a package; it's a behaviour change compared to the 2.5 release. I certainly can move it -updates (maybe together with the 2.5.1 final release, there shouldn't be more changes)
<Mithrandir> doko: yes, please.
<doko> heno: no lrm updates required for iso testing after the kernel updates from the weekend?
<cjwatson> no, l-r-m for 2.6.20-15 is already there
<cjwatson> why do you ask? is something going wrong?
<doko> cjwatson: no, didn't see that there was no abi bump
<fabbione> Keybuk: nope.. sleep doesn't help anywhere
<fabbione> it's like the lvm rule is not invoked at all
<fabbione> but it is at random
<heno> iwj, kylem, mvo, bdmurray, mikebro, cburg, Riddell, kwwii, rtg, pkl, Keybuk, pitti, seb128: Just a mass-ping to make sure everyone is aware the 20070415 CDs are published (20070416 for DVDs). Please test.  emails have gone out with links and instructions
<pitti> heno: acknowledged, I'm 80% done already
<iwj> heno: Thanks.  My rsync is running.
<iwj> heno: BTW, might it be worth swapping over some of the test cases ?
<pitti> heno: I'll also test cli, for the fun of it (it's fast)
<iwj> Your earlier mail suggested I should look at the isotesting/ page, which I did, so now I'm downloading the d-i cd instead of the livecd.
<iwj> Since it seemed to need more attention.
<fabbione> iwj: hey.. if you have a second do you mind to read the scrollback for the conversation between me and Keybuk about lvm/raid etc?
<heno> iwj: great, thanks. please improvise as you find it best. 
<fabbione> iwj: it seems i found another race
<fabbione> iwj: if you need i can easily give you access to the box console
<iwj> fabbione: Sure.  I sort of skimmed it hoping Keybuk would handle it :-).
<iwj> Let me read it properly.
<fabbione> iwj: ehhe
<fabbione> iwj: i just need to be able to file a proper bug at this point to add to the release note.. i don't think we can get a fix in at this point in time
<Mithrandir> fabbione: not if you can find a workaround, at least.  And not unless this can be shown to affect more people.  (Sorry. :-/)
<fabbione> Mithrandir: well whatever we can get out.. 
<fabbione> Mithrandir: well clearly.. but i seriously doubt it affects only me.. tho if it's a race it might trigger at random to anybody..
<iwj> The difficulty is knowing how common it is.
<iwj> So at a guess what's happening is that the kernel generates its last change event for the md device before the device is ready for IO.
<Mithrandir> in that case, a kernel bug, then?
<iwj> Yes.
<iwj> But I could be casting aspersions.
<iwj> It's very difficult to say for sure from the information we have right now.
<iwj> Oh, hold on, Fabio says adding `sleep' didn't help.
<fabbione> cat /etc/udev/rules.d/85-lvm.rules 
<fabbione> # This file causes block devices with LVM signatures to be automatically
<fabbione> # added to their volume group.
<fabbione> # See udev(8) for syntax
<fabbione> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", RUN+="watershed sh -c 'mkdir -p /dev/debugging/ && touch /dev/debugging/lvm.%k'"
<fabbione> iwj: ^^ this doesn't work either.. it's like lvm rule is ignored
<fabbione> no sleep doesn't help
<iwj> Sleep where ?
<iwj> ENV{ID_FS_TYPE} comes from the vol_id in persistent-storage.rules.
<fabbione> i did try both in 00-init and 85-lvm 
<fabbione> i added a sleep 1 before invoking pvscan; vgchange...
<iwj> fabbione: Can you try this: in persistent-storage.rules just before   IMPORT{program}="vol_id --export $tempnode"
<iwj> do something like this
<iwj> Err, actually let me just check the syntax.
<fabbione> sure
<fabbione> take your time
<fabbione> iwj: as i said.. if it's easier for you to get access, i can set it up in a few seconds
<fabbione> iwj: it's one of those sandboxes you can beat up to death
<iwj> udev--
<iwj> run_program: '/lib/udev/sh' (stdout) 'run_program: program '/lib/udev/sh' not found'
<iwj> Gets me every time, that one.
<iwj> PROGRAM="/bin/sh -c 'vol_id --export $tempnode >/tmp/volid.%k.$$$$'"
<iwj> Just before IMPORT{program}="vol_id --export $tempnode"
<iwj> Oh, sorry, instead:
<iwj> PROGRAM="/bin/sh -c 'vol_id --export $tempnode >/tmp/volid.%k.$$$$ 2>&1'"
<fabbione> # by-label/by-uuid (filesystem properties)
<fabbione> KERNEL=="*[!0-9] ", ATTR{removable}=="1", GOTO="persistent_storage_end"
<fabbione> PROGRAM="/bin/sh -c 'vol_id --export $tempnode >/tmp/volid.%k.$$$$ 2>&1'
<fabbione> IMPORT{program}="vol_id --export $tempnode"
<fabbione> ok ?
<iwj> Right.
* fabbione does
<iwj> With luck it will still fail.
<iwj> If it doesn't it might still produce some useful info.
<fabbione> ok
<iwj> We'll need copies of all of those /tmp files it makes ...
<fabbione> yeps
<fabbione> easy enough
<mvo> heno: server is done, upgrade testing is runing (take a bit)
<heno> mvo: woo! thanks
<fabbione> iwj: it's still failing.. waiting for the timeout
<iwj> Yay.
<iwj> Don't vgchange straight away.
<fabbione> nope
<iwj> We need to know which device it failed to find the volumes on.
<fabbione> yeps
<fabbione> iwj: /tmp is emptu
<fabbione> empty
* fabbione scratches his head
<Mithrandir> I'm wondering if just entering "5" as the size in partman should select 5GB and not 5MB
<iwj> fabbione: Freaky.
<fabbione> iwj: i wonder if the bug is exactly in vol_id
<iwj> We would expect a bunch of empty files then .
<iwj> Did you regenerate your initramfs ?
<Keybuk> should be /lib/udev/vol_id too
<iwj> Oh, so it should.
<iwj> vol_id is in the path in the real system so I didn't notice.
<fabbione> iwj: yes i did regenerated it
* fabbione fixes the path
<Keybuk> (still should've had an empty file)
<Keybuk> or one with an error
<Keybuk> I think
<Keybuk> no, maybe not
<fabbione> hmm it makes no sense
<fabbione> if i have to specify the path.. how would this work
<fabbione> IMPORT{program}="vol_id --export $tempnode"
<iwj> fabbione: udev prepends /lib/udev to the program name in "..."
<fabbione> iwj: ok
<cjwatson> Mithrandir: one of those annoying finger-macro-compatibility things, I think. TBH I reckon it should probably just reject plain numbers altogether
<iwj> There surely should have been an empty file.  sh would have tried to execute vol_id from the path.
<iwj> So we still don't know why no files at all.
<fabbione> i noticed that udev was telling me that there was a bad rule....
<fabbione> but i couldn't see which one
<cjwatson> Mithrandir: the more common confusion is AFAICT not megabytes with gigabytes but megabytes with bytes - people type in "2147483648" and wonder why it tells them their disk is too small
<iwj> Oh, you have dropped the trailing "
<Mithrandir> cjwatson: heh, true.
<tarzeau> can i help with $105996 ?
<iwj> fabbione: syntax error ^
<tarzeau> i mean # not $
<fabbione> iwj: good catch
<iwj> This installer lvm wedge is deeply annoying.
<iwj> I mean, the 3 minute pause.
<tarzeau> i've got http://gnu.ethz.ch/debian/libfreebasic/libfreebasic_0.16b-1.dsc for #105996 someone feel like adding quilt/dpatch to it?
<fabbione> iwj: yeah.. i agree
<Keybuk> iwj: it's three minutes in which people might think about what they're about to do with their root filesystem, and realise that they're silly :p
<iwj> fabbione: You can bypass it with mknod in VC2 :-).
<fabbione> there.... now we have files in /tmp
<iwj> And it has failed ?
<iwj> When you copy the files, use cp -a just in case the timestamps are at all useful.
<fabbione> iwj: http://people.ubuntu.com/~fabbione/crap.log
<fabbione> so it did fail on md*
<Keybuk> fabbione: can you re-order that so that it's in pid order
<Keybuk> but yes, it's failing on all md*
<fabbione> Keybuk: i guess so...
<iwj> fabbione:   egrep . *
<Keybuk> actually, no need to reorder, it's in order anyway
<Keybuk> what's on sda1?
<fabbione> sda1 is unused partition
<Keybuk> likewise sdb1?
<fabbione> same
<Keybuk> ok
<fabbione> it's a 8MB padding partition
<Keybuk> it looks like the md0 change event happens too early then
<fabbione> you mean my machine is too fast?
<Keybuk> no, I mean that there's a bug in the kernel
<Keybuk> the whole point of the change event is to say that the md is ready for use
<iwj> `unknown volume type' can mean the size is zero.
<iwj> But not that it couldn't be opened.
<iwj> Unfortunately I don't have a /dev/eio here.
<fabbione> iwj: my offer for access is still valid
<iwj> Oh, now I know why sleep didn't help.
<iwj> Keybuk said RUN+= but vol_id is in PROGRAM.
<iwj> OK, here's a workaround: when we get an add or change event for an md* device, we poll it with vol_id for (say) 5s until vol_id works, before letting the rest of persistent-storage continue.
<fabbione> iwj: ok.. sure i can test that...
<iwj> This md stuff is all such crap!
<fabbione> iwj: can you give me the rule you would like in there?
<iwj> My test box is doing a cd install test so I can't test my own script.
<iwj> How about I draft you a script and you debug it ? :-)
<fabbione> i am ok to test it for you..
<Keybuk> iwj: yeah, I keep making that mistake
<Keybuk> iwj: workaround = fix the kernel
<iwj> Uh ?  You think we should patch the kernel for this at this stage ?
<Keybuk> no
<Keybuk> I think we should do nothing at this stage
<iwj> fabbione: Install http://www.chiark.greenend.org.uk/~ijackson/d/t as /scripts/wait-for-crappy-md and then something like
<iwj> KERNEL=="md*", PROGRAM="/scripts/wait-for-crappy-md $tempnode"
<iwj> just before the vol_id >tmp we had before.
<iwj> Keybuk: Sure, but I want to know that we understand the problem before I say we should ignore it for the release.
<fabbione> iwj: won't I need some changes in hooks/ to get that script in the initramfs?
<iwj> fabbione: You could just edit the initramfs manually.
<fabbione> iwj: ok
<iwj> Or whatever you like really.
<iwj> You'd best run that script in your real system first to check it for syntax errors.
<iwj> I haven't executed it at all.
<Nafallo> fabbione: btw. /dev/md2 wasn't the degraded array. /dev/md3 was :-P.
<fabbione> iwj: seems to work fine
<iwj> Right, good.
<iwj> But see what Keybuk said.  I don't think we want to ship this.
<Keybuk> fabbione: random question
<Keybuk> does booting, waiting for timeout, initramfs shell, then run "udevtrigger" work to make the lvm appear
<fabbione> Keybuk: i will check it if it fails at the next reboot
<iwj> You're thinking of your while sleep 10 do udevtrigger aren't you ?
<fabbione> iwj: your workaround did the trick
<fabbione> machine is booting
<Keybuk> iwj: moi? :p
<Keybuk> it's a simple change, with understood results <g>
<iwj> I think it's a good idea and can we have it in feisty ?
<iwj> *snort*
<Mithrandir> fabbione: so  http://www.chiark.greenend.org.uk/~ijackson/d/t makes it all happy for you?
<fabbione> Mithrandir: yes. of course that requires a few extra changes.. like 65-persistent-rules changes and installing the script in initramfs
<Mithrandir> ok, but this can be worked around from the command line, or just fixed by retrying the boot a few times?
<fabbione> it can be worked around from cmdline for me
<fabbione> i have to issue a lvm vgchange -a y manually
<iwj> Mithrandir: I was referring to Keybuk's insane repeated udevtrigger idea.
<fabbione> and it works
<fabbione> last test with udevtrigger then i need to grab some food.
<Mithrandir> fabbione: ok, then I think we should put something about it into "known issues" and put something into -updates to fix this.
<iwj> Mithrandir: Proper fix is a kernel change.
<Mithrandir> I didn't say proper fix. ;-)
<Mithrandir> I just said "fix".
<iwj> Riight.
* fabbione waits for timeout
<fabbione> we can for sure fix it in an update
<fabbione> the problem are only those people (like this poor bastard) that are affected at first reboot
<fabbione> so i hope  a small amount
<Keybuk> stop overclocking your scsi card ;)
<Nafallo> http://home.nafallo.info/bugs/udev.txt
<fabbione> Keybuk: calling udevtrigger a few times help
<fabbione> Keybuk: hehehe
<Keybuk> "a few times" ?
<fabbione> let me try once...
<fabbione> it did exit too quickly and i did run it 3/4 times.. then realized that i had to wait
<Mithrandir> or just udevtrigger and udevsettle, I suspect.
<Nafallo> iwj: wat do you think?
<Nafallo> what even
<fabbione> Mithrandir: that works too.. one udevtrigger, one udevsettle wait...
* heno takes a break
<Nafallo> hmm
<iwj> Nafallo: That log looks like a transcript of successful device discovery to me.
<Nafallo> iwj: you do see the places were I've killed mdadm?
<iwj> Nafallo: Err, no.
<Nafallo> search for died or something :-)
<Nafallo> pretty close to the end
<Nafallo> I've killed it two times
<Nafallo> mdadm: SET_ARRAY_INFO failed for /dev/md/2: Device or resource busy
<iwj> Nafallo: Hmm, I'm afraid I've never seen this one before.
<Nafallo> I see it everytime I boot :-)
<Nafallo> always the same array...
<Nafallo> I should see if man mdadm has anything to say about it :-)
<iwj> What mdadm has to say about it is `mdadm: SET_ARRAY_INFO failed for /dev/md/2: Device or resource busy' which AFAICT is a form of `You appear to be using Linux software RAID.  Back luck.'
<Nafallo> :-P
<Nafallo> I start to think something might be wrong with the array. so I'm looking for something to try to repair it ;-)
<iwj> `Something wrong with it' ought not to cause these symptoms so I'm sure there's a bug.
<iwj> Well, I was already sure there was at least one bug.
<iwj> But I mean I'm sure you're experiencing one of the many bugs.
<Nafallo> okey :-)
<Nafallo> I'll try to help you solve it the best I can anyway.
<iwj> At a guess the md* device is wedged in such a way that (a) vgchange hangs trying to read it and (b) mdadm can't fix it because vgchange has it open.
<Nafallo> so a race? :-/
<iwj> Well, I imagine a race is involved, yes.
<Nafallo> that array HAS lvm on it...
<iwj> Almost every bug in this area only happens if you lose some race.
<Nafallo> and it haven't happened to the other /dev/md1 on the same disk with no LVM...
<iwj> If my guess is right then it's a kernel bug and it's far from clear how it might be even worked around.
<iwj> Races happen sometimes.  It's what they do.
<Nafallo> also, sometimes I have to kill it once and sometimes twice...
<Nafallo> I think that might support your theory.
<Nafallo> hmm
<Nafallo> should we find a good place to set a sleep? ;-)
<fabbione> iwj: should we add a bug for my raid thingy and prepare a release note? (hounestly i am counting on your better english than my itaglish ;))
<ogra> Keybuk, how hard is it to siplit bootchart into a raw data collecting piece and a image generator ? we wont be able to do ltsp profiling on low level HW (300Mhz/64MB) with the current package it takes to long on such systems to create the png ... i'd like to copy the raw data to the ltsp server and run the generating part there
<iwj> fabbione: Yes, probably.
<iwj> But I seem to be becoming grumpy and should obviously go and have something to eat.  BIAB.
<ogra> Keybuk, (we plan to do a lot of ltsp profiling in spain)
<fabbione> iwj: enjoy
<Nafallo> iwj: I like you anyway :-)
<seb128> cjwatson: I just had a non-working installation due to "no boot flag set" after manual partitioning is that still bug #14244 or should I open a new one?
<ubotu> Malone bug 14244 in partman-auto "Automatic partitioning reset boot flag in DOS partition table?" [Medium,Confirmed]  https://launchpad.net/bugs/14244
<cjwatson> seb128: probably the same thing
<seb128> ok, I was sure with the new partitionner
<seb128> not
<cjwatson> benefit of the new partitioner is that we get roughly the same set of bugs as the old one rather than a new and exciting set :)
<seb128> ah, ok ;)
<Keybuk> ogra: relatively easy
<ogra> great
<ogra> thanks, i'll look at it before sevilla then :)
<Keybuk> before sevilla?
<ogra> yeah, i want to have a binary ready for the profiling sessions 
<ogra> so we can do our measuring :)
<Keybuk> fair enough
<Keybuk> split the profiling bit into a separate package that readahead can depend on
<Keybuk> e.g. readahead-profiler
<ogra> oh, i was only referring to bootchart for now
<Keybuk> err
<Keybuk> s/readahead/bootchart/
<Keybuk> sorry
<ogra> not sure readahead will be so happy about nfs root
* iwj returns fed and with coffee.
<ogra> yeah :)
<Keybuk> for some reason, my brain always switches those two words
<ogra> heh
<iwj> Nafallo: Thanks :-).
<Keybuk> (so then we can still tell people to "install bootchart" and have generated pngs)
<ogra> right
<iwj> Nafallo: You may find that putting sleep 1 in front of the vol_id in persistent-storage.rules helps.
<ogra> i dont want to mangle the current package 
<bddebian> Heya
<ogra> but have a switch or something so i dont have to wait 10-15 mins on these machines until i can log in 
<Mithrandir> ogra: I have a SoC student who wants to work on profiling and such.
<iwj> TBH I don't think we know enough atm to even propose a coherent workaround for -updates.
<ogra> Mithrandir, the ltsp profiling will rather target a small new kernel flavour and very low spec HW ... not sure he wants to take such special cases into account 
<Mithrandir> ogra: you might want to chat with him, at least.
<ogra> (and we need to have found the drawbacks after seville to make the results flow into development for gutsy ) 
<ogra> Mithrandir, yep, will do
<hunger> Is the -15-generic kernel more crashprone than the -13-generic version?
<mc44> it shouldnt be
<mc44> but then the -13 wasnt either for me
<cjwatson> hunger: it is not intended to be; please report bugs speedily if you encounter them
<hunger> cjwatson: How do I report random crashes that might be my hardware failing or whatnot:-(
<phaidros> where is configured which entries are made into menu.lst when installing new kernel?
<phaidros> I'm getting always (hd0,0) instead of (hd2,0), which was working in edgy.
<dany_21> phaidros: look at this section in /boot/grub/menu.lst: ## default grub root device
<dany_21> ## e.g. groot=(hd0,0)
<dany_21> # groot=(hd0,1)
<dany_21> phaidros: the line with one "#" is the default option (but it should stay commented (#)) - its only read by a script - not by grub
<phaidros> thanx dany_21 
<iwj> These 50-75% translated documents are surprisingly hard to read.
<pitti> and look totally hilarious, on top of it
<iwj> cjwatson: I trust that bug 107023 isn't anything to worry about ?
<ubotu> Malone bug 107023 in partman-auto "cfdisk complains about auto-resize generated setup" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107023
<iwj> Woah!  What does  `_pSLsys_getkey: EIO error'  mean ?
<pitti> iwj: ah, testing rescue mode :)
<iwj> Oh, bug 60423.  WTF
<ubotu> Malone bug 60423 in rescue "freeze after exiting rescue shell" [Undecided,Confirmed]  https://launchpad.net/bugs/60423
<iwj> `Rescue a broken system' aka `crash leaving my root fs dirty'.
<cjwatson> it's an error message from slang
<cjwatson> I have NFI what it means
<cjwatson> help welcome
<cjwatson> iwj: partitions not being in disk order seems like an intrinsic property of resizing a big partition near the start and adding multiple partitions in the middle, unless you think it's a good idea to renumber existing partitions. I'm therefore not concerned about the fdisk error
<cjwatson> iwj: not sure what the cfdisk error means. It doesn't obviously seem to be borne out by the output from the other tools
<cjwatson> hmm, comments in the bug instead
<cjwatson> either way I don't think it's cause for panic unless it causes systems to fail to bot
<cjwatson> boot
<iwj> cjwatson: No, that's the only symptom.
<iwj> Feel free to declare it a bug in cfdisk.
<iwj> cfdisk has a tendency to renumber things and it's one of its worst features.
<iwj> So please don't change partman to do that :-).
<cjwatson> I'm not even sure how. :-)
<cjwatson> cfdisk source says:
<cjwatson>               /* the enlarged logical partition starts at the
<cjwatson>                  partition table sector that defines it */
<cjwatson>               *errmsg = _("enlarged logical partitions overlap");
<cjwatson> do we think it maybe means that the logical partition starts at the same sector as the extended partition?
<cjwatson> I must admit I am finding the cfdisk source a bit inscrutable around there
<asac> i installed server cd, tested that exim4 works, then replaced by sendmail and got during install
<asac> http://pastebin.ubuntu-nl.org/15976/
<asac> anyway, sendmail is running ... not yet tried if basic things work
<cjwatson> asac: I think that's clearly a sendmail bug although not RC
<ogra> sendmail is in main ? 
<ogra> nah, isnt ...
<cjwatson> over pitti's dead body, I expect
<ogra> heh
<ogra> asac, file a bug for motu :)
<kylem> sendmail is a perfectly reasonable piece of software.
<pitti> *shudder*
<asac> dunno just thought might be good to know that it works for server flavour
<iwj> cjwatson: But in this case the logical partition starts strictly inside the extended one.  (I don't know what an `enlarged logical partition' is)
* pitti kicks kylem really hard
<ogra> kylem, but nothing we support 
<kylem> pitti, :P
<Keybuk> qmail rocks
* kylem files a MIR.
<fabbione> kylem: yes.. it is.. printed on 4 layers toitel paper
<asac> any sendmail expert here?
<ogra> kylem, eek
<kylem> haha.
<cjwatson> iwj: oh, is that what "9354+" means from sfdisk? OK.
<pitti> asac: our cat can probably configure it well by randomly walking on the keyboard with caps lock turned on
<asac> rofl
<iwj> cjwatson: I assume so.
<cjwatson> iwj: enlarged> that's the bit I'm finding inscrutable.
<pitti> oh, we install exim4 by default in server? why do we bother with maintaining the deltas to debian which change the prefered mailer to postfix? 
<iwj> I still have the setup here so if you want me to ask it anything let me know.
<elmo> I never understood why we bother maintaining that default anymore anyway
<bhale> my server doesnt have exim
<elmo> when we installed an MTA by default it made sense, now we don't, it just seems like busywork
<pitti> Keybuk: erk @nonfree :) what does it do so much better than postfix? (genuine question)
<Keybuk> propose a spec for Sevilla
<asac> pitti: no not by default .... but should work right?
<Keybuk> pitti: be understood by me
<pitti> asac: of course; I was just curious
<poningru> working on the 7.04 'feature tour'
<pitti> Keybuk: point :)
<poningru> https://wiki.ubuntu.com/FeistyFawn/RC
<asac> pitti: no we don't ship it ... at least for LAMP
<poningru> anyone have any topic suggestions?
<Keybuk> pitti: in this company, "I'm shutting my e-mail server down for two weeks to learn a new one from scratch" ain't exactly easy
<asac> s/ship/install by default/ of course
<poningru> that I can writeup?
<pitti> asac: oh, LAMP doesn't install an MTA either?
<asac> pitti: no
<poningru> pitti: no
<pitti> Keybuk: so, mainly hysterical raisins then?
<cjwatson> pitti: which of those deltas still exist?
<asac> but exim4 worked well for me with smarthost setup ... heaven't tried things like tls et al
<Keybuk> pitti: entirely hysterical raisins;  I have a qmail config that's survived for ~7 years, it would take me too long to learn another MTA and work out how to deliver e-mail how I'm used to with that
<pitti> cjwatson: ugh, ask me again when we are merging again; I don't remember the particular packages any more, but there are some where this is the only delta
<Keybuk> (OR) get used to a new method of delivering e-mail
<asac> in fact LAMP doesn't even install an example app
<asac> wonder if that is intentional
<pitti> cjwatson: mutt is one example
<jsgotangco> asac: why should it, a person running ubuntu server is supposed to know how to configure it in the first place right
<asac> yeah ... but you could argue the same for lamp things
<jsgotangco> a little phpinfo could help but beyond that would need a spec for future release
<elmo> is universe frozen yet?
<ogra> i dont think so
<elmo> anyone know for sure?
* iwj makes tea.
<crimsun> it's not.
<ogra> ajmitch, dholbach, crimsun someone else  ? ^^^
<jdong> try uploading a CVS snapshot of ffmpeg and see if it goes through :D
<jdong> lol
<elmo> crimsun: thanks - when does it freeze?  release?
<crimsun> elmo: pretty much.
<elmo> crimsun: k, thanks
<cjwatson> release minus a bit to let the buildds quiesce
<habeeb> Greetings, good gentlemen.
<habeeb> I created a thread in the forums, but well, I got no answers so I'll just ask here too. Why is there not a dual-boot auto-partitioner by default?
<habeeb> I mean.. it seems like such an easy thing to develop and I bet that it would really help Window to Linux switching.
<cjwatson> err ... there is?
<cjwatson> "Resize <Windows partition> and use freed space"
<cjwatson> it depends on whether automatic resizing is actually possible, which it isn't in all situations, though
<habeeb> I see... You know I asked in the other irc room too, and the guys who answered told me about the manual way..
<cjwatson> e.g. if you have too many primary partitions already, or not enough free space on a resizable partition, then auto-resize won't be offered
<habeeb> I see.
<cjwatson> pre-feisty, if you had more than a couple of GB of free disk space, it wouldn't be offered either; in feisty I decided that that was a mistake and removed that check
<cjwatson> mdz: do you still have the installation from bug 106971 lying around?
<ubotu> Malone bug 106971 in oem-config "Keyboard layout test doesn't seem to work in firstboot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106971
<habeeb> And tell me something else... Because it's been some time since I last used Ubuntu. If I, like, download the Feisty release tomorrow or whenever it comes out, will I have Beryl/Compiz by default in my _ATI_ card?
<cjwatson> we don't have beryl/compiz by default on anything (yet); we ship System -> Preferences -> Desktop Effects to let you turn it on
<cjwatson> depends on the vintage of your ATI card, of course; r500 support isn't in yet
<cjwatson> (for example)
<habeeb> and that will download/setup the fglrx drivers, and also install Beryl/Compiz?
<habeeb> I see...
<habeeb> No well, I'm saying that, because last time I used Ubuntu was in the start of the Edgy era, and I remember many many threads on the forums of people unable to setup DRI and their card correctly, and I'm wondering if the problem is fixed.
<cjwatson> System -> Administration -> Restricted Drivers Manager for fglrx
<habeeb> "problem"
<habeeb> Interesting!
<habeeb> Also, the kubuntu live-cd installer is the same as the ubuntu one?
<cjwatson> same codebase although a different frontend
<habeeb> ye..
<habeeb> ok
<habeeb> and right now, which is the default "desktop effects manager"? compiz or beryl? I think compiz, right?
<cjwatson> compiz
<cjwatson> I would really suggest #ubuntu+1 for more, though
<habeeb> Ye, ye, that was my last question anyway...
<habeeb> Thank you very much, sir.
<cjwatson> np
<pitti> tepsipakki: did you see that the intel driver FTBFSed across the board?
<iwj> cjwatson: And finally, I was wondering about your opinion of bug 107042.
<ubotu> Malone bug 107042 in debian-installer "expert install produced passwordless root account" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107042
<pitti> Mithrandir: http://pastebin.ca/443097 -> ok to upload?
<pitti> cjwatson: ^ Mithrandir seems to be afk, can you have a look at it, please? it does not affect the CDs
<Mithrandir> no, I'm not afk
<Mithrandir> I'm merely not staring at my irc client all the time
<Mithrandir> pitti: please upload.
<pitti> Mithrandir: oh, sorry, then ubotu lied
* pitti hugs Mithrandir 
<pitti> ubuntoid, even
<pitti> Mithrandir: thanks
<pitti> done
<shawarma> ubuntoid?
<fabbione> shawarma: bot
<shawarma> 19:13 -!- ubuntoid: No such nick/channel
<seb128> Mithrandir: could you accept the slab upload? It's broken at the moment due to a gnome-control-center libslab ABI change, the update makes it build staticly with the copy they ship, that's the easier way at the moment, we will clean it up next cycle
<Mithrandir> seb128: sure
<seb128> Mithrandir: thank you
<cjwatson> iwj: could I get /var/log/installer/cdebconf/questions.dat please?
<Mithrandir> mvo: I think I'll ask you to put your gnome-app-install upload in for -updates.
<mvo> Mithrandir: the changes are pretty trivial, could they be accepted if we have to re-spin the CD and rejected if not maybe?
<Mithrandir> mvo: it's not a critical bug so, no, I don't think that is a good idea.
<Mithrandir> mvo: about the update-manager crash; how common is this?
<mvo> Mithrandir: not very common, the user has to close totem while the codec search starts up to trigger it
<mvo> Mithrandir: so yeah, -updates is fine
<Mithrandir> uh, the update-manager one is a KDE related thingy so that's probably not related to totem?
<cjwatson> iwj: hmm, did you notice that the debconf priority wasn't actually set to low from the start?
<Mithrandir> bug 106863
<ubotu> Malone bug 106863 in update-manager "[kde]  Upgrade tool crashed" [Medium,Fix committed]  https://launchpad.net/bugs/106863
<mvo> Mithrandir: oh, sorry. I was thinking about the crash in g-a-i that got fixed 
<mvo> Mithrandir: the kde one seems to be happening more often, I would rather want to see it in
<mvo> if at all possible
<iwj> cjwatson: No, I didn't.
<cjwatson> at least it doesn't seem to have been
<cjwatson> Mithrandir: ^-- do you care about that? fix is a one-liner in gfxboot-theme-ubuuntu
<cjwatson> gfxboot-theme-ubuntu
<cjwatson> -    /dimode.option "DEBCONF_PRIORITY=low" def
<cjwatson> +    /dimode.option "priority=low" def
<Mithrandir> cjwatson: what does it require a respin of?
<cjwatson> syntax changed a while back; I updated everything else but not that :-/
<cjwatson> Mithrandir: alternate/server ISOs
<iwj> cjwatson: No, you can't have that file.  d-i didn't put it on my usb stick and it doesn't exist in the installed system AFAICT.
<iwj> But must go.
<cjwatson> mm, ok, I'll have to try reproducing it myself
<cjwatson> /var/log/installer/cdebconf/questions.dat should *definitely* be on the installed system
<mvo> Mithrandir: it seems to be triggered on a dpkg error, so we may move it into -updates on the ground that dpkg errors are rare (hopefully!)
<Mithrandir> mvo: trying to make up my mind.  It's on all the CDs so it'll require a full respin.
<iwj> ls: /var/log/installer: [enoent] 
<cjwatson> merp, weird
<cjwatson> that should never happen
<cjwatson> oh but you saved to a USB stick
<cjwatson> ok, I'm not familiar with that mode, will look later
* cjwatson -> dinner
<mvo> Mithrandir: it affects only kde, it will let Riddell decide
<mvo> Mithrandir: I need to run now, hockey
<Mithrandir> mvo: see you around.
<mvo> bye
<vciaglia> guys, firefox on amd64 crashes really a lot of times. To me causes the X restart too! Is there any fix? :/
<vciaglia> (i'm using the feisty fawn 7.04-beta)
<mako> who fixes planet ubuntu when it, for example, becomes planet mako
<cjwatson> wow, you got the full set
<kylem> you say that like it's a bad thing
<jdong> AAAHHH I SEE MAKO EVERYWHERE :D
<_ion> Haha
<mako> ALL MAKO ALL THE TIME
<mako> i prevented this on planet debian because i can clear the cache
<sn0> mako that is a lot of posts O_o
<mako> sn0: it's my entire rss feed, in fact
<jdong> mako: now all you need is an ALL YOUR BASE post and that'll top it all off :D
<sn0> excellent, maybe you can get planet.mako.net forwarded by dns oo planet.ubuntu.com too ;] 
<cjwatson> anyway, it's Canonical sysadmin for planet.u.n
<cjwatson> u.c
<Kmos> someone check this out.. LOL
<Kmos> bug 107062
<ubotu> Malone bug 107062 in kubuntu-docs "Linux.org is hurting Linux; don't recommend it" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107062
<mako> cjwatson: thanks, i sent a mail
<mako> the cache file for mako.cc just needs to be deleted or nuked, oh well :)
<Kmos> mako: if you change the date of the posts for yesterday they don't appear in the next refresh
<mako> Kmos: unfortunately, the dates *are* dated back.. but the feed they are using rss, not atom, so that trick doesn't work
<Kmos> mako: you can't change in the atom? <updated>2007-04-10T18:26:08Z</updated>
<mako> Kmos: sure i can, and i have, but planet.ubuntu.com isn't look at my atom feed at all
<Kmos> strange.
<mako> Kmos: it only knows about my rss feed
<mako> Kmos: it's not that strange, the feed was added before warty released and i think before i eve had atom support in my blog :)
<robertj> jdub: I enjoy the new all-jdub  all-the-time format of planet ubuntu
<mako> robertj: that's not jdub, that's me
<Treenaks> robertj: that's mako
<mako> robertj: but i'm glad you enjoy it
<robertj> doh ;)
<mako> i've filed a request to have it fixed :)
<robertj> got my nicks crossed
<jdong> well it's phanatic to the rescue :)
<phanatic> jdong: :)
<Mithrandir> janimo: system-config-printer> rejected; do it as an SRU.
<janimo> Mithrandir: ok
<Chriss_> tag
<Chriss_> und wie?
<Chriss_> fewefwe
<Chriss_> fwefwe
<Chriss_> kack
<bhale> phew.
<Arby> cjwatson: bug 99908
<ubotu> Malone bug 99908 in ubiquity "The ext3 file system creation in partition #1 of SCSI1 (0,0,0) (sda) failed." [Undecided,Needs info]  https://launchpad.net/bugs/99908
<Arby> is it worth me testing manual partitioning
<Arby> to see if I can reproduce what jerry reports?
<cjwatson> Arby: sure, though as I said it looks like your problem is due to running out of memory and that's not his prroblem
<cjwatson> honestly, you need more memory in that box to run ubiquity right now
<Arby> I know I know :)
<cjwatson> which is a bit annoying as you have 256MB
<cjwatson> maybe it's just Kubuntu ...
<cjwatson> Xubuntu at least has lower memory requirements and should definitely work, Ubuntu may
<cjwatson> there were also definitely CD read errors in some of your syslogs
<Arby> it's fine with auto-resize partitioning, it's just erase disk that struggles
<cjwatson> I have a feeling that's luck
<Arby> Xubuntu is fine, not tried ubuntu in a while
<Arby> I must be consistently lucky then :)
<cjwatson> I would love to figure out what's really going on, but CD read errors and out-of-memory are showstoppers and I can't get anywhere until those are eliminated
<Arby> OK we'll I'll try manual partition on my testbox
<Arby> then on a spare partition on my main box
<Arby> which has more ram :)
<Arby> and a much newer cd drive :)
<cjwatson> could just be dirty rather than old
<Arby> also possibly true
<cjwatson> I've had excellent luck with CD drive cleaners to revitalise drives
<Arby> I should get one of those
<cjwatson> in gutsy we'll have a version of squashfs that will fail much more abruptly on CD read errors, which will make this kind of thing easier to diagnose
<cjwatson> thanks to pkl
<Arby> shiny :)
<Arby> I'm happy to help out debugging ubiquity if you want me to try stuff.
<cjwatson> I'm absolutely keen to investigate if you can reproduce it on a system that has enough memory and isn't thrrowing squashfs errors
<Arby> my other laptop has 512MB so that should be enough
<cjwatson> one reason I was interested in getting info from Jerry - he has 512MB RAM
<cjwatson> that would be lovely
<Arby> it also has a spare partition :)
<Arby> well it has edgy on it but I can live without that
* Arby goes off to back up /home
<cjwatson> Arby: if I didn't mention it, btw, that update-dev thing I suggested was a red herring
<cjwatson> I forgot that there's a script immediately after the one I had you editing that already calls update-dev
<cjwatson> sorry about that
<Arby> yes you did say
<Arby> np
<cjwatson> ok
<cjwatson> but that does mean I have no explanation for why the device node isn't appearing, short of a kernel bug
<ajmitch> morning
<Arby> anything I can do? besides get more ram :)
<cjwatson> or an outside chance of libparted lying when it says it's committed the partition table changes
<cjwatson> I suppose it might also be possible to kill optional parts of the desktop, if possible - I don't know KDE
* cjwatson -> bed, sorry, will have an annoyed wife otherwise ;)
<Arby> np
<cjwatson> working on avoiding the CD read errors would be a good thing to try though - make sure to run the integrity check before booting
<cjwatson> it's not cast-iron, but it can help find problems earlier
<Arby> I always do
<Arby> it always passes
<keescook> hiya pitti.
<pitti> hi keescook, how are you?
<ajmitch> hey keescook 
<keescook> pitti: good! mostly done (finally) reviewing all the MOPB stuff with jmm and seanius
<keescook> hiya ajmitch!
#ubuntu-devel 2007-04-17
<geser> keescook: hi
<geser> keescook: have you seen the mail about the prepared cacti packages for dapper-security? https://lists.ubuntu.com/archives/ubuntu-motu/2007-April/001532.html
<keescook> geser: yeah, I did, unfortunately, his DNS has been down ever since.  :(
<geser> that's bad
<geser> keescook: I've checked it now and it works here
<keescook> geser: oh good!  thanks for checking
<Seveas> mako, please stop flooding planet ubuntu kthxbye ;)
<jcole> where did nvu go? http://packages.ubuntu.com/nvu
<geser> jcole: according to a comment in a bug it was removed because nvu is unmaintained upstream
<jcole> geser: hrm, i like it did tables... i wonder what a good alternative html gui editor would be
<jcole> geser: open office's html editor puts a bunch of unnecessary crap in the html
<geser> jcole: kompozer (http://kompozer.net/) is the successor of nvu but I don't know if there are packages already somewhere
<ajmitch> geser: there are on revu
<ScottK> jcole: Ping tonyyarusso (or soemthing close to that) on #ubuntu-motu.  He can hook you up.
<jcole> ScottK: will do
<jcole> thanks geser, ScottK 
<cjwatson> Mithrandir: erm, is it known that the xserver-xorg-video-intel source builds an xserver-xorg-video-i810 binary and will supersede that in main?
<cjwatson> tepsipakki: ^--
<cjwatson> this seems like a bad idea to accept
<pygi> hello folks
<ajmitch> hi pygi 
<mr_pouit> hey pygi 
<jcole> does dvd menu navigation now work in feisty's totem-gstreamer? on edgy and below, i usually install totem-xine to work around this...
<mjg59> No
<mjg59> Nobody's implemented it for gstreamer-0.10 yet
<jcole> ah, ok, back to totem-xine then
<jcole> mjg59: thanks
<pochu> jcole: feel free to implement it :-)
<jcole> later all, time to go home!
<pygi> Hobbsee & Jdong, hi :)
<jdong> hey
<Hobbsee> heya pygi!
<eck> what parameters should I run strace with when filing a bug report on a package that segfaults?
<eck> never mind, i found it in the wiki
<lifeless> mjg59: around ?
<mjg59> lifeless: Hi
<lifeless> mjg59: hi. I suspect my laptops hdparm etc stuff is on crack due to my fiddling with it ages ago, and I know you've done some work on sane defaults here. Whats the best way for me to get your recommended behaviour w.r.t. disk spindown when on battery?
<mjg59> Purge acpi-support and reinstall? :)
<lifeless> hdparm as well ? (or is /etc/hdparm.conf irrelevant ?)
<mjg59> Yeah
<lifeless> any other packages?
<mjg59> Shouldn't be
<lifeless> *boom*
<lifeless> (unclear sorry, I mean, I've hit the button to do that)
<lifeless> mjg59: thanks, will I need to reboot to activate the changes?
<lifeless> (please say no)
<mjg59> No
<lifeless> thank you!
<Nergar> hello
<Nergar> where can i take a look at the ubuntu todo list?? things developers are working on??
<Hobbsee> Nergar: http://wiki.ubuntu.com/MOTU/TODO
<Nergar> nice, thanx Hobbsee 
<RenatoSilva> hi guys, let me ask: will Feisty come with the newest GNOME 2.18.1 and be based on the newest Debian 4.0 "Etch"??????
<RenatoSilva> i guess that's not a coincidence
<jdong> RenatoSilva: Ubuntu is always based on Debian unstable/"Sid"
<jdong> and it will come with GNOME 2.18
<RenatoSilva> jdong: nice! dont' forget the additional 1 after "18"
<jdong> well if the point-releases hold worthwhile updates, they will be provided
<jdong> historically, that has been the case. Either Ubuntu is released with the .1 or .2 patches, or they are provided as post-release updates
<RenatoSilva> jdong: do you remember me from yesterday?
<jdong> yes, I do
<RenatoSilva> jdong: lets's start a meta discussion again, what about I notice Mr. Shuttleworth about the issue we've discussed yesterday? 
<jdong> it is probably worse for your cause if you pester more and more people about it...
<jdong> the specs process is already in place for proposing new features
<jdong> and shortcutting it by persistently nagging developers will not get you anywhere.... 
<RenatoSilva> jdong: i just want he keeps this in mind, as he says on his wiki page: "the problem is not to get funds, but allocate them to people and projects", so i think it's a nice place to invest money in case there's no volunteers available
<BenC> RenatoSilva: if it's a worthwhile spec, it'll get done by paid developers
<BenC> RenatoSilva: and that's what the spec process is for
<BenC> RenatoSilva: if it's not so important, then you, or whoever can do it
<RenatoSilva> BenC: and who does decide the importance of the spec?
<BenC> RenatoSilva: most likely, if you yourself aren't prepared to put in some work, then the spec will just die...it's not a process where you toss in a two-liner idea and expect us to work out all the details
<BenC> RenatoSilva: we the developers do
<BenC> mostly it's decided by mdz, cjwatson and Keybuk
<BenC> RenatoSilva: and just so you know, if you email Mark, the most likely answer will be very close to what I've told you here :)
<BenC> thought I can't speak for him directly
<BenC> s/thought/though/
<jdong> BenC: are you the one with the Macbook, or am I thinking of someone else?
<RenatoSilva> BenC: so let me sse if i've understand
<BenC> jdong: I don't own a macbook, but kyle does
<jdong> ok
<jdong> was just wondering how well it runs Ubuntu
<jdong> and also battery life figures
<RenatoSilva> BenC: teh spec is there, and you let the community starts to implement it, so the importance you give to it grows with feedback the specs obtains????
<BenC> I know ti runs Ubuntu, but I couldn't tell you details
<BenC> RenatoSilva: Most specs we implement are written by the ubuntu-core-dev team
<jdong> kylem: if you have a sec and could talk to me a bit about your macbook, let me know :)
<BenC> RenatoSilva: but yes, the importance, and likelyhood of a spec being implemented by us increases based on the support of that spec
<BenC> RenatoSilva: if someone proposes a spec, and doesn't follow through with the specs implementation details, discussions process, and approval, then we wont even look at it
<BenC> note, that's not because of it coming from the community
<BenC> even we have specs we propose that never even get approved
<lifeless> and we propose heaps
<RenatoSilva> BenC: I think that even if this feature suggestion and spec (winmodems out of the box) doesn't become main-stream in Launchpad (and I believe it's likely to happen since all dial-up users cannot connect to the internet so that can "protest", and almost many of the non-dialup users just *don't care* about the other ones), it's still a critical issue for all I've said yesterday. I think it's a *great demand* that is almost likely to keep *silent* an
<BenC> RenatoSilva: oh, check the spec list, I believe we already have this proposed
<BenC> ltmodem or something
<mjg59> The most common Winmodems (Conexant-based ones) can't be supported
<mjg59> Smartlink ones are already supported
<RenatoSilva> BenC: i know, there's a spec and a great wiki describing the "gravity" of the issue, as Mr. jdong and I have talked about yesterday
<mjg59> And ltmodem is in l-r-m, but breaks on SMP kernels, so
<jdong> RenatoSilva: winmodems are already supported to the best of our abilities
<jdong> mjg59: RenatoSilva was speaking about a new martian driver for the Agere 1648C's
<mjg59> If you want people to write new drivers, then I'm afraid Ubuntu isn't the best place to do it
<jdong> (it seems to be a relatively new driver though, but claims SMP support)
<mjg59> jdong: Oh, that one? The hack of ltmodem that puts half of it in userspace?
<RenatoSilva> mjg59: why? distribution limitation?
<mjg59> It's interesting. I remain unconvinced by the licensing aspect.
<mjg59> RenatoSilva: What, for the Conexant stuff? Yes.
<jdong> mjg59: I've never heard of it, so you obviously know more about it than I do :)
<jdong> also Conexant HDA drivers mess around with alsa
<Hobbsee> oh not this again...
<RenatoSilva> mjg59: doesn't linmodems.org have written some driver?
<mjg59> RenatoSilva: No
<jdong> I'm sure our alsa deity hates that :)
<mjg59> RenatoSilva: For Conexant modems, you have to obtain them from linuxant.com
<jdong> Hobbsee: good to see you :)
<mjg59> We don't have permission to redistribute them. Even the 14.4k ones.
<Hobbsee> hi jdong 
<Hobbsee> jdong: you might want to take to the forum pepole what BenC just said above, about the specs
<`23meg> Hobbsee, I'm a leader of the forum ambassadors team and will write a "feasibility FAQ" of sorts within a few days which will be along those lines
<ajmitch> `23meg: try & control the flood of ideas in the gutsy forum? :)
<Hobbsee> great, so we have a leader for it now?
<`23meg> we're trying hard :)
<Hobbsee> ajmitch: heh.  i've seen it.  lots of crack
<`23meg> we'll be doing our best to filter out the best of them and make them into mature, workable specs
<`23meg> Hobbsee, actually, four leaders
<Hobbsee> `23meg: and then propose that people actually do them?
<ajmitch> Hobbsee: that's expected
<Hobbsee> ajmitch: to which?
<ajmitch> about there being lots of crack
<Hobbsee> ah, yes
<RenatoSilva> jdong: so the "very hard work" you reffered yesterday are justo to *write* the drivers????
<jdong> RenatoSilva: not necessarily... both to write the drivers and to integrate the drivers into a distribution
<`23meg> at least one of the FA leaders will represent the most workable ones in uds-sevilla, maybe grouping some of the smaller ones into "pack" specs similar to common-customizations
<Hobbsee> `23meg: what concerns me is the fact that a lot of the documentation [idea] s that are there, the forum community should be able to get there and write themselves
<Hobbsee> yet they dont seem to, and prefer wand waving
<`23meg> i agree
<`23meg> we're steering them in that direction
<`23meg> as DIY as possible
<`23meg> we'll almost certainly need technical consultation on some of the ideas that can make solid specs, so i'll probably be bugging you around here until uds
<Hobbsee> heh
<RenatoSilva> jdong: I dunno about the other modems, but I believe the most common allow to be redistributed, and that integration work is not that hard I think, at least on the boudaries I'm around in my mind, let me give my example with Agere:
<jdong> RenatoSilva: we've already told you many times about the agere modem.
<jdong> the ltmodem driver is ALREADY in by default
<jdong> it just does NOT work on SMP kernels, hence you have to install the -386 kernel to use it
<jdong> and mjg59 has technical reasons why he is uncomfortable with the martian driver
<jdong> and the Agere is not the most common winmodem. By far the most common are Conexant HCF/HSF chipsets, of which there is no support we can include legally
<RenatoSilva> jdong: I can describe the detection of the modem and the installation of Martian as a simple shell script. From this towards a .deb is not that difficult I think (except that i dunno how to do it :D ), so I think that at least one very common modem can be embeded into Ubuntu and its installation, not being that difficult. Correct me please if I'm wrong...
<jdong> RenatoSilva: Please listen. A core developer has technical reasons why he is UNCOMFORTABLE with the inclusion of the martian driver.
<Hobbsee> RenatoSilva: and is the shell script on crack?  mjg59 clearly thinks it is
<mjg59> RenatoSilva: It's a PCI device. We don't need a shell script.
<mjg59> We already have support for autoloading drivers based on PCI devices.
<RenatoSilva> mjg59: I absoulutelly dunno how it could be implemented, but if it can be described as a simple script, for sure that a better thing can be done over it I think 
<mjg59> RenatoSilva: We could just include the driver. Right now I'm not especially happy to do so, but I'll look into it.
<mjg59> But already it should just work if you use the -386 kernel
<RenatoSilva> mjg59: then you coud autoload martian, but as jdong is saying, you have technical reasons to don't doing this, reasons that I can't undestand on my level of abstraction,  right?
<mjg59> RenatoSilva: Right
<mjg59> Or, rather, we have reasons not to include the driver right now
<mjg59> If we did include the driver, it would be autoloaded
<RenatoSilva> mjg59: if Ubuntu autodetect my mdem, then it should load ltmodem, when linux-restricted-modules was isntalled?
<RenatoSilva> mjg59: I think ltmodem would work with me, but don't remember why, it did not, am I right?
<jdong> yes, ltmodem would work if you installed the 386 kernel
<RenatoSilva> jdong: true! I forgot! you've said
<RenatoSilva> jdong: I'm in a Core 2 Duo, so that martian was my only option
<RenatoSilva> jdong: if someday you could feel comfortable with it, so you could include it in generic kernel
<jdong> RenatoSilva: right, which is why you would want a SMP capable kernel
<jdong> RenatoSilva: martian will likely be evaluated for the next release
<RenatoSilva> jdong: SMP?
<jdong> multi-processor
<jdong> the -generic kernel
<RenatoSilva> jdong: hum
<mjg59> RenatoSilva: Anyway, there's a defined process for specifying improvements to Ubuntu. This isn't the right place to ask technical questions unless they directly relate to Ubuntu development.
<RenatoSilva> mjg59: sorry again :D
<RenatoSilva> so I ask everybody
<RenatoSilva> if you 've undestand the critical importance of winmodem out of the box, and also undestand that the spec may fail, not because it's not important, but because it keeps hidden, silent, so *what can I (or we, dialupers) do* to fight it become true, so that it opens a great door for ubuntu adoption growing around the world???
<mjg59> RenatoSilva: Write drivers
<mjg59> Find other people to write drivers
<Hobbsee> RenatoSilva: find someone to bloody well code it yourself.  that's the simple solution, and the only way that you can be sure-fire guarenteed that it happens.
<Hobbsee> s/yourself/themselves/
<RenatoSilva> mjg59: another options? This i dunno! :D
<mjg59> RenatoSilva: Really, this is off-topic here
<Hobbsee> RenatoSilva: 
<Hobbsee> RenatoSilva: you've been told the solution over and over.  take what's been said, and act on it,  or dont complain when it doenst get done.  But you can quit disturbing the development channel, after you've been given the answer, time and time again. 
<RenatoSilva> so since I can't write drivers, i can't do nothing, only hoping!
<Hobbsee> you can find someone else to...
<RenatoSilva> and about the off-topic, this is why i meta-duscuss
<RenatoSilva> which channel do you recomment?
<Hobbsee> #ubuntu-offtopic
<fabbione> morning guys
<Hobbsee> hi fabbione 
<fabbione> hey Hobbsee 
<ajmitch> morning fabbione 
<fabbione> hi aj
<jtt> good evening
<jtt> does anyone know how i can force my 1G ethernet card to 1000FDX
<jtt> mii-tool only appears to work up to 100FDX
<fabbione> jtt: try mii-tools
<fabbione> then no...
<RenatoSilva> ok, there is the place where we say things that no one directly involved in the strategic decisions will be there to listen and consider, so i should be saying all my blah-blah-blah there, and be happy to it taking no effect. You don't care about us. Even proprietary, at least M$ listen its users. I'm sad with the way you treate me, and I gess I'm giving-up of all this and take my original Win copy free of charge that Microsoft provides me at Univ
<jtt> fabbione: at least the current man page show  10FDX and 100FDX  thansk
<RenatoSilva> sabdfl: very sad
<fabbione> jtt: i would like to have that problem.. my network switch is 100Mb ...
<jtt> fabbione: yeah 
<desrt> RenatoSilva; nobody pays for ubuntu.  there is limited money for the development of ubuntu.  there are only so many developers and only so many hours in a day.  important features that affect the highest numbers of users are prioritised.  some people get a raw deal.  with limited resources you can't possibly please everyone.
<desrt> RenatoSilva; sorry.  really.
<mjg59> desrt: This isn't the place to have this discussion
<desrt> mjg59; i agree
<mjg59> Anyway. Bed.
<desrt> good idea!
<RenatoSilva> desrt: this is a very important feature and affect all the dozens of millions of dial-up users we have here, *believe you or not*. It was a nice and great way to tell me: "Hey, if you want to help, WIRITE A DRIVER. Otherwise, STOP DISTURBING US". Very Nice.
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+o jdong]  by ChanServ
<desrt> Hobbsee; take it easy
<fabbione> guys calm down please
<fabbione> RenatoSilva: he didn't say or mean that.. so please calm down
<fabbione> RenatoSilva: if you believe that this is a really important issue please follow the escalation procedure for technical issue using the Technical Board
<jdong> RenatoSilva: please take this discussion to #ubuntu-offtopic... nobody is belittling the importance of winmodem support
* mode/#ubuntu-devel [-o jdong]  by jdong
<fabbione> RenatoSilva: this is not the right forum to express your hanger because we are in short of resources
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<RenatoSilva> fabbione: it's not a question of only expressing, but make a thing become real
<RenatoSilva> fabbione: please me redirect me to the right place (and offtopic is NOT) and I'll leave you right now
<fabbione> RenatoSilva: i understand what you are trying to do but this is not the right way to do it.. sure.. allow me a couple of minutes to find the procedure on the wiki page..
<RenatoSilva> fabbione: thanks!!!!!
<fabbione> RenatoSilva: ok the first pages you want to look at are: http://www.ubuntu.com/community/processes/governance and https://wiki.ubuntu.com/TechnicalBoardAgenda
<fabbione> RenatoSilva: specifically the Technical Board section.
<fabbione> RenatoSilva: in the wiki it's explained how to raise an issue to the Technical Board to raise the importance of the issue
<fabbione> RenatoSilva: now.. from my personal experience (so take it as you like), they might ask you to write a blueprint/specification on how to achieve this technical goal
<fabbione> RenatoSilva: in that case i suggest you look at .. /me looks for URLS...
<jdong> fabbione: a spec already exists....
<fabbione> jdong: yes.. i am getting there
<jdong> ok :)
<fabbione> RenatoSilva: https://blueprints.launchpad.net/ and https://blueprints.launchpad.net/ubuntu/+spec/winmodem-support
<fabbione> RenatoSilva: from there you see what has been done/what is the status/why it's not done yet and so on...
<fabbione> RenatoSilva: you can also find the names of the people that have been working on the specification and see if the specification is correct or not
<fabbione> RenatoSilva: does this answer your question?
<fabbione> brb
<micahcowan> RenatoSilva, please realize, the issue isn't that we don't want to fix the problem, it's that it's a very difficult problem: the manufacturers of your modem card have decided /not/ to let people take a look at how it works, which makes it very difficult to write drivers for. They, of course, wrote their own drivers for Windows, but it's really not the Linux/Ubuntu developers' fault that we don't have a quick-n-easy s
<micahcowan> olution for you...
<fabbione> re
<micahcowan> dict -d vera re: re = r&e = research & engineering... :/
<RenatoSilva> fabbione: : i have to read the docs you passed  me to know if it answer. But finally anywway i'll stop after all docs on that spec, so i hope that I can actively get involved on it, helping to improve its importance. I have saved your links, tahnk you very much.
<fabbione> RenatoSilva: getting involved would be lovely.. specially because that will extend the user base and hardware where we can get help for testing
<fabbione> RenatoSilva: as you can imagine yourself it's not possible for us to have access to all variants of all hardware
<fabbione> RenatoSilva: 
<fabbione> ops
<fabbione> RenatoSilva: so any extra help is good
<fabbione> RenatoSilva: in regard of the docs, what you really want to read carefully is how to escalate issues to the Tech Board. This is important if you feel that the issue has not been prioritize properly.
<RenatoSilva> fabbione: that's what I'm trying to do "though humanly" difficult
<RenatoSilva> fabbione: thanks about the doc, I'll focus specifically on that, I think this is exactly what I'm searching for
<fabbione> RenatoSilva: yes as i said i do understand why you come here and the reason why i am pointing you to those docs, is because you were using the wrong way.
<fabbione> RenatoSilva: anyway i am glad that we are partially solving this little accident.. but i would be glad if next time we can use a more appropriate forum 
<RenatoSilva> micahcowan: What i'm saying and what spec also does is that some modems have proprietary linux drivers that can be redistributed, and now with the new policy of including propietary software such as MP3 codecs into Ubuntu default install, it could be applyed to modems too. *At least these could be supported*, such as, but not limited to, mine. I was sad because of the "human" isse: "WRITE A DRIVER OR GET OUT". But now Fabbione is treating me with 
<RenatoSilva> Now I'll do what I said. I'll read that docs and stop disturbing you, very sorry and thanks to fabbione
<jcole> has this been fixed in 2.6.20-15? i'm running 2.6.20-13 -> http://pastebin.ca/444038
<Mithrandir> uh, we don't include proprietary codecs in a default installation.
<Mithrandir> that'd leave us extremely vulnerable to lawsuits, etc.
<Treenaks> Mithrandir: installation is made easy though
<fabbione> ok guys.. i think we have addressed (partially at least) the problem with Renato.. let's stop the mess here since we have a release to do
<RenatoSilva> fabbione: that message was written minutes before you told me that thing, forget it all
<fabbione> RenatoSilva: ok it was also to everybody else.. not just you...
<fabbione> RenatoSilva: good luck
<RenatoSilva> fabbione: for you too
<fabbione> RenatoSilva: gracias :)
<RenatoSilva> fabbione: obrigado! tenha um bom dia!
<fabbione> RenatoSilva: anche a te!
* Mithrandir twiddles his thumbs while new Kubuntu images are building.
<ajmitch> morning tollef
<Mithrandir> morning Andrew
<jtt> good morning all
<jtt> anyone know how to force 1G card to 1000FDX  mii-tools only appears to go to 100FDX
<micahcowan> mako, ping
<dholbach> good morning
<ajmitch> hey daniel
<pitti> Good morning
<ajmitch> & pitti :)
<dholbach> hey Andrew
* pitti hugs ajmitch 
<AndrewB> Hello?
* pitti hugs AndrewB, too :)
<carlos> pitti: hi
<carlos> pitti: Could you check where is being installed quanta.mo files?
<pitti> hey carlos!
<carlos> pitti: I see it exported from Launchpad, but kde base packages doesn't have it
<carlos> pitti: https://bugs.launchpad.net/ubuntu/+source/kdewebdev/+bug/46156
<ubotu> Malone bug 46156 in kdewebdev "Quanta with wrong language (English)" [Medium,Confirmed]  
<pitti> ./sources-base/language-pack-kde-hu-base/data/hu/LC_MESSAGES/quanta.po
<pitti> carlos: ^ et al
<pitti> carlos: plenty of them in the kde packages
<carlos> carlos@aragorn:~$  dpkg -L language-pack-kde-de-base|grep quanta
<carlos> carlos@aragorn:~$
<carlos> Using 7.04+20070412
<carlos> pitti: it seems to affect Edgy too
<carlos> not sure about Dapper
<pitti> carlos: edgy-updates has them in the kde-base sources, too
<pitti> Copying pt_BR/quanta into package ../edgy-updates/sources-update/language-pack-kde-pt
<pitti> and so on
<pitti> carlos: the po files have a lot of errors, though, so they might not actually be compiled into a .mo file
<carlos> oh!, I see...
<carlos> hmm
<carlos> do you have the log output?
<pitti> carlos: well, errors in pt and oc only
<pitti> carlos: http://people.ubuntu.com/~pitti/langpacks/ <- logs
<carlos> pitti: ok
<dholbach> hey seb128!
<seb128> hi dholbach
<carlos> pitti: that's weird... Launchpad should export 100% valid .po files...
<pitti> carlos: apparently not :(
<dholbach> heya mvo
<mvo> hey dholbach
<mvo> good morning
<pitti> hiya mvo
<Hobbsee> hi mvo, dholbach, pitti 
<dholbach> hey Hobbsee
* dholbach hugs Hobbsee
* Hobbsee hugs dholbach :)
* pitti dances around Hobbsee 
<Burgundavia> mjg59: you around?
* Hobbsee backs away from the crazy pitti....
<mvo> hello Hobbsee, pitti
<Mithrandir> Hobbsee: isn't that hard to do when he's dancing around you?
<Hobbsee> Mithrandir: depends how quickly i run away :P
<pitti> Hobbsee: thanks for the video-intel fix; I'll wait with NEWing until this has built
<Hobbsee> pitti: :) no problem
* pitti doubles his revolving speed
<tepsipakki> Hobbsee: oh! :)
<tepsipakki> good catch
* Hobbsee watches pitti lose it, and smash against a wall or something
<pitti> oh, c'mon, 180 bug mails in 12 hours?
<pitti> seb128: ^ how many must you get, 3000? :-(
<seb128> pitti: might be due to me, I closed over 300 NeedInfos desktop bugs yesterday
<pitti> seb128: oh, that's great then :)
* pitti hugs seb128
* seb128 hugs pitti back
<pitti> seb128: no, that wasn't it unfortunately; mostly networkmanager spam
<seb128> :(
<seb128> maybe somebody cleaned it? ;)
<stub> Launchpad going down in 10 minutes for a code and database update. Estimated downtime is 10 mins or less.
<heno> *** New Kubuntu CD and DVD entries posted at https://www.stgraber.org/ubuntu/isotesting/ -- 20070417 ***
<mdz> cjwatson: no, I erased the installation  from 106971, but could easily recreate it again in vmware
<mdz> cjwatson: I didn't chase it as it seemed a minor issue, certainly for the moment
<Mithrandir> morning Matt
<pitti> hi mdz
<cjwatson> mdz: sure, was just in case you had it handy
<cjwatson> I agree it's clearly minor
<Riddell> heno: thanks
<shawarma> Hmm. Wasn't the multiminute delay in creating logical volumes fixed?
<fabbione> shawarma: no.. release note
<fabbione> https://wiki.ubuntu.com/FeistyKnownIssues?action=show
<shawarma> fabbione: Oh, ok. It's just in the installer, though?
<fabbione> only text installer 
<fabbione> yes
<fabbione> it (should) work in the installed system
<shawarma> Alright.
<shawarma> fabbione: Do we know what causes it?
<fabbione> sharms: yes.. look at the bug
<shawarma> fabbione: The bug speaks about the lilo installer being broken, not much about lv creation taking a long time. Am I perhaps looking at the wrong bug?
<fabbione> shawarma: i see why.. second.. i will fix the wiki page
<fabbione> wrong url link
<shawarma> fabbione: Coolio.
<fabbione> try again :)
<shawarma> Ah, that makes much more sense. >/(
<shawarma> Er.. Gah, frickin US keyboard layout.
<shawarma> >/) == :-)
<fabbione> iwj: did you ever get around to file a bug for that raid thingy? otherwise i am going to do it and add it to the release notes.. 
<cjwatson> Mithrandir: bug 99908 looks like it may be Xubuntu-specific ubiquity breakage
<ubotu> Malone bug 99908 in ubiquity "The ext3 file system creation in partition #1 of SCSI1 (0,0,0) (sda) failed." [Undecided,Needs info]  https://launchpad.net/bugs/99908
<cjwatson> at least, jerrylamos' hijacking of that bug
<Mithrandir> cjwatson: is there anything you want from bug 107205?  (I just filed it, attached a copy of /var/log/installer); I'm about to blow away the installation.
<ubotu> Malone bug 107205 in debian-installer "LVM install crashed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107205
<Mithrandir> (and yes, it's a terrible title)
<fabbione> Mithrandir: what do you mean by crashed?
<fabbione> what happened exactly?
<Mithrandir> fabbione: I chose guided (LVM) got the "something blew up" error and retried, it then worked.
<fabbione> hmm ok...
<Mithrandir> iirc, the previous install was an desktop install off the same kubuntu dvd.
<fabbione> Mithrandir: is it reproducible? like on each install?
<Mithrandir> I haven't retried yet, I suspect what was on the disk from before was relevant.
<Mithrandir> ubuntu-server installed fine earlier at least.
<fabbione> Mithrandir: i can see there is an error coming from partman-lvm.. but it shoudl have warned you that there was already a VG/LV enabled..
<fabbione> Mithrandir: sorry to sound paranoid, but are you sure it didn't warn you that there was already one vg/lv enabled and that they had to be wiped to proceed? it's sort of a new warning
<Mithrandir> iirc, there wasn't.  Previous install was just two partitions.
<fabbione> might be that one of the previous one was lvm?
<fabbione> there is the chance that there were dirty lvm data on the disk
<Mithrandir> yes, so the metadata might very well still be on the disk.
<fabbione> that's the possibility than
<fabbione> Apr 16 14:04:57 partman-lvm: Physical volume '/dev/sda5' is already in volume group 'blupp'
<fabbione> Apr 16 14:04:57 partman-lvm: Unable to add physical volume '/dev/sda5' to volume group 'ubuntu'.
<fabbione> and then it proceed properly
<fabbione> tho the warning should have been there
<fabbione> i wonder if the priority of the warning is too low in kubuntu
<fabbione> or something along that line
<Mithrandir> it's the same d-i
<fabbione> oh right.. d-i
<fabbione> i guess it was because of the old lvm metadata
<fabbione> it still won't explain why re-running it would have worked
<iwj> fabbione: No, I'm afraid I didn't.
<fabbione> iwj: no problem.. we are still in time.. should i do it?
<iwj> I'll do it now.
<fabbione> ok great thanks
<cjwatson> Mithrandir: I reckon partman-auto-lvm was written before partman started automatically activating volume groups, and so has no idea how to deactivate them
<cjwatson> reassigned to partman-auto-lvm
<iwj> fabbione: bug 107211
<ubotu> Malone bug 107211 in linux-source-2.6.20 "udev event for md setup sent too early" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107211
<fabbione> iwj: thanks..
<iwj> Is there a way to subscribe "the bug contacts for mdadm" or do I have to create a spurious task ?
<iwj> fabbione: Shall I subscribe you ?
<fabbione> iwj: i am adding myself thanks
<fabbione> actually it's assigned to the kernel.. i get them all :)
<ogra> seems the ppc alternate for ubuntu and edubuntu are oversized, do we care for that with a last minute seed change or do we just ignore it ?
<cjwatson> powerpc -> not release-critical
<ogra> (i guess we could drop something from supported without affecting other stuff)
<cjwatson> supported does not affect the alternate CDs
<ogra> cjwatson, i know, thats why i ask about the plans :)
<ogra> err, ship, sorry
<pitti> ogra: ugh, they were within the limit about three days ago
<cjwatson> I'll take a quick look at language packs
<ogra> ok
<pitti> cjwatson: can it be that they still have some old kernels or so?
<cjwatson> but if it can't be done in ship, we won't change desktop to cope
<pitti> they had been at 730 MB, and suddenly at 690 MB the day after
<cjwatson> pitti: not in alternate, no
<pitti> hmm, weird
<pitti> cjwatson: indeed I added some 15 MB of langpacks to ppc/alternates recently, because there was plenty of space; but not nearly enough to cut down by 45 MB
<ogra> edubuntu is only at 727M
<ogra> and intrestingly kubuntu is fine 
<TomaszD> pitti, hello. Where have all the daily langpacks gone?
<pitti> TomaszD: into feisty proper :)
<TomaszD> pitti, oh no. So it's too late for any changes now?
<ogra> pretty much
<pitti> carlos needed to shutdown the Rosetta export for a bit, so I'll continue to build them in May, when the next regular update is due
<pitti> TomaszD: everything will go into feisty-updates, don't worry
<TomaszD> just one more tiny upload, maybe...? :P
<TomaszD> *sigh*. OK.
<pitti> TomaszD: no, CD images are looking good, and will most probably not be updated any more
<ogra> TomaszD, "one more tiny upload" == some 100 manhours of testing :)
<TomaszD> ogra, didn't know. :]  oh well.
<Mithrandir> TomaszD: the deadline was close to a week ago.
<TomaszD> I just missed the time-frame within which network-manager's "manual configuration" elements appeared in lp
<cjwatson> the reason we have language packs is so that this stuff can be updated after release
<TomaszD> fine fine, no problem.
<TomaszD> one more question, what's the date of the proper langpacks?
<TomaszD> wait, I can check that myself, can't I...
<pitti> TomaszD: version string
<TomaszD> 12th April
<TomaszD> damn, the gnome-panel update didn't go in as well, shucks.
<TomaszD> I guess I can only blame myself. Too late, too late. 
<TomaszD> pitti, langpack update is due in May, yes?
<pitti> right
<TomaszD> feisty-updates enabled by default, cool. No more questions here. So, you/we're pretty much done with feisty, right?
<pitti> TomaszD: let's cross our fingers
* TomaszD crosses fingers
<TomaszD> I'll hold my congratulations then
<TomaszD> :] 
<cjwatson> I suppose I could take language-support-en or build-essential off powerpc ship
* ogra votes for build-essential
<cjwatson> the monolithic nature of language-support-en is the bane of my life
<pitti> weird, expert on Kubuntu falls back to guided mode after configuring the keyboard
<cjwatson> I think that may be the gfxboot-theme-ubuntu bug I fixed but didn't push for since I couldn't figure out actual effects that it had
<pitti> is there a workaround?
<cjwatson> try entering expert mode by adding priority=low to the kernel command line rather than using the F6 menu
<pitti> ah, cool
<cjwatson> let me know if that works
* Riddell yet to try expert
<pitti> cjwatson: right, much better
<pitti> Riddell: doing amd64/alternate tests, FYI
<cjwatson> Mithrandir: ^-- FYI reproduction of the gfxboot-theme-ubuntu problem; shame I didn't go past console-setup when testing ...
<cjwatson> probably too late now though
<pitti> cjwatson: shuold I file that as a new bug, or is there an existing one?
<cjwatson> pitti: no, could you file a bug on gfxboot-theme-ubuntu about that
<cjwatson> ?
<pitti> of course
<pitti> thank you
<cjwatson> no existing one I mean, AFAIK anyway
<Mithrandir> cjwatson: can you make sure it's release-noted?
<pitti> no, I didn't see one on g-t-u
<pitti> bug 107220, FYI
<ubotu> Malone bug 107220 in gfxboot-theme-ubuntu "selecting expert mode does not work for Kubuntu" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107220
<cjwatson> pitti: I do not see how it could avoid affecting the Ubuntu alternates - are you sure?
<cjwatson> at that level there should be no difference
<pitti> cjwatson: weird, I did an expert install with raid yesterday with the .15 images
<pitti> cjwatson: I can try again to verify, of course
<cjwatson> Mithrandir: done
<cjwatson> pitti: I don't suppose it matters all that much
<Mithrandir> cheers.
<mneptok> who's packaging zsh for coredev?
<mvo> cjwatson: can we have recommends in ubuntu-minimal too for will that confuse something in the installer? I'm thinking of a fix for bug #42555
<ubotu> Malone bug 42555 in update-manager "syslog-ng causes ubuntu-minimal to be removed." [Wishlist,Confirmed]  https://launchpad.net/bugs/42555
<cjwatson> mvo: no, I'm afraid not
<cjwatson> at least not without serious debootstrap testing
<cjwatson> mvo: feel free to remind me after feisty and we can have a look at it
<mvo> cjwatson: ok, sure
<Mithrandir> mneptok: TIL, afaik.
<cjwatson> mneptok: it's imported from Debian with relatively small changes
<mneptok> k
<mneptok> (4.3.3 just dropped. might be nice to have it for Feisty.)
<cjwatson> mneptok: absolutely not
<cjwatson> unless it fixes security vulnerabilities
<Mithrandir> in which case it should go to -security.
<cjwatson> and even then it should go in post-release
<cjwatson> mvo: it might actually work ok, thinking about it - would still want to go through it all fairly carefully though, as minimal's a bit weird
<mvo> cjwatson: I taged it "later", lets have a look early
<cjwatson> hmm. for powerpc, dropping build-essential saves 4674948 bytes, while dropping language-support-en saves 19121700 bytes. Neither gives the 27847370 bytes I need
<cjwatson> pitti: is language-pack-en produced in such a way as to drop msgstrs identical to msgids?
<cjwatson> apparently not
<pitti> cjwatson: I could download 13 and 15 and compare them to find out where the heck those 70 additional MB come from
<pitti> cjwatson: no, I don't think so; they should rather be empty than identical, though
<cjwatson> pitti: for gutsy, could you make langpack-o-matic not waste 5+MB on language-pack-en when most of the msgstrs are just the msgids?
<pitti> cjwatson: definitively, we should either just fix it in rosetta or I mangle them in langpack-o-matic
* cjwatson would be inclined to mangle it - the en_BLAH completists seem to like filling up their statistics
<cjwatson> I don't care really as long as it stops affecting our CDs ;-)
<pitti> carlos: ^ can we easily detect that in Rosetta proper?
<cjwatson> in Rosetta, I'd think it should be preserved but not exported
<carlos> pitti: I think so, yes
<carlos> pitti: please, file a bug
<pitti> carlos: will do, thanks
<carlos> thank you
<iwj> cjwatson: Can I overwrite the broken expert mode install (the one with no normal user and no root password) ?  I'll still have the files the installer saved to the usb stick.
<cjwatson> iwj: yes, that's fine, thanks
<cjwatson> iwj: what other files got saved?
<iwj> The installer created an `install' directory containing hardware-summary install-report.template lsb-release partman status syslog
<iwj> cjwatson: ^
<cjwatson> Thanks. Maybe it's because that function is also used for saving to floppies
<cjwatson> oh well, I'll see if I can reproduce it myself at some point
* cjwatson has about three hours' worth of other reproductions in his queue
<cjwatson> pitti: so, Edubuntu/powerpc was easy to fix, but Ubuntu/powerpc less so. I've been experimenting with germinate, and I think the most practical set of things to drop from Ubuntu powerpc ship (not other flavours - in particular not Edubuntu) would be lsb-*, apache2-mpm-worker, ltsp-server-standalone, ltsp-client, ldm, and language-support-en. What do you think?
<pitti> cjwatson: I just finished rebuilding the kernel only server to diff the 13 vs. 14.1 iso images; I'm interested what the actual cause for the huge size increase is
<pitti> cjwatson: oh, we ship apache on the alternate CDs? interesting
<cjwatson> I'm not concerned about certification for ports architectures, hence lsb-*; ltsp is useful to have in Ubuntu for our supported architectures but I think it's a edge case on Ubuntu powerpc; I couldn't make up the required size without language-support-en; and apache2-mpm-worker just seemed like a reasonable target for a couple of extra MB
<cjwatson> I think build-essential is actually kinda useful to keep at least for ps3
<pitti> cjwatson: right, but IMHO its removal causes little pain; as a developer system, the default installation is incomplete anyway
<cjwatson> pitti: 13 was smaller because linux-image-*-2.6.20-15-* was accidentally missing
<cjwatson> it's clear from a diff of the .list files
<iwj> cjwatson: I can try to reproduce it in some other way, eg by not saving to usb stick.
<pitti> cjwatson: not sure what you mean; 13 had 14.12
<cjwatson> pitti: which of the ones I suggested would you prefer to keep? (note language-support-en is not an option, it's just too big - and build-essential + lsb-core gets rid of 3MB more than the sum of either of them alone)
<cjwatson> pitti: sorry I mean that linux-image-2.6.20-*.deb was missing from 13
<cjwatson> IOW, 13 was broken
<pitti> ah, indeed
<cjwatson> I'll try build-essential + lsb-core + language-support-en + ltsp|ldm*
<pitti> cjwatson: what is ldm?
<cjwatson> part of ltsp
<pitti> I don't see anything I your list that makes me cry 'OMGweneedthat'
<pitti> is apache necessary for ltsp? still curious why we have that in the first place
<saispo> hi pitti and cjwatson :)
<ogra> no
<cjwatson> pitti: "# ThomMay; for simple file/web serving -> add zeroconf and we have swish mac os x style :-)"
<pitti> seems like a good candidate for 'first against the wall' if we get gutsy space problems
<ogra> pitti, it would be a recommends or dep :)
<ogra> (if ltsp would need it)
<pitti> hi saispo 
<thom> heh
<thom> cjwatson: good grief
<saispo> kernel 2.6.20-15 is the final kernel for feisty release ?
* pitti will cry out very loudly if it wasn't
<saispo> :)
<pochu> saispo: 15.27
<saispo> pitti: it's normal in the git tree, when i try to build it i have an error on vboxdrv ?
<pygi> pitti, are we back to /dev/hdX with that or?
<saispo> source vbox driver are not in git ?
<mjg59> pygi: Depends on your chipset
<pitti> saispo: -> #ubuntu-kernel, please; I don't  know
<saispo> ok
<pygi> mjg59, got it, thanks
<pitti> pygi: not for me; I got hda->sda change only two weeks ago
<pygi> pitti, nod, got that part.
<pitti> (yay for enforcing freezes and such)
<pygi> siretart, got a couple of news for you, we'll talk later
<pygi> laters folks, uni calls
<iwj> Freaky, am I testing the wrong dvd here ?  I just installed it and now it is offering me software updates.
<iwj> feisty-dvd-i386.iso 20070416 8956582e1e7ba94db14c5a557079fa9a
<iwj> Hmm, that's the one from Testing/md5sums.
<iwj> It's offering me update-manager{,-core}
<Mithrandir> iwj: that is correct.
<Mithrandir> we have a small skew there; I decided to ignore it rather than having to respin and retest all the images invalidating the testing we have already done.
<iwj> Mithrandir: Fair enough.
<iwj> Is the oem prompter supposed to be translated ?
<cjwatson> iwj: not yet
<cjwatson> (known bug basically)
<iwj> OK.
<pitti> mvo: wrt bug 42555, I entirely disagree
<ubotu> Malone bug 42555 in ubuntu-meta "ubuntu-minimal should support recommends (was: syslog-ng causes ubuntu-minimal to be removed.)" [Wishlist,Confirmed]  https://launchpad.net/bugs/42555
<mvo> pitti: why?
<pitti> mvo: if people replace random things in ubuntu-minimal with alternatives, then it is not a standard ubuntu system any more, and they should be aware of this
<mvo> pitti: this probably comes down to a policy decision. it seems to me like stuff like "vim-tiny" does not necessarily have to be a depends (and the case of syslog can be argued too). but if we do not want that, then the bug should be rejected and nothing should change 
<pitti> mvo: right
<pitti> mvo: but we e. g. often ask for syslogs in bug reports and such, so I would call the logging rather important
<mvo> pitti: the release-upgrader will install ubuntu-minimal and ubuntu-standard if its not installed already by default currently, people who do not want this have to use apt-get (or aptotidue)
<pitti> mvo: ah, nice; well, that solves half of my suggestion :)
<mvo> pitti: fair enough, I have no strong opinions about this, I'm fine with rejecting it.
<mvo> pitti: update-manager will also make sure that a -desktop package is installed
<pitti> mvo: if it's uninstallable, what will it do?
<mvo> pitti: fail and report the failure (something like "a essential meta-package could not be upgraded")
<mvo> pitti: but in the case of the reporter it will just replace syslog-ng with syslog (this is of course displayed before the user performs the upgrade)
<pitti> mvo: uh, let's hope they actually read that
<mvo> pitti: its listed first and in bold
<doko> cjwatson: bug 105701; so there's no way to install with the optimal screen resolution? the alternate installer does it.
<ubotu> Malone bug 105701 in gfxboot "screen resolution 1920x1200 not offered" [Undecided,Rejected]  https://launchpad.net/bugs/105701
<cjwatson> doko: you mean the X resolution set up by the alternate installer?
<doko> cjwatson: yes
<cjwatson> doko: and are you trying to use that menu to set the X resolution for desktop boot?
<cjwatson> doko: that's not what it does - it passes a vga= option for console framebuffer resolution
<cjwatson> it might be best to remove that menu for desktop CDs, I guess
<doko> cjwatson: hmm, well removing it would mean that I don't have any option to enter nosplash (avoiding my kernel panic)? maybe I should just buy a new graphics card ...
<cjwatson> uh, the VGA/screen-resolution menu does not have anything to do with usplash
<cjwatson> I mean that particular menu, not the entire CD boot menu
<doko> ok, but my workaround to avoid the kernel panic was to select some resolution except the default one
<cjwatson> you should also be able to edit the kernel command line and remove splash from it
<mjg59> doko: This is only on the edubuntu DVD?
<cjwatson> F6
<doko> mjg59: that's the only one I'm currently testing; but I don't think so
<mjg59> doko: When did this first start happening?
<doko> mjg59: did see it in the beta, but I didn't check/see it before
<mjg59> doko: But you only filed the bug last week?
<cjwatson> doko: can you get e.g. a digicam photo of the kernel panic?
<cjwatson> I doubt the kernel team will be able to do anything at all with a report that just says "the kernel panicked"
<doko> rebooting; currently I only did see two keyboard LED's blinking
<mjg59> Well, if it's only happening when vesafb isn't loaded, it's probably a usplash/svgalib issue
<mjg59> doko: Which platform?
<doko> mjg59: amd64, with a Radeon 9600 graphics card
<mjg59> And does i386 on the same hardware have the same problem?
<doko> mjg59: have to check ...
<doko> cjwatson, mjg59: removing the splash option let's the kernel boot; keeping the splash option I only see a black screen, so no chance for a photo
<cjwatson> does usplash work properly if you have a serial console attached?
<mjg59> Yes
<doko> ok, will get a serial cable
<pitti> Riddell: kubuntu oem app looks great!
<Riddell> pitti: doesn't it just :)  what happens when summer of code goes right
<Mithrandir> pitti: sabdfl talking about apport: http://news.zdnet.com/2100-3513_22-6175365.html
<pitti> Mithrandir: ugh, it's not enabled any more...
<StevenK> "Some versions of Ubuntu come with long-term, five-year support--the first and most recent being 6.04, called Dapper Drake."
* StevenK twitches
<jsgotangco> they forgot we delayed it
<bhale> i cant imagine it is written as 6.04 almost anywhere
<StevenK> It just looks ... wrong.
<Treenaks> they probably extrapolated backwards :)
<cjwatson> we did talk about it as 6.04 for a while, but I thought we'd edited away most of that
<Treenaks> redac^Wedited
<StevenK> cjwatson: I can't recall any place off the top of my head that mentions Dapper as 6.04
<iwj> Google shows that we referred to it as 6.04 quite a bit before we released it.
<cjwatson> yes
<cjwatson> though that is an article based on an interview with sabdfl who's well aware of the version number :-) so I assume they got it from Google rather than from him
<sharms> I am waiting for a couple releases down the road when we get to "S".  I will be trying to get the name "Sexy Sharms" for that release :)
<sabdfl> sharms: you may need to create your own derivative for that :-)
<mc44> sharms: only 5 years to wait :)
<sharms> ha, well you guys know where to reach me
<pitti> sharms: 'sabdfl' 'Shuttleworth' might have his own ideas about 'S' :-P
<sabdfl> "the skanky sab" has a certain ring to it
<sharms> that sounds like great gimp material :)
<Treenaks> sabdfl: or seb ;)
<bddebian> Heya
<ion_> Hi
<bddebian> Hello ion_
<pitti> hi ion_ 
<micahcowan> sexy sharms... hm... ubuntu-calendar reborn? :)
<sharms> I got the pictures taken already, just waiting for the call!
<bhale> you're kidding
<tkamppeter> Mithrandir, I have found a bug in the DVD ISOs (all except Kubuntu): See bug 86893, The DVDs contain python-qt (http://cdimage.ubuntu.com/dvd/current/feisty-dvd-i386.list) but do not install it. This prevents the HPLIP GUI tools (like the HP Toolbox) from working out-of-the-box.
<ubotu> Malone bug 86893 in ubuntu-meta "[Feisty]  Starting HPLIP Toolbox in DVD edition or after update through internet: No python-qt3, but plenty of space on DVD or internet repository" [High,Confirmed]  https://launchpad.net/bugs/86893
<bhale> april 1 is past
<sharms> bhale: don't underestimate the sexy-ness of my winterhat / beard combo
<bhale> i would look but mako is flooding my rss
<sharms> haha I just dug up this one: http://www.mindwarp.net/img/sohot.jpg
<sharms> and you will only get my humor if you have seen the movie zoolandeer
<doko> pitti: was the generation of locales during the installation of language-support-* packages fixed for feisty?
<pitti> doko: no, it wasn't; it's pretty tricky to achieve with our current system
<doko> pitti: do you have an open report?
<pitti> I don't think so
<ogra> are we still preparing for RC ? i guess the topic needs an update :)
<Keybuk> we're preparing for R
* ..[topic/#ubuntu-devel:ogra] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy, #ubuntu+1 for feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Main frozen for release preparation
* ogra drops the C :)
<Lure> Riddell: unfair treatment of kubuntu: http://fridge.ubuntu.com/node/864 ;-)
<bhale> ogra: rock
<ogra> :)
<ogra> Keybuk, do you have an opinion about bug 107252 ?
<ubotu> Malone bug 107252 in udev "Group of /dev/fuse not set by /etc/udev/rules.d/45-fuse.rules when using LDAP" [Undecided,Rejected]  https://launchpad.net/bugs/107252
<Riddell> Lure: yes, but I've always taken the view of being happy with what we get
<Lure> Riddell: that is why I have put ;-)
<Keybuk> ogra: I believe I started my opinion in the bug, no?
<ogra> ah
<ogra> i didnt reload yet, thanks :)
<Keybuk> it's a long standing rule that users and groups for system services belong in /etc/passwd and /etc/group, not on LDAP
<Keybuk> and that LDAP is for physical users and NPC users
* Mithrandir didn't know Keybuk was an RPGer.
<Keybuk> Mithrandir: once-apon-a-time, yeah
<ogra> heh
<Keybuk> NPC, user account for some automated task or cronjob :p
<viviersf> k right
<viviersf> if you run ubiquity in debug mode
<viviersf> where does the logs go
* Mithrandir goes home.
<AlinuxOS> asac, hello, I still get this for Georgian language: http://gnome.inet.ge/alinux/firefox.png
<\sh> mdz: do we have a documentation about the desktop notification policy? 
* highvoltage thinks it would've been nice if the user could set a 'notification priority' like with debconf
<silwol> hi people
<silwol> could somebody give me some guide with this spec: https://blueprints.launchpad.net/ubuntu/+spec/easy-network-filesending ?
<silwol> I have problems to get the openobex running with the patches needen
<silwol> needed
<mvo> \sh: yes, https://wiki.ubuntu.com/InteractiveUpgradeHooks
<mvo> highvoltage: we support a priority, but its currently not used
<highvoltage> aah
<\sh> mvo: thx
<ogra> Keybuk, (or any other archive admin who can wipe stuff from the archive) can we react on bug 96374 and just drop it ... i just talked to upstream, a removal bug in debian seems to exists since sarge but the DD didnt react yet
<ubotu> Malone bug 96374 in lessdisks "[UNMETDEPS]  lessdisks has unmet dependencies" [Undecided,Confirmed]  https://launchpad.net/bugs/96374
<pitti> ogra: I'll take a look at it
<ogra> pitti, thanks you will make a potential ne colleague happy :)
<ogra> *new
<ogra> i just linked the debian bug in LP as well
<YokoZar> I have a pbuilder question: the wiki tells me to add universe support by adding a "OTHERMIRROR" line, but isn't that what the "COMPONENTS" line is for?
<elmo> any KDE folks around?
<ScottK> elmo: Try #kubuntu-devel
<pitti_> ogra: because the debian bug is not against ftp.debian.org, thus it's not a removal bug
<ogra> aha
* ogra tells vagrant
<pitti_> ogra: is it urgent to kick it out in feisty? after all, not all binaries are uninstallable
<ogra> pitti, its obsoleted by ltsp (similar implementation) 
<pitti_> ogra: I see
<ogra> upstream works only on ltsp and abandoned it 
<ogra> i'm fine with keeping the broken stuff if its too much hassle
<ogra> but it appears cleaner to remove it
<pitti> no, it's not, I just want a good rationale
<ogra> ok
<pitti> ogra: done
<ogra> yay, thanks
* ogra closes the bug ...
<pitti> already done
<ogra> wow, you rock :)
<mdz> \sh_away: desktop notification policy?
<seb128> crimsun: around? about bug #64695, how is that a gdm bug?
<ubotu> Malone bug 64695 in gdm "KDE logout dialog is missing shutdown and restart options" [Undecided,Confirmed]  https://launchpad.net/bugs/64695
<seb128> crimsun: it's KDE not using gdmflexiserver, which looks like a wishlist or NOTABUG
<ogra> wow there are some intresting setups in that bug *g*
<ogra> "gdm as the login manager, kde for desktop and ion3 as window manager"
<ogra> heh
<ion_> :-)
<ion_> I used to run ion3 + gnome.
<iwj__> heno: How's the state of the iso testing ?  Anywhere in particular you need more help ?
<iwj__> (My DSL is down atm but I imagine it will be back soon.)
<iwj__> Oops, bounced again.
<iwj__> Aha!  Of course!  Now I get the gprs properly working the dsl comes back.
<hggdh> seb128: is the launchpad localisation thingy already in place?
<hggdh> wrong channel, sorry
<iwj> The iso test page looks to be in good shape.
<ogra> yeah
<ogra> smells like release ready :)
<iwj> But it's only Tuesday!
<Nafallo> iwj: it's delayed since Thursday? ;-)
<ogra> so we can slack two days :)
<Nafallo> or did we skip RC?
<Treenaks> ogra: ssh! sabdfl might hear you :)
<ogra> s/slack/prepare many many good specs for UDS\/UES/
<iwj> I think we might be treating this release candidate as a release candidate.
<ogra> *g*
<sharms> you know what we need?  After a release, have a bug cleaning party where we try to get the number of open bugs down to a certain number
<ogra> iwj, hmm, henos mail sounded different 
<iwj> ogra: Well, yes.  My dsl died but I didn't notice for an hour because I was too busy writing dpkg triggers emails.
<iwj> ogra: Maybe I haven't read that one yet ...
<iwj> `We are asking for widespread  testing of the following CD and DVD images which we are considering for Final release:'
<Nafallo> iwj: the thing that will update-initramfs one time instead of ten? :-)
<ogra> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-April/000281.html
<iwj> Nafallo: Only ten ?  You lucky lucky user :-).
<sharms> Like right now we have 27199 open bugs.  If everyone focused on closing bugs, maybe get that down to something more managable?
<Nafallo> iwj: haha. I take that as a yes ;-)
<iwj> 20070415 was a RC respin, wasn't it ?  I don't suppose it matters what it was intended to be.  Good to see we might be calling it final.
<heno> iwj: Edubuntu server, upgrade or DVD would be great
<iwj> heno: I'll see what I can do.  I don't have an edubuntu dvd primed.
<iwj> But if I start it now I'll definitely have it tomorrow morning.
<heno> ok, cool. Server should be faster then
<heno> I have the Edubuntu DVDs and can test those
<ogra> iwj, you can cat the server/desktop isos together ... that ususally saves 1/3 of rsync time 
<iwj> ogra: I've got a normal Ubuntu dvd, which will do I think.
<ogra> my DVD is still rsyncing ... i wonder if its done before release 
<ogra> running since 10h
<sabdfl> Treenaks: YOU CALLED?
<Treenaks> sabdfl: it was him -->
<ogra> sabdfl, no he just wanted to squeal
<mvo> heno: what upgrade is missing?
<ogra> :)
<heno> mvo: kubuntu amd64 and sparc
<Treenaks> so anyway.. large iso download..
<mvo> heno: sparc -> no way, kubuntu-amd64 is something I can attack
<heno> mvo: yep. The montreal folks are looking at sparc
<ogra> iwj, it also seems we commited to the 19th ... http://www.ubuntu.com/news/ubuntudesktop704
<iwj> ogra: Oh, yes.
<ogra> so what we test *should* be final :) else it would mean some hard nights ahead
<iwj> *snort*
<Treenaks> and somewhere near the end of the week, I get my new server to poke at feisty+kvm :)
<iwj> The Ubuntu stuff (rather than *buntu) is pretty solid now I think.  I didn't see any of the kernel problems myself but I gather it's considered good now too.
<iwj> pretty solid> Mind you, the lvm/mdadm/udev nightmare is still a hideous hideous thing.  We must deploy Keybuk's insane workaround-fixup in -updates.
<cjwatson> iwj: we are indeed treating this release candidate as a release candidate
<cjwatson> (for a change)
<iwj> cjwatson: Excellent :-).
<cjwatson> maybe we can adjust the translation freeze deadlines a bit so that that becomes the normal course of events
<cjwatson> -> "how was feisty for you" session at DS
<cjwatson> UDS
<heno> cjwatson: several people have also commented to me that they prefer this approach to RC
<cjwatson> TTBOMK the main reason we do RC/release that way is because we have to respin for language packs anyway
<cjwatson> though also because we rarely manage to cram the last fixes in in time for T-1week
<heno> I think Vista was in RC for about 6 months :)
<bobrik> hello, what bug status should I assing when "reopening" a bug (it's current status is "Fix released")? "In progress" or "Confirmed"?
<pitti> bobrik: 'in progress' hardly makes sense
<pitti> bobrik: confirmed, needsinfo, or unconfirmed make sense
<bobrik> pitti: ok, thanks
<Lutin> doko_: can you have a look at this debdiff please ? http://people.dunnewind.net/lutin/bittorrent_3.4.2-10ubuntu3.debdiff
<Seveas> mako, sabdfl, elmo: Don't forget: cc meting in < 30 minutes
<mako> Seveas: i know, i need to go get some (late) lunch first.. 
<elmo> Seveas: yeah, I know, thanks
<holycow> anyone seen burgundavia around?
<crimsun> seb128: ok, sounds good
<Lutin> well, if a core-dev's around with 5 minutes free, could you please have a look at this debdiff ? http://people.dunnewind.net/lutin/bittorrent_3.4.2-10ubuntu3.debdiff
<fabbione> Lutin: is bittorrent on the CD?
<Lutin> fabbione: you mean, the ubuntu cd image ?
<fabbione> yes
<Lutin> fabbione: don't know, how can I check it ?
<fabbione> http://cdimage.ubuntu.com/daily/current/feisty-alternate-amd64.list
<fabbione> *.list files
<fabbione> yeah it is
<fabbione> no way it can make feisty
<fabbione> you will have to go trough an SRU procedure
<fabbione> Lutin: https://wiki.ubuntu.com/StableReleaseUpdates
<Lutin> fabbione: eek :/. to late for the archive. I thought it was, but I wasn't sure
<Lutin> fabbione: I guess, even if btdownloadgui won't even start ?
<fabbione> Lutin: yes.. even if.. it's not a release blocker
<Lutin> fabbione: sure
<fabbione> Lutin: go trough the update procedure
<sylpheedClaws> I bet you've been asked this before, but will Feisty still be out on schedule, even with the delays? If no, any ETAs?
<Kmos> bug 8360
<ubotu> Malone bug 8360 in os-prober "grub menu shows two identical SuSE 9.1 entries" [Low,Confirmed]  https://launchpad.net/bugs/8360
<Kmos> this is fixed?
<Lutin> fabbione: okay. thanks :)
<YokoZar> oops, I made a folder with a - sign as the first character...how do I rename it?  mv thinks I'm passing an option
<mr_pouit> put -- before
<mr_pouit> mv -- -file file
<mr_pouit> iirc
<YokoZar> mr_pouit: ahh, thanks
<mr_pouit> np ;)
<wasabi_> great. cyrus broked in edgy. *sigh*
* wasabi_ ugprades server to feisty!!!
<ash211> I'm interested in becoming Ubuntu's bug contact for Amarok - https://launchpad.net/amarok/
<ash211> how would I go about doing that?
<wasabi_> Probably simply subscribe to it in launchpad
<ash211> I did that, but I'm looking at being able to change upstream bug reports that don't have a URL
<ash211> ubuntu-qa isn't enough
<ash211> (cleared up on #kubuntu-devel)
#ubuntu-devel 2007-04-18
<tsmithe> hi. i attached a debdiff to https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/106588 (comment 6) to allow evolution to start on systems without esound. i was wondering if this could be included in feisty?
<tsmithe> i will at some point look further into the matter... why does evolution seem to wait on an orbit socket forever unless esound works?
<tsmithe> is it too late?
<goedson> cjwatson: I have some changes to suggest for Brazilian Portuguese translation of ubiquity. What should I do?
<elmo> tsmithe: IANAUD but evolution is on the CD, I very much doubt you're going to get that updated at this stage, it'll need to be a SRU
<tsmithe> ah yes. of course
<tsmithe> i can't see the release being delayed for that
<vdepizzol> cjwatson, ping
<grayman> hrm
<grayman> what's up with Vesa. It seems to be a lot of troubles
<grayman> apparently it turns off the monitor when using geforce FX 5200(tried only on it). Is it a known issue or it's just my pc?
<kylem> "turns off the monitor"?
<grayman> yes litterally
<grayman> like it goes black when X loading and the status led showing it on stand by
<grayman> but it's fixed when you change the driver to nv
<grayman> or "fixed"
<Teremd> doko: ping
<Burgundavia> fabbione: are you around?
<bluefoxicy> awwh.  No Ubuntu packs smaller than 200?
* bluefoxicy got 10 and it was just fine for him for Dapper.. if he has to get 200, he's going to have to find some way to get rid of them.
<bluefoxicy> 10 CDs I can hold onto, easily accessible and i can part with a few if needed; the extra 190 I need to do something with them other than let them bitrot for 6 months before they get replaced.
<fabbione> Burgundavia: i am now
<Burgundavia> fabbione: can you fill in the sparc stuff on https://wiki.ubuntu.com/7%2e04Tour
<Burgundavia> ?
<fabbione> Burgundavia: isn't the doc team supposed to do that?
<Burgundavia> fabbione: the marketing team, actually, but we have no idea about the sparc stuff, as none of us use it
<Burgundavia> fabbione: I only need 1 or 2 sentences
<fabbione> Burgundavia: very short, so expand it sensibly: availability of openssh server in the installer on request...
<fabbione> Burgundavia: silo-installer improved to recognize other installed OS'es 
<Burgundavia> sounds good
<fabbione> Burgundavia: i think as general hit it should be enough
<jdong> are you sure we don't need (tm) thingies all around AOL to not be sued? ;-)
<Burgundavia> jdong: where abouts?
<jdong> Burgundavia: on the tour
<Burgundavia> naw, not so much of a big deal
<jdong> ok
<Burgundavia> there is usually a footer about trademarks
<Burgundavia> fabbione: is the title correct?
<fabbione> Installer for Sparc64 ?
<Burgundavia> yep
<fabbione> i guess so
<fabbione> yeah it's ok
<fabbione> bbl
<pitti> Good morning
<ion_> Hi
<dholbach> good morning
<ion_> Hi.
<dholbach> hi ion_
<Kagou> morning
<pitti> hi Kagou 
<Kagou> hey pitti 
<pitti> heno, Mithrandir: for coordination, I'll do the kubuntu amd64 edgy->feisty upgrade test now (I stole some quota from my fiancee :) )
<heno> pitti: well done, thanks :)
<Mithrandir> pitti: cheers.
<mvo> can someone translate " no foi possvel criar `./usr/lib/libGL.so.1.2': Arquivo ou diretrio inexistente" for me?
<Mithrandir> ./usr/lib/libGL.so.1.2, no such file or directory.
<Mithrandir> the first bit, I'm not sure about.
<lifeless> not ... possible ...
<mvo> thanks, that helps already
<Mithrandir> "it was not possible to create"
<Mithrandir> according to babelfish
<dholbach> "it was not possible to create `./usr/lib/libGL.so.1.2 ': Archive or inexistent directory"
<lifeless> god bless the fish
<dholbach> gnome-translate is your friend :)
<mvo> dholbach: I did not know about this one, I will try it out now
<mvo> dholbach: g-t is quite nice, the gui needs a bit of love though
<seb128> mvo: g-t?
<mvo> seb128: gnome-translate
<seb128> ah, ok
<ogra> seb128, ugh, the patch you mention in bug 105836 is a horrible hack
<seb128> ogra: I did mention a patch?
<seb128> what bug is that, launchpad is b0rked
<ogra> yeah, i just noticed
<ogra> black screen not black in gss
<seb128> that's not a patch, that's what has been commited upstream some months ago
<ogra> you mentioned a gnome bug with a patch for pixmap themes
<seb128> I mentionned there was a bug upstream which has been closed
<seb128> well, I'm just triaging some gnome-screensaver bugs to help you
<seb128> don't shoot the messenger :p
<mvo> seb128: #95631 looks like a pango race again, its busted during the upgrade: "Pango-WARNING **: /usr/lib/pango/1.4.0/modules/pango-basic-fc.so: cannot open shared object file: No such file or directory at " apparently. 
<mvo> this is when debconf-gnome tries to start its interface
<seb128> mvo: any idea on how to workaround it?
<seb128> I'm starting to think we should link staticly the upgrade tools
<mvo> seb128: not right now, didn't we fix that last release?
<ogra> seb128, thanks for that, i didnt want to argue with you indeed ;) but upstreams patch just removes the pixmap, while the problem seems to be that the embedded X window of the screensaver doesnt show up ...
<mvo> seb128: another idea would be to run the upgrade from the live-cd or something like this. so that the upgrade happens, but does not change the environement under itself
<ogra> so after removing the pixmaps users see a plain gtk window background instead of a black screen
<seb128> ogra: hum, k
<seb128> mvo: what upgrade is the bug about?
<seb128> mvo: launchpad is sort of broken, it's 6.10 to 7.04?
<mvo> https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/95631
<ubotu> Malone bug 95631 in update-manager "postfix released (was. dist-upgrade failure (edgy->feisty) - SystemError from cache.commit(): installArchives() failed)" [High,Needs info]  
<seb128> ah, working again
<mvo> seb128: I noticed LP breakage too. i try to reproduce it now
<seb128> they fixed lp, that was quick ;)
<seb128> mvo: yeah, we workarounded the bug previous cycle by ship a static pango config with the package under /var IIRC
<mvo> seb128: yep - do we no longer do that?
<seb128> not sure, the Debian package has structure changes as well
<seb128> it might have been dropped during the merge
<seb128> or it didn't apply correctly
<seb128> I think I talked to you about it some months ago
<mvo> seb128: ok, I check the source
<seb128> "  * Drop the old module files handling.
<seb128>     - Drop update-pango-modules and man pages.
<seb128>     - Conflict with packages using update-pango-modules in the past, i.e.
<seb128>       pango-libthai (<< 0.1.6-2).
<seb128>     - Delete /etc/pango/pango.modules on upgrades of libpango1.0-common."
<seb128> they did that
<mdz> tepsipakki: are you still editing FeistyKnownIssues?
<mdz> seb128: I did a test in vmware of an upgrade from 6.10+updates to 7.04 with workrave running, and couldn't reproduce my bug
<mvo> seb128: thanks, I'm investigating
<seb128> mdz: ok, dunno what was causing it, it might have been fixed or not easy to trigger
<pitti> mvo: will /cdrom/cdromupgrade.sh work for Kubuntu, too?
<mvo> pitti: it should
<pitti> mvo: I just installed a stock Kubuntu edgy; I guess I need to get some edgy-updates packages before?
<mdz> pitti: yes, update-manager
<pitti> mvo: oh, the script calls 'gksu'
<mvo> pitti: yes, at least u-m and the kde backport for konsole/kdelibs/kdebase
<pitti> right, I see
<mvo> pitti: please run it with sudo, this is whats in the upgrade notes 
<mvo> pitti: kubuntu has no "distro-cd detected" prompt yet, it needs to be started manual
<pitti> Riddell: how can I call adept-updater to update to feisty? some hidden --devel-release option?
<Arby> pitti: do you mean this https://help.ubuntu.com/community/FeistyUpgrades?
<pitti> Arby: *erk*
<Arby> I could be mistaken
<pitti> seems not; thank you
<pitti> I hoped that was some obsolete info, now that we have the new adept in edgy-updates
<Arby> it does look a little nasty
<pitti> no wonder that people just use the good old apt-get dist-upgrade :)
<Arby> indeed
<Arby> something for gutsy maybe
<Riddell> pitti: in feisty there's a hidden switch to call the upgrade tool but not in edgy
<pitti> Riddell: ah, good to know
<ogra> stratus, ping
<pygi> hello folks
<ogra> mvo: <pips1> I'm getting a screen refresh of GDM on the server's monitor when I'm logged in on the client and I change the default system language... oh, well it actually makes sense, because the options in GDM will change
* pitti waves to pygi
<pygi> hi pitti ^_^
<ogra> mvo, is there anything in the lang selector that causes gdm to restart ???
<ajmitch> hi pygi, pitti 
<mvo> ogra: yes
<ogra> hi ajmitch pygi pitti 
<ogra> :)
<mvo> ogra: not restart, reload
<pitti> ogra: yes, langpacks have a gdm reload AFAIR
<pygi> hi ogra ajmitch :)
<ogra> mvo, ah, ok fine then 
<pitti> ogra: otherwise gdm does not show new locales
<ajmitch> hey ogra, how's it going? :)
<mvo> ogra: this is needed so that it picks up the new language
<mvo> s
<pygi> ha, mvo :)
<pygi> hi
<ogra> mvo, fine with me, i just wanted to know if its wanted :)
<mvo> :)
<mvo> hey pygi
<pygi> mvo, we've got java bindings for libburnia libs :P
<ogra> ajmitch, fine, thanks ...
<mvo> pygi: nice
<pygi> I do have to commit them tho, and they are not finished
<mdz> Riddell: so this is really the upgrade procedure for Kubuntu? manually downloading the upgrade tarball?
<pygi> (not  my work, I don't speak java-ish languages)
<mdz> Riddell: I thought we  backported a new adept in order to make this work more like Ubuntu
<pitti> well, the dist-upgrade itself is fine, it's just lacking the equivalent of u-m's -d option
<mdz> pitti: oh, so when the final release is out, it will happen automagically?
<mdz> pitti: -d only tells update-manager to consider development releases as well as stable ones
<mvo> mdz: that is my understanding, a wizard dialog will appear when the user clicks "check"
<pitti> mdz: automatically> I don't knwo
<pitti> since I could not use adept-notifier for that, the recipe requires to start the dist-upgrader directly without going through adept
<mvo> mdz: and that was how it worked in -proposed. Riddell said earlier that the -d switch was added for feisty, but not backported as the version in -proposed defaulted to -devel
<pitti> ogra: do you have someone to test edubuntu netboot?
<mdz> mvo: ok
<mdz> I've updated https://help.ubuntu.com/community/FeistyUpgrades accordingly
<Riddell> mdz: no, it'll prompt to upgrade once http://changelogs.ubuntu.com/meta-release is updated
<mdz> Riddell: please confirm that FeistyUpgrades is correct now (for final)
<mdz> mvo: likewise
<Riddell> editing a small change
<Riddell> oh, mvo is already editing
* Riddell cancells
<mvo> yes
<mvo> Riddell: I'm done
<seb128> mdz: do you think that bug #103246 should be listed on FeistyKnownIssues?
<ubotu> Malone bug 103246 in gnome-compiz-manager "Gnome-compiz-manager thrusts itself into .gnomerc" [High,Confirmed]  https://launchpad.net/bugs/103246
<mvo> mdz: a small correction, its not needed to click on check
<mc44> mvo: but what if your update manager is not up to date?
<mvo> mc44: when u-m starts it will check for a new release autoamatically (its a very small file that is checked)
<mc44> mvo: oh just someone had the authentication problem due to not having an up to date u-m
<mvo> mc44: right, sorry for that, but there is little we can do (beside pointing out that the feisty-updates should be installed prior to the upgrade)
<StevenK> mvo: s/feisty/edgy/ surely?
<mvo> StevenK: of course
<mc44> mvo: sure just wondered if that should be pointed out in FeistyUpgrades document
<mc44> mvo: and now i see it is
<mc44> sorry :)
<mvo> :)
<ogra> pitti, i have to setup a netboot server on my ppc but i need my laptop i could use as client for the meeting in 1h ... i'll do one after the meeting
<pitti> ogra: I'm testing edubuntu/amd64 netboot now
<ogra> ok, i'll do i386 then in about 2h
<pitti> ogra: I don't know at all how to test the installed system, but I can probably check if it installs correctly
<ogra> right
<mdz> mc44: that's documented in the release notes as well
<pitti> ogra: I just finished jigdo'ing the server CD
<Keybuk> mvo: could you give me some dummy instructions for an edgy user who may not have updates installed
<Keybuk> how do they ensure that updates are enabled, and then install them?
<ogra> ogra2@edubuntu:~$ eject
<ogra> dm_task_set_name: Device /dev/mapper/hda3 not found
<ogra> ^^^ whats that ?
<Treenaks> libdevmapper
<ogra> well, i guessed that it has to do with devmapper ... but why do i get it on my up to date feisty ?
<ogra> ogra2@edubuntu:~$ ls /dev/mapper/hda3 
<ogra> /dev/mapper/hda3
<ogra> it seems to exists
<SoftIce> hi, what has happend to vserver support in feisty
<SoftIce> has that dev stopped?
<SoftIce> will their be vserver kernels, etc and up to date vserver packages? eg: util-vserver?
<Keybuk> evms
<Keybuk> ogra: remove that :p
<Treenaks> Keybuk: evms is officially Bad?
<ogra> ah, k seems i pay the price for not using u-m here 
<siretart> Keybuk: hey, evms is supported since warty after all!
<Keybuk> Treenaks: it's annoying, always has been
<siretart> Treenaks: I wouldn't consider it bad, rather undermaintained in ubuntu
<Keybuk> that's what makes the /dev/mapper/* versions of all your drives
<Keybuk> sometimes util-linuxness likes to use those instead of the real ones
* Keybuk isn't aware of it being harmful though
* ogra sighs ... every shoddy package regenerates the initramfs nowadays ... :/
<siretart> btw, is there a timeline for specs for Sevilla?
<siretart> ogra: this could improve with dpkg-trigger
<ogra> siretart, not for single package removals though
<siretart> that's right. well, in fact, you could use dpkg --suppress-triggers, I suppose
<ogra> well, then i would still have it in the initrmafs ...
<siretart> choose your poison. right
<ogra> the regeneration is needed ... triggers are only helpful for mass installations that all have similar postinst stuff
<siretart> ogra: do you happen to know the deadline for specs for gutsy?
<ogra> nope ... 
<siretart> ah, ok, so it hasn't been announced yet. good (for me)
<mneptok> siretart: 5 minutes before you finish >:)
<ogra> there will surely be a mail soon
<siretart> mneptok: excellent, so I have a lot of time left ;)
* ogra too, all outlined already, but not registered yet
<mneptok> siretart: the universe can be very patient as it waits to screw you over, yes ;)
<mvo> Keybuk: after lunch?
<mvo> Keybuk: how detailed do you want it? shall I do it on the wiki?
<Keybuk> mvo: sure
<Keybuk> yes to the wiki
<mvo> Keybuk: ok, I will do that right after lunch
<Riddell> seb128: two evoluation menu entries known?
<Riddell> s/a//
<Riddell> mm, bug 13845
<ubotu> Malone bug 13845 in evolution "evolution has two icons in applications menu" [Medium,Rejected]  https://launchpad.net/bugs/13845
<ogra> Riddell, they (used to) start two different parts of the app ...
<siretart> Mithrandir: I just uploaded a fix for rdesktop bug #104332 - upstream is sitting next to me and it really seems a very good idea to have that patch in for feisty
<ubotu> Malone bug 104332 in rdesktop "Segmentation Fault (core dumped)" [Undecided,Fix committed]  https://launchpad.net/bugs/104332
<Mithrandir> siretart: -updates;
<siretart> oh. ok. please reject my upload then
<siretart> I reupload in a sek
<Mithrandir> -updates isn't open yet, and you need to follow the normal SRU procedure.
<siretart> oh. I see
<siretart> k
<siretart> I update the bugreport then
<Keybuk> we need something stronger than "frozen" for this point in the release process
<Keybuk> "buried in concrete" ?
<Mithrandir> Keybuk: "set in stone"
<elmo> "srsly, no"
<seb128> Riddell: yes, there is one mailer specific and one for office, that's not ideal though but not a new bug
<StevenK> "frozen", after which we have "ftpd on upload.u.c killed"
<seb128> Mithrandir: do you know when -updates will open?
<Keybuk> this building gets strange vibrations
<siretart> how about opening -updates earlier, like, before releasing? we don't necesarily need to accept stuff yet, but at least the packages are in some queue
<cjwatson> seb128: immediately upon release
<seb128> ok
<Keybuk> oh, I see, a wacking great big helicopter flew past
<cjwatson> actually I thought you could already upload to -proposed and it would be queued
<cjwatson> ICBW
<siretart> cjwatson: shall I try with rdesktop? ;)
<cjwatson> but if it's not, then flipping feisty to CURRENT in LP will be enough
<cjwatson> siretart: sure, why not
<siretart> on my way
<Mithrandir> seb128: once we release.
<Mithrandir> siretart: that requires changing soyuz, something we'd like to not do at this point.  But yes, the plan is to have -updates and friends open a week or so before for gutsy.
<siretart> ok, reuploaded to feisty-updates for testing if it gets queued
<siretart> Mithrandir: I agree
<Saied> all, hi
<Saied> I have problem with kde-i18n-fa package in KDE 3.5.6
<Saied> i have upgraded to kubuntu feisty
<Saied> and i have installed kde-i18n-fa package for gui translation of KDE to persian language
<cjwatson> hmm, lamp-server task installation fails on the Ubuntu amd64 DVD
<Riddell> Saied: I answered you in #k-d
<Saied> Riddell: i dissconnected for some minutes, can you help me again
<cjwatson> Mithrandir: ^-- do you care enough about that for a DVD respin? I think it's just a cdimage bug
<cjwatson> all the tasks other than desktop are probably broken (missing from Task: fields)
<Mithrandir> cjwatson: that == kde-i18-fa?
<cjwatson> Mithrandir: 12:54 <cjwatson> hmm, lamp-server task installation fails on the Ubuntu amd64 DVD
<Mithrandir> cjwatson: ugh.
<Mithrandir> yes, I think I would like to get that fixed.
<cjwatson> just trying to work out how to fix it cleanly and whether I need to change seeds or whatever
<cjwatson> BRB after coffee
<Mithrandir> ok, thanks.
<cjwatson> Ubuntu/alternate and Edubuntu/server powerpc respun, within size limits now
<cjwatson> Mithrandir: ok, I have a cdimage fix; confirm OK to respin DVDs?
<Mithrandir> cjwatson: yes, please.
<cjwatson> unfortunate, but they'll be quick to rsync
<cjwatson> respinning
<Mithrandir> cheers
<ogra> cjwatson, yay
<Mithrandir> heno: we're respinning the DVDs, please obsolete all the test cases for those.
<pitti> ogra: is it a known bug that /etc/ltsp/dhcpd.conf defaults to /ltsp/i386 instead of /ltsp/$ARCH?
<ogra> yes
<pitti> ogra: I configured network, ran ltsp-build-client, now it seems to work
<pitti> the ltsp-build-client step is not really obvious
<ogra> amd64 is somewhat special ... i only had one user yet who runs amd64 clients 
<ogra> we cant put i386 packages on the CD (yet) 
<ogra> so the dhcpd.conf is left in place for i386 chroots
<pitti> ogra: oh, ltsp-build-client runs automatically for i386 installs?
<ogra> it runs from the installer
<pitti> ogra: ah, maybe not because this was a netboot install
<ogra> you should already have an /opt/ltsp/amd64 chroot
<pitti> ogra: anyway, I loop-mounted the alternate to /var/www/ubuntu and used my host system's apache as a local mirror
<ogra> ah, might be that defaults to a workstation install
<pitti> ogra: hm, I think I didn't have it
<ogra> heh, you can dso that without http ;) --mirror file:///cdrom 
<pitti> ogra: I need to check again in another install, but the first time I tried to boot it didn't find a kernel to boot
<pitti> ogra: no, edubuntu server runs in vmware
<ogra> ah
<pitti> ogra: hm, student-control-panel complains about 'install x11vnc on the client'; on the client I just manually enabled 'remote desktop', but that's apparently not enough?
<ogra> no
<ogra> thats a bit trickier ;)
<ogra> https://wiki.edubuntu.org/InstallX11VncOnLtspClients
<ogra> you need to attach to the real client display :)
<ogra> gutsy will have a script to make it easier to setup from thin-client-manager
<ogra> for now i'm happy to have the client side at least
<pitti> ogra: ah, alright; just checking :)
<ogra> oh, heh, the howto misses that you should install x1vnc actually :)
<ogra> *x11vnc
<pitti> ogra: hm, but we already have vnc apps by default in desktop; those don't work?
<ogra> no
<ogra> it needs to run instde the chroot ... i dont think you can run vino outside of gnome 
<ogra> and we have no other vnc server in main
<ogra> *inside
<ogra> (and i surely dont want to  load gnome libs on a thin client with 64M ;) )
<pitti> ok, so I just stop worrying about that screen display now
<pitti> thanks, ogra
<ogra> yeah, i'll fix that for gutsy for now the errormessage should give users some pointers
<Riddell> heno: iso testing results page down?
<Mithrandir> Riddell: wfm
<heno> Riddell: works for me
<heno> though I don't think it can take a slashdotting
<cjwatson> I've respun Ubuntu DVDs, but I'd like to give it a quick test myself first before wasting everyone else's time on it in case I screwed up the code
<ogra> thats for LAMP only ?
<cjwatson> looks ok at a quick glance through Packages
<cjwatson> dns-server, lamp-server
<Hobbsee> awww, no more updates.
<Riddell> heno: working now for me too
<heno> Hobbsee: having withdrawal ?
<jsgotangco> heh
<`anthony> fwiw, upgrading from edgy broke for me with all sorts of clashes in compiz-extra packages.
<jsgotangco> weird though i get gzip errors in amd64
<Hobbsee> heno: yes.  already.
<jsgotangco> should try later
<pitti> as beautiful as ubiquity and d-i are, you get sick of them after a week of testing...
<jsgotangco> or worse rsync a dvd
<Mithrandir> heno: just think of how seb128 must be feeling, then.
<ogra> pitti, i wonder how cjwatson copes with that for years :)
<ogra> since ?
<ogra> hmm
<pitti> for
<Hobbsee> ogra: i believe the term is pure insanity?
<cjwatson> sheesh, come on, what's taking this rsync so long - total changes are aspell-ku, update-manager-core, update-manager
<heno> but at least he can look forward to a fresh stream of bug reports in a few days :)
<Mithrandir> cjwatson: somebody posting rsync instructions to planet, perhaps.
<ogra> Hobbsee, heh
<heno> cjwatson: my sync is at 60%
<cjwatson> "for <length of time>", "since <point in the past>"
<cjwatson> Mithrandir: I'm *cough* rsyncing from lithium
<fabbione> cjwatson: rsyncing now
<heno> (i386 dvd)
<ogra> cjwatson, pitti thanks ... :=
<ogra> :)
<Mithrandir> cjwatson: hm, ok, then I don't know.  I was just about to try the same for the new DVDs.
<mvo_> Keybuk: https://help.ubuntu.com/community/FeistyUpgrades updated (it links to https://wiki.ubuntu.com/EdgyUpdatesEnabled now) - I could add screenshots here too if required 
<Keybuk> mvo_: we don't enable -updates by default though, no?
<cjwatson> we do
<mvo_> Keybuk: we do 
<cjwatson> always have, AFAICR
<Keybuk> do we disable it on the live cd then?
<pitti> Keybuk: we disable update-notifier
<cjwatson> not so much disable as fail to enable, but yes
<cjwatson> livecd.sh only sets up feisty main restricted and feisty-security main restricted
<Keybuk> ah, ok
<seb128> `anthony: we had no compiz-extra in edgy
<seb128> `anthony: you liked installed a buggy version available on a non official source, not a lot we can do about it
<seb128> `anthony: s/liked/likely
<`anthony> seb128: Hm. NFI - I don't recall doing that, but who knows what crap has accumulated on this box. I found that as a result of multiple upgrades, my sources.list has a commented out line for the cdrom of feisty Badger. search and replace wins!
<ogra> lol
<pitti> seb128, dholbach_: FYI, recent LP rollout seems to have broken launchpadBugs again :/; therefore I disabled the retracers yesterday
<seb128> pitti: ok, I didn't notice, we get almost no apport crashes since your turn it
<seb128> turned
<heno> the latest Ubuntu DVD boots fine here, doing an install now
<stratus> ogra: pong
<dholbach_> pitti: sounds like a case for -updates :-/
<goedson> cjwatson, ping.
<cjwatson> goedson: yes?
<goedson> cjwatson, where should I send translation corrections for ubiquity?
<robertj> under what circumstances does it make sense not to have pam use mkhomedirs?
<cjwatson> goedson: change them in Rosetta
<cjwatson> goedson: it's too late for feisty now though - the deadline passed nearly two weeks ago
<goedson> cjwatson: couldn't find it there.
<cjwatson> but Rosetta is where these live. https://translations.launchpad.net/ubuntu/feisty/+source/debian-installer/+pots/debian-installer
<pitti> dholbach: indeed
<goedson> cjwatson: I was looking for ubiquity :)
<dholbach> pitti: did you see what is broken?
<cjwatson> yes, I wish they'd put some kind of manual link in there
<dholbach> pitti: until now I found the attachments not to be listed after initializing Bug()
<pitti> dholbach: no, I didn't have time to investigate it yet
<dholbach> pitti: ok no problem
<bddebian> Heya
<siretart> cjwatson: uploading to -updates results in a reject email with this explanation: Not permitted to upload to the UPDATES pocket in a release in the 'FROZEN' state.
<cjwatson> siretart: ok, fair enough
<ogra> stratus, i thought you might be intrested in bug 105709, i saw you just added th eltsp-sound script ;)
<ubotu> Malone bug 105709 in ltsp "sound config not reset after thin client usage" [Undecided,In progress]  https://launchpad.net/bugs/105709
<stratus> ogra: oh, will read the full description, thanks
<ogra> stratus, btw, why is sacix not in LP ... i would just have added it to the affected distros
<stratus> ogra: hm set-pulseaudio and unset-pulseaudio are ubuntu only (yet) patches for pulseaudio, unfortunately
<ogra> no, they are alsa patches afaik
<stratus> ogra: I've added Sacix as a project as recommended by LP people, but didn't much work on that yet.
<ogra> ah, i was looking for distro :)
<stratus> they're pulseaudio patches, I'm almost sure ;)
<ogra> well it sets a virtual alsa device ... pointing to pulse
<stratus> oh no, alsa patches yes
<stratus> they reproduce asound.conf
<ogra> right
<ogra> if you grab what asoundconf does to the config you can add that to the ltsp-sound script indead of my stuff
<ogra> then it should work on any distro
<stratus> ogra: btw, I need to ping somebody there, I've received no reply after my last message (about Sacix as project and some needed features, mainly malone related)
<ogra> #launchpad should be the place then :)
<wasabi_> hmmmmmm... 
<stratus> yes, I thought the same and was running the set default card and stuff like that, but it wasn't working
<stratus> ogra: sure, don't worry.
<stratus> in other words I haven't figured in a short time how i could extend the 'alias' set-pulseaudio. unset-pulseadio sounds easier
<iwj> ogra: I'm testing the edubuntu dvd (i386) and it doesn't seem to set up an ltsp server at all, contrary to what Testing/Short says.
<stratus> ogra: there's something I'm planning to upload for experimental, see: http://people.debian.org/~stratus/bzr/ltsp/ltsp-server-init/
<stratus> ogra: I've discussed this patch and some other stuff with vagrantc two days ago when we uploaded for sid, closing tons of bugs.
<ogra> iwj, are you installing from the live session ?
<ogra> ubiquity will only do a workstation install
<stratus> ogra: He's going to merge from you and we will do a new upload for sid once our 'mainly bug fix only' upload enters testing, so I've some time for new features into experimental.
<ogra> stratus, btw, your ltspfs patch ... why are you loading ide-cdrom ? that wont affect usb floppies which will be seen as scsi devices
<ogra> err
<ogra> ide-floppy indeed
<LeeJunFan> what recently changed in feisty that reconfigures X on boot? I have 25 systems w/o X because it's rewriting the PCI ID of the gfx card?
<stratus> as weird as it seems it's needed in Debian (dunno about Ubuntu, but I can ask a co-worker to test with edubuntu)
<stratus> and the module needs to be loaded before add_fstab_entry run
<ogra> well, are you sure it doesnt pull in something else which is what you actually need ?
<ogra> ide-floppy shouldt affect usb devices, really ...
<ogra> *shouldn't
<stratus> not regular devices, but floppy drivers on usb are scary and weird
<stratus> I haven't looked through ide-floppy code, but this is the right module to load,  there's no dependency needed
<iwj> ogra: Well, first I tried in the live session (Testing/Short wasn't clear).
<iwj> But now I have done a d-i install from `server install' and selected the edubuntu server and edubuntu desktop tasks.
<iwj> My 2ary ethernet interface has no IP address and there's no dhcp server.
<ogra> did the ltsp udeb run ? you should have seen it 
<ogra> it takes good 10 mins so its something you would notice i guess
<iwj> No, nothing sat for 10 mins.
<iwj> What would it look like ?
<ogra> a progress bar with title: "building LTSP client"
<iwj> Nothing like that, no.
<iwj> Or at least not for 10 mins.
<iwj> I might have failed to look at it for a minute or two.
<iwj> Where are the installation instructions that I ought to be following, if any ?
<ogra> it sits there pretty long ... and it should have shown a note if it didnt confiog your second interface 
<ogra> i dont have any for the DVD to be honest ...
<iwj> ogra: I think we can safely say it didn't run.
<iwj> Well, err, where are the cd instructions then ?
<iwj> The alternate d-i CD I suppose.
<ogra> i was assuming there is the default install from the CD running 
<Riddell> fabbione: installing feisty on sunblade 100 seems to be working but I can't select the keyboard (type 6 usb), type 4 and 5 do some crazy remapping
<ogra> (alternate)
<fabbione> Riddell: yes.. known bug.. see Release Notes.. you need to select a standard PC105 keyboard
<iwj> ogra: Tell you what, I'll do it again and this time I'll ask you which option to take at the key point s?
<ogra> http://www.edubuntu.org/GettingStarted we're just reworking that for feisty, but most of it should be similar
<Riddell> fabbione: ok
* ..[topic/#ubuntu-devel:Hobbsee] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy, #ubuntu+1 for feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Entire archive frozen for release
<ogra> (apart from ststic IP config and the dhcpd.conf stuff in the end)
<ogra> *static
* iwj looks.
<fabbione> Riddell: X won't be autoconfigured properly tho but i guess you know that
<fabbione> Riddell: once we get sometime, i would love to get access and see if we can automate it
<Nafallo> Keybuk: you haven't written a topicdiff for irssi, have you? :-)
<iwj> Ah, there is `install to the hard disk' and `install a server'.
<iwj> Separately.
<iwj> Previously I picked `install a server'.
<iwj> Let me see what happens if I say `install to the hard disk'.
<Keybuk> Nafallo: no, for x-chat
<ogra> iwj, apart from the LTSP bit it shouldnt look different to an ubuntu alternate install
<fabbione> hey Hobbsee 
<Riddell> fabbione: if the distro sprint is in london I could bring it down
<Hobbsee> hi fabbione :)
<Nafallo> Keybuk: the one thing I'm missing ;-)
<Keybuk> Riddell: that's the plan
<iwj> ogra: In this case it didn't look _at all_ different to an Ubuntu d-i install (except that the result looked like edubuntu, of course).
<ogra> iwj, ah, right ... install a server was renamed on the CD to "install a commandline system" 
<ogra> but seems we missed out the DVD text
<fabbione> Riddell: nah.. i just need ssh access and you tell me if X works or not.. or give me your working xorg.conf and a few data.. patching dexconf for sparc should be easy enough
<fabbione> Riddell: it's not worth to move the entire machine.. but if you want.. well up to you
<iwj> ogra: Ah.  I think you need to mention this issue in the release notes.
<Riddell> fabbione: you're assuming I can get a working xorg.conf :)
<ogra> iwj, good point
<fabbione> Riddell: yes.. i am sure you can.. there are tons posted on google... 
<fabbione> Riddell: point is that i don't want to rely on them to hack dexconf
<iwj> ogra: Actually, I think it's a bug.  Since I selected the `edubuntu server' task, I mean.  Or is that not the ltsp server ?
<ogra> it is, but not the setup of the client
<iwj> Err, `the setup of the client' meaning some setup on the server to make clients work.
<iwj> Since the clients are diskless and haven't got any state ...
<ogra> edubuntu-server is a metapackage that just pulls in ltsp-server-standalone and friends ... setting up the chroot is done by the installer udeb
<iwj> I see.
<ogra> if you do it via edubuntu-server you need to run sudo ltsp-build-client post install
<iwj> I assume this is intended to be used by people who wouldn't understand what you just said :-) so I suggest that these distinctions shouldn't be user-visible ?
<fabbione> Riddell: anyway the SB1000 should have an ATI card.. so fairly simple to mangle
<iwj> I mean, I selected the `edubuntu server' task, and isn't an `edubuntu server' exactly one of these ltsp setups ?
<ogra> iwj, on the CD its is pretty clear ... the DVD is always been rather a stepchild
<iwj> Which is why it seems like a bug to me if it doesn't DTRT.
<iwj> IC
<iwj> What do you think the user will understand by the `edubuntu server' task ?
<ogra> the CD has: install to the HD, install a workstation, install a commandline system (and the usual rescue/check stuff)
<ogra> can you make a screenshot of the DVD menu ? i somehow dont understand what you mean with edubuntu server task 
<ogra> do you mean the "inastall a server" point ?
<ogra> or do you refer to the edubuntu-server metapackage ? 
<iwj> No, I mean after I said `install a server' (which you say should have been renamed) I eventually got to a tasksel prompt offering four things: `edubuntu server', `edubuntu desktop' and a DNS server and LAMP.
<ogra> oh, tasksel
<iwj> I selected the first two.
<iwj> Yes.
<ogra> i havent seen that since ages :) sorry i didnt even associate task with it ... silly mne :)
<iwj> Hence my use of the word `task' :-).
<iwj> Is there a bug about the inaccurate dvd menu item name ?
<ogra> hmm, indeed the user should be notified that he needs to run ltsp-build-client ... i never thought that we might run into such a thing ... 
<ogra> no, i dont think so since you just reported it :)
<iwj> OK.  I'll file a bug about that ...
<ogra> only doko tested the DVD yet ... but he had other way more serious issues so he likely has overseen it
<iwj> ogra: Which LP path ?  LP doesn't have /edubuntu and I'm not sure of which package either.
<ogra> hmm, i think either d-i or gfxboot-theme or so ....
<ogra> i suspect the latter ... cjwatson ? wrong wording in CD menu entries ?
<ogra> err DVD
* iwj files bug 107507
<ubotu> Malone bug 107507 in gfxboot-theme-ubuntu "edubuntu dvd menu has misleading title" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107507
<ogra> great ... i'll refer to it in the known issues
<ogra> re> <iwj> I assume this is intended to be used by people who wouldn't understand what you just said :-)
<ogra> i wouldnt expect sduchj people to even see tasksel once in their life ;)
<ogra> *such
<ogra> hmm and tasksel has no opportunity to show a help text or additional info about a task ... tricky
<iwj> Well, anyway, I have filed bug 107508 about the latter problem.
<ubotu> Malone bug 107508 in ltsp "tasksel "edubuntu server" does not set up ltsp" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107508
<ogra> i'm planning to get ird of edubuntu server as it is now anyway for gutsy ...
<ogra> *rid
<vciaglia> hi
<cjwatson> ogra: actually, "Install a server" is different - I was asked to include a server boot option on the DVD which is analogous to ubuntu-server
<conn> mjg59, have you resolved the conflict with networkmanager and softmac drivers? I suppose it's too late to have it included with the release :(
<ogra> cjwatson, meh, by whom ? 
<cjwatson> ogra: wasn't specifically for Edubuntu
<ogra> cjwatson, ah
<cjwatson> I wish Edubuntu was less full of crazy exceptions to everything
<cjwatson> some day I need to make a list of all the constraints
<ogra> cjwatson, i plan to let the first CD die as soon as we have a proper solution for the ltsp stuff in ubuntu
<cjwatson> don't drag me into your debate with mdz :)
<ogra> so you wont have to trick around with it anymore :)
<cjwatson> <cjwatson@cairhien ~/src/ubuntu/cdimage/cdimage>$ wcgrep 'PROJECT.*kubuntu' | wc -l
<cjwatson> 8
<cjwatson> <cjwatson@cairhien ~/src/ubuntu/cdimage/cdimage>$ wcgrep 'PROJECT.*edubuntu' | wc -l
<cjwatson> 46
<ogra> well, its pretty clear we'll get any kind of solution here 
<ogra> be it his or mine ;) 
<ogra> ot a miture, who knows  ...
<ogra> *mixture
<cjwatson> this time please can I have a cast-iron clear description of exactly what Edubuntu requires; also preferably can you please review how the non-Edubuntu images are set up and try not to be gratuitously incompatible
<cjwatson> because it really does cause problems that Edubuntu uses such different terminology for everything, made up essentially in isolation
<ogra> thats why i want to get rid of most of it :)
<cjwatson> I just want to avoid the creation of more utterly confusing stuff in its place
<ogra> yup
<cjwatson> so, I haven't respun Edubuntu yet for the task bug
<cjwatson> would you like me to just get rid of the "Install a server" boot option?
<ogra> that would be cool
<ogra> and solve both of iwj's bugs
<cjwatson> iwj: agree?
<iwj> cjwatson: Yes, I think so.
<heno> ogra: I'm interested in that debate. I'm thinking we should combine all the alternate CDs together on a 3-CD set
<iwj> Although I don't know what that options is supposed to be for so I can't say that it wouldn't be wrong to do so.
<holycow> i have feisty on this laptop and it seems to hang the box at 100% cpu intermittently
<holycow> any suggestions on a tool i can use to track down what might be spiking th cpu like that to hang the system?
<heno> that way you get different live CDs, but the alternate is just one set
<holycow> any tips for trying to track down this issue?
<heno> and that could be the DVD
<cjwatson> iwj: "Install a server" is a recent addition to allow the DVDs to subsume the server CDs
<ogra> heno, well, i'd like to move edubuntu to be a complete addon CD ... so users can choose the underlying desktop 
<cjwatson> I think it can be turned back off on Edubuntu without too much hassle
<cjwatson> addon CDs are crack, installer-wise
<cjwatson> just hope you know that
<shawarma> holycow: Ask in #ubuntu
<holycow> uh no
<ogra> cjwatson, just like it is now ... but with .desktop entries in g-a-i for the different tasks
<holycow> what would newbs know about tracking down issues like that?
<ogra> no installer stuff planned
<holycow> hoping experienced devs have some tools/tips thats all :)
<cjwatson> sigh, I give up, I've spent years arguing about this
<cjwatson> just as long as I don't have to implement it
<ogra> it is already implemented
<holycow> ogra, thats just a stupid idea
<holycow> seriously
<crimsun> holycow: oprofile.
<crimsun> oh, you want app, not actual kernel?
<Nafallo> will people on feisty-changes be copied to gutsy-changes?
<ogra> cjwatson, i dont want to change anything with the current addon CD only seed contents... 
<holycow> crimsun, no kernel is a good start
<ogra> its prefectly fine as is
<holycow> crimsun, i have a sneaky feeling its a kernel module this gives me one extra thing to try, thank you!
<holycow> ogra, no cd addons, drop the idea
<holycow> its stupid
<cjwatson> ogra: you won't be able to install an Edubuntu desktop using the installer any more
<ogra> cjwatson, right thats the plan
<jsgotangco> boo
<ogra> cjwatson, you install ubuntu, kubuntu or xubuntu and pop in the addon CD that gives you different age related tasks in g-a-i
<cjwatson> you realise that won't work?
<ogra> which add the different artwork and edu apps
<cjwatson> the add-on CD is germinated with respect to ONE seed
<cjwatson> there is no support for germinating it with respect to the intersection of multiple seeds
<cjwatson> which means that it can only possibly work when attached to a given single CD, at least without significant development work somewhere in the middle of cdimage and germinate
<cjwatson> I already brought this up last time add-on CDs were discussed
<ogra> right, i remember 
<ogra> well, still it can go fine with ubuntu-desktop as base ... if thats the restriction it is as it is ...
<cjwatson> and making it work for any of Ubuntu, Kubuntu, or Xubuntu would involve making the add-on CD significantly bigger due to the requirement to include all the necessary libraries
<ogra> yup, i remember what you said last time ...
<ogra> the thing is that imho the first CD is now mainly needed for ltsp setup if we can get an ubuntu solution for that we wont need it anymore
<ogra> i just dont see why we should put additional time into maintenance for it
<iwj> And this silly laptop doesn't seem to want to netboot.
<cjwatson> heno: ok, I've tested the server boot option on the Ubuntu 20070418 DVDs and it's now working; could you invalidate Ubuntu 20070416 DVDs and replace them with that?
<cjwatson> heno: I'm rebuilding Kubuntu and Edubuntu to match
<iwj> Aha!
<cjwatson> ogra: I sympathise with maintenance concerns; I just want to make sure the result is feasible
<iwj> ogra: When you say `add him/her to the fuse group with the users-admin gui tool (this is not done automatically for security reasons' this appears to be false.
<ogra> well if there are limitations we'll have to live with them .. but i want to make our life as easy as i can here ...
<ogra> iwj, where do i say that ? we didnt do it by default in edgy and feisty
<ogra> err
<ogra> s/feisty/dapper/
<iwj> Oh FUCK.
<ogra> whats wrong? 
<iwj> This stupid automounting my stuff has automounted my journalled filesystems from my hibernated install.
<iwj> Now I will have to force-no-resume the hiberanted install, ie crash it.
<iwj> s/my stuff/stuff/
<iwj> Oh well, I don't _think_ I had anything important running.
<iwj> Still, now I'll never know.
<ogra> you are using a hibernated machine as thin client ? 
<iwj> I'm using my laptop and netbooting it for testing purposes.
<ogra> hmm is there any way to recognize there is hibernation data on it ... we could exclude such partitions ...
<iwj> Using a machine that has some other purpose for a test or a demo is quite normal and shouldn't cause hideous doom.
<ogra> sbalneav, ^^^^
<iwj> This isn't the first time some overly-clever thing has done this.
<iwj> The installer does it too.
<cjwatson> please provide me with a way to tell it's hibernated and shouldn't be used
<ogra> well, if there is a way to find out about it we can really exclude it ... 
<cjwatson> I have conflicting requirements here and need a way to satisfy both
<iwj> cjwatson: For the installer it's easy: if it's dirty, leave it alone.
<iwj> For edubuntu it's harder since removeable things may end up dirty.  Perhaps prompt on insertion.
<cjwatson> hmm, wonder if parted can tell me that
<iwj> Didn't I already report a bug against the installer ?
<iwj> If not I should have done.
<cjwatson> you did, I'm sure
<cjwatson> but I remember having no idea how to satisfy both requirements at the time
<ogra> iwj, the point where i can prompt in the session the HW got already mounted on the client ... that would need implementation changes
<cjwatson> (all bug fixes need implementation changes)
<iwj> cjwatson: ROTFL
<iwj> No, sometimes we change the documentation to define darkness as the new standard ...
<ogra> heh, well, yes, small or big ones :)
<iwj> Even refusing to run at all when a hibernated setup is found would be better.
<sbalneav> Are we talking edu on a separate cd?
<ogra> sbalneav, nope we're talking ltspfs automounting hibernation partitions
<cjwatson> libparted doesn't seem to have any fs-independent way to tell whether a filesystem is dirty, unless I'm missing something
<ogra> on laptops ...
<iwj> cjwatson: Lovely.
<heno> cjwatson: will do. I've tested live CD w/ install and I'm testing server now, FWIW
<iwj> ogra: Bug 107518.  Feel free to reassign it to a more appropriate package.
<ubotu> Malone bug 107518 in ltsp "auto filesystem mounting can cause hideous data loss" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107518
<cjwatson> iwj: like I said in Oslo, I welcome help with the installer
<cjwatson> particularly in the field of partitioning
<iwj> cjwatson: *snort*
<iwj> Why don't we assign this bug to me ?
<iwj> Let me see if I can find it.
<ogra> iwj, done :)
<iwj> Not that I regularly look at my bug list :-/
<cjwatson> I would suggest teaching parted_server (in partman-base) about a new command to tell whether the fs on a given partition is dirty, and making use of that in partman-basicfilesystems where it decides whether to automount things
<iwj> cjwatson: bug 41624.
<ubotu> Malone bug 41624 in partman-basicfilesystems "Replaying journals of other OS's filesystems, by mounting them, is unsafe" [High,Confirmed]  https://launchpad.net/bugs/41624
<ogra> sbalneav, i subbed you to the bug
<cjwatson> let me brain-dump into that bug
<iwj> cjwatson: OK.
<cjwatson> iwj: Debian 417407, also
<ubotu> Debian bug 417407 in debian-installer "debian-installer: d-i destroyed existing raid device" [Critical,Open]  http://bugs.debian.org/417407
<cjwatson> hmm, curious, ubotu lists the original subject not the current one
<heno> cjwatson: great if you could PM me the new md5sums when the set is complete
<cjwatson> and the original package, for that matter
<iwj> ogra: Re that fuse group thing, I'm talking about Testing/Short.
<iwj> Under Edubuntu, point 3.
<ogra> oh, i need to update that 
<iwj> I see.  So these security reasons don't apply any more or to put it another way we've changed our mind ?
<ogra> the latter rather
<iwj> Right.  Well, OK.
<ogra> for shools with 500 users its a pain to enabled it manuially :)
<ogra> *schools
<ogra> iwj, isnt your hibernation data usually on a swap partition ? 
<ogra> i'm just wondering how it gets mounted then 
<iwj> ogra: It's my filesystems that get mounted.  Eg the hibernated install's root fs.
<iwj> Why is there no `eject' item on the menu for this fuse local usb stick, in my client desktop ?
<ogra> ah, and then you have differences between the hibernated data and the actual FS ... now i understand
<ogra> because its never mounted unless you write or read ... 
<ogra> it gets unmounted 2 secs after the last access happened
<iwj> ogra: The mounting by the ltsp client replays the journal, and then the resumed install knows nothing of this and writes more stuff.
<ogra> yuip, i understand now
<iwj> There's still an `unmount volume' on the `File' menu in Nautilus.
<iwj> I just tried that option and it gives me a silly error dialogue.
<ogra> gah, bug
<ogra> i thought i removed it everywhere 
<geser> can somebody explain me why my upload of bzr-gtk (universe) was first accepted to only be rejected 30 min later?
<ogra> why the heck do you find all this stuff ... 
<iwj> I think users will find it confusing that `sometimes' (eg, on their normal ubuntu machine at home) they have to eject/unmount and `sometimes' (eg at school) they don't.
* ogra makes a note to hire iwj for a mid gutsy test session :)
<highvoltage> hie hie :)
<iwj> I think software knows I have a bad opinion of it so it sets out to make me grumpy.  But it doesn't work because it's just confirming my expectations :-).
<ogra> *giggle*
<iwj> Also I'm a weirdo who tries to do what it says in the manual.  No-one else does that :-).
<ogra> well, there is no opportunity to unmount anything with ltspfs ... what would you suggest ?
<ogra> apart from relying on the admin to tell his users
<iwj> Not sure.  Provide an `eject' option that does nothing but don't mind if the user doesn't do it ?
<ogra> since thats common practice since ltsp exists ...
<cjwatson> geser: it was initially accepted but then a decision was taken that the archive is closed for feisty
<cjwatson> we need to lock down
<iwj> What I really think we should do is fix the crazy behaviour on normal desktop installs.
<iwj> It's outrageously crap.
<ogra> hmm, right ... thats an option
<ogra> yeah
<iwj> So do you want a bug about the nautilus unmount volume thing ?  It doesn't seem important to me but I'm always happy to file another bug ...
<ogra> yeah urgently, thats an oversight i would be angry to forget to fix in gutsy
<iwj> What package ?
<ogra> hmm
<ogra> ltspfs for now ... even though the patch belongs to nautilus ...
<ogra> but i wont monitor nautilus bugs ...
<Keybuk> (random: how do you limit the height of a table cell in HTML/CSS?)
<Ng> I'd expect a combination of a height: css attribute and an overflow: one would stop the browser forcing the cell bigger
<Keybuk> doesn't seem to obey it
<Ng> ah, http://archivist.incutio.com/viewlist/css-discuss/71730 has a good suggestion
<cjwatson> Mithrandir: I'm going through release-noted bugs and sorting out milestones
<Keybuk> ng: doesn't work for me
<Ng> well that's me out of html/css clue ;/
<Keybuk> it's the "expand to the minimum height" rule that's the problem
<Pici> hehe
<Pici> ^^ windows xp cdkey
<cjwatson> Mithrandir: do you think the hardware-related issues in FeistyKnownIssues should be milestoned later? I'm not sure how many of those were added by you and how many were added by aggrieved users trying to get more attention
<crimsun> (I added the AD1986A one, but I'll remove it if you guys think it's best omitted from that page.)
<cjwatson> crimsun: I've got no problem with developers adding important bugs there
<heno> *** New DVDs posted: 20070418 *** Anyone have those primed and can rsync?
<doko> cjwatson: will it be possible to promote a package in feisty-updates, or should this be done before the release?
* heno afk
<ogra> doko, it needs to go to -propsed anyway, no ?
<ogra> i heard thats open already
<doko> ogra: no, aksing about promotion, not upload
<cjwatson> doko: no more changes are happening to the archive pre-release unless the sky falls in, so the latter is moot
<cjwatson> we don't typically promote post-release either. What's the justification?
* ogra checks the sky ...
<Hobbsee> ogra: it's still purple.  it's all good.
<ogra> mine is grey here ... but still where it belongs :)
<Hobbsee> mine's on the ground
<Hobbsee> but then again, i'm australian, so am upside down...
<doko> cjwatson: avoiding a crash in ooimpress after a presentation in full screen mode by building using stlport4.6 instead of stlport5.1
<cjwatson> heno: top of https://www.stgraber.org/ubuntu/isotesting still says "*16 for DVDs"
<ogra> Hobbsee, *g*
<doko> another workaround would be to build using the internal copy of stlport
<Hobbsee> ogra: :D
<cjwatson> doko: it may be possible to promote post-release, but I'd have to check; ask me after release. Building using the internal copy would be acceptable if the result is stable
<heno> cjwatson: fixing
<silwol> hi ubuntu developers!
<silwol> I have a rather generic network programming problem, maybe somebody could help me here...
<silwol> I want to open a server on a high-port and afterwards announce it over avahi
<silwol> is there a specific method to get an available random port?
<silwol> ... in C
<ion_> Please see topic./
<stratus> ogra: around?
<stratus> ogra: figured out with a co-worker the need for modprobe floppy before add_fstab_entry on usbfloppy implementation
<stratus> ogra: the problem is that for some unknown reason there's no /dev/sdX on the server without the *ide*-floppy loaded (2.6.18 kernel)
<stratus> ogra: of course we need that before add_fstab_entry, so..
<bluefoxicy> Am I correct in assuming the default frequency scaler in Ubuntu is "ondemand" rather than userspace daemons
<ogra> stratus, weird
<stratus> ogra: my co-worker ack'ed that edubuntu also needs the ide-floppy trick
<ogra> feisty ?
<ogra> (edgy had 2.6.17)
<stratus> ogra: he told me about .19, so I think it's something pre-feisty beta, he tested some weeks ago
<stratus> before FISL
<ogra> ok
<Mithrandir> cjwatson: thanks; I've barely touched the KnownIssues page.  I guess it depends on how common the hardware is; I'd like the sound problems on common intel motherboards to be fixed quickly, for instance, but if $random_obscure_piece_of_hardware is broken, I don't really care that deeply.
<conn> looking at FeistyKnownIssues, it says that using the livecd will be excessively slow for <256mb. I noticed the same with my systems, but I when I tried a livecd from about a week ago, the livecd environment functioned much better than previous herds/beta... I noticed that it was using swap on the harddisk. I don't know if this was intentional, but it allowed me to use the livecd to install on a system with just 196mb ram... will Feisty final use swap in 
<conn> the same way?
<juliux> hi all
<rsk> hey
<juliux> i reported #81804 in january, but it is fixed, can i reject the bug?
<juliux> https://bugs.launchpad.net/update-manager/+bug/81804
<ubotu> Malone bug 81804 in update-manager "update-manager is not working after upgrade to feisty" [Undecided,Unconfirmed]  
<pochu> juliux: sure
<juliux> ok then i will reject the bug to have the bugtracker clean;)
<pochu> :)
<juliux> pochu, where is the reject button on the new launchpad?
<juliux> ah found it
<mc44> juliux: why not set it to fix released :)
<juliux> mc44, hmm
<juliux> mc44, good point
<juliux> mc44, i am not using launchpad everyday;)
<davmor2> any xubuntu dev's here?
<pochu> davmor2: what about xubuntu-devel ? :)
<davmor2> cheers pochu found an easy to rectify bug
<heno> cjwatson: the server install from the DVD didn't work for me (virtualbox). I got this on reboot: http://people.ubuntu.com/~henrik/temp/DVD-server-install.png
<heno> <heno> cjwatson: the server install from the DVD didn't work for me (virtualbox). I got this on reboot: http://people.ubuntu.com/~henrik/temp/DVD-server-install.png
<pochu> heno: where should netboot bugs be reported?
<heno> pochu: good question; what are you seeing?
<heno> is it a debian-installer issue?
<pochu> bug #107568
<ubotu> Malone bug 107568 in firefox "I have done a netboot install of xubuntu and the ubuntu-artwork folder is missing" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107568
<pochu> davmor has just noticed that
<heno> pochu: commented on the bug
<pochu> thanks :)
<somerville32> This is weird.
<somerville32> Shouldn't it be xubuntu-artwork and not ubuntu-artwork?
<somerville32> http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=xubuntu-artwork&searchon=names&subword=1&version=feisty&release=all <-- Says xubuntu-artwork is in universe.
<somerville32> I guess they don't have it setup that way.
<richie_> hi!
<richie_> anybody knows if thunderbird 2.0 will be available in feisty? 
<mrsno> richie_ thunderbird 2 isn't final yet i thought
<richie_> no0
<richie_> its final, since a few hours
<richie_> http://www.mozilla.com/en-US/thunderbird/
<Burgwork> richie_: not going to happen
<mrsno> feisty is in freeze so i guess no :)
<richie_> ok
<richie_> thanks
<pochu> richie_: maybe for feisty-backports
<richie_> that would be great.
<richie_> good night!
<mrsno> gnite :)
* mrsno upgrades his tbird
<pochu> night richie_
<pochu> asac: ^ TB 2.0 out :) http://www.mozilla.com/en-US/thunderbird/
<mrsno> it redirects me here, strange
<mrsno> oh its quite nice :)
<asac> pochu: rc build is in mozillateam preview archives
<asac> and bzr branch
<pochu> asac: do you mean gnomefreak's repo?
<asac> yes
<pochu> didn't see it last time :)
<asac> probably now :) ... however locales are missing so upgrade might not be that smooth
<pochu> do you have the url? I can't find it :/
<gnomefreak> yes hold on a sec
<pochu> ty
<asac> http://wiki.ubuntu.com/MozillaTeam/PreviewArchives
<asac> ?
<pochu> yeah :)
<cjwatson_> conn: we do use swap, but there's something weird going on beyond that that we don't understand
<ajmitch> morning
<Burgwork> hey ajmitch
<ajmitch> how's it going?
<cjwatson_> asac: I commented on bug 107568; I haven't investigated, but it's probably 50/50 between it being a Xubuntu bug or a firefox bug, so could you check that we haven't dropped the appropriate bits of default home page configuration?
<ubotu> Malone bug 107568 in xubuntu-artwork "I have done a netboot install of xubuntu and the ubuntu-artwork folder is missing" [Undecided,Needs info]  https://launchpad.net/bugs/107568
<Burgwork> ajmitch: sick
<asac> cjwatson_: looking
<ajmitch> Burgwork: join the club :)
<asac> cjwatson_: the artwork page is not shipped from within firefox
<asac> its like in my chroot ... if i go homepage its not there
<asac> its file:///usr/share/ubuntu-artwork/home/index.html
<cjwatson_> yes, of course, it's in the relevant flavour artwork packages
<cjwatson_> see the wiki page I referred to in that bug
<cjwatson_> I just wanted to make sure that the appropriate firefox configuration to make use of that was still in place
#ubuntu-devel 2007-04-19
<asac> cjwatson: i guess its firefox looks at /usr/share/ubuntu-artwork/home/index.html (yes we still have that setting) ... but xubuntu-artwork doesn't ship it.
<keescook> Mithrandir, cjwatson: can you shove libx11 through for -security on dapper/edgy please?
<cjwatson> asac: last I heard, xubuntu-docs shipped an alternative, I think
<cjwatson> maybe they dropped that by mistake
<cjwatson> keescook: where, on drescher?
<keescook> cjwatson: I think so?  I assume it's not showing up on the archives because the archives are frozen.
<cjwatson> yeah, publisher's not been running
<cjwatson> let me just make sure it's safe
<cjwatson> looks ok ...
<keescook> cjwatson: thanks!  :)
<cjwatson> mkay, publisher's running
<cjwatson> only seems to be publishing libx11 binaries plus a few misc sources, none to feisty
<cjwatson> firestarter/edgy, python-xlib/edgy, app-install-data-commercial/dapper
<keescook> cjwatson: no clue about the non-libx11 stuff...
<cjwatson> probably SRs
<cjwatson> SRUs
<asac> cjwatson: it works for me: install ubuntu-docs ... set alternative for firefox-homepage to xubuntu
<asac> s/ubuntu-docs/xubuntu-docs/
<cjwatson> it's a recommends of xubuntu-desktop, oughta work fine
<cjwatson> shrug, guess I'll have to follow up tomorrow
<cjwatson> thanks for checking
<asac> hmmm ... maybe they install some other none existing alternative by accident? probably ask user what alternatives are available :)
<asac> cjwatson: makes sense for me to download xubuntu and try vm install tomorrow morning? or too late anyway?
<cjwatson> only if you feel *particularly* keen
<cjwatson> I wouldn't spend too much time on it; sounds like it isn't a firefox problem
<asac> sure ... so if I discover that alternative is really messed up in iso ... would we fix it before release? otherwise, I would not test it :)
<cjwatson> asac: not now, no
<cjwatson> we have completely locked down
<asac> thought so ;)
<cjwatson> I can still imagine scenarios in which we would change things, but they're getting rarer and rarer
<ajmitch> bugs that eat children?
<cjwatson> I rebuilt a few images today, but that was only with fixed cdimage code, not archive changes
<shawarma> xubuntu is releasing tomorrow, too?
<cjwatson> yes
<shawarma> I thought they were usually lagging a few days.
<davmor3> cjwatson: my xubuntu bug #107568 the file firefox asks for is the same as in ubuntu
<ubotu> Malone bug 107568 in xubuntu-artwork "I have done a netboot install of xubuntu and the ubuntu-artwork folder is missing" [Undecided,Needs info]  https://launchpad.net/bugs/107568
<shawarma> "usually" takes on a special meaning for something that has released twice or so. :-)
<asac> davmor3: what alternatives do you have?
<davmor3> asac: sorry?
<cjwatson> shawarma: I don't believe Xubuntu has ever lagged in terms of final releases. Announcements may have lagged.
<asac> davmor3: update-alternatives --display firefox-homepage
<cjwatson> davmor3: yes, that's intentional
<shawarma> cjwatson: Ah, yes, I suppose that may have been the case.
<cjwatson> davmor3: it's supposed to point to /usr/share/ubuntu-artwork/blah - alternatives sort that out, and the command asac posted above should determine whether that mechanism is functioning correctly
<cjwatson> in any case the bug is not that firefox is pointing to /usr/share/ubuntu-artwork/home/firefox-index.html for its home page
<davmor3> cjwatson: yes but that page is missing completely the folder is also in a different place
<cjwatson> davmor3: please answer asac
<cjwatson> we know that the real file is in a different place, but the alternatives mechanism is *supposed* to install a symlink
<cjwatson> we are trying to work out where the bug in that mechanism is
<cjwatson> repeatedly telling us that the file is missing does not help
<davmor3> sorry hang on
<cjwatson> the xubuntu-docs package appears to take care of it
<Kmos> at my feisty ubuntu:
<Kmos> kmos@bash:~$ update-alternatives --display firefox-homepage
<Kmos> firefox-homepage - status is auto. link currently points to /usr/share/ubuntu-artwork/home/firefox-index.html
<Kmos> /usr/share/ubuntu-artwork/home/firefox-index.html - priority 40 slave firefox-homepage-locales: /usr/share/ubuntu-artwork/home/locales-ubuntu
<cjwatson> do you have /usr/share/xubuntu-docs/about/xubuntu-index.html ?
<Kmos> Current `best' version is /usr/share/ubuntu-artwork/home/firefox-index.html.
<cjwatson> Kmos: please, not from an Ubuntu installation
<cjwatson> Kmos: this is apparently a Xubuntu-specific problem of some kind
<Kmos> cjwatson: ok, just to test :)
<cjwatson> the code in xubuntu-docs.postinst looks correct to me
<Kmos> davmor3: show the command output
<asac> i just can imagine that some none existing alternative with higher priority is installed by accident
<davmor3> ascs: no alternatives for firefox-homepage
<asac> no?
<cjwatson> davmor3: dpkg -l xubuntu-docs
<cjwatson> keescook: published
<keescook> cjwatson: great!  thank you.  :)
<cjwatson> xubuntu-docs has Task: xubuntu-desktop so should be installed
<cjwatson> davmor3: did you definitely select the "Xubuntu desktop" task in the installer?
<cjwatson> (probably best to answer those questions in order ...)
<cjwatson> ok, I have to go to bed, sorry, hopefully somebody else can run with the answers
<asac> will be awake for another 15 minutes :)
<asac> so davmor3 better answer fast :)
<asac> cjwatson: night
<davmor3> cjwatson: Yes I only selected xubuntu.
<Kmos> davmor3: dpkg -l xubuntu-docs (run this command and show us the output)
<davmor3> Kmos: I'll tell you dpkg -l says un xubuntu-docs
<Jordan_U> Sorry if this is the wrong place, but ubuntu.com is down, is this schedualed? If not it is a bad time to be down on the eve of a new release.
<davmor3> Kmos: anything else did I miss anything?
<asac> davmor3: what iso did you download? daily? or daily-live?
<davmor3> netboot
<asac> davmor3: xubuntu-docs is not installed
<shawarma> Jordan_U: I can see it right now.
<shawarma> Jordan_U: It took a while, but it got there eventually.
<asac> davmor3: can you drop that info to bug?
<davmor3> okay I'm installing them then do I run the alternative line again?
<asac> davmor3: no if you install it it should just work
<asac> bug would be that its not installed by default
<Jordan_U> shawarma, Timed out for me, I can ping it though, which is what makes me suspect it is just schedualed so they can change the home page
<davmor3> yeap thanks
<davmor3> it's alive :)
<Kmos> ubuntu.com is very slowly :)
<davmor3> nice one I'll add it to the report many thanks
<shawarma> davmor3: You can probably do an 'apt-get install xubuntu-desktop^' and everything will be fine. Notice the ^ 
<davmor3> shawarma: thanks everything else seems fine but I was reporting more from iso testing point of view than anything else.
<shawarma> davmor3: Sure. It's appreciated.
<davmor3> night
<Riddell> Mithrandir: all Kubuntu DVDs good to go (as are CDs)
<Enverex> Does Ubuntu have a "rolling version"?
<ion_> Is a rocking version good enough?
<cypherbios> lol
<Enverex> ...
<PriceChild> !release > Enverex 
<Enverex> I know there are fixed releases every 6 months, that wasn't my question.
<fabbione> morning
<tonyyarusso> mornin'
<tonyyarusso> Night here, but hey
<ajmitch> morning fabbione 
<nixternal> is it out yet?
<nixternal> d'oh
<tonyyarusso> lol nixternal - the release party's over there... ;)
<nixternal> that didn't work good as a joke because I was scrolled up to 2 days ago when dholbach joined the channel :)
<Mithrandir> Riddell: great, thanks.
<Mithrandir> good morning everybody
<fabbione> morning Mirv 
<fabbione> AMEN
<fabbione> morning Mithrandir 
<Nergar> please all mighty devs, when will feisty be released???
<ajmitch> morning Mithrandir 
<ion_> Most likely this year.
<Nergar> :(
<Mithrandir> Nergar: #ubuntu+1 is too boring yet.  It needs to boil first.
<Nergar> #ubuntu-release-party is getting crazy!
* Nergar dances
<dholbach> good morning
<ion_> Hi
<dholbach> hi ion_
* ..[topic/#ubuntu-devel:fabbione] : Development of Ubuntu (not support, even with feisty; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy, #ubuntu+1 for feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Entire archive frozen for release | stop asking AWTY
<ajmitch> hey dholbach 
<dholbach> hi ajmitch
<micahcowan> AWTY?
<Mithrandir> Are We There Yet
<dholbach> hey tollef
<micahcowan> (not that any of 'em will actually start bothering to read the topic...)
<Mithrandir> morning, Daniel.
<fabbione> micahcowan: but we can point to it and if it becomes unbearable +m :)
<tonyyarusso> dholbach, sabdfl, ajmitch, cjwatson, keescook, mako, mdz, BenC, whomever this is appropriate for:  We have #ubuntu-release-party if someone wants to drop by when the time comes and start the torrenting off with a bang.
<RenatoSilva> BTW, is there a scheduled TIME?
<tonyyarusso> Doubt it
<ajmitch> RenatoSilva: when it's ready
<RenatoSilva> I guess in London it's 11:28 pm
<RenatoSilva> ajmitch: still working on it? :D desperated, making the final refinements? I'm developer, I know how it is :)
<Mithrandir> actually, I'm just eating breakfast.  Can't release without breakfast.
<tonyyarusso> lol, true
<RenatoSilva> Mithrandir: uhauahuauahauhahua
<RenatoSilva> true
<Burgundavia> we need a quotebot
<pitti> Good morning
<Lathiat> howdy
<fabbione> hi pitti
<tonyyarusso> Hey pitti 
<Hobbsee> hiya pitti, Lathiat, fabbione and tonyyarusso :)
<fabbione> hey Hobbsee 
<Lathiat> howdy Hobbsee 
<Lathiat> this could go all day.. ;)
* Lathiat optimizes
<Lathiat> "howdy everyone"
<Mithrandir> hiya pitti, Hobbsee.
<Hobbsee> hi Mithrandir :)
<Hobbsee> Lathiat: heh
<codingmaster> hey pitti :)
<imbrandon> qqq
<imbrandon> \
<imbrandon> hrm
* Treenaks takes imbrandon's keyboard away
<ion_> Record an empty macro into register q, do nothing for a while, move one character left and replace it with a m?
<pitti> Hi Mithrandir! When you will .... have lunch today? :-P
<Mithrandir> pitti: just after release, I think.
<Fujitsu> Mithrandir: I presume that's going to be a very late lunch, then.
<Mithrandir> Fujitsu: I hope and believe you are wrong.
<Fujitsu> Oh, good.
<Kljaver> We are all waiting!!! =)
<Hobbsee> Kljaver: it's all a conspiracy.  it'll never release
<Kljaver> Hobbsee, =D
<kwah> hehe
<Treenaks> Hobbsee: We'll converge to a release, but never quite get there?
* Treenaks calls a mathematician to resolve this
<Hobbsee> Treenaks: nah.  feisty is an illusion.  it's vaporware
<heno> 'Eternity is a very long time, esp. towards the end.'
<heno> (Woody Allen, I believe)
<xarquid> Are any of you running beta's daily build release from April 15th and going to simply update using the Update Manager or will you guys/gals do a fresh install? Just curious :)
<xarquid> Also, any of you actively on the Compiz bug? I see a few fixes in the packages that may resolve some of the issues in the repository database
* kwah thinks, that his system is already running feisty
<kwah> will do update
<xarquid> kwah, well I am but not technically the release ;p I'm not special like that yet!
<kwah> don't think it will update anything %)
<xarquid> i hear ya ;p
<xarquid> Is there a list of contacts anywhere for certain bugs/applications in the releases? I may just be blind.
<kwah> xarquid, hehe https://help.ubuntu.com/community/ReportingBugs
<xarquid> I know the community board has a great list of contacts but do not necessarily go into detail about project managers
<kwah> launchpad is your friend
<xarquid> Aye, I use it hourly almost
<xarquid> However, most of the Compiz bugs I see aren't assigned to a team?
<jsgotangco> real men install and install until their hard drives die
<Fujitsu> xarquid: That is a a problem?
<Fujitsu> s/ a//
<ion_> ggdG
<xarquid> Fujitsu: Well, no. It's not a problem! I mean, what if I want to propose a fix? Just put it in the thread. I just do not know how to handle proposing fixes and/or taking responsibility for a fix if I have them.
<jsgotangco> hey sabdfl happy release day :)
<Kljaver> jsgotangco, but where release o_O ?
<jsgotangco> Kljaver: patience, the big red button will be pushed soon
<tepsipakki> I thought it was orange..
<JanDM> Is there really such button? :P
<jsgotangco> it may not be red, but there is definitely a button
<ivoks> no, it's green :)
<kwah> led free?
<kwah> a, no. it is just free.
* Fujitsu looks at Mithrandir for a definitive answer on the colour of the mythical button.
* dAndy suspects white and enter key shaped
<Kljaver> =D kwah burning!!!
* kwah suspects that it might be a key on Das Keyboard
<Kljaver> =)
<Mithrandir> Fujitsu: depends on which machine I use.  White, blue or black.  All with a bit of brown dirt on them.
<JanDM> Fujitsu: I think it's a 'human' style button...
<Mithrandir> JanDM: that wasn't an option when I bought my thinkpad.
<Fujitsu> JanDM: You think?
<JanDM> Minthrandir: ow is it a real button
<Fujitsu> Mithrandir: A blue keyboard? Never seen one of them before.
<Mithrandir> Fujitsu: no, just the enter key.  Actually, closer to indigo.
<Fujitsu> Oh, that strange ThinkPad colour.
<mdz> morning
<Fujitsu> Hi mdz.
<Kljaver> mdz, q!
<ivoks> Mithrandir: so, you already have ./release-now and just waiting to hit enter? :)
<JanDM> ivoks: he is just teasing us and laughing at the forums :)
<Mithrandir> ivoks: the actual command is "sync-mirrors", but yes.
<Mithrandir> and I haven't typed it into a terminal yet.
<ivoks> :)
<pitti> hey mdz, good morning
<tepsipakki> is the knownissues-page kept open for editing after release?
<Nafallo> hehe
<Nafallo> I woke up before release atleast :-)
<mdz> tepsipakki: I suppose, but users won't be pointed to that page. why?
<tepsipakki> mdz: oh ok, who is it for then?
<mdz> tepsipakki: it was a scratch space for writing the release notes
<tepsipakki> mdz: ok
<pitti> wow, one of those rare days where update-notifier does not jump at me in the morning ;)
<fabbione> eheh
<Kljaver> hehe =)
<fiery_cleric> exit
<ion_> pitti: :-)
<jsgotangco> absolute mayhem
<Kljaver> http://torrent.ubuntu.com:6969/   is there release?
<jsgotangco> i would advise waiting for the annoucement, its not like you'll run out of iso
<Kljaver> oops
<cjwatson> Kljaver: no, not until the release manager says so
<cjwatson> nothing there right now is final
<Kljaver> ok
<Treenaks> (except the isos for older releases: 6.06.*, 6.10, etc.)
<Treenaks> (I guess)
<jsgotangco> its a shame that some people are downloading the wrong images now
<cjwatson> oh, sure, not final feisty I mean
<phire> it always happens
<phire> every single time
* hunger thought there would be another kernel upgrade before final. Was that cancelled?
<jsgotangco> the last updates i got were for update-manager and update-manager-core
<cjwatson> there were several kernel upgrades before final
<cjwatson> there were none planned after -15.27
<hunger> cjwatson: Yeap... but -15 is absolutely instable. I went back to -13 again.
<ivoks> it would be great to work on update of dapper now
<ivoks> latest 3ware controllers and intel gigabit cards don't work :/
<Fujitsu> fabbione: You are brave.
<fabbione> Fujitsu: why?
<fabbione> there is nothing wrong in explaining to people
<cjwatson> hunger: bug#? (it won't be fixed pre-release now but might be fixable in an update
<cjwatson> )
<hunger> cjwatson: I didn't report it since it a) crashes randomly and b) I was told there will be a new version anyway.
<cjwatson> information like b) is typically unreliable and there is no reason why it should fix your problem if it's not reported
<cjwatson> there isn't a crash_now() function that was inserted by accident ;-) it would need investigation
<hunger> cjwatson: Yeap. And with that I can not help, so there is not much sense with writing a bugreport:-(
<cjwatson> then I'm afraid it is unlikely that your problem will be fixed except by dumb luck
<hunger> cjwatson: My box just freezes after a while:-(
<tepsipakki> hunger: broken memory?
<pitti> hunger: nothing in kern.log after reboot?
<\sh> pitti: moins...question: is it possible (for later) to switch off apport for special packages/apps?
<hunger> tepsipakki: Kernel -13 works like a charm, never had any crash with that, so I'd guess it is unlikely.
<pitti> \sh: such a thing is on the TODO list
<pitti>  - support /etc/apport/blacklist.d/ for check_ignored(): one exe
<pitti>    per line
<hunger> pitti: Nothing useful:-( Not even a Oops or anything.
<pitti> \sh: I didn't squeeze it into feisty, because u-n won't report apport crashes by default
<\sh> pitti: cool...and will it be possible to set a different backtrace functionality for special packages/apps? (I'm thinking about wine, just because we would need there the winedbg debugger app)
<pitti> \sh: not  sure what you mean; but you can certainly add a package hook
<pitti> \sh: /usr/share/doc/apport/package-hooks.txt
<\sh> pitti: thx a lot ... that's all I need to know:)
<jsgotangco> Seveas: +1
<Mithrandir> heno: fwiw, i386 dvd with server seems happy for me on real hardware.
<jsgotangco> wow that's like a year old bug
<jsgotangco> heh
<jsgotangco> oopss
<Treenaks> jsgotangco: it's a bug  that i386dvd looks happy?
<jsgotangco> no no no remember  bug 20247
<ubotu> Malone bug 20247 in netcfg "WEP key setting doesn't work on IPW2200 without "restricted"" [Medium,Confirmed]  https://launchpad.net/bugs/20247
<heno> Mithrandir: cool. I tested the server CD in virtual box and that fails too, so it seems cjwatson is right that vbox doesn't like the server kernel
<Mithrandir> heno: sucks to be vbox. :-P
<cjwatson> jsgotangco: I'm just clearing up my +assignedbugs page, that's all
<jsgotangco> ahh
<juliux> hi, did anybody know why there are no jigdo files for the desktop isos?
<cjwatson> juliux: it would be pointless
<cjwatson> juliux: jigdo has no idea how to disassemble a squashfs
<cjwatson> juliux: so you'd basically get a .template roughly equivalent in size to the .iso
<juliux> cjwatson, ah thanks
<juliux> cjwatson, i was just wondering
<Treenaks> jsgotangco: oh wow, that's my bug, even
<sabdfl> hey jsgotangco - to you too!
* pitti waves to sabdfl
<seb128> hi sabdfl
<juliux> hi sabdfl 
<\sh> moins sabdfl
* \sh needs some coffee and a guardian angel...
<ajmitch> hehe
* ajmitch just needs dinner
<jsgotangco> ajmitch: is it still the 19th there? hehe
<ajmitch> sure
<ajmitch> just after 9pm
<ajmitch> it's funny how so many people are on the edge of their seats
<jsgotangco> heh
<ajmitch> this is probably the calmest ubuntu channel of the lot
<jsgotangco> its alright, their anticipation is a good thing
<jsgotangco> well its a good diversion so as not to have them flood here
<\sh> ajmitch: I have to update 350 servers and more still counting with some pam.d changes regarding ldap...:( 
<ajmitch> \sh: lots of fun
<jsgotangco> 350!
<fabbione> \sh: if the change is the same all over, just script it
<\sh> jsgotangco: more 
<fabbione> there is a cluster ssh something to do exactly that
<jsgotangco> so you do fai stuff over there?
<\sh> fabbione: yepp...I scripted it already...
<\sh> jsgotangco: nope..those machines are in production...so a live change ;()
<\sh> jsgotangco: doing normal for|ssh|sed|awk|done stuff ,->
<jsgotangco> fun edge on your seat scenario
<\sh> fabbione: not on sles9
<\sh> well, you can listen to some internals during froscon...I'll talk about FAI/HP OpenView ServiceDesk/Deployment etc. together with thomas lange
<ajmitch> \sh: what's the pam change?
<Chipzz> \sh: do you know dsh? :)
<\sh> ajmitch: adding ldap to all machines which are not already connected to ldap...so doing changes to login/ssh
<ajmitch> ah fun
<Kljaver> i feel release will come very soon (release/source/)
<xarquid> so most of these people in ubuntu-release-party are killing my eyes. *rubs*
<jsgotangco> alright im going home, happy release day everyone ciao
<xarquid> cya js
<ajmitch> see you later, jsgotangco 
<juliux> can someboy check the bittorrent tracker?
<Kljaver> juliux, for what?
<juliux> Kljaver, i get an error if i try to seed the feisty isos: rejected by tracker - Requested download is not authorized for use with this tracker.
<Kljaver> juliux, is already release? i dont understand!
<JanDM> juliux, just wait before it's released
<juliux> it is on the mirros;)
<Kljaver> where?
<Kljaver> O_O
<cjwatson> we have an announcement list for this
<cjwatson> use it and wait for the mail to arrive
<xarquid> what you see on the mirrors is either from the 15th or your simply see directories dated the 19th.
<mvo> pitti: #96244 is ready (modulo feisty-proposed of course)
<juliux> xarquid, i see an iso from today
<Kljaver> xarquid, yes you are right
<pitti> mvo: thanks
<xarquid> i know, i was just telling jul
<pygi> hi mvo, pitti 
<xarquid> i think some of these people are now =delirious ... maybe.
<Kljaver> =D
<mvo> hey pygi!
<pygi> mvo, how is it? :)
<ajmitch> hey pygi, mvo 
<mvo> hey ajmitch
<mvo> pygi: good, thanks. good tea, release day, sunshine. do I have to say more ;) ?
<Kljaver> http://releases.ubuntu.com/7.04/   what is it?
<pygi> mvo, no :)
<pygi> mvo, glad to hear ^_^
<seb128> doko: did you look at the python bug with setlocale I mentioned some time ago?
<seb128> $ LC_ALL=de_DE.UTF-8 python -c "import locale; locale.setlocale(locale.LC_ALL, '')"
<seb128> Traceback (most recent call last):
<seb128>   File "<string>", line 1, in <module>
<seb128>   File "/usr/lib/python2.5/locale.py", line 476, in setlocale
<seb128>     return _setlocale(category, locale)
<seb128> locale.Error: unsupported locale setting
<seb128> doko: we have several bug of apps crashing this way and it would be nice to know if they all should have a try, except or if if that's a python bug
<Mitario> mvo: hey :)
<Mitario> dholbach: quite a bit quiter here :)
<saispo> first update for feisty is thunderbird 2 ? ;)
<mvo> Mitario: hello! long time not seen :) 
<dholbach> yeh, not quite that frantic
<seb128> saispo: no new versions to stable
<Mitario> mvo: indeed :) hi! how are you?
<ajmitch> it had better be quieter here..
<ajmitch> time to start on specs 
<saispo> hi seb128 :)
<Mitario> ajmitch: seconded
<seb128> lu saispo
<mvo> Mitario: good! and you?
<saispo> great work to all ubuntu devellopers !
<xarquid> this is like paradise for my eyes compared to the other rooms :)
<saispo> this release is very impressive and work very well
<Mitario> mvo: quite well :) been busy in dutch politics last 3/4 - 1 year
<Mitario> mvo: but my term ends in a month so will be going active in the ubuntu/gnome community quite soon
* Mitario misses it
<mvo> Mitario: w00t!
<mvo> Mitario: we will be happy to have you back :-D
<Mitario> haha, thanks :) me too
<Mitario> mvo: i saw your great work on update-manager btw
<Mitario> and others probably ;)
<Kljaver> Congratulations to all!!!
<Kljaver> =D
<Mitario> mvo: but i'll cheer you up for it
<mvo> Mitario: :) thanks - glatzor was pretty active too the last couple of months on it
<Mitario> ok :) great
<Kljaver> http://www.ubuntu.com/  IS DOWN!!! =P
<Mitario> mvo: the dist upgrade functionality really works well
<Mitario> how it will work today as well ;)
<ivoks> congratz everyone (i have to go)
<xarquid> cya ivoks
<ivoks> this will be the best release til now
<Mitario> ivoks: i say that with every ubuntu release ;)
<Mitario> ivoks: cheers to you
<ivoks> Mitario: well, i didn't with edgy :)
<ivoks> bye
<iwj> Bloody hell, the `logout' option on this edubuntu install doesn't work.
<iwj> Oh, that's because I logged in twice as the same user and it broke everything.
<xarquid>   Something you wouldn't regularly see lately though, good to know lol
* iwj increases the severity of bug 67366.
<ubotu> Malone bug 67366 in ltsp "LDM does not warn when a user is already logged in" [Medium,Confirmed]  https://launchpad.net/bugs/67366
<ogra> iwj, yesterday specced for UDS ;)
<iwj> Oh, good.
<iwj> TBPB it's _hopelessly lame_ that you can't log in more than once.
* iwj files 107672 and seb128 will thank me ha ha.
<iwj> bug 107672 even
<ubotu> Malone bug 107672 in gnome-session "multiple logins by same user" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107672
<seb128> yet another dup? ;)
<iwj> I couldn't find any existing report.
<seb128> hum, in fact not exactly
<seb128> there was a bug on gdm to not let an user log in twice
<pygi> seb128, hi ho, long time no see =)
<seb128> which has been fixed, it uses the previous session
<iwj> seb128: That would be sensible.
<iwj> But my complaint is that you ought to be allowed to dammit.
<seb128> but you use 2 boxes which is a new corner case ;)
<seb128> right
<iwj> Bug 67366 is about the fact that it let me do it.
<ubotu> Malone bug 67366 in ltsp "LDM does not warn when a user is already logged in" [Medium,Confirmed]  https://launchpad.net/bugs/67366
<iwj> Bug 107672 is about the fact that it ought to have worked.
<ubotu> Malone bug 107672 in gnome-session "multiple logins by same user" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107672
<seb128> hi pygi
<iwj> So please rewrite the whole of gnome.  Perhaps you can preview it for UDS for us.
<cjwatson> heh
<pygi> iwj, ehm ...
<iwj> You're talking to the submitter of Debian #1708 here :-).  I don't expect my bugs to get fixed ...
<iwj> 12:00 <ubotu> Error: Could not parse data returned by Debian bugtracker: need more than 1 value to unpack
<seb128> ;)
<pygi> seb128, will we fix this cd-recording stuff finally this year? :-)
<seb128> pygi: would be nice ;)
<thom> hasn't that been said every release since hoglet? :-)
<Riddell> Seveas: I feel so left out at not have an @ sign in -party
<pygi> thom, what? :)
<pygi> thom, you mean about the burning?
<thom> pygi: yeah
<pygi> thom, perhaps ^_^
<ogra> seb128, i'll have a thin client with me in sevilla, lets have a look at that there, since i plan some ldm sessions :)
<ogra> s/sessions/BOFs/
<pygi> thom, we'll see how it goes ^_^
<seb128> ogra: k
<thom> pygi: *g*
<pygi> seb128, thom : you ought to be in #ubuntu-burning :P
<seb128> too many chans already ;)
<pygi> although no one is ever there
<thom> pygi: i'm not that interested, just amused :-)
<pygi> thom, ok, it'll still be fixed ^_^ Just be patient pls :)
<pygi> You was patient for 20 years already so :P
<ajmitch> pygi: isn't schily's cdrecord good enough? :)
* thom douses ajmitch in holy water
<pygi> ajmitch, sure, I didn't mention any application or anything =)
<ogra> iwj, gnome upstream is working on consolekit, that defines a "seats" mechanism it assigns the apps to, i guess that will solve the problem once and for all at some point
<Lutin> Mithrandir: are you around ?
<Mithrandir> Lutin: yes, why?
<pygi> ajmitch, I'm not allowed to talk to much in this channel like I used to before :(
<ajmitch> pygi: not allowed?
<pygi> exactly ^_^
<Lutin> Mithrandir: I've got an issue with the cinepaint package. actually it got accepted and built for all archs, but only released for amd64
<Mithrandir> Lutin: uh, the binaries might have gotten lost.
<cjwatson> failed-to-move is empty
<Mithrandir> Lutin: can you email ubuntu-archive@lists.ubuntu.com about it?
<cjwatson> (phew)
<Mithrandir> I'm ever-so-slightly busy.
<Lutin> Mithrandir: okay
<Mithrandir> thanks
<iwj> Assigns the apps to `seats' ?  I doubt that will really help.
<cjwatson> 08:16:02 INFO    Rejected:
<cjwatson> 08:16:02 INFO    Exception while accepting: ERROR:  duplicate key violates unique constraint "distroreleasequeuebuild__distroreleasequeue__build__unique"
<cjwatson> (cinepaint)
<cjwatson> fun fun fun
<cjwatson> absolutely no idea why that happened
<pygi> thom, so all I can say is ... be patient :)
<iwj> ogra: I'm not sure what that means exactly but it sounds like only one of your sessions will be able to run each app ?  Which is a bit bad.
<Mithrandir> cjwatson: I suggest we just do an -updates no-change-rebuild.
<pygi> seb128, how would you feel about blocking n-c-b to overburn? (if it can do that)
<cjwatson> Mithrandir: I guess
<seb128> pygi: blocking?
<iwj> Of course the main application you might want to do this with is .... firefox!  And that's not going to work properly any time soon.
<pygi> seb128, ergh, well, removing the chunk of code that allows overburn
<ajmitch> pygi: why?
<ajmitch> does overburning break things in weird ways?
<pygi> ajmitch, because overburning is not good =)
<seb128> pygi: why?
<seb128> pygi: it's useful
<pygi> but oh well, what do I know =)
<pygi> seb128, in some situations perhaps, yes
<pygi> oh well, I'm quiet :)
* pygi goes back to his work and stops preventing people from working
<seb128> it's not un-usual to have an iso oversized
<seb128> and being able to write it on a CD is nice
<iwj> ogra: The student control panel thing (called `thin client manager' in the menu unlike the instructions in Testing/Short) is quite impressive.
<ogra> thanks
<ogra> its still not done ... we planned far more features .-... (iCafe support ... billing backend, better vnc support)
* Fujitsu agrees with iwj very much.
<Fujitsu> I particularly like the tiled VNC viewers.
<ogra> yeah they are cool if they update :) but you still have to set up x112vnc manually thats a big backdraw gutsy needs to fix...
<iwj> Why can't this thin client access www.ubuntu.com ?  It can do everything else ...
<ogra> can your server access it ?
<iwj> Oh, no, here it is.  Maybe the server was just being slow.
<pygi> heh :)
<pygi> iwj, it is too slow, yes
<ajmitch> because there are a lot of people checking to see if feisty is release
<ogra> yeah it was ... the whole morning :)
<ogra> should be a lot better now
<jsgotangco> ZOMG want feisty
<pygi> get it then xD
<hunger> Will the new ATI drivers make it into feisty soonish? They are supposed to fix bugs only and add support vor kernel 2.6.20.
<jsgotangco> damn my fingers almost got bonded by super glue
<pitti> hunger: feisty is closed
<rytmisk> Hi I have an apt bug after upgrading - a helpful guy in #ubuntu-desktop refered me here
<hunger> pitti: There will be updates at some point I hope:-)
<AlinuxOS> hello all! :)
<rytmisk> It is a long list in the line of
<rytmisk> E: dmsetup: underprosessen post-installation script returnerte feilstatus 1 
<ajmitch> rytmisk: I saw the conversation in ubuntu-desktop, is /boot full?
<rytmisk> in norwegian = sub process post-installation script returnedNo 4.8 gb free
<rytmisk> according to nautilus
<iwj> ogra: And generally I should say that despite the beatings I keep giving you about bugs and things, I'm impressed with how smooth and functional the edubuntu ltsp setup is.
<ajmitch> alright, it was just one of the more obvious reasons for things failing that I've had :)
<rytmisk> 4.8 gb should be sufficient
<rytmisk> Good tip!
<ogra> iwj, i appreciate your feedback, its not "beatings" :)
<ogra> and thanks :D
<ogra> you find many things no user ever reports to me, thats immensely important for me
<pygi> iwj, you mean the ltsp even works? :-)
* pygi hides
* pitti tested it yesterday for the first time and was impressed; sure, some bugs, but still this is amazing stuff
<ogra> pygi, it manages pretty well to pretend that i'd say :)
* pitti hugs ogra
* ogra hugs pitti 
<Monk-e> Congrats on feisty.
<ogra> not yet :)
<Monk-e> Kind of.
<bhale> its not over until the fat troll sings (slashdot)
* Monk-e is downloading the i386 dvd image right now.
<jsgotangco> dinner brb
<shawarma> Are the iso's at http://releases.ubuntu.com/7.04/ the final ones? I'm just wondering if there's any point in starting to seed the via bittorrent already.
<jsgotangco> 630+ people in #ubuntu-release-party is asking the same thing
<jsgotangco> heh
* fabbione points shawarma to /topic
<shawarma> fabbione: *G*
<fabbione> shawarma: no... no point the trackers are not available yet
<fabbione> and the images are not final until we announce so
<shawarma> Sorry. My screen isn't wide enough to show the entire topic. I didn't notice.
<xarquid> This is the time to prove that VIRUSES can -prevail- in Linux/Ubuntu if you download the wrong ISO/Torrent.
* xarquid nods in agreeement with himself.
* xarquid eyes #ubuntu-release-party with a red eye.
<doko> seb128: no, buz just checked, and it works for me. did you generate the de_DE.UTF-8 locales?
<jsgotangco> christ
<cjwatson> doko: the bug is precisely asking whether an exception is the right thing to do if the locale doesn't exist
<cjwatson> it's usually unnecessary to fall over and die if a locale is missing, IME, but shrug
<cjwatson> I suppose there ought to be some way for programs that do care to know
<seb128> doko: no, that's what the bug is about
<seb128> doko: I think it should fallback to C and not break when you don't have the locale
<doko> cjwatson, seb128: well, if language-support-xx would generate the locales, we would have a lot less reports. anyway, what was the bug number?
<seb128> doko: there is bugs on random apps, not on python
<seb128> I was asking if I should open one on python and dup them
<cjwatson> doko: I don't think that would be any excuse
<seb128> or if apps are to change
<cjwatson> anyway, language-pack-xx generates the locales
<cjwatson> language-pack-xx-base rather
<cjwatson> as in fact does language-support-xx
<cjwatson> but there is no requirement to have either installed when you're trying something random out
<doko> cjwatson, seb128: how could that be done?
<doko>     if (locale) {
<doko>         /* set locale */
<doko>         result = setlocale(category, locale);
<doko>         if (!result) {
<doko>             /* operation failed, no setting was changed */
<doko>             PyErr_SetString(Error, "unsupported locale setting");
<doko>             return NULL;
<doko>         }
<doko> cjwatson, seb128: setlocale(3) returns NULL, nothing else, or can I set the locale in another way?
<doko> "The return value is NULL if the request cannot be honored."
<cjwatson> it could ... not throw an exception? :P
<cjwatson> that would be an upstream decision though
<cjwatson> I think in the meantime applications should clearly catch setlocale exceptions and ignore them
<cjwatson> in almost every possible case
<doko> cjwatson: no, that would mean to deviate from upstream.
<cjwatson> doko: I don't think seb is necessarily suggesting the change shouldn't be made upstream.
<seb128> I'm asking whether that's a python bug or not
<tepsipakki> whoa, check slashdot :P
<doko> cjwatson: ahh, ok. will take it upstream; 2.6 is still long away; and such kind of change will not happen in the 2.5 branch, so better check in the applications
<seb128> doko: ok, that's what I wanted to know
<seb128> thanks
<seb128> doko: could you suggest them to change it for 2.6 though?
<doko> seb128, cjwatson: I can do it, but I fail to see the reason. why not change setlocale(3) in glibc then to ignore it?
<cjwatson> setlocale(3) doesn't throw an exception, it just returns NULL
<cjwatson> most C programs ignore the result of setlocale(3), but that's because in C it doesn't take much effort to do so
<cjwatson> in python you need to actively work to do so
<cjwatson> in most cases this is a good thing but arguably less so in this case
<doko> it's an error condition, which is signalled else in python and C
<cjwatson> yes, but C->python ought not to be a mechanical translation
<seb128> C program don't segfault on it
<seb128> python program do stop on a exception
<cjwatson> turning good C APIs into good Python APIs requires actual thought, so I don't buy mechanical arguments
<doko> I could imagine an additionaloptional parameter to ignore errors for the C API
<cjwatson> it should be a warning, not an error
<jsgotangco> PriceChild: err what's with the ban heh..
<PriceChild> jsgotangco, you were hit by a DCC attack.
<PriceChild> !dcc > jsgotangco 
<jsgotangco> ouchie
<PriceChild> jsgotangco, join #pricechild and ping me for a test when ready :)
<jsgotangco> thanks
<seb128> doko: 
<seb128> bug #88638
<ubotu> Malone bug 88638 in pitivi "[apport]  pitivi crashed with Error in setlocale()" [Medium,Confirmed]  https://launchpad.net/bugs/88638
<seb128> bug #81556
<ubotu> Malone bug 81556 in exaile "[apport]  exaile crashed with Error in setlocale()" [Medium,Confirmed]  https://launchpad.net/bugs/81556
<seb128> bug #90525
<ubotu> Malone bug 90525 in hwdb-client "[apport]  hwdb-gui crashed with Error in setlocale()" [Medium,Confirmed]  https://launchpad.net/bugs/90525
<seb128> doko: etc
<seb128> doko: pitivi upstream says that it uses to no break, maybe that's new with python2.5
<doko> seb128: ok, thanks, but better fix these as long as we use 2.5
<seb128> doko: can't we distro patch python rather than patching a zillion of apps?
<cjwatson> the obvious concern is that some things might actually have a legitimate reason to care that setlocale fails
<cjwatson> I can't think of any offhand, but it's imaginable
<cjwatson> so those programs would break if we patched python, and there would be no obvious compatible way to fix them
<doko> seb128: IMO it's a very bad idea to deviate from upstream. do you know why this happens with en_US.UTF-8 and en_GB.UTF-8? these locales should be present on every system
<cjwatson> the only locales that a sane program is allowed to expect to exist on every system are C and POSIX
<Mithrandir> doko: why would they be present on every system?
<seb128> doko: they use 'locale.setlocale(locale.LC_ALL, '')'
<seb128> hum
<seb128> dunno
<doko> Mithrandir: well, on every desktop system
<cjwatson> there is a very common reason why you might set a locale that does not exist on your system
<cjwatson> ssh forwards your LANG and LC_* environment variables
<cjwatson> this is usually a good thing, because it means you get the same character encoding and such at the other end
<Mithrandir> doko: you didn't anwer my question; there's no real reason for me to have en_GB or en_US installed.
<cjwatson> but it is incredibly annoying when silly programs decide that the appropriate response to the locale not existing is to crash, rather than just carrying on
<radevil> like cedega
<cjwatson> doko: en_US.UTF-8 doesn't exist on chinstrap
<doko> Mithrandir: I'm wondering why people do see this very often, even with locales which are generated on every desktop install. cjwatson: chinstrap doesn't have a desktop install afaik
<cjwatson> any of our developers with LANG=en_US.UTF-8 locally who sshes to chinstrap, by default, will find that python programs that use locale.setlocale will crash
<cjwatson> doko: oh, for goodness' sake. Since when was Python only for desktop installations?
<cjwatson> let's say man were implemented in Python
<cjwatson> it could easily be - it's not, but it could be
<cjwatson> it does setlocale()
<cjwatson> or let's take a more realistic example
<cjwatson> bzr
<Fujitsu> Um, all of the announcements on ubuntu.com are dated the 16th. That might want to be fixed.
<cjwatson> Fujitsu: they went out early for the PR company
<Fujitsu> cjwatson: Ah, I see.
<doko> cjwatson: calm down, I'm not saying that python is only used on the desktop ;-) , the cited bug reports were for desktop applications only.
<cjwatson> doko: bzr definitely crashed due to this not that long ago
<cjwatson> I think it's been fixed now, but still
<cjwatson> I agree with you that it's not a good idea to deviate from upstream
<seb128> doko: bug #91583 is a non-desktop one ;)
<ubotu> Malone bug 91583 in apt-listchanges "[apport]  apt-listchanges crashed with Error in setlocale()" [Medium,Unconfirmed]  https://launchpad.net/bugs/91583
<cjwatson> I think we're stuck with patching all the applications for now, anyway
<cr3> cjwatson: thanks for your message to Selbak about logging bugs as "private for unreleased hardware". do you think this is worth addressing in a generic sense to formalize a new feature for malone?
<cr3> crap, that's off topic in here, sorry folks :(
<cjwatson> cr3: the feature used to exist in Malone and was deliberately disabled
<cjwatson> for UI reasons
<cjwatson> so I'm not holding my breath
<cr3> cjwatson: but as more commercial users start using malone, the lack of such a feature might become increasingly problematic
<cjwatson> cr3: I would certainly love to have something better than filing them as security vulnerabilities
<danielk> hey
<dholbach> hi danielk
<danielk> hey ho dholbach
<Hobbsee> hi danielk, dholbach 
<dholbach> hey Hobbsee
<danielk> hey Hobbsee
<doko> cjwatson, seb128: http://python.org/sf/1703592
<cjwatson> thanks
<seb128> doko: danke
<mc44> is the bit in FeistyUpgrades about edgy server upgrades right? update-manager-core doesnt appear to be in edgy according to someone on a server install
<mvo_> mc44: its in edgy-updates
<mc44> mvo_: aha thanks :)
<mvo_> cheers
<jg> People, Ubuntu *really* needs to fix https://bugs.launchpad.net/ubuntu/+bug/94112
<ubotu> Malone bug 94112 in Ubuntu "old-style fstab not updated during system upgrade" [Undecided,Unconfirmed]  
<cjwatson> err, it really should have been - that generally *was* done
<jg> heh.  I lost yesterday afternoon.
<cjwatson> don't upgrade direct from dapper to feisty though
<jg> upgrade was from Edgy.
<cjwatson> perhaps you could help us debug that with reference to /var/lib/dpkg/info/volumeid.postinst, which is supposed to do that migration?
<jg> cjwatson: there is no case for /dev/hda? in the case statement....
<cjwatson> there doesn't need to be, it's included in /dev/*
<StevenK>         if dpkg --compare-versions "$2" lt "093-0ubuntu5"; then
<jg> cjwatson: my shell is too rusty to help much...  I've grown pointy hair...
<StevenK> That seems to strike me as backwards, and I don't know why.
<robertj> is the release officially out now? tis on the top of /.
<cjwatson> "if version we're upgrading from is older than 093-0ubuntu5, then do the migration"
<pitti> hm, should really be lt-nl, but that shouldn't cause this bug
<jg> cjwatson: here's the scenario, I think that caused me to lose....
<jg> I think checking the version is a *bad* idea.
<pitti> or, no, maybe not
<jg> I had a flaky motherboard, but thought it was my disk.
<jg> I got file system damage.
<jg> I went and got another disk.
<cjwatson> the problem is that if you don't do that then the migration happens over and over and over again
<cjwatson> and people who have some problem and really need to go back to mount-by-something-else lose
<jg> Did a fresh install of Edgy, and then moved my /home back.
<jg> using the "normal" old fashioned syntax.
<cjwatson> could you drop this in the bug? The udev maintainer is on holiday today, so information on IRC is liable to get lost
<jg> I think you need to see if /dev/hda? exists, and go from there, rather than key it on version.
<jg> ok, I'll add to the bug.
<cjwatson> it's not as straightforward as that, because not all devices have moved from /dev/hd*
<jg> cjwatson: If I were you, I'd mark this as a pretty severe problem; you end up with a unusable system....
<delire> agreed
<jg> one that is beyond most randoms to debug.
<cjwatson> jg: I've raised the importance to high
<jg> My shell may be rusty,  but I've been around the block a *very* long time.
<cjwatson> I do think we need some way to make sure the migration doesn't happen multiple times, but perhaps by-version isn't best
<jg> heh.  I'd sure echo that...
<psusi> is there a package to assign bugs to that deal with the livecd packaging rather than with a specific package itself?
<seb128> psusi: what do you mean by "packaging"?
<cjwatson> psusi: what about the live CD packaging?
<psusi> as in there is a problem with the way the livecd was packaged
<cjwatson> detail, man
<psusi> as opposed to a bug in one of the packages of software on it
<psusi> well, the amd64 feisty build does not have gparted on it
<psusi> but the i386 cd does
<cjwatson> I thought I fixed that before release
<psusi> ohh, has the release been made?  I just tested this with the beta cd 2-3 days ago
<cjwatson> ubuntu-7.04-desktop-amd64.manifest:gparted 0.2.5-2ubuntu2
<cjwatson> psusi: it's there
<psusi> ok... cool
<cjwatson> was a post-beta change
<psusi> for future reference though, is there somewhere such a bug should be assigned?  it doesnt seem like it should be assigned to the gparted package
<cjwatson> the bug would have been ubuntu-meta in this particular case
<cjwatson> but there are a number of different aspects of live CD "packaging"
<jdong> cjwatson: you think we can shoot for a newer gparted in Gutsy?
<cjwatson> jdong: I've ceased caring about gparted, since ubiquity doesn't use it any more
<psusi> does anyone here happen to know gparted's internals well?  I noticed it had a regression in feisty too... it no longer lists dmraid devices in the disk drop down menu
<psusi> was wondering how it chooses what devices to list in there
<cjwatson> I think that was an upstream change
<seb128> psusi: I don't think anybody is actively maintaining gparted for Ubuntu atm
<seb128> upstream would be the best bet for that
<cjwatson> IIRC it prods /proc/partitions
<cjwatson> it deliberately excludes dm-*, loop*, ram*
<psusi> k
<psusi> oh really?  since the last release they made it do that?
<cjwatson> I don't recall exactly, best check upstream
<cjwatson> it may have changed again since the version we have
<cjwatson> we had trouble upgrading easily since we had to carry a huge patch for ubiquity integration
<psusi> odd... since there has been a bug filed for ages that upstream supposedly has been working on to get it to work _correctly_ with dm devices, since before it couldn't update the partitions then say, format the new partition since dm doesn't support the BLKPRT ioctl
<cjwatson> that can probably be thrown away now - ubiquity in gutsy won't support using gparted
* ..[topic/#ubuntu-devel:cjwatson] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Entire archive frozen for gutsy opening
<\sh> http://www-static.ubuntu.com/GetUbuntu/purchase is not displayed correctly on firefox ... plain source for the page 
<giftnudel> epiphany similar
<cjwatson> \sh: elmo says that's fixed now
<jdong> Are there plans for us to adopt that incremental packages.gz downloading thing Etch is doing?
<jdong> (requires changes to the archives, right?)
<StevenK> Worse, changes to Soyuz
<cjwatson> jdong: probably not in the near term, it's a bit more insane with hourly cron.daily
<jdong> ah, ok :)
<jdong> not a terribly big deal
<cjwatson> you'd end up downloading a hell of a lot of ed diffs
<\sh> cjwatson: cool...say thx to him :)
<somerville32> mdke, ping
<mdke> somerville32: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
<robertj> where do I get macros such as  AM_CONFIG_HEADER
<mvo> jdong: something based on zsync is more likely
<jdong> mvo: very cool; it'll probably only be beneficial to devel branch folks
<jdong> but nonetheless cool
<jdong> mvo: lol I like update-manager --help, if you're the one responsible for it :D
<cjwatson> /usr/share/aclocal-1.10/header.m4:11:# AM_CONFIG_HEADER is obsolete.  It has been replaced by AC_CONFIG_HEADERS.
<cjwatson> robertj: ^--
<cjwatson> that file defines it as an alias
<robertj> thx
<ivoks> why aren't all mirrors on ubuntu.com listed?
<cjwatson> only the ones that were up-to-date at the point the announcement was prepared are listed
<leonel> after reading the topic  ... i think it's not off topic to  say   THANKS  FOR  FEISTY  GREAT WORK  UBUNTU DEVELOPERS !
<somerville32> :)
<ivoks> hm...
<ivoks> ok
<jdong> :) spreading good cheer is ALWAYS on topic :)
<leonel> hehe
<xq> aye, good job guys and gals
<JanDM> jep very nice release indeed, THANKS GUYS
<ivoks> cjwatson: so... i've set up on mirror to update every 4 hours, should it be every 2 hours? :)
<ivoks> s/on/one
<cjwatson> ivoks: around release time, that wouldn't hurt
<ivoks> ok, thanks
<sharms> anyone have encfs + sshfs working on feisty?
<Nergar> where can i talk with some IRCops?
<sharms> Nergar: ubuntu related: #ubuntu-ops
<Nergar> ok thanx
<JR> whats happened to this page? :/ http://www-static.ubuntu.com/news/ubuntu704
<cjwatson> how are you getting to www-static?
<JR> http://www-static.ubuntu.com/getubuntu/releasenotes/704
<JR> (from ubuntu.com) then home
<JR> then clicking the "Feisty Out tomorrow" gets me to that page
<sharms> yeah all the links are relative off www-static
<cjwatson> JR: change it to www in the meantime
<cjwatson> admins are looking at it
<JR> ah ok :)
* pochu wonders when the gutsy repo will be open for upload :)
<pochu> s/open/opened/
<Lathiat> maswan: i see youve upgraded your link :)
<tonyyarusso> cjwatson: a note re: the /topic, #ubuntu+1 is currently closed; we can re-open when appropriate.
<gnomefreak> tonyyarusso: i dont think the repos are open yet
* ..[topic/#ubuntu-devel:cjwatson] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Entire archive frozen for gutsy opening
<cjwatson> gutsy is indeed not open yet
* gnomefreak tried chroot for gutsy
<tonyyarusso> #ubuntu+1 should come back once they are
<gnomefreak> right
<gnomefreak> give or take
<cjwatson> it hasn't even been created in launchpad yet, and after that we'll need publisher runs and stuff
<hunger> is www.ubuntu.com supposed to be a page about ubuntu 7.04 only?
<tepsipakki> hunger: until the DDOS ends ;)
<maswan> Lathiat: we borrowed a couple of computers and 2Gbit/s more for this release. :)
<ogra> hunger, yes, for the moment
<Lathiat> maswan: i can see that ;)
<Lathiat> maswan: i cant help but feel its still not enough.. heh
<Lathiat> i wonder what the canonical DC pushes
<zyga> is gutsy going to be open with two week delay like last time; is this planned and described somewhere?
<sharms> https://wiki.ubuntu.com/GutsyReleaseSchedule
<zyga> thanks
<psusi> outch..... ubuntu.com is slashdotted?
<cjwatson> psusi: unsurprising ;-)
<zyga> hmm, no powerpc images?
<zyga> is ppc dead officially?
<kylem> no. it's a port.
<psusi> hrm... the main download link on the web site still doesn't list feisty
<cjwatson> zyga: http://cdimage.ubuntu.com/ports/releases/feisty/release/
<zyga> cjwatson: got it
<psusi> why are the cd images not there?
<zyga> do I guess right that there are no dvd releases for ports?
<keescook> it's always nice waking up to a release.  :)
* keescook hugs everyone
<zyga> :-)
<sm> Thanks ubuntu devs! Congratulations!
<torshido> is there any rsnc mirror I could use to update a daily image to the release iso?
<torshido> rsync
<Mithrandir> torshido: https://launchpad.net/ubuntu/+cdmirrors has a list of rsync mirrors.
<bddebian> Heya
<torshido> Mithrandir: thanks!
<delire> doesn't seem to be any reports of breakage from those that used EasyUbuntu or Automatix in 6.10. that's a relief.
<sm> UbuntuHashes needs updating, https://bugs.launchpad.net/ubuntu-website/+bug/84273
<delire> (during upgrade to 7.04 i mean)
<ubotu> Malone bug 84273 in ubuntu-website "hash for feisty on the md5sum page" [Wishlist,Rejected]  
* Pici knocks on wood
<wasabi_> So... this is odd. On feisty... but subversion's apache module is uninstallable.
<wasabi_> oh, nope, not anymore. Weird.
<baha-d> any devolper can help me i want to ask a question about keyboard settins in 7.04 installation
<Burgwork> baha-d: help is #ubuntu
<baha-d> no this isn't a problem 
<baha-d> just a mistake done by developers
<cjwatson> baha-d: please file a bug; if it's keyboard configuration during the installer, https://launchpad.net/ubuntu/+source/console-setup/+filebug is appropriate
<tonyyarusso> I saw on the Planet a while back a suggestion for a 6.06.2 - anyone heard of anything along those lines?
<baha-d> in keyboard setting in installation there is a choise under Turkey ; choises likte this turkis turkish q kurdish kurdish q etc.. there is no formal language like kurdish and no keybord scheme like kurdish in turkey
<cjwatson> Kurdish>> whee, geopolitics
<poningru> hehe
<holycow> guys i'm running ubuntu on core duo cpus and feisty is freezing all machines for 15 seconds intermittently.  because the entire system locks top really isn't usefull but i can tell that what its doing is making random apps that i'm using and throwing them into uninterruptible state while the cpu spikes to 100%
<poningru> cjwatson: you should see some of the comments that come in through hendrix
<holycow> any info on how i can track down what is causing this issue?
<poningru> holycow: this isnt a support channel
<poningru> #ubuntu please
<holycow> no its a dev channel
<holycow> what would a noob channel know about this type of isue?
<holycow> ah okay good enoughh
<Hobbsee> holycow: #ubuntu+1 shoudl be able to answer it
<Hobbsee> holycow: but check yoru syslog
<cjwatson> poningru: through what?
<holycow> bah frozen again
<holycow> syslog okay
<holycow> Hobbsee, okay
<poningru> err right
<poningru> cjwatson: mofo's user input thingy
<poningru> http://hendrix.mozilla.org/
<sladen> so guys, did we release yet?
<sn-> !feisty
<ubotu> FEISTY IS OUT! Party in #ubuntu-release-party - Torrent downloads at http://us.releases.ubuntu.com/7.04/ - Metalinks (use with Aria2 or, under Windows, GetRight) at http://download.packages.ro/metalink/ubuntu/
<sn-> :-)
<cjwatson> oh, and with respect to Kurdish, https://bugs.freedesktop.org/show_bug.cgi?id=6159
<ubotu> Freedesktop bug 6159 in General "Keyboard configuration for Kurdish (Latin)" [Normal,Resolved: fixed]  
<cjwatson> so having it included under symbols/tr was explicitly requested by an Ubuntu user
<cjwatson> the phrase "please keep your war out of my bug tracking system" comes to mind
<\sh> Mithrandir: congrats :) 
<\sh> Ubuntu / Canonical: Nice work...thx for it :)
<Mithrandir> \sh: cheers.
<mc44> https://help.ubuntu.com/community/FeistyUpgrades is forwarding to http://www.ubuntu.com/getubuntu/upgrading but that page hasn't got some extra instructions for the server upgrade mvo added
<\sh> Ok Guys, time to leave the office and get some drinks...456 servers updated for ldap integration, deployed a complete new infrastructure for our DC (around 100 new servers), and announced the release of feisty to all employees of this company. Thx for all your work and time ... have a nice evening and go and get some drinks
<mc44> anyone know who I should ping about that?
<Ng> mc44: newz2000 in the first instance, if he's not about then #canonical-sysadmin
<mc44> Ng: thanks
<kwah> hi, everyone
<danielk> later
<kwah> if i understand correctly network-manager-pptp is not available on the feisty install CDs/DVDs. Why?
<Ng> kwah: probably because it's in universe, not main
<kwah> bad :(
<Mithrandir> it might make it for gutsy.
<kwah> with package is crucial for many people, especially in places where dial-up is the main way of connecting to Internet
<kwah> s/with/this/
<Mithrandir> they can still use the old way of configuring the network.
<Mithrandir> so while it would have been nice to have it working, it's not a regression of any sort.
<kwah> Mithrandir, sure, but n-m-pptp is kinda user-friendly :)
<Mithrandir> kwah: yes, so I think trying to get it integrated in the next release makes sense.  While we would have loved to, we don't have unlimited time or resources.
<kwah> I know. Thanks for your effort!
<kwah> We'll try to come up with something :)
<micahcowan> I'm getting into the habit of running my "dpkg -l foo"s through "| cat", so that it doesn't detect stdout as a tty, and fields (especially the "Version" field) are never truncated. Is there a better way to accomplish this?
* poningru cries
<cjwatson> Mithrandir: ok, gutsy seeds are open and mirrored
<cjwatson> Mithrandir: I've updated update-germinate but it won't work until the archive opens
* micahcowan pats poningru consolingly: "there, there"
<poningru> I have no idea who packaged beryl
<poningru> and no one will tell me
<cjwatson> Mithrandir: will be back later this evening if you need anything else from me
<poningru> and the wiki is messed up
<poningru> gaaah
<poningru> !!
<geser> poningru: check the Uploaded-by field for the beryl packages
<sharms> http://packages.ubuntu.com/feisty/x11/beryl
<geser> you should find there 2 or 3 persons which did the actuall packageing
<micahcowan> racarr uploaded it; but it was packaged by Nicholas Thomas
<poningru> I tried the maintained by field but couldnt find anything
<poningru> micahcowan: do you know his nick?
<poningru> of nicholas thomas I mean
<geser> racarr and lupine did the packages, imbrandon did upload them
<Amaranth> poningru: lupine_85
<poningru> thank you
<micahcowan> Oh, that's right: "Uploaded By" doesn't really say who uploaded it ('coz I have a package with me as "Uploaded By", and I obviously don't have the privs).
<micahcowan> Is "Uploaded By" really just the last (top) person listed in the debian/changelog then?
<geser> if Changed-by (= last person in the changelog) is the same as Uploaded-by in LP then yes
<holycow> poningru, thank you for the tips
<micahcowan> I take it nobody has a better alternative for ensuring that the Version field is preserved in the dpkg-query -l output?
<geser> micahcowan: COLUMNS=256 dpkg -l
<micahcowan> geser, actually, that's worse, as it /forces/ the columns to 256, even if the content is much shorter. And, it's more typing than piping through cat.
<micahcowan> Maybe I'll talk to the dpkg folks about the possibility of preserving Name and Version at any cost, stealing from Description as needed...
<micahcowan> I don't think it should be necessary to lie to dpkg about whether it's on a terminal or how many columns we have, just to see the crucial installation info.
<micahcowan> Or maybe I'll just shut up, and use -f to specify a format that doesn't include a description ^_^
<sharms> is it for sure that we will be using new gcc in gutsy?
<tepsipakki> sharms: https://wiki.ubuntu.com/FeistyPlusOneToolchainRoadmap
<tepsipakki> sharms: also, check the post from doko to u-d on 2007-04-02
<sharms> tepsipakki: if I understand things correctly, that will drop performance by 40%?
<tepsipakki> sharms: don't know, I only pointed you to the right direction ;)
<gnomefreak> gcc drop performance?
<gnomefreak> sharms: what ar eyou reading?
<sharms> http://gcc.gnu.org/ml/gcc/2007-02/msg00390.html
<gnomefreak> ty
<sharms> The performance drop on the two benchmarks seems to be well understood, GCC
<sharms> developers tend to trade the performance regression for more correct code in
<sharms> 4.2.
<sharms> from: http://www.whatimiss.net/ubuntu-devel/?m=20070402   -- under experimental feisty+1 toolchain packages
<sabdfl> very well done everybody
* sabdfl ==> celebration!
<nekohayo> whoa
<gnomefreak> i see
<sharms> that is a big concern for me atleast
<Treenaks> sabdfl: cheers :)
<gnomefreak> 40% is a bit high
<sharms> I can imagine that 500000 bug reports
<nekohayo> feisty's livecd boots in 7 minutes (edgy used to boot in 2 mins 30)... was there something changed to DMA or the likes?
<gnomefreak> upstart was finished in feisty i believe
<nekohayo> hmm
<tepsipakki> sharms: AFAIK the version has not been decided yet
<gnomefreak> finished being implemented
<sharms> sabdfl: I am still working on the art for feisty+13 (sexy sab) release
<gnomefreak> lol
<nekohayo> okay I just timed the boots on the same machine
<nekohayo> feisty is 7 minutes and dapper takes 2 minutes 46 on the liveCD
<psusi> wow nekohayo
<nekohayo> anyone know of a big structural change lately?
<nekohayo> made my unscientific benchmarks on a 512mb of ram computer and a 4gb of ram computer
<grayman> hrm
<zul> nekohayo: I believe that is known
<nekohayo> zul: do you have some pointers/link I could look at?
<zul> nekohayo: check the #ubuntu-kernel logs for the past couple of days
<Paul_UK> hey guys, did anyone really test vpn pptp connectivity?  it looks like it doesnt work at all
<cjwatson> installing network-manager-pptp from universe may help
<Paul_UK> did that
<Paul_UK> and configured it and connected to the server
<Paul_UK> route shows nothing tho
<cjwatson> ok, I have no idea then I'm afraid; it's true that pptp has not received much testing
<Paul_UK> i even had to do : sudo /etc/dbus-1/event.d/25NetworkManager restart  to get it to show in the network manager
<Paul_UK> its a real shame, as alot of previews have said that vpn connectivity is much easier....  and its totally broke!
<Paul_UK> its not a big deal at the end of the day, as i can do vpn through a virtual machine, but its nice to have it native to linux
<davmor2> Just wanted to say Many thanks for a great ubuntu version and various bits of help I've been given a long the way.  Nice one Devs
<Paul_UK> looking forward to the next release tho ;)  or when vpn works and desktop effects as well, cos i get a white screen, running ati mobility chipset, but will try to resolve it on my own tho :)
<Mithrandir> davmor2: cheers. :-)
<Paul_UK> oh yeah and RDP is so much faster as well, well done guys
<ajmitch> morning
<Monk-e> Can somebody please take a look at this: https://bugs.launchpad.net/ubuntu/+source/devmapper/+bug/107813
<ubotu> Malone bug 107813 in devmapper "Incompatible libdevmapper 1.02.08 (2006-07-17)(compat) and kernel driver" [Undecided,Unconfirmed]  
<sharms> I looked, and lack the skills to figure it out, but that looks bad
<Monk-e> Yes.
<Monk-e> sharms: you think it might get fixed and they'll put new release images online?
<sharms> Monk-e: I wouldn't expect a new install release to come out, someone has to confirm it and get it looked at by someone in core
<Monk-e> Bah...
<sharms> Monk-e: does this look related: https://launchpad.net/bugs/107815
<ubotu> Malone bug 107815 in debian-installer "installing using LVM does not work" [Undecided,Unconfirmed]  
<Monk-e> Yes, that's NO DOUBT the same bug. vgchange -ay hangs too here
<ivoks> it's a known issue
<ivoks> read release notes
<delire> youch
<sharms> ivoks: but the incompatible library is not right?
<ivoks> http://www.ubuntu.com/getubuntu/releasenotes/704
<ivoks> On the alternate or server CDs, creating LVM logical vol...
<Monk-e> .. ivoks thanks.
<ivoks> (i think it is the same)
<Monk-e> ivoks: only one way to find out. ;) I'll try installing again.
<ivoks> :)
<jdong> bug 107648
<ubotu> Malone bug 107648 in Ubuntu "The Ubuntu community is insane" [Undecided,In progress]  https://launchpad.net/bugs/107648
<jdong> glad to umm... see people having fun with Malone?
<tonyyarusso> lol
<jdong> what's next? Schroedinger's bug report where people keep on flicking it between confirmed and unconfirmed?
<jdong> (oh wait Xgl already does that)
#ubuntu-devel 2007-04-20
<mc44> jdong: the bug is accurate
<mc44> :)
<jdong> yeah it is :)
<jdong> but we can't fix it
<jdong> maybe they should require a backport from the development species
<mc44> should be set to wontfix
<gnomefreak> the OO.o guys maintain hunspell right?
<pochu> sabdfl: ^ it looks like a bug for you ;)
<ryan_> can someone kick the torrent tracker?
<ryan_> it is refusing connections
<jdong> haha DHT FTW!
<rukuartic> <3 Folks, congratulations on another awesome release!
<BenC> Can anyone help me figure out why make is rm'ing a stamp file in my debian/rules?
<BenC> I got a target that deps on a stampfile, which has a rule to do something, and touches the stamp file, but then make does "rm stampfile"
* ion_ tries to remember how to get rid of that...
<ion_> If "target-foo" is requested and "target-foo" depends on "target-bar", make may very well remove target-bar after target-foo has been created.
<BenC> foo-%: stamp-%
<BenC>         @echo Made $*
<BenC> stamp-%:
<BenC>         touch $@
<BenC> with that Makefile, "make foo-temp" removed stamp-temp
<BenC> how can I make it not do that?
<BenC> hmm, looks like I need ".PHONY: stamp-temp"
<BenC> which sucks for a matching rule
<BenC> wait, no, that just made it skip the rule
<ion_> No, then stamp-temp is expected to be a rule that doesn't actually create a file stamp-temp.
<ion_> .PRECIOUS : stamp-%
<ion_> No, that isnt the correct one either.
<BenC> seemed to work
<ion_> Yes, but only as a side effect. It has a bit different semantics.
<BenC> well, .PRECIOUS: stamp-temp does
<ion_> This should be the correct one: .SECONDARY : stamp-temp
<BenC> anyway I can do the same thing without knowing what possible %'s there could be ahead of time?
<BenC> stamp-% doesn't work, but stamp-temp does
<ion_> .PRECIOUS means never delete the target, even if its build failed, .SECONDARY means even if this target is deemed to be intermediary, dont delete it.
<ion_> intermediate even.
<ion_> Try .SECONDARY :
<BenC> ah, that works
<BenC> ion_: big thanks
<ion_> yw.
<BenC> ion_: got time for another question? :)
<ion_> Sure.
<BenC> foo-%: stamp-%
<BenC> stamp-%:
<BenC>         touch $@
<BenC> If I just have that, "make foo-temp" says no rule to make target
<BenC> I have to give commands for foo-%
<BenC> like the echo I had before
<ion_> Hmm
<ion_> What is the purpose of the foo-% target if its just empty?
<BenC> ion_: easier to type and remember "debian/rules build-generic" than "debian/rules debian/stamps/stamp-build-generic"
<EricBig> hi... can someone spare a sec for me? 
<pochu> !ask
<ubotu> Don't ask to ask a question. Just ask your question :)
<pochu> :)
<EricBig> i'm thinking to start a new project on uBuntu ... 
<EricBig> in short, i want to hav a version of this that is usable for my mum
<EricBig> but im' not a programmer
<EricBig> so i want to know how and where should i start
<EricBig> say to look for partners etc.
<pochu> EricBig: ubuntu is usable by my grandma
<shawarma> You need to figure out, why you believe it's not already usable by her.
<pochu> so it should also be usable by your mother ;)
<shawarma> What's stopping her?
<EricBig> 3 words: two many buttons
<EricBig> for all the OS today
<EricBig> i think a proper OS for grandma should hv less than say 10 buttons
<EricBig> i want to make it like an internet kiosk or something like that
<EricBig> and can run on very very old laptops
<EricBig> say pentum 2 300mhz + 64m ram equivilant
<shawarma> An OS thatdoes less than 10 things seems rather useless to me.
<Chipzz> EricBig: that's a no-go I think
<pochu> then try xubuntu?
<tonyyarusso> EricBig: Xubuntu?
<pochu> !xubuntu | EricBig 
<ubotu> EricBig: xubuntu is Ubuntu with Xfce instead of Gnome. For more info, see http://www.xubuntu.org and http://wiki.ubuntu.com/Xubuntu/ - To install from Ubuntu: "sudo apt-get install xubuntu-desktop". | For support, see #xubuntu | See also: !ubuntu and !xubuntu-channels
<Chipzz> EricBig: I used to run debian (slimmed down) on a p2 233 with 64MB ram
<Chipzz> and that's with a lot less daemons than ubuntu
<Chipzz> didn't work
<tonyyarusso> 64 megs is pretty slim, so if XFCE doesn't cut it try IceWM, fluxbox, enlightenment, or others
<Chipzz> firefox (or epiphany for that matter) just eats memory
<EricBig> sorry. im really knew to uBuntu...  in fact, i'm a graduate student studying technology policy and one of the things i discovered along my research is that in general technology is too much for average ppl in terms of desktop computing
<Chipzz> pochu: I doubt xubuntu would help much there ;)
<pochu> Chipzz: maybe msdos? :)
<EricBig> i'm thinkin to hav an interface that only hav say 5-6 big buttons in the middle of it : E-mail, Web, Music, Movie that's it
<EricBig> thanks ubotu, im checking xbuntu now
<EricBig> think about all the web 2.0 stuff and how google start to moving everything desektop into browser.
<Chipzz> EricBig: ubotu is a bot, and doesn't care about you thanking him ;;)
* tonyyarusso thinks the problem here is people, not software
<Chipzz> +much
<EricBig> its my first time in IRC, sorry for being an idiot
<Chipzz> EricBig: no offence meant ;)
<pochu> EricBig: we have always had a first time :)
<Chipzz> pochu: on 64MB of RAM, even X + twm + firefox will grind to a halt pretty fast ;P
<tonyyarusso> dillo ?
<EricBig> i'm thinkin to slim down everything ... 
<tonyyarusso> links2 -g?
<Chipzz> tonyyarusso: with proper javascript etc support.. ?
<EricBig> my ultimate goal is to challenge the OLPC project
<tonyyarusso> Chipzz: I think dillo can, not sure if links2 does or not
<EricBig> so a slim-down version of uBuntu - which is still a decent OS (unlike the OLPC sugar, which i think is er... not so decent), to run on a very cheap hardware platform
<Chipzz> tonyyarusso: EricBig is referring I think to stuff like gmail etc; doubt that would work properly on anything except firefox/konq/opera
<tonyyarusso> Chipzz: You could probably compile Firefox with some options to make it less featureful but smaller
<EricBig> is it ok to post a link for one of my blog entries here? is it against the channel rule?
<pochu> or use epiphany
<tonyyarusso> no idea what rules are here...not one of my usual realms
<EricBig> tonnyy - that's basically what i 'm thinking, to recompile everything and kick-out features that will never use by old grandma
<Chipzz> tonyyarusso: still, IMHO firefox still grossly leaks a sh*tload of resources (like server-side pixmaps etc...)
<Chipzz> I have my doubts how far you would get
<Chipzz> and the mozilla developers refuse to acknowledge the problem and keeping referring to it as a "feature" doesn't help much :P
<Chipzz> s/refuse/refusing/
<EricBig> umm.. here's a post i wrote a while back: http://blog.sinnovate.net/2007/04/some-fundamental-thoughts-on-public-top.html 
<EricBig> umm.. just want to ask, will IRC channel be a proper way to looking for developers that are willing to start a project ?
<bhale> not really
<bhale> your call for help will be off the screen in a few minutes
<EricBig> so where should i go ? any suggestions thx bhale.
<Chipzz> bhale: arguably ;)
<EricBig> maybe forums / discussion boards? 
<bhale> if you'd like
<Chipzz> EricBig: a lot depends on your timing; what bhale means is that irc is a very volatile medium ;)
<EricBig> is there any place for discussions for new ideas / projects like mine in the ubuntu / linux community?
<bhale> but development is tracked on the wiki and launchpad
<bhale> bring your own advertising
<bhale> !blueprints
<ubotu> Sorry, I don't know anything about blueprints - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<bhale> !specs
<EricBig> bhale: advertising? you mean a full project proposal? i will do that, but don't know exactly how should I do it
<ubotu> Sorry, I don't know anything about specs - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<bhale> ubotu: you are dead to me.
<EricBig> and, once i've come up with a Blue-print, where should I post it ---- that's the problem ... how uBuntu people normally deal with this
<bhale> https://wiki.ubuntu.com/FeatureSpecifications
<Chipzz> EricBig: btw, if I may say something; you're actually proposing 2 different things:
<Chipzz> 1) create a very simple GUI with only 6 buttons
<Chipzz> 2) create a distro that runs on 64MB of RAM
<EricBig> Chipzz: EXACTLY
<Chipzz> make sure to propose these as 2 different blueprints; they're 2 different and seperate goals
<EricBig> and of course there is a way to get more buttoms out, say after entering admin username and pwd .
<Chipzz> one which may be implemented a lot faster than the other
<EricBig> i know, i think 1) is most important actually, and i guess you are saying 1) is easier right?
<Chipzz> easier, but not per se one that would be accepted
<EricBig> because 2) is largely because of the hardware cost, which can be overcome by time & price drops
<Chipzz> also, 2) is something very general (reducing needed resources) which is a global goal which people are working on all the time
<EricBig> but my general feeling is the latest distro of uBuntu (7.x) is big and powerful, and it inevitiablly put more pressures on the hardware?
<Chipzz> not necessarily correct
<EricBig> or do you mean developers do the kernal optimization and feature adding at same time?
* Fujitsu finds it a little sad that jigdo can't be used to grab Feisty... The images refer to an old version of update-manager(-core) that isn't in the archive any more :(
<EricBig> so the weight doesnt jump up too quickly?
<Chipzz> for example, a lot of improvements have been made to pango, which makes font rendering faster
<Fujitsu> EricBig: It should be no more resource-intensive than 6.10.
<Chipzz> EricBig: most of that kind of stuff is being done upstream anyway
<EricBig> right. 
<EricBig> chipzz, can i hav your contact method like an e-mail address? or does IRC support something like add buddy in ICQ? 
<Chipzz> EricBig: I'm not really an ubuntu developper; mostly just lurking here ;)
<EricBig> umm... i just need some one to help me start with.. coz i have been mostly working on user study and technology policy side and never touch the development field ...
<ion_> ericbig: Has Ubuntu been called uBuntu somewhere? Im just curious.
<Chipzz> EricBig: the best thing you can do actually is proposing blueprints really (after investigating their feasability)
<EricBig> icon_ sorry im a mac user so got used to decaptialize first letter in every word :P
<micahcowan> When is a simple patch preferable to a debdiff? For instance, in the case of packages that get heavy development and are either synced often or get frequent bugfixes, is it better to supply a plain diff and let the package maintainers decide how it should fall with ordering/package-version?
<Chipzz> EricBig: the button idea is not a bad idea per se; but it has to fit in with what ubuntu developers think is a good idea
<Chipzz> EricBig: but it's something that you could very easily implement with pygtk really; I'ld say about 100 lines of code
<EricBig> Chipzz: is Launchpad only for ubuntu or its for general opensource softare
<Chipzz> EricBig: it's meant for general opensource software, but there aren't a lot of projects actually using it as such (though there are some)
<EricBig> but it's more thant that... because the less buttons you allows user to click, the 'smarter' the system must be, they will have to 'actively' understand what users want without asking users to click lots of buttons and enter too many lines of command
<EricBig> Chipzz: and it must not be annoying at the same time ( a bad example is the clippy in ms office)
<Chipzz> EricBig: a good question you would have to ask yourself is: is the button interface actually needed, and why is it needed
<EricBig> Chipzz: things like WYSIWYG and drag-n-drop for everything is a must.
<Chipzz> because gnome goes to great lengths to create a very easy and non-complicated menu structure
<Chipzz> if it fails to do that, maybe something is wrong with the gnome menu structure
<Chipzz> so the right question to ask may not be: "do we need a buttons-interface?" but instead "what's wrong with the current menu so my mum can't find the email-program easily?"
<EricBig> Chipzz: i think, if you mark down the buttons you click on a GUI OS, say windows, and their frequencies, you will discover for most of the time people are only using a Word Processor, music player, web browser, email client and chat-client. that makes other buttons less useful and a waste of desktop space and system resrouce
<Chipzz> EricBig: there's the novell slab thingy, which keeps recently used menu entries in the 1st level menu like the windows xp menu does
<EricBigLineDropp> sorry closed the wrong window  -- i'm using a web IRC 
<EricBigLineDropp> .
<Chipzz> EricBigLineDropp: anyway, I would recommend taking a look at the current specs and see how they are written (use cases etc)
<Chipzz> EricBigLineDropp: learn from that how you should write your own proposal
<EricBigLineDropp> Chipzz: you mean the specs on launchpad right?
<Chipzz> EricBigLineDropp: uhu
<Chipzz> EricBigLineDropp: what I mean is, argue for why you're proposing something, consider alternatives, use cases, etc
<EricBigLineDropp> Chipzz: the philosophy behind is to make the GUI / OS as simple as possible, while sacrificing user's choices. For example, only allow user to use one e-mail client, say Thunderbird, and that's it. Although there might be pros and coins between different apps, average user won't care. the problem of today's mainstream OS is that there are too many options, too many configurations and too many things to
<EricBigLineDropp> Chipzz: there is nothing wrong for the existing menu structure, just they don't need to be there if most people don't use it for the most of the time.
<EricBigLineDropp> <Chipzz> but anyway thanks a lot for the advice... i will go back and write a full spec / proposal and see what happens next.
<Chipzz> EricBigLineDropp: btw. you may want to pay a visit to #ubuntu-desktop too, and propose your idea there
<Chipzz> (also, at an hour at which more developers are online ;))
<jmg> hey all, anyone here involved in UMC (MediaCenter)?
<EricBigLineDropp> <Chipzz> thx... gotta go... bb
<conn> hi mjg59, did you have time to try Tim's modified ieee80211softmac.ko module, re: bug 103768 ?
<ubotu> Malone bug 103768 in linux-source-2.6.20 "softmac and network-manager cite unreconcilable differences" [Critical,In progress]  https://launchpad.net/bugs/103768
<wasabi__> Yay. Compiz and stuff works on my laptop, out of hte box. 100% free
<voraistos> Hi
<voraistos> there is something very disturbing i want to talk about
<wasabi__> Does it have anything to do with ubuntu development?
<voraistos> but on #ubuntu, i dunno whats going on, but people are talking about changing their wallpaper ?!!!
<voraistos> yep, kind of
<voraistos> or bug maybe
<voraistos> i dunno
<wasabi__> Bugs go in the bug tracker...
<voraistos> its about the laptop over heating problems
<voraistos> i think its a bug or a virus
<voraistos> i have this "old" laptop
<voraistos> i has always been running fine on ubuntu
<voraistos> no over heating, performances 100 times better than windows, extended battery life, etc
<voraistos> but, since i am a bad person and dont treat my hardware very well, its not in superb condition
<mjg59> voraistos: If you ahve something that you believe to be a bug, please file it in the bug tracker, not here
<voraistos> hmm
<voraistos> yeah, but i dunno how to do that, and, i have no idea if its a bug or not
<mjg59> bugs.ubuntu.com
* Fujitsu wonders if update-manager 1:0.59.19 could be republished, so that jigdo works.
<Flannel> Guys, where is update-manager-core?
<Fujitsu> Flannel: The ISOs are inconsistent with the archive.
<Fujitsu> Flannel: That's what I was just talking about :(
<Fujitsu> You'll have to use rsync.
<Flannel> Not for me, I'm not upgrading.  But just wondering what to file a bug against
<Fujitsu> Flannel: there's nothing you can really file a bug against, but it's inconvenient to not be able to use jigdo.
<voraistos> there are some vague bug reports about it, but they are not taken seriously it seems
<Flannel> Fujitsu: eh, the website should be.
<wasabi__> About this archive thing. Are you suggesting that the ISO of feisty has packages not in the archive?
<Fujitsu> Flannel: Pardon?
<Flannel> Fujitsu: http://www.ubuntu.com/getubuntu/upgrading
<Flannel> Besides the fact that the nav on top of that page points to the wiki page still, but that's a second bug
<wasabi__> It's perhaps somewhat reasonable to think... which mirror of hte archive are you looking in, for instance.
<Fujitsu> wasabi__: Indeed. a new update-manager was published for Kubuntu, which meant that the one in the Ubuntu ISOs was removed. That is wrong.
<wasabi__> Oh, jigdo.
<wasabi__> I see.
<wasabi__> That does seem like an issue. Shouldn't a new upgrade to that go to -updates?
<Fujitsu> wasabi__: No, because it was before Feisty was released, but after the latest Ubuntu ISOs were created.
<wasabi__> So somebody needs to rebuild the ISOs?
<Fujitsu> ISOs can't really be rebuilt at this stage.
<mjg59> Or re-publish that binary to the archive
<Fujitsu> mjg59: That's what I asked earlier.
<mjg59> Yes
<Fujitsu> I suppose we wait for Mithrandir or so for that.
<mjg59> Yeah. He ought to be up in a few hours.
<Fujitsu> Noted.
<Fujitsu> I hope Soyuz actually supports doing that sort of thing.
<voraistos> i bought a new laptop thinking mine was broken... I bought one from dell (didnt receive it yet), and i was just checking if ubuntu was running nice out of the box or not... when i found a huge thread about over heating issues. Strangely somebody described the same problem as i have.. The laptop crashes after a while, disk stops spinning because it seems the chipset fucked up. when i reboot the hdd is not detected anym
<voraistos> ore, and to use it right now i had to cap cpu freq at 600 mhz. Could this be kernel related ? or something else ?
<mjg59> voraistos: Please file a bug, or if one already exists add a comment. This isn't the appropriate place to raise issues of this nature.
<voraistos> i just want to know how to make this high priority ?
<wasabi__> Things become high priority on their own.
<Fujitsu> voraistos: File a bug. It will be looked at.
<mjg59> The appropriate developers will flag it as high priority if they think it's appropriate
<voraistos> yeah, well, people destroyed their brand new hardware because of that !
<mjg59> voraistos: And talking about it here will do nothing to help that
<voraistos> i dunno... you guys are the devs, maybe you heard about that :P
<voraistos> (i mean the problem :) )
<Fujitsu> That sounds like pretty stupid hardware if it dies like that.
<wasabi__> I actually have a laptop suseptable to that, and yes.
<wasabi__> Early generiation ibook g3. If the cpu stays on while it's shut, it'll melt the LCD. ;)
<wasabi__> So, if your suspend is busted!
<mjg59> voraistos: Nobody here is going to tell you anything you haven't already been told
<Fujitsu> wasabi__: That's what ibooks are for.
<bimberi> Hi, http://www.ubuntu.com/getubuntu/upgrading recommends installing and using update-manager-core to upgrade servers to Feisty.  However...
<bimberi> !info update-manager-core edgy
<ubotu> Package update-manager-core does not exist in edgy
<bimberi> I'll report it against update-manager and ubuntu-website
<ajmitch> bimberi: is it not in edgy-updates?
<ajmitch> https://launchpad.net/ubuntu/+source/update-manager-core seems to indicate that it made it there
<bimberi> ajmitch: hmmk, I'm going by ubotu, searches on packages.ubuntu.com and a couple of questions in #ubuntu
<Fujitsu> !info update-manager-core edgy-updates
<ubotu> update-manager-core: manage release upgrades. In component main, is standard. Version 1:0.59.18 (feisty), package size 25 kB, installed size 1812 kB
<Fujitsu> There we go, bimberi.
<bimberi> Fujitsu: ah, thanks. Hm, there's been 4 questions in the last 12 hours.
<ajmitch> hopefully the -updates binary got to all the mirrors
* ajmitch would assume that it did so
<bimberi> If I see it asked again I'll ask them to check that they have edgy-updates enabled
<Nergar> ok, who helped build ubuntu???
<slop> me
<Nergar> all of you made a great job!
<slop> it was mostly me
<slop> thanks
<Nergar> now this is an upgrade!! not like xp-vista
<Nergar> lol
<Nergar> feisty is way higher than what i expected!, and i expected a lot
<Nergar> congrats to all!
<Nergar> later
<ion_> Haha
<slop> :p
<ajmitch> ah, enthusiastic users
<xq> wow, grub might drive me to insanity
<tepsipakki> hm, the libx11 security update broke rdesktop on dapper
<Fujitsu> tepsipakki: I heard about it breaking if running in 8-bit or similar, but it might not be the same thing.
<Treenaks> tepsipakki: I heard that too
<fabbione> tepsipakki: do you have a bug number?
<tepsipakki> yes, it's fixed in sid
<fabbione> morning btw
<Fujitsu> Hey fabbione.
<tepsipakki> yeah, good morning
<ajmitch> morning fabbione 
<tepsipakki> fabbione: bug 107780
<ubotu> Malone bug 107780 in libx11 "rdesktop segmentation fault after libX11-6 update" [High,Confirmed]  https://launchpad.net/bugs/107780
<fabbione> tepsipakki: who did the security update?
<tepsipakki> me and keescook
<fabbione> for the win
<fabbione> can i see the patch please?
<fabbione> also.. subscribe kees to it
<tepsipakki> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418098
<ubotu> Debian bug 418098 in rdesktop "rdesktop segfault with libx11-6 1.0.3-7" [Unknown,Open]  
<fabbione> no i want to see the patch to libx11
<tepsipakki> ah, a sec
<fabbione> the fix to rdesktop is simple
<tepsipakki> http://users.tkk.fi/~tjaalton/dpkg/libx11.debdiff
<tepsipakki> that's what got in feisty
<tepsipakki> kees applied the others
<tepsipakki> um, seems that the rdesktop-patch already got in feisty :)
<tepsipakki> bug 104322
<ubotu> Malone bug 104322 in plptools "[apport]  ncpd crashed with SIGSEGV in pthread_join()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/104322
<tepsipakki> no, bug 104332
<ubotu> Malone bug 104332 in rdesktop "Segmentation Fault (core dumped)" [Undecided,Fix committed]  https://launchpad.net/bugs/104332
<tepsipakki> sorry, it's waiting for -updates
<tepsipakki> i'll mark the other bugs as duplicate of that one
<tepsipakki> since it clearly is the parent
<fabbione> the patch looks safe.. tho a strace or dbg would be more helpful
<Fujitsu> Might want to add dapper/edgy tasks to that bug.
<Fujitsu> Hm, and gutsy I guess.
<fabbione> gutsy will get it automatically at merge time with debian
<fabbione> don't bother
<Fujitsu> Ah, true, it's just a rebuild at the moment.
<tepsipakki> oops, bug 107909
<ubotu> Malone bug 107909 in linux-restricted-modules-2.6.20 "Files corrupt in ubuntu-7.04-dvd-i386.iso" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107909
<Fujitsu> sounds pleasant.
<fabbione> hmm i can check that
<fabbione> but i find it strange
<tepsipakki> yeah, not necessarily valid
<fabbione> he might have downloaded the file.. checked the md5sum (good) and then the burn was bad
<fabbione> md5sum matches..
<Fujitsu> Hm, that's not a good sign.
<tepsipakki> does the techboard have a mail-address?
<ajmitch> tepsipakki: there is a list, I can't find the details though
<fabbione> whops
<fabbione> wrong hit :)
<ajmitch> tepsipakki: http://www.ubuntu.com/community/processes/techboard
<tepsipakki> ajmitch: cool, thanks
<ajmitch> has the list, looks like it's just not publically listed on lists.u.c
<Fujitsu> fabbione: Is the ISO bad, or is the application he's using to view it braindead?
<tepsipakki> ajmitch: no wonder ;)
<fabbione> Fujitsu: it's checking now... i did reboot my machine instead of vmware by mistake
<Fujitsu> fabbione: Haha, smooth.
* Starting logfile irclogs/ubuntu-devel.log
<fabbione> looks good here all the way
<fabbione> bad burn imgo
<fabbione> imho
<tepsipakki> fabbione: thanks for testing!
<fabbione> np
* keescook just tuning in again
<fabbione> keescook: hey dude
<keescook> libx11 was busted?
<fabbione> keescook: no .. libx11 is ok. it's the other package that needs love
<fabbione> rdesktop?
<keescook> ah.  okay.  somewhat of a relief.  :P
<keescook> rdesktop is in main though... they're not playing nicely?
<fabbione> keescook: no with the libx11 change.. basically libx11 change did exploit a rdesktop bug
<fabbione> keescook: it's a one line patch ... tho it needs to be applied
<keescook> is there a fix for rdesktop?  Sounds like a regression that needs fixing.  :(
<fabbione> yes.. there is a fix
<fabbione> it's all in the bugs linked by tepsipakki 
<keescook> okay, cool.
<fabbione> and yes it a partial regression ...
<fabbione> fixing a to find a bug in b is not what i exactly consider a regression but bad code in b
<keescook> sure, but a security update rendered another part of the system broken, so it needs to be fixed.  :)
<fabbione> yeps we agree :)
<jernst> siretart: hi, any idea when the fix for #104332 will be released ? any progress with the SRU process ?
<keescook> jernst: it's in progress still.  if you're on dapper/edgy you can force a downgrade of libx11
<jernst> keescook: Thanks. I'm on feisty, I have three users depending on rdesktop on my ltsp server that are complaining
<keescook> jernst: ah, less of a simple fix for that.  you can try this:
<keescook> cd /tmp; sudo apt-get build-dep rdesktop; sudo apt-get fakeroot build-essential devscripts; apt-get source rdesktop; cd rdesktop-*; dch -n 'fix libx11 crashes'; curl -s 'http://librarian.launchpad.net/7300958/rdesktop-xcreateimage2.patch' | patch -p0; debuild -uc -us
<keescook> that should build a new rdesktop*.deb package for you; which you can install with   sudo dpkg -i ../rdesktop*.deb
<Mithrandir> second apt-get call is missing "install"
<jernst> thanks I will try that and let you know
<keescook> Mithrandir: ah, thanks
<fabbione> keescook: gcc wrapper = bad :)
<keescook> fabbione: agreed!  :)
<fabbione> keescook: i think we need something like gcc-defaults to install an /etc/ubuntu-gcc/default.conf
<fabbione> keescook: and debhelper to source it.. or something
<fabbione> keescook: that will wide spread to at least 90% of packages in the archive if not more
<keescook> fabbione: sure, I'm all for it; since I'm not a toolchain expert, I just need people to tell me what to try and I'll test it.  :)
<fabbione> keescook: but we need to make sure we can override the settings
<pitti> Good morning
<keescook> right.  hiya pitti!
<fabbione> hey pitti
<fabbione> keescook: i don't think it's a toolchain issue here, but a packaging one
<fabbione> keescook: what we need to make sure from gcc is to install proper defaults in that file for each $arch
<keescook> fabbione: well, true.  I'm no packaging expert either.  ;)
<keescook> I'd like to be able to be able to pick between some preset defaults "regular" "security" "crazy secure" etc
<fabbione> keescook: i hope this isn't the only job you have :)
<jernst> keescook: the .deb has been created successfully, I installed it remotely on the server and I'm now waiting that the people working with rdesktop try it. Thanks for that
<keescook> jernst: great!  I hope that works.  :)
<keescook> fabbione: my job is never done.  :)
<fabbione> jernst: worth testing before people will look for you with a bat
<pitti> keescook, fabbione: I didn't see the start of the discussion, you mean to make gcc look for some external conffiles which modify the profile? that does not seem to make sense to me TBH
<keescook> pitti: yeah, I think fabbione just took my u-dev ml post and brought it up here.
<fabbione> pitti: ubuntu-devel@
<pitti> I don't see how to solve it without a gcc wrapper that is used by packages; after all, it *is* a different compiler (behaviour) than vanilla 'gcc'
<fabbione> pitti: well it depends how you want to look at it
<pitti> fabbione: well, of course we can make gcc itself look for $DEB_BUILD_CFLAGS or so
<fabbione> pitti: i think the biggest motivator to have a conf file is to avoid to set the default in gcc for testing
<fabbione> pitti: that too...
<pitti> fabbione: ah, well, the conffile could check the environment if it is really a script
<pitti> fabbione: i. e. turn the environment into a gcc profile?
<fabbione> pitti: that's my best guess from kees email
<jernst> fabbione: by the way rdesktop is unasable currently so it can't be worst
<pitti> fabbione: right, we cannot hardcode those as defaults in the profile
<fabbione> pitti: IMHO it can also be useful to archive rebuild.. like we decide to test -foo option.. we can do that without having to change gcc defaults and if it works, we will already know what packages will FTBFS and how.. it will allow a bunch of pre-testing options that at the moment can be more annoying to achieve
<fabbione> pitti: never mind that we can also change the defaults without having to upload a gcc
<pitti> fabbione: right, you are preaching to the choir :)
<fabbione> pitti: ehhe
<pitti> I just wasn't sure how to connect the env vars to the gcc profile
<fabbione> i see what kees wants.. we just need to make sure to implement it right at the first go
<fabbione> yeah that's what he is really asking
<ajmitch> hey pitti 
<fabbione> pitti: and given our previous experiences with gcc wrappers...
<pitti> fabbione: and then we need to plan that with Debian; there's no way that we can change 15.000 packages for it
<fabbione> pitti: exactly
<pitti> fabbione: well, for testing it might be good enough to preliminary patch dpkg-buildpackage IMHO
<fabbione> it needs to be external to the packaging but still possible to override
<pitti> fabbione: i. e. have dpkg-buildpackage set those to our defaults
<fabbione> pitti: planning with Debian means talking to doko.. so that's somehow easy :)
<pitti> fabbione: that way we lose reproducability with 'debian/rules build', but *shrug* :)
<Fujitsu> Hi Mithrandir.
<pitti> fabbione: well, no, it means talking to all DDs
<Mithrandir> hi Fujitsu
* pitti hugs Mithrandir 
<Fujitsu> Mithrandir: We have a little bit of a problem.
<pitti> Fujitsu: do we want to know?
<Mithrandir> Fujitsu: let me hear.
<Fujitsu> jigdo is useless of Feisty images, because of the new update-manager(-core) that was uploaded for Kubuntu.
<Fujitsu> *on
<Mithrandir> hm
<Mithrandir> cjwatson: ^^ ; thoughts?
<pitti> erk
<Fujitsu> The version on the ISOs was thus removed, and... well...
<pitti> can't we put it back somehow?
<Fujitsu> pitti: That is what I was hoping.
<Mithrandir> pitti: slightly hard.
<pitti> Mithrandir: I know :/
<Fujitsu> A little manual hackery shouldn't hurt too much.
<pitti> well, it's hard to convince Soyuz to not remove it again
<Fujitsu> Won't it only be removed on another upload of it to Feisty's release pocket?
<pitti> Fujitsu: no, I believe the cleanup runs daily
<Fujitsu> I thought it was changed to Superceded when a new upload occurred.
<pitti> Fujitsu: and packages in different pockets are not superseded
<Fujitsu> pitti: Surely if it is republished, there won't be another upload to set it back to superseded, so it won't be removed?
<Mithrandir> I'm wondering if we can force-include it in the .jigdo file somehow
<Mithrandir> that'd be a better solution
<Mithrandir> .jigdo/.template
<pitti> Mithrandir: in fact, if you just rebuild the template, since it won't find the deb, won't that happen automatically?
<Fujitsu> That works too.
<pitti> i. e. with the classic jigdo-file, not with the cdimage jigdo feature
<Mithrandir> pitti: I don't know jigdo well enough to answer yes or no to that question, but I suspect so.
<Mithrandir> yeah
<pitti> erm, wait
<pitti> does that mean we ship a .deb on the CD which we don't have the source for?
<Fujitsu> pitti: Indeed, that is correct. Eek.
<pitti> thats...bad
<Mithrandir> no, it's on the source CDs
<Fujitsu> Well, it's on LP, but that's likely to be cleaned at some point.
<Mithrandir> source CDs are per derivative.
<fabbione> pitti: all the sources are stored on  LP anyway..
<Fujitsu> fabbione: They're cleanup up sometimes, so not there forever.
<fabbione> pitti: for each single upload. that should be enough to fulfill GPL requirements of making the source available
<pitti> fabbione: true, but not really in the archive any more
<fabbione> pitti: i don't think it matters.. they are still available
<pitti> Fujitsu: fabio's right, all old sources are preserved
<fabbione> Fujitsu: in LP they are not deleted afaik
<Mithrandir> and we own the copyright so it's not an actual problem.  We're free to ship GPL-ed binaries without source (but we shouldn't).
<Fujitsu> pitti: I'm sure I heard from an LP guy that they are cleaned.
<pitti> Fujitsu: from archive., yes
<Mithrandir> anyway, it's on the source CDs, so it's not a problem.
<fabbione> exactly
<pitti> Fujitsu: check https://launchpad.net/ubuntu/+source/update-manager, you can click on all past versions and will see the package
<pitti> Mithrandir: well, we are free to ship binaries without source xor GPLed binaries, right :)
<Fujitsu> Mar 16 14:24:47 <lifeless>      LaserJock: why not give ubuntu archive urls ?
<Fujitsu> Mar 16 14:25:16 <LaserJock>     lifeless: because archive packages come and go
<Fujitsu> Mar 16 14:25:30 <LaserJock>     we want access to every source package ever :-)
<Fujitsu> Mar 16 14:25:34 <lifeless>      LaserJock: the librarian has garbage collection too though
<pitti> Fujitsu: I guess the only thing that keeps them alive is precisely the +source package :)
<lifeless> you called?
* Fujitsu apologises to lifeless.
<Fujitsu> pitti: What do you mean?
<pitti> Fujitsu: (leaving area of definite knowledge) I believe that the librarian deletes files which are not referenced from anywhere any more
<pitti> Fujitsu: but since the +source package refers to them, their reference count never drops to zero
<lifeless> thats right
<pitti> s/package/package page/
<lifeless> I know that historical size is a concern
<pitti> lifeless: well, it's a life safer sometimes
<Fujitsu> pitti: So they will grow indefinitely... Hm..
<pitti> I used it more than once to get a previous version
<lifeless> so theres no 'contract' if you like that these will be kept forever at this point, only that what is currently published will always have its source available
<lifeless> but the soyuz devs know more
<Lathiat> AIUI your supposed to kepe the source available for X years from ship date arent you?
<Fujitsu> That release has to stick around for at least 18 months + some years.
<elmo> no
<lifeless> Lathiat: for the written offer clause only.
<elmo> the X years stuff is one option, and it's not one we use
<elmo> we use 'ship source with binary'
<Lathiat> ah ok
<lifeless> elmo: isn't the CD cover a written offer ?
<elmo> and we do it by having our archive management stuff (dak or soyuz) do source reference counting
<Lathiat> except that the source isnt on the default CD
<Lathiat> so if you shipit me a cd...
<elmo> lifeless: yes, but that's independent of this discussion, and even that relies on the source reference counting
<Lathiat> right
<lifeless> elmo: right it does. Your 'no' was a little unqualified though ;)
<elmo> well, look these are two different things
<elmo> Canonical has to be able to provide the source to someone because of shipit
<lifeless> anyhow, I know this stuff; ciao.
<elmo> but that doesn't mean ubuntu.com has to make it available
<Lathiat> right, ok
<elmo> but anyway, I don't know what the context was, but please don't use librarian URLs for archive files
<elmo> that's not going to scale well at all
<elmo> as long as a binary is published on archive.ubuntu.com, there will be a valid (albeit unreferenced in Sources.gz) corresponding url for the source, also on archive.ubuntu.com
<Fujitsu> elmo: In this case it isn't published any more, but is on ISOs.
<lifeless> elmo: that wasn't the context at all :). It was about librarian garbage collection.
<pitti> elmo: original problem was that ubuntu CDs have an older version of update-manager than the kubuntu CDs, and the older version has gone from archive
<elmo> Fujitsu: err, what?
<elmo> whine
<elmo> seriously?
<Fujitsu> elmo: A new update-manager was uploaded to Feisty after the Ubuntu ISOs were rolled.
<lifeless> should it not have gone into f-s-u ?
<Fujitsu> Kubuntu was rerolled, as it needed that fix... but Ubuntu now has unpublished binaries on the ISO.
<pitti> I raised the GPL problem, but was pointed to the still existing source, so I *phew*'ed
<lifeless> ah
<elmo> fan-TASTIC
<Fujitsu> pitti: I suggest you revoke that phew for now.
<Fujitsu> elmo: that's right.
* Fujitsu decides to not bring this up in future.
<pitti> Fujitsu: we still have the broken .jigdo problem, but that's less delicate
<pitti> Fujitsu: please do bring it up
<lifeless> Fujitsu: we take GPL very seriously
* Fujitsu thinks the Soyuz guys might have to come up with a way of getting it republished.
<Mithrandir> Fujitsu: no, they don't.
<Mithrandir> we have the bloody source ISOs so it's fine.
<Fujitsu> Mithrandir: Oh, true.
* Fujitsu hides.
<Mithrandir> it's not great, but it's fine.
<pitti> Fujitsu: btw, in this case we are triple-sure, we also have the source in bzr
<lifeless> in fact, bzr is the preferred form for modification ;)
<pitti> bzr++
<lifeless> nono, just bzr ;)
* Fujitsu shuts up before making himself look any more foolish in a public channel in front of a large number of demigods.
<Mithrandir> lifeless: sssh!  Or we'll be required to ship the .bzr trees to everything as well.
<ion_> Lets write a new VCS. Well call it bzr++. :-)
<lifeless> Mithrandir: and thats bad how ?
<lifeless> :)
<dholbach> good morning
<ion_> Hi
<dholbach> hey ion_
<Mithrandir> lifeless: depends.. if we suddenly built ooo from a bzr import, I imagine we could make debian-cd explode due to not being able to fit a source package on a CD, even alone.
<pitti> Mithrandir: *shrug* source hard disks
<mjg59> Hnnnnnnnnnnnnnngh.
<ajmitch> hey dholbach 
<dholbach> hey ajmitch
<Mithrandir> Fujitsu: seriously, your concern is fine and the jigdo problem is a real problem we need to fix.  I'd much rather have people report problems that can be dismissed than not having them reported in the first place.
<mjg59> Providing the preferred form of modification for the Nelson Mandella video would be bad enough...
<Mithrandir> hiya Matthew.
<Mithrandir> mjg59: but is it under the GPL?
<Mithrandir> it could easily be licenced under the BSD licence in which case we're fine.
<Mithrandir> or some CC licence
<Fujitsu> Mithrandir: Yes, but I completely ignored the fact that there are source CDs and similar.
<mjg59> Mithrandir: Ah, but source = preferred form of modification. Judging by debian-legal.
<Mithrandir> mjg59: luckily, we don't have debian-legal here.
<lifeless> Mithrandir: the .bzr should be a small multiple of the ooo source tree in tarball form
<lifeless> Mithrandir: its already compressed.
<mjg59> Anyway. Bed now.
<lifeless> night
<Mithrandir> lifeless: a small multiple, like 2-3x?
<mjg59> (I'm -8 hours this week, if anyone wants to get in touch)
<Fujitsu> lifeless: `Need to get 309MB of source archives.'
<Fujitsu> lifeless: Still not insubstantial :P
<lifeless> Mithrandir: often less, except for pathological cases
<lifeless> anyhow, HistoryHorizons for the win
<lifeless> ship only a few 100k more.
<Fujitsu> lifeless: When is that feature arriving?
<Mithrandir> lifeless: OOo is an ancient project with tons and tons of commits, so I wouldn't be surprised if the .bzr repo would end up being quite large.  And even if not, I'd like not to have to ship stuff like the .git tree for the linux kernel since it's fairly big.
<lifeless> when its written?
<lifeless> Mithrandir: right. HH.
<\sh> moins
<tepsipakki> keescook: another borken software segfault due to libx11 update, this time it's proprietary: IDL
<tepsipakki> keescook: bug 107945
<ubotu> Malone bug 107945 in libx11 "Security update of libx11-6 causes IDL segfault" [Undecided,Unconfirmed]  https://launchpad.net/bugs/107945
<Fujitsu> tepsipakki: Ouch, my father won't be pleased :(
<tepsipakki> Fujitsu: yep, I'll mail the company about it
<Fujitsu> tepsipakki: That's the only way to go, I guess.
* Fujitsu subscribes to the bug.
<Stonekeeper> hi. not sure if this is the right channel, but I've found 2 things with wireless in feisty: 1. Network Settings->Wireless only allows you to insert a WEP key and 2. Typing in my password to a discovered network doesn't work, but if i set it up manually it does. Cheers.
<Mithrandir> Stonekeeper: use launchpad, not IRC for bug reports.
<Stonekeeper> ok! never used that before. What's the URL?
<Mithrandir> http://launchpad.net/ubuntu/+filebug is probably what you want.
<Stonekeeper> thanks
<Mithrandir> np
<doko> mvo: the question in 104716 to you was, if font packages should run fc-cache with or without the -s option
<cjwatson> Mithrandir: hmm. should be possible to regenerate the jigdo somehow. I think. It's a lot easier when you're in the process of building the image ...
<cjwatson> our jigdo files are actually generated by mkisofs, y'see
<Mithrandir> cjwatson: yes, but we should be able to just download the ISO, point it at an up-to-date mirror and then generate the jigdo file the old way.
<Mithrandir> and then replace it in the tree
<cjwatson> yeah, theoretically
<cjwatson> I'll give it a try
<mvo> doko: I haven't investigated this closely but my gut-feeling is that "-s" is a good idea and that some of the failures with fonts are releasted to the fact that we don't use it
<Mithrandir> cheers.
<mvo> doko: or rather, that some packages use it and some don't 
<cjwatson> TBH I'd almost rather figure out how to hex-edit it into the .template :)
<Mithrandir> cjwatson: ew.  I think just regenerating it is easier, and that's how it's traditionally done so I suspect it's not very error-prone?
<cjwatson> surely it's just dd'ing update-manager-core and update-manager into the right place and removing them from the .jigdo
<Riddell> "Kubuntu daily CD health check  No problems found!"  yay
<cjwatson> Riddell: one would hope so at this point ;)
<cjwatson> I'll turn the cron jobs off until gutsy CD building starts
<doko> cjwatson, seb128: http://python.org/sf/1703592 has the somewhat expected answers
<seb128> doko: hum, k
<cjwatson> doko: followed up
<cjwatson> ("practicality beats purity" - but I doubt there is anything to be gained by quoting bits of the zen of python back and forward)
<pitti> erk, Malone seems to be broken entirely, is that just me?
<cjwatson> yes, just commented on that in #canonical
<cjwatson> come to that, https://launchpad.net/ -> OperationalError
<cjwatson> ah, it's back
<pitti> jdub: happy birthday!!!
<ogra> jdub, yay, happy bday !
<seb128> jdub: happy birthday!
<StevenK> jono: Love the blog post.
<dholbach> HAPPY BIRTHDAY jdub!!!
* dholbach hugs jdub ecstatically
<Hobbsee> hi dholbach 
<dholbach> heya Hobbsee
* dholbach hugs Hobbsee ecstatically too
<Hobbsee> :)
<mvo> jdub: HAPPY BIRTHDAY!
<jsgotangco> whoa!
<cjwatson> Mithrandir: decent progress on jigdo fixing - I've regenerated ubuntu-7.04-alternate-i386 and am working on the others using the same method
<siretart> pitti: cjwatson: ok to upload https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/104332/comments/16?
<ubotu> Malone bug 104332 in rdesktop "Segmentation Fault (core dumped)" [High,Confirmed]  
<Mithrandir> cjwatson: ok, cheers.
<bluefoxicy> heh
<cjwatson> I'm using jigdo-file make-template, merging in the old jigdo, and then fixing up by hand
<bluefoxicy> We are giggling about Ubuntu's servers not serving Feisty yesterday due to DDOS-Scale load
<cjwatson> for minimal diff, basically
<bluefoxicy> because some of us used the bittorrent
<bluefoxicy> which reacts the opposite way; a billion users == ultimate download speed :D
<cjwatson> siretart: yes
<siretart> cheers
<cjwatson> I've not reviewed it in detail but it looks appropriate for an SRU
<siretart> I wanted to upload it to feisty directly, but was to late :(
<pitti> siretart: looks innocent enough
<siretart> and is approved by upstream (he's sitting next room to me)
<dholbach> mneptok: cool mugshot in LP ;-)
<dholbach> and lots of people in the bugsquad: http://launchpad.net/~bugsquad/+mugshots :)
<pitti> dholbach: nice, +mugshots  :)
* Hobbsee is amused at the description of https://launchpad.net/~ubuntu-clusterfuck
<fabbione> hey Hobbsee :)
<Hobbsee> heya fabbione!
<jsgotangco> haha
<j0nas`> gentleman.. (and ladies).. are there known issues with the partitioner on the feisty install disc?
<j0nas`> i get a cryptic error message: "??? ???"
<cjwatson> j0nas`: not that I know of, please file a bug on partman-base attaching /var/log/syslog and /var/log/partman
<cjwatson> you can use "save debug logs" from the installer main menu to extract those
<j0nas`> how to get the log files?  can i get a shell from the install disc?
<j0nas`> oh right. :)
<cjwatson> or 'anna-install openssh-client-udeb' and you can scp them out
<j0nas`> k brb im going to look into this
<j0nas`> thanks
<bddebian> Heya
<robertj> is anyone here interested in a possible solution to the "why doesn't samba work" (did you add a samba password) problem?
<seb128> robertj: what problem is that? you mean the "you need to add an smb user to share something"?
<seb128> pitti: do you know if the feisty task on https://bugs.launchpad.net/ubuntu/feisty/+source/hwdb-client/+bug/105510 is correct or if it should be closed?
<ubotu> Malone bug 105510 in hwdb-client "hardware database notification has poor ui" [Undecided,Confirmed]  
<pitti> seb128: right, it can go away since we disabled it entirely
<seb128> pitti: ok, closing it then
<robertj> seb128: https://wiki.ubuntu.com/SimpleSambaIntegrationSpec <-
<bddebian> Is Gutsy open yet, is Gutsy open yet??...
* bddebian hides
<seb128> hi bddebian ;)
<bddebian> Heh, hello seb128 :-)
<seb128> robertj: hum
<cjwatson> bddebian: getting there
<seb128> robertj: I was rather thinking using nautilus-share and net usershare
<bddebian> cjwatson: Sorry, I'm joking.  I'm pretty much out of commish until about July :'-(
<ogra> bddebian, no, we're still not finished shovelling all the gutsy backports into the archive :P
<bddebian> ogra: :)
<cjwatson> lp_archive@drescher:~$ q -s gutsy -Q unapproved info
<cjwatson> Listing ubuntu/gutsy (UNAPPROVED) 8/8
<pitti> cjwatson: ! yay
<ogra> hooray
<robertj> seb128: the big issue is that people aren't setting smbpasswds
<robertj> does that seem like a workable idea? does it seem sane?
<seb128> robertj: http://gentoo.ovibes.net/nautilus-share/mediawiki-1.4.4/index.php/Accueil
<seb128> robertj: its uses the samba "net usershare" and it doesn't need to add any user
<robertj> I personally dislike security = share, and I know the feeling is common around #samba
<seb128> robertj: I think that's what NDL is using
<seb128> robertj: that's not security = share, that's a new samba thing
* robertj reads
<robertj> seb128: so how does that void creating samba users?
<robertj> err avoid 
<seb128> robertj: it's done by nautilus-sendto using net usershare
<seb128> if your user is member of the samba group it can add samba shares
<seb128> and require an username and password for them
<robertj> yes, thats fine but what about other users that need to access it
<seb128> ?
<seb128> give them the username and password you used
<robertj> seb128: is that per-share?
<seb128> I need to look on how it works exactly
<seb128> but it should be
<seb128> the usual way you share thing is right click on a directory and share it
<robertj> seb128: the problem is if you try to enforce permissions samba can't auth users without you giving them per-user passwords again
<robertj> and most orgs won't get by with per-share passwords
<robertj> and without that you have fundamentally the same problems as you have with a security = share samba share
<seb128> what is wrong with having a password for a share?
<robertj> seb128: because then you end up needing two interfaces for medium businesses and home users
<seb128> what do medium businesses need?
<robertj> they need each user to have their own password so you can log access
<robertj> and medium-large businesses also need a structure that integrated with their SSO, which pam gives you for free
<robertj> so if you have pam hash smb passwords you can join your smb machine to ads or samba4 and everyone will live happily ever after
<seb128> so you basically want to add every system user to the samba users list?
<robertj> seb128: sorry i confused that a bit
<robertj> up until the point you join a directory
<robertj> so before then I do want to add every user
<seb128> k
<robertj> and if you use authtool to switch to a directory then you would want it to edit that portion of pam out
<robertj> so the big win is if you have a decidedly medium business
<seb128> I mentioned samba shares on the list of things that would be nice to fix next cycle
<seb128> so I guess we will discuss it at next UDS
<robertj> and you have a computer with 6 users on it
<robertj> and you think "ok, I want to make the spreadsheet available to my employees, but be able to tell if someone screws up who it was"
<robertj> so if the smb users are auto-created you can add samba through Add/Remove and the only thing you need to do is uncomment the homes directory and add writabe = yes and restart samba
<robertj> and you don't have to call mary in from home to put in her password, and you don't have to ask mary what her password is, or give her another password
<robertj> and if you add another 30-50 users you don't have to keep dual-entering passwords, or syncing passwords, or end up sharing a password with 50 users
<robertj> worst-case scenario...you turn that machine into a directory server that doesn't
<robertj> doesn't run SMB, and you end up with a million hashed passwords you don't need, but that's really far-fetched ;)
<pitti> siretart: rdesktop -> it should have a maintainer: field change
<Hobbsee> hiya pitti 
* Hobbsee hugs pitti 
<pitti> hey Hobbsee 
<seb128> robertj: k, thank you for the details on that, we will discuss the options available
<pitti> siretart: well, the .debs will be ok, so let's not worry about it too much
<robertj> seb128: but do vandalize https://wiki.ubuntu.com/SimpleSambaIntegrationSpec with any ideas/comments/thoughts
<seb128> robertj: we will get one wiki page for the spec, if that's not this one I'll add the URL on it
<robertj> seb128: np, just as long as it gets fixed ;)
<robertj> I was one of the many who slash'd and burned various iterations of the EasyCodecInstallation* hierarchy, I just accept it as part of the process
<robertj> enabling [homes]  seems to be a special use case
<robertj> I would say quietly enable it when /home is shared but that sucks if your home dir isn't /home
<robertj> or your home's parent
<robertj> [printers]  and [print$]  also seem like they are worth considering. the [profiles]  and other shares related to domain controllers don't need to be exposed there and [cdrom]  probably's isn't worth the trouble really
<siretart> pitti: I can do it for the -updates uploads, I wanted to keep the diff minimal though. I wasn't sure
<siretart> btw, can I login to ubuntuforums.org with my lp password?
<pitti> siretart: right, don't worry
<siretart> ok
<micahcowan> What happens, release+1 development-wise, after a launch? Is a straight copy-over of feisty to gutsy repositories done, and when is that usually finished (and gutsy repos opened, and development can begin)?
<Hobbsee> micahcowan: pretty much.  the first stuff is the toolchain, but they started doing that towards the end of feisty, so it should get done quicker
<micahcowan> Hobbsee, what constitutes the toolchain? I'm assuming all of core and universe are carried over at some point (and then later potentially merged with Debian)
<Hobbsee> micahcowan: the stuff in build-essential, and the stuff marked as essential
<Hobbsee> the really core stuff
<pochu> micahcowan: https://wiki.ubuntu.com/FeistyPlusOneToolchainRoadmap
<cjwatson> glibc, binutils, gcc
<micahcowan> Thanks pochu, hobbsee
<cjwatson> essential isn't toolchain per se - by toolchain we basically mean the GNU development toolchain
<Hobbsee> ah
<cjwatson> we're in the middle of this - doko's uploaded initial toolchain versions, and we're just waiting for the buildd operator to wake up at this point (he's in .au)
<Hobbsee> i thoguht it all counted
<Hobbsee> bah.  it's not 2am yet.  wake him up.
<micahcowan> Does development for gutsy usually start out as simply pbuilder stuff, then (since most of the OS isn't there yet), and if so, when does it tend to move to actual development within the OS itself?
<cjwatson> the OS is there, we have feisty
<cjwatson> feisty gets copied to gutsy to start with
<Hobbsee> micahcowan: yes, although there are hacks for pbuilder for testing that things work.  as soon as it's stablish, people will move to gutsy
<micahcowan> okay, that's part of what I'm asking.
<micahcowan> That's been accomplished already (the copying)?
<cjwatson> yes, that was done a few hours back
<cjwatson> archive.ubuntu.com is being hammered though so it hasn't been successfully mirrored yet
<pochu> And is the repo opened? :)
<robertj> seb128: do we wanna have one big monolithic spec for samba integration though if we can do smaller specs that don't block?
<cjwatson> pochu: still frozen until the toolchain is in
<pochu> cjwatson: k, ty
<cjwatson> fear not, it'll be announced ;)
<robertj> btw, anyone got throughput stats on archive?
<seb128> robertj: having a spec doesn't seem to be too complicated
<seb128> robertj: we can describe several changes to do on it
<micahcowan> Do a lot of devels tend to have installs of both the current (for usability) and next (for devel) releases on their machines? Or do many devs tend to prefer virtual machine installs for the devel until it gets dependable?
<cjwatson> it should work once the buildd chroots are created, but we prefer to get the toolchain through first so that we don't have to have stuff rebuilt
<micahcowan> (Sorry if I'm asking a volume of questions more common to a six-year-old child; guess I just never followed this train of thought before)
<cjwatson> a virtual machine install sounds like a lot of effort, I wouldn't bother with that
<cjwatson> some folks dual-boot, some just go all-out and trust to ability to recover :)
<micahcowan> cjwatson, I'd do the latter, but the rest of my family probably wouldn't appreciate it when things break :)
<cjwatson> I tend to go all-out because working on the installer tends to give you plenty of experience with putting systems together from the ground up
<micahcowan> OTOH, I don't think I bothered with a separate /home partition, so that'd need adjusting...
<cjwatson> you don't actually need to run gutsy in order to work on it for the initial round of merges, but it does help to be able to test at least some things
<robertj> seb128: its not the spec, its finding people to implement it that's the hard part ;)
<micahcowan> Sure: you could pbuild all the way 'til release; but you can't find what's actually broken without running it :)
<cjwatson> quite so
<seb128> robertj: well, the work is the same if you split it or not
<robertj> seb128: then i'd say manage perceptions and spec small weekend-sized tasks :)
<micahcowan> I'd like to see pbuilder installed with setup for multiple distros by default, so you don't have to go through the manual setup anymore. I may write a spec to that effect.
<Hobbsee> micahcowan: it's already got example docs on how to do that
<seb128> robertj: let's discuss what we wants to do, then we can split tasks, etc
<pitti> argh, forgot to sub to gutsy-changes@
<micahcowan> Hobbsee, yes, I know: but it shouldn't. It should be a couple lines in the shell, instead of copying a (buggy: I just made some adjustments on the wiki) script and copying/editing files: it's all automatable, and it's not like it's a corner use-case
<micahcowan> BTW: I'm planning on replying to the "texlive" post on ubuntu-devel-discuss; but I wasn't sure if ubuntu-motu might be more a appropriate forum to which to move it?
<Hobbsee> micahcowan: *shrug*
<Hobbsee> micahcowan: both are developers stuff, devel-discuss tends to ahve the crack filled ideas
<robertj> seb128: ok, this is anathema, but here is another question, is there some way we could ask users if they wanted to open shares admin if they add it through add/remove/
<micahcowan> I'll leave it there, then.
<Hobbsee> micahcowan: and most wont be subscribed to -motu
<seb128> robertj: what do you mean?
<micahcowan> Hobbsee, mm, good point.
<robertj> seb128: nm, samba doesn't show in Add/Remove
<robertj> seb128: https://wiki.ubuntu.com/SimpleSambaIntegrationSpec now has a beautiful mockup of hte extensive proposed changes to shares-admin
<seb128> robertj: nice drawing :p
<robertj> thanks, I credit my skills to omni-graffle
<robertj> it makes it so each to produce professional results that you realize that it doesn't help
* robertj heads out for lunch
* cjwatson builds gutsy vim - after that it's on to the installer
<Mithrandir> cjwatson: how do you build it sans toolchain?  Oh, I forgot, you're Colin. :-P
* fabbione has already gutsy openais and redhatclustersuite
<cjwatson> Mithrandir: I don't mind building it with feisty's toolchain for testing
<Treenaks> Mithrandir: do we need Colinfacts now?
<cjwatson> all I'm doing is merging and adding gutsy to the syntax highlighting
<Mithrandir> Treenaks: pondering it.
<cjwatson> after that I think all the development tools aside from the toolchain that I care about will be gutsy-friendly and I can just install them all on this laptop and be happy. ;-)
<Mithrandir> yeah, I should probably do emacs too, or at least the debian mode for it.
<pitti> can I do vim? :)
<Mithrandir> I think Colin just did
<pitti> ah, splendid
<cjwatson> sorry ;-)
* pitti hugs cjwatson 
<pitti> right, he did vim for feisty, too
<cjwatson> haven't quite yet, testing a build first to make sure I don't like kill people's editor
<pitti> so traditionally I should upload the mutt merge first
<Mithrandir> cjwatson: everybody knows the real editor is ed anyway.
<cjwatson> the benefit of the editor wars is that it's hard to kill *everyone's* editor
<Treenaks> as long as you don't break ar + tar, we'll manage :P
<Mithrandir> Treenaks: and if he does, we'll still manage.
* Mithrandir hugs sash
<pitti> dchroot -c feisty vim foo.txt :)
<Treenaks> Mithrandir: good point
<Mithrandir> heck, worst case I can do ar and tar with dd, though I'd like not to.
<Mithrandir> gzip is slightly worse, though.
<cjwatson> well, doko's doing the binutils merge, so ar would be his fault, and I wasn't planning on doing tar. :)
<Mithrandir> yeah
<ogra> is someoune mergig the MLs or do we need to subscribe manually to -changes ? 
<cjwatson> in fact, tar is a sync
* cjwatson subscribed manually
* pitti uploads the hal merge from hell to chinstrap
<Mithrandir> ogra: you need to subscribe manually.
<Mithrandir> it'll all be in the "opening gutsy" email I'm going to send out when we have a toolchain.
<codingmaster> hello people :)
<codingmaster> for the public interest: Google SoC 2007
<codingmaster> Ubuntu Firewall Configuration
<codingmaster> https://lists.ubuntu.com/archives/ubuntu-soc/2007-April/000022.html
<pitti> codingmaster: I wish you all the best for it!
<codingmaster> thanks martin :)
<codingmaster> muahahahaha :p
<codingmaster> ;)
<codingmaster> IMHO the project needs ASAP a good name :)
<cjwatson> uriel
<pitti> He "stands at the Gate of Eden with a fiery sword," [2]  or as the angel who "watches over thunder and terror."
<pitti> sweet :)
<cjwatson> (traditionally, the archangel who guards the Gate of Eden with a fiery sword)
<codingmaster> nice :)
<pitti> kraal (the name of the previous SoC project) was quite nice as well, from Xhosa heritage
<cjwatson> codingmaster: ^--
<codingmaster> @my nickname
<codingmaster> ha ha ha
<ogra> perfect
<codingmaster> It is about 10 years ago, I chose that name
<codingmaster> :p
<pitti> codingmaster: apt-cache search uriel is empty, too
<cjwatson> also Milton describes Uriel as the "sharpest sighted spirit in all of Heaven"
<codingmaster> I was a kid then: lucky me, that I did not choose a stupid name :)
<codingmaster> the ideas are good :)
<codingmaster> I will add them to the wiki later
<pitti> oh, merges.ubuntu.com is down, too bad
<elena_g> hello all, I've installed mozilla-firefox-locale-ka-ge module but mu Firefox continues to be in english.
<pitti> elena_g: 'This is an empty transitional package to ensure a clean upgrade
<pitti>  process. You can safely remove this package after installation.'
<pitti> This language is unavailable for the current Firefox version.
<pitti> elena_g: sorry :/
<elena_g> piti this language is present here: http://www.mozilla.com/en-US/firefox/all.html
<elena_g> pitti, sorry...
<elena_g> - 1(p) :D
<elena_g> may I install from here ?
<pitti> elena_g: right, you can
<elena_g> pitti, and what about Georgian language support in the next browsers realise ?
<elena_g> 3.0 or 4.0
<elena_g> :P
<pitti> elena_g: depends, if there is someone who provides translations we can include them
<elena_g> pitti, thanks... 
<elena_g> I have 2.0.3 version
<elena_g> pitti, have a nice afternoon! :)
<elena_g> Ciao ciao!
<pitti> elena_g: bye
<nox-Hand> Hey
<nox-Hand> In the -14 and -15 kernel (the two newest upgrades) I cannot boot Ubuntu
<nox-Hand> And I am told it might be because of some drivers that were removed?
<nox-Hand> Can I somewhere check that?
<elmo> so, umm, when I press brightness up on this x60, the display turns off
<elmo> what's the most likely/suitable package as a victim for a bug report
<ogra> g-p-m :(
<ogra> or hal
<mjg59> Kernel
<mjg59> (probably)
<mjg59> Does it happen at the console?
<elmo> will check
<elmo> it's just rebooting
<pitti>         <match key="/org/freedesktop/Hal/devices/computer:system.hardware.version" string="ThinkPad X60">
<pitti>           <merge key="laptop_panel.brightness_in_hardware" type="bool">true</merge>
<pitti>         </match>
<pitti> so if it's a hal bug, then the bug is that it doesn't properly set this rule for your model
<ogra> pitti, there are pther ules that match on LENOVO iirc
<ogra> *other
<pitti> yep
<pitti> elmo: can you please followup to bug 61184?
<ubotu> Malone bug 61184 in hal "Screen brightness buttons don't work properly on Thinkpad Z61T" [Medium,In progress]  https://launchpad.net/bugs/61184
<mjg59> elmo: If you blacklist the video module, it'll probably work. It seems related to newer BIOSes which actually implement the acpi video extension properly
<mjg59> pitti: No, I think this bug is entirely separate
<pitti> elmo: that's a collection of various thinkpad brightness quirks
<pitti> mjg59: oh, ok
<mjg59> elmo: But I have no hardware that implements this stuff, so...
<elmo> it's horribly sluggish to react to the brightness up/down on the console
<mjg59> It's very hard to figure out what on earth is going on
<elmo> mjg59: can I do anything to help remote debug this?
<elmo> mjg59: alternatively, it's "demo" hardware, I could have it loan to you next time it's free...
<elmo> I love how we load asus_acpi on an IBM x60
<kylem> elmo, bring it to uds?
<elmo> kylem: mm, can't, it'll be in use then
<kylem> bummer.
<elmo> to be fair, this is the first thing I've found that doesn't work
<elmo> of course, I found it out as I was explaining what it great laptop it was to silbs, *sigh*
<kylem> eep.
<mjg59> elmo: Can you try rmmodding video and see if it's happier?
<elmo> oh, you said 'video' why did I read that as 'blacklight'
<elmo> or backlight even
<elmo> mjg59: that got me a BUG \o/
<mjg59> elmo: Winning.
<mjg59> elmo: Blacklist it and reboot?
<elmo> grr
<elmo> I have no wired intarweb either
<elmo> kylem: why is that e1000 ignore invalid checksums switch not on by default?
<mjg59> elmo: Gah, that was supposed to be fixed in newer BIOSes
<kylem> because it's a bad idea....
<mjg59> Intel's failure to fix certain types of bug is somewhat infuriating
<elmo> kylem: in what way?
<kylem> and can cause serious problems that are much worse than people having to add a command line option.
<elmo> kylem: this laptop is brand new
<kylem> elmo, silent corruption of data?
<elmo> eh, but intel themselves are shipping machines with nics in this state?
<kylem> perhaps for gutsy we could dmi-whitelist certain known-fucked machines.
<kylem> elmo, yessir.
<elmo> meh, well, h9 of intel and lenovo and everyone else involved
<kylem> i need to re-prod monteal about it.
<elmo> kylem: worth reporting this BUG?
<mjg59> e1000 supports powering down the hardware when there's no cable plugged in
<mjg59> The driver does nothing to power it up before checking the eeprom state
<mjg59> = loss
<mjg59> = loss that's been documented for over a year
<kylem> winningest.
<kylem> elmo, the video one? sure.
<mjg59> There's nothing wrong with the hardware config, it's the software that's at fault
<kylem> mjg59, yes, which is why ignoring the eeprom warning universally is a bad idea.
<mjg59> Yeah
<Treenaks> mjg59: software as in driver, or as in firmware?
<kylem> iz driver boog, likely.
<mjg59> Driver, yeah
<elmo> mjg59: interesting
<elmo> mjg59: blacklisting video fixes the 'brightness up turns off my display' problem in X
<mjg59> Ok. Eez kernel boog.
<elmo> mjg59: but in both X and console it's still very sluggish to respond to both
<mjg59> elmo: Hm. That's more of a pain.
<mjg59> But the brightness change is done in hardware...
<jdub> pitti, ogra, seb128, dholbach, mvo: um, fuck you all! ;-)
<elmo> and also the brightness up/down meter doesn't work
<jdub> hey elmo
<elmo> hi jdub
<pochu> elmo: do you mean the applet?
<elmo> pochu: the little thing that pops up in the centre  of the screen
* pochu has never seen that for the brightness
<pochu> Though I have an Acer, dunno if that matters
<mjg59> Yeah, it matters
<pochu> :)
<elmo> it seems to take about a second to process each key press
<elmo> but only for brightness, changing volume, f..e is fine
<pochu> bug 81339
<ubotu> Malone bug 81339 in hal "Cannot get laptop panel brightness" [Undecided,Confirmed]  https://launchpad.net/bugs/81339
<sharms> If I need to map a comport to a tcp/ip device, is this possible?
<elmo> oh, interesting
<elmo> if I add the brightness applet to the slider, it works flawlessly
<elmo> as in, no slag
<Spads> (when using the software slider)
<elmo> err, no lag
* Spads slags elmo 
<ogra> is comport a noun ?
<Spads> ogra: verb
<Spads> ogra: oh, it can be a noun too
<cjwatson> "COM port"
<ogra> right, thought so :)
<sharms> cjwatson: I am having a bit of trouble finding anyone who has done it before
<cjwatson> probably makes more sense to DOS rejects
<cjwatson> sharms: (sorry, I've no idea)
<tepsipakki> the X60 brightness-bug has been reported already a while ago
<tepsipakki> bug 87028 :)
<ubotu> Malone bug 87028 in linux-source-2.6.20 "Thinkpad X60s (also T60, R60): changing the screen brightness blanks screen" [Medium,Confirmed]  https://launchpad.net/bugs/87028
<cjwatson> sharms: do you mean you want to make a network connection over a physical serial port, or you want to make some other kind of network connection look like it's a serial port?
<kylem> heh, SLIP.
<sharms> cjwatson: I need a local app to connect to the serial port, which really forwards to a network device
<cjwatson> and the local app is talking what kind of protocol?
<sharms> I am not quite sure, its complicated because it is a windows program ran through wine, so it just needs a comport, and then I have a device which is networked which is hooked up to the actual device
<kylem> what you're saying is that you have a device on a network, and a windows program that exposes a serial interface to the device console (over the network)
<kylem> you likely need a windows .dll for that.
<kylem> er, i thought "driver" and typed "dll" odd.
<sharms> yeah I was hoping to just find some easy way to tell linux to redirect the serial device to the network
<kylem> things don't work like that. :)
<Ng> network character devices would be very handy, but don't seem to exist
<kylem> you could likely snoop the windows program running to figure out the protocol.
<pitti> hey bryce!
<cjwatson> bryce: welcome
* pitti hugs the new X master
<bddebian> whoa
<bddebian> sucker..
<bddebian> err uhm, I mean Welcome!! :)
<sharms> yeah it looks like the network serial device uses tcp/ip and telnet
<kylem> sharms, is it a rocketport device?
<sharms> its a "systech"
<kylem> ahok.
<kylem> one of these decades i'll work on a linux driver for the rocketport ethernet serial doodads.
<sharms> looks like I might be able to do this over rtelnet
<sharms> woo just found a package bug in  socks4-clients
<tepsipakki> oh we have an official X maintainer now? that's cool :)
<bryce> heya pitti and cjwatson
<geser> if someone is interested: bug #108232 has a debdiff for a merged devscripts for gutsy
<ubotu> Malone bug 108232 in devscripts "[Merge]  devscripts 2.10.3ubuntu1" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108232
<cjwatson> geser: I already uploaded it
* cjwatson points publish-queue at gutsy
<Mithrandir> cjwatson: care to fix mdebdiff too, when you're at it?
<Mithrandir> s/when/while/
<cjwatson> done, and new-source
<geser> cjwatson: should I reject my merge bug then?
<cjwatson> I fixed madison-lite config earlier
<cjwatson> geser: I just marked it fix-released (bit of a lie, but)
<Mithrandir> cjwatson: is there any reason why we don't have it all in a sourcable bit of shell somewhere?
<Mithrandir> it's kinda silly
<cjwatson> Mithrandir: I guess cprov's lp-query-distro will fix it when it's written
<Mithrandir> I love mythical software.
<Mithrandir> can I have a pony with it too?
<Mithrandir> (sorry, not intending to be harsh)
<zul> yes...yes you can
<cjwatson> ok, http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/unapproved/ is in place now
<cjwatson> should help with coordination
<Draconicus> http://pastebin.ca/450323
<Draconicus> This is a bit unpleasant. 
<Draconicus> I'm not really asking for support. I'm just pointing out that something very simple has seemingly hosed my system.
<Draconicus> That's the original kernel I'm working with. Haven't updated it.
* Draconicus waves.
<Burgwork> Draconicus: if this is a fresh install of 7.04, file a butg
<Burgwork> if it is an update from 6.10, file a bug
<Burgwork> if it was updated throughout the dev cycle, don;t
<Draconicus> It's quite a bug..
<Draconicus> I didn't really do anything. D:
<geser> cjwatson: is the devscripts package from this url your merged package?
<Draconicus> And it's a fresh install, as stated in the thing..
<Burgwork> Draconicus: file bug and ask for support elsewhere, thanks
<Draconicus> Alright, alright. I'm just trying to say that you've released too early.
<Burgwork> Draconicus: breaking on some random piece of hardware is a bug, not a release blocker
<Draconicus> Burgwork: Random piece of hardware?
<Draconicus> Well, you go ahead and say that. I'll see it tested.
<Burgwork> Draconicus: it is a bug and if you file it, it should get fixed
<Draconicus> I need a solution now, but fine.
<Draconicus> This was supposed to be a nice, clean install for a client.
<Draconicus> I didn't expect a stable release to fall apart.
<Burgwork> Draconicus: what I am trying to say it that occasionally some peice of hardware fails to work. You apparently hit a piece like that. If that were the general experience, the release would have been delayed
<Seveas> !bug | Draconicus 
<ubotu> Draconicus: If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/  -  Bugs in/wishes for the bots can be filed at http://launchpad.net/products/ubuntu-bots
<Seveas> hmm
<Seveas> who broke the bot...
<Seveas> it used to say something different in here :)
<Burgwork> Seveas: I blame the owner ;)
<Seveas> of course
<Draconicus> Burgwork: Given the unusual sequence of problems I encountered, it may not be hardware releated. I ran out of space and had to compensate. That could happen to anyone.
<Seveas> !bugs
<ubotu> If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/ IRC is not a good medium to report bugs and this channel is for development coordination.
<Draconicus> related*
<Seveas> that's the one I man
<Seveas> Draconicus, running out of space breaks lots of things
<Draconicus> Oy... You know, I think I'll just reinstall. The home partition is separate anyway.
<Mithrandir> Draconicus: this doesn't look like a full disk problem?
<Mithrandir> s/Draconicus/Seveas/
<Seveas> Mithrandir, bodged initramfs?
<Mithrandir> that shouldn't make the kernel oops
<Seveas> bodged/hald written kernel
<Seveas> half*
<elmo> grr
<elmo> kylem: ping
<Draconicus> The disk isn't full anymore, but it was during installation of certain libraries and such.
<Mithrandir> could be, or it could be something dodgy in the paravirtualisation bits.
<Draconicus> And most importantly nvidia drivers.
<elmo> kylem: e1000.eeprom_bad_csum_allow doesn't even appear to work?
<Seveas> Draconicus, with nvidia drivers you're on thin support ice anyway :)
<Draconicus> You're an ice! D:<
<Draconicus> :P
<Draconicus> Anyway, I'll just reinstall. I probably killed it with the full disk. You have a very good point.
<Seveas> elmo, please don't hurt the poor kernel developer too much, he still needs to cook some Gutsy kernels
<shawarma> cjwatson: Would you consider applying this patch to the vim package in gutsy? http://linux2go.dk/vim_regex_cleanup.diff   It's starting to look silly. :-)
<Draconicus> Huh. After all that, it may have been a hardware issue. The install disc is failing.
<Draconicus> Draws a blank after loading the kernel.
<Mithrandir> sure it's not a bad CD?
<Draconicus> I'm about to check that.
<Draconicus> Well, it fails a CD test, which is to say it goes into it and draws a blank there, too. :P
<Draconicus> I'm going to try a 6.06 CD.
<Draconicus> Official Dapper install CD has a kernel panic when I attempt to check disc integrity.
<Draconicus> I guess I worked this poor old Dell too hard. o.O
<Draconicus> Must have overheated somehow.
<shawarma> geser: In case you haven't found out yet: Yes, those are the merged packages. Check the .changes file
<geser> shawarma: then cjwatson might be interested in my debdiff as it is for devscripts 2.10.3
<shawarma> geser: True.
<cjwatson> geser: yeah
<shawarma> cjwatson: I didn't realise you already uploaded those packages. Just forget about my vim patch then. I'll just prepare a proper package sometime when the archive opens. 
<cjwatson> shawarma: I'm applying it now actually - though I added commercial as well
<cjwatson> thanks
<shawarma> cjwatson: Right, good catch.
<shawarma> cheers
<tkamppeter> Does someone know why Kubuntu is released and Ubuntu not (according to the Fridge)?
<cjwatson> shawarma: done
<cjwatson> tkamppeter: the fridge is mistaken and should be corrected
<Burgwork> tkamppeter: because nixternal forgot to write the ubuntu stuff
<tkamppeter> So everything released?
<Nafallo> even the Nordic Remix of everything :-)
<cjwatson> tkamppeter: yes
<kylem> elmo, you have to add it to /etc/modprobe.d/options first.
<cjwatson> tkamppeter: subscribing to ubuntu-announce@lists.ubuntu.com would be a good idea, if you haven't already; it's the authoritative source of information here
<shawarma> cjwatson: cool.
<shawarma> cjwatson: Any idea when MoM will show up?
<sharms> tkamppeter: Also ubuntu.com will show you it is released
<cjwatson> shawarma: I think it's still blocked on disk space, but Scott would know more
<kylem> elmo, i've got a patch to handle modprobe options on the kernel command line (right now it doesn't apply them, upstream bug)
<shawarma> cjwatson: Oh, ok.
<geser> cjwatson: aren't doko and Mithrandir responsible for MoM now?
<cjwatson> geser: I believe that's the plan but the sysadmin ticket requesting access to the relevant machine is still open, so not really
<ion_> Morning.
<tepsipakki> ion_: don't push it ;)
<ion_> tepsipakki: I just woke up. :-)
<tepsipakki> lame excuse
<tepsipakki> :P
<tkamppeter> Thanks cjwatson, sharms, Burgwork
<Burgwork> tkamppeter: it will be rectified soon
<ajmitch> morning
<conn> mjg59, regarding bug 103768, have you verified if Tim's fix works properly? The bug was closed, but I still have problems connecting to an encrypted network and need to fiddle with enabling/disabling wireless during the connection attempt
<ubotu> Malone bug 103768 in linux-source-2.6.20 "softmac and network-manager cite unreconcilable differences" [Critical,Fix committed]  https://launchpad.net/bugs/103768
<mjg59> conn: It's not closed, and I haven't had an chance to check it
<mjg59> conn: I'm in the US right now
<conn> mjg59, thanks for the reply... I thought "Fix committed" was the equivalent to closed, so I wasn't sure if I should open a new bug - Tim thinks that your issue and mine is different, but with the same symptoms
<conn> mjg59, anyway... if you're on holiday or whatever, enjoy ;)
<Burgwork> conn: committed means the bug has been fixed, however not yet released. Fix Released is that status
<conn> Burgwork, thanks & I understand, but Tim made the fix available, and after testing it the issue remains on my system... so either I can contest that it's "fixed", or open a new bug. I was wondering if it's a waste of time to open a new one, or else to wait and see if this is followed up in the original bug
<mjg59> conn: One option is to de-duplicate them
<mjg59> I'll be back home next Thursday, and I'll try to test it then
<conn> I may do that mjg59, thanks
#ubuntu-devel 2007-04-21
* lamont wonder wth gtkpod takes focus when it comes up
<lamont> as opposed to letting the window manager do its job
<Burgwork> lamont: maybe the window manager that the developer uses doesn't play nice?
<lamont> it's still wrong
<lamont> if I want it to have focus, I tell the wm to do it.  taking focus because you think you know more than the user or his window manager is wrong
* lamont winds down on his vent.
<lamont> fwiw, gaim does the same thing
<lamont> equally b0rken, of course.
<lamont> and most metacity users wouldn't notice it, since metacity does the same thing by default
* lamont wanders
<cjwatson> ok, at least one jigdo (ubuntu-7.04-alternate-i386.jigdo) confirmed fixed
<cjwatson> for those who reported jigdo problems
<cjwatson> there are still six jigdo files I believe to be broken (ia64, sparc, source of various flavours), but I'm progressively fixing those too
<elpargo> hi is the firefox .pc file missing in 7.04?
<vustar> why does https://wiki.ubuntu.com/FeistyKnownIssues redirect to http://www.ubuntu.com/getubuntu/releasenotes/704 ?
<cjwatson> vustar: because it was a holding page for preparing that page on the website
<vustar> cjwatson, where can I find the feisty's system requirement ?
<vustar> cjwatson, thanks
<jdub> http://feeds.feedburner.com/~r/oreilly/radar/atom/~3/110729240/ubuntu_word_on.html
<mtm8> Would anyone be able to help me figure out the d-i partman-auto/expert_recipe_file string /hd-media/recipe line that comes standard with the alternate CD installer for remastering purposes?
<mtm8> 1) Where is /hd-media 2) How can I make a partition scheme as follows?: /dev/sda1: 128 M for /boot (ext2) with no disk space allocated for the super user with noauto,noatime options for mounting, /dev/sda2: 40 G for / with 3 percent disk space allocated for the super user and defaults,errors=remount-ro options for mounting, /dev/sda3: 11 G extended partition, /dev/sda4: an NTFS partition that isn't mounted, /dev/sda5: 1 G swap, /dev/sda6: 10 G (ext3) partitio
<mtm8> Does anyone know how to setup a preseed file for a remastered alternate CD so that it partitions in the following manner?
<mtm8> /dev/sda1: 128 M (ext2) mounted as /boot with 0% reserved for superuser and noauto,noatime mount options; /dev/sda2: 40 G (ext3) mounted as / with 3% reserved for superuser and defaults,errors=remount-ro mount options; /dev/sda3: 11 G extended partition; /dev/sda4: NTFS partition, not mounted; /dev/sda5: 1 G for swap; /dev/sda6: 10 G (ext3) mounted as /home/DOMAIN with 0% reserved for superuser and defaults,grpquota mount options
<sonictwin> how cani edit the applications - places - system menu?
<sonictwin> under places - i want to remove two folders that were dragged there mistakenly
<Burgundavia> sonictwin: #ubuntu for support, but you can right click on it
<sonictwin> right clicking it just opens it
<Burgundavia> then I cannot help you
<sonictwin> ty though
<Fjodor> fabbione: ping?
<fabbione> Fjodor: pong
<Fjodor> fabbione: Would you be coming to rhus today?
<fabbione> Fjodor: no sorry. I am not feeling good.
<Fjodor> fabbione: Oh, sorry to hear (on both counts). I do hope you get better then
<fabbione> Fjodor: thanks
<ion_> tzdata (2007e-0ubuntu0.6.10~prop1) edgy-proposed; urgency=low
<ion_>     - Introduces two new time zones (America/Indiana/Winamac and America/Resolute).
<ion_> Winamac sounds like an Apple campaign. :-)
<StevenK> Hah
<Treenaks> ion_: maybe it is :)
<ion_> :-)
<Treenaks> ion_: though it's next to Star City, according to google
<Treenaks> (though I doubt it's the same Star City as the Russians use to train cosmonauts ;))
<mdke> cjwatson_: just responded to your comment on bug 84273
<ubotu> Malone bug 84273 in ubuntu-website "hash for feisty on the md5sum page" [Wishlist,Rejected]  https://launchpad.net/bugs/84273
<ion_> benc: Hi. You might have noticed already, but anyway: http://www.nvidia.com/object/linux_display_ia32_100.14.03.html Added support for GeForce 8600 GTS, GeForce 8600 GT, GeForce 8500 GT, GeForce 8400 GS, and GeForce 8300 GS
<jsgotangco> the bugs! the bugs!
<ion_> benc: And at the same time they changed the version number format. :-)
<tepsipakki> ion_: the free driver also got support for those (2.0.2)
<tepsipakki> hm, actually only 8500/8600
<tepsipakki> ah, 8300/8400 support is in git
<tepsipakki> "support" being the pci-id's
* Treenaks can't wait for nouveau to reach stability
<ion_> treenaks: Hear, hear
<Burgundavia> tepsipakki: what do you think of this xorg/HAL stuff?
<tepsipakki> Burgundavia: input-hotplug?
<Treenaks> tepsipakki: and display-hotplug
<ion_> I(m going to) *love* that functionality.
<Mithrandir> so, anybody running gutsy yet? :-P
<Treenaks> Mithrandir: you? colin? :P
<tepsipakki> Burgundavia: I've been following the thread.. but don't have an opinion of my own yet :)
<Mithrandir> Treenaks: I'm not doing it yet.
<Burgundavia> tepsipakki: opensource, easy to use, multiseat is something I am looking forward too
<tepsipakki> Mithrandir: there's just tzdata for now :)
<Mithrandir> tepsipakki: I know, I just accepted it.
<tepsipakki> hehe
<fabbione> Mithrandir: i do :)))
<jsgotangco> hey sabdfl
<sabdfl> hey jsgotangco, how's life in the East?
<ajmitch> hey sabdfl, celebrated feisty release in style?
<bhale> hi sabdfl, ajmitch 
<ajmitch> hi bhale 
<jsgotangco> sabdfl: 36C here at the moment..ouch
<Hobbsee> nice and warm :)
<jsgotangco> Hobbsee: 87% humidity
<Hobbsee> jsgotangco: now that's a bit much
<ajmitch> ah, winter is approaching then? :)
<jsgotangco> we average 60% humidity since summer came
<Hobbsee> Mithrandir: w.r.t running gutsy - does pbuilder count?
<Mithrandir> Hobbsee: no. :-P
<Hobbsee> Mithrandir: awww, darn
* Hobbsee should, though
<StevenK> I'm not running Feisty yet.
<Hobbsee> StevenK: catch up then!
<StevenK> Soon.
<ajmitch> morning Mithrandir 
<Mithrandir> hiya ajmitch 
<sabdfl> jsgotangco: welcome to the sauna
<StevenK> Mithrandir: Recovered after the Feisty release?
<Mithrandir> StevenK: getting there.
<Hobbsee> jsgotangco: tell you what...i'll swap your weather with ours
<StevenK> Hobbsee: Hey, it's 20 degrees, it's pleasant at the moment.
<Hobbsee> bah
<StevenK> Download all files that we need to get (42359 MiB).
* StevenK kicks debmirror.
<StevenK> I already have that much locally debmirror, kthxbye
<ajmitch> hm
<ajmitch> next billing cycle in 3 days
<ajmitch> I wonder how much I went over this month
<ajmitch> ah, painful
<ion_> Over what?
<Hobbsee> whisky tango foxtrot...this idea is just getting more and more bizarre...
<StevenK> Hah
<StevenK> Hobbsee: Which?
<Hobbsee> StevenK: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-April/000763.html
<Hobbsee> (the latest post hasnt shown up there yet, i dont think)
<StevenK> That meta-distro thing?
<Hobbsee> oh, yes it has
<Hobbsee> yep
<Hobbsee> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-April/000774.html is the last, and doesnt appear to be threaded
<Hobbsee> something tells me if ubuntu says "hi, we're going to take over the entire linux world, adn call it ubuntu"...most people wont be terribly pleased...
<StevenK> Um. Eww
<mneptok> "Ubuntu has bees so successful as a user-friendly Linux distribution that I think it's time to see tho community wark on projects like intercontinental railroad logistics or unassisted human flight."
<mneptok> *been
* mneptok tries to wake up
<Mithrandir> morning mneptok 
<Hobbsee> hi mneptok 
<mneptok> mornin'
<mneptok> shifting the sleep cycle this weekend.
<ajmitch> hey mneptok 
<Mithrandir> woo, gutsy binutils building.
<mneptok> heya ajmitch 
<Mithrandir> probably won't make this publisher run, though
<Hobbsee> Mithrandir: pedal faster, and it might!  :D
* ajmitch waits for the hordes of users to start dist-upgrading to feisty
<Hobbsee> ajmitch: s/feisty/gusty/ perhaps?
<ajmitch> yeah, habit :)
<lifeless> is dapper meant to auto-detect the upgrade to fisty?
<mneptok> heehee. a "gusty" from Hobbsee O:)
<ajmitch> it'll take a few weeks to break
<ivoks> lifeless: no
<Hobbsee> er, gutsy
<mpt> fisty and gusty
* Hobbsee beats mneptok 
<ajmitch> that misspelling probably won't stop :)
<Hobbsee> no.  as long as we all get it right in changelogs
<Hobbsee> or dch gets updated :)
* mneptok is usually betean by a pair or ace high
<mneptok> Flatulent Fawn. Gusty Gibbon.
<mpt> Wordy, Hairy, Bronzy, Dipper, Itchy, Fisty, Gusty
<mpt> These are the releases of the starship Ubutnu
* ajmitch remembers to stick in the 'farting monkey release' into his f-spot changelog
<mneptok> i saw Farting Monkey Release on their '92 tour. great show.
<Fujitsu> Hobbsee: There are new devscripts/vim/etc in UNAPPROVED, so I presume that's already been done.
<mneptok> ooo! better yet. as a label to some big lever inside a commercial airliner.
<Hobbsee> Fujitsu: great :)
<bryce> Gutty Gibbs, the next new Quake enhancement
<mpt> http://www.loc.gov/exhibits/oz/images/vc13.jpg
<ajmitch> bryce: I heard you got suckered into X?
<mneptok> mpt: and your little dog, too!
<bryce> heh
<mneptok> bryce: BTW, where in OR?
<bryce> ajmitch: tell me what the punchline is here?
<bryce> mneptok: Tigard (near Beaverton)
<ajmitch> :)
<mneptok> bryce: Canonical moved me to Montreal from Cedar Hills Blvd. area in B-tron
<ajmitch> just looking at the motto of the x-swat team :)
<bryce> ajmitch: previously I'd been doing NFSv4 testing, so Xorg maintaining seems pretty thrilling in comparison ;-)
<ajmitch> yes, it certainly would
<bryce> mneptok: wow
<mneptok> bryce: X.org maintenance + long, sunless winters = worriod mnep
<mneptok> *worried
<mneptok> bryce: kees is in SE
<jsgotangco> heh
<bryce> yup
<mneptok> and i get to travel to exotic PDX for Ulive
<mneptok> i guess it will be nice to see friends, but Seville sounds so much more interseting.
* bryce nods
<mneptok> although Seville doesn't have Powell's
<mpt> ajmitch, is <http://code.google.com/soc/ubuntu/appinfo.html?csaid=8BAD38809EB97475> similar to what you were working on?
* bryce has too many books already
<ajmitch> mpt: yes, similar to what I'm still working on :)
<Mithrandir> bryce: oh, so you'll make sure our NFSv4 support is great too? :-)
<bryce> heh
<Mithrandir> bryce: excellent, since then I don't have to. ;-)
<mpt> ajmitch, is it complicated, or do you have very little free time, or both?
* ajmitch got back to FDS stuff recently
<ajmitch> mpt: both at the moment
<mpt> ok
<ajmitch> hopefully #2 will improve a lot soon
<ajmitch> I'm not entirely sure what the SoC project is proposing besides an easy way to setup FDS
<ajmitch> which really requires packages
<Mithrandir> it looks like the wrong solution.  "Write a program to make it easy to set up FDS" rather than just "Make it easier to set up FDS".
<bryce> Mithrandir: unfortunately the test lab I'd built for nfsv4 is scheduled for demolition/ebay soon
<mpt> Every time someone adds another item to Ubuntu's Administration menu, God kills a kitten
<ajmitch> Mithrandir: I presume the student will end up changing the project a bit
<mneptok> oh my god. i just realized i'll be seeing iwj vs. Powell's!
<mneptok> this will be epic.
<mpt> (That was poorly worded, sorry)
<lifeless> FDS?
<ajmitch> fedora directory server
<bryce> mpt, did you mean every time god kills a kitten, another entry appears in Ubuntu's Administration menu?  I can confirm that.
<ajmitch> formerly netscape
<mpt> bryce, no, that would mean solely US kitten deaths would cause 4,763,225 items to appear in Ubuntu's Administration menu per year
<bryce> you're not seeing that?
<mpt> Not so much
<bryce> huh
<mpt> What I was trying to say was, when there's a GUI for something missing from Ubuntu, people's instinct isn't "where would the GUI make the most sense", but "I know, I'll make a new program for configuring this"
<tepsipakki> Mithrandir: nfsv4 works just fine on ubuntu, it's kerberos that makes me pull my hair off sometimes (some software not designed to handle $HOME becoming inaccessible)
<ajmitch> tepsipakki: but kerberos is so much fun :)
<tepsipakki> ajmitch: no doubt ;)
<tepsipakki> it only breaks usability somewhat
<bryce> throw automounter into the mix there too
<ajmitch> tepsipakki: tickets expiring?
<bryce> ajmitch: well, even just troubleshooting why you don't get the auth in the first place can be hard to figure out
<bryce> nfsv4 error messages can be rather esoteric
<ajmitch> true, but I imagine that a kerberos ticket expiring when you need it for $HOME could make your day awkward
<sladen> cjwatson_: the jidgo format /is/ described somewhere---it's a list of literal data and checksums
<tepsipakki> ajmitch: yep
<sladen> cjwatson_: the checksums are MD5sum but not in the standard hex format (no no, NIH is so much better)
<sladen> cjwatson_: never mind it was scroll-locked from a couple of days ago
<tepsipakki> ajmitch: gnome-screensaver can handle refreshing the ticket, if pam_krb5 is set up, but gconfd/gnome-settings-daemon can get confused when $HOME is not accessible
* ajmitch also uses krb5-auth-dialog to help refresh tickets
* Mithrandir just uses the screensaver for that
<maswan> ajmitch: it's mostly browsers that break, I have a "find .mozilla -name '*lock* |xargs rm" handy for when firefox crashes.
<ajmitch> how evil
<maswan> I have my $HOME in afs at work
<maswan> oh, and I've recently had cause to run gaim for a jabber conference thingie, and that keeps silently hanging every other night
<maswan> if someone else gets hit by this, i guess we should start submitting bugs then. :)
<ajmitch> of course :)
* \sh is really stupid...
<ajmitch> what broke?
<ajmitch> bad server change?
<\sh> ajmitch: still my vmware prob..tested with  1.0.0 and 1.0.2 same shit different version
<ajmitch> ah
* ajmitch pulls out the laptop to test it on
<\sh> /usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libpng12.so.0/libpng12.so.0: no version information available (required by /usr/lib/libcairo.so.2)
<\sh> is the error...and I don't find anyway to stop that .. VMWARE_USE_SHIPPED_GTK=force vmware doesn't work either...it just doesn't start up
<\sh> does anyone know if a intel dual core t2050 supports x86_64?
<ajmitch> hm, no headers for the running kernel on the laptpo
<\sh> ajmitch: you need vmware-any-any-update109.tar.gz
<ajmitch> no, I need to upgrade & reboot into the released feisty kernel
<ajmitch> still running -13
<\sh> and those people from intel removed the specs for intel core duo t2050 somehow..
<Treenaks> \sh: they seem to have removed all Core (1) Duo stuff.. I can only find core 2 duo things
<mastroDani> hi. I have some question on the libata for ata disk you used from edgy in ubuntu. ( https://wiki.ubuntu.com/LibAtaForAtaDisks ) i would like to know why you choosen to use this, what are the advantage? do you know it's not possible to tweak the disk setting with hdparm anymore? i'm a bit concerned on security of the system too.. if you choosen to do a think like this MUST be a good reason, and i want to know w
<mastroDani> hat this good reason is.. thanks
<SoftIce> where is the best place to find out what development or better yet why no development for vserver has been intergrated into ubuntu fesity?
<SoftIce> #ubuntu people don't know shit
<elkbuntu> insulting people will not get answers
<Hobbsee> SoftIce: think about it.  it's probably not done because someone hasnt done it.  why dont you be that someone?
* lifeless prefers Hobbsee' answer
<Hobbsee> lifeless: *grin*
<SoftIce> elkbuntu was its fscking frustrating seeking help and nobody can answer you
<SoftIce> and I have no problem building an ubuntu server kernel for vserver, i just wanted answers
<SoftIce> was/well
<elkbuntu> SoftIce, it is still not an excuse to insult people. We have a code of conduct in this community and it'd be nice if you could respect it
<Hobbsee> SoftIce: if you'd actually looked, you would have seen that there are 1300 or so people in that channel - if yours is a corner case question, it probably wont get answered.
<SoftIce> Hobbsee: i've spent numerous amounts of time helping people in that channel, I feel its only fair that I get some answers.
<SoftIce> otherwise, what is the point of that saying, you scratch my back I...
<Hobbsee> SoftIce: think about it - it's more likely that people didnt know, because you were asking about something not-well-known, rather than you being ignored
<lifeless> so
<SoftIce> ok, sorry. i'm in the wrong.. 
<SoftIce> just frustrated.. sorry once again
<Hobbsee> did you check google?
<\sh> Xen packages are in the archives...vserver is a special case which isn't touched actively for ubuntu afaik...
<mastroDani> hi. I have some question on the libata for ata disk you used from edgy in ubuntu. ( https://wiki.ubuntu.com/LibAtaForAtaDisks ) i would like to know why you choosen to use this, what are the advantage? do you know it's not possible to tweak the disk setting with hdparm anymore? i'm a bit concerned on security of the system too.. if you choosen to do a think like this MUST be a good reason, and i want to know w
<mastroDani> hat this good reason is.. thanks
<mpt> mastroDani, you may well have better luck getting an answer to that question by posting to the ubuntu-devel-discuss@ mailing list
<mastroDani> mpt, i know.. but i already follow a lot of mailing list.. can't stand another one
<james_w> mastroDani: there is a Rationale section in the page that you linked to.
<mdke> mastroDani: you can try using a web frontend to the mailing list to avoid subscribing. Try news.gmane.org
<mastroDani> if somebody can adress me to the guy that taken the decision i will contact him directly
<ion_> I havent really studied the actual reasons behind the move to libata, but id assume it is to get a common interface for all block devices. Yes, hdparm can be used. I dont see any security implications.
<mastroDani> mdke, tnx for the advice...
<mastroDani> i've not much time... but i will
<mastroDani> ion_, hdparm can't be used, i've tried it
<mastroDani> ion_, it say something like: this kind of action isn't supported by the device type
<james_w> mastroDani: have you tried sdparm?
<mastroDani> james_w, as for i know sdparm is a read-only tool for now
<mastroDani> that's why i think that the decision to use or not libata should be left to the user..
<mastroDani> this means having 2 different kernel to choose from "with" and "without" libata
<ion_> mastrodani: Whats the action youre trying to do with hdparm? Just retrieve values, or set something specific?
<mastroDani> ion_, setting some specifick, optimized one, for my disk
<ion_> mastrodani: Have you made a bug report?
<mastroDani> before edgy i have a setting on /etc/hdparm.conf on /dev/hda ... not it's useless.. i've tried setting the same to /dev/sda without the same result
<mastroDani> ion_, no.. this is a decision taken a while ago, so i think that a "bug report" it's not the best thing.. i want to talk to the guy(s) that taken this decision before, to understand why
<ion_> libata is the way to go, period. If theres a regression with some (perhaps rarely used) feature, its a bug but not a reason to stay with the worse solution forever.
<mastroDani> james_w, you see.. the rationale section on that link say it is simplier to use only one system... my objection is this: we pay on performance for keeping things simplier to the developers (how much simplier? not much i think)
<ion_> we pay on performance seems to be somewhat unfounded statement.
<mastroDani> ion_, i think libata it's not ready for this, when it will be completely "as if" you are not using it then it will be ready
<mastroDani> ion_, i can't use hdparm anymore, so i pay on performance
<ion_> mastrodani: Have you filed a bug report?
<mastroDani> ion_, as i told you before, i want to talk to the guy that token this decision before filing a bug
<ogra> there is no such guy
<ogra> file a bug
<mastroDani> ogra, ok...
<mastroDani> i think that it will be ignored but i will
<Amaranth> mastroDani: So don't make the bug 'revert the change to libata'
<ogra> mastroDani, specs are never decided by a single person .... its a week of discussion in the group of developers that goes before that 
<Amaranth> Your specific problem is that a specific hdparm option doesn't work anymore
<Amaranth> that's what the bug report should say
<ogra> the rationale is pretty clear stated in the spec wikipage btw
<ogra> the old implementation will go away ... 
<Amaranth> Using one subsystem for all storage devices makes things much simpler
<ogra> that as well
<Amaranth> And yeah, this would happen eventually anyway because upstream is doing it
<mastroDani> phone
<mastroDani> Amaranth, i don't see this "simplier".. ones a disk as been recognized and mounted you can use it in the same way, IDE o SCSI doesn't matter anymore
<mastroDani> Amaranth, anyway tnx.. i will file this bug
<Amaranth> mastroDani: Less duplication of code
<Amaranth> mastroDani: Instead of having similar code for every type of storage device they all share a common base
<ogra> less duplication f maintenance tools ;)
<jmg>  OMFG SLAYER!!!!!!!!!!!!!!!!!!!!!!!!!
<Amaranth> and common bug fixes :)
<ogra> as you can see with hdparm 
<jmg> oopz.... wrong chan 
<mastroDani> Amaranth, i see your point of view, but i always think that is more important the final result than the this
<mastroDani> ogra, it's right.. but in this case: FIRST wait that sdparm is ready to do anything hdparm can do.. and than change it
<mastroDani> not before
<Amaranth> It's impossible to have zero regressions unless you stop coding completely
<Amaranth> I'm willing to accept short-term regressions in functionality for long-term benefits
<ogra> mastroDani, well, instead of having the problem in gutsy because upstream made the switch you have it now ...
<mastroDani> well guys.. thanks for your time and goodbye
<mdke> hmm. I go away on holiday, come back and find that nautilus has gone away on holiday too and taken my desktop with it
<StevenK> Heh
* mdke checks to see if there was a late nautilus upload before feisty released
<Hobbsee> mdke: you didnt *really* want nautilus and your desktop, did you?
<mdke> Hobbsee: no, no. I'm just being picky
<Hobbsee> heh
<mdke> ah, the classic rm -rf ~/.nautilus has done the trick
<cjwatson> mdke: I've replied again on the hash thing. I'm sorry but that is desperately, desperately bogus.
<cjwatson> straightforward instructions for checking MD5SUMS.gpg would be infinitely better than people trusting hashes published on a wiki page
* cjwatson -> out
<mdke> cjwatson: ok thanks; but it was the solution elmo recommended
<cjwatson> I'll talk to elmo, it's hideously wrrong
<mdke> cjwatson: digging out the bug now
<cjwatson> I'll see elmo in the London office on Monday
<cjwatson> https://help.ubuntu.com/community/HowToMD5SUM does not even mention gpg
<cjwatson> anyway, weekend
<mdke> cjwatson: ok! I'll leave it to you (footnote - that wiki page is only editable by me and newz)
<mdke> still your solution is better anyway
<cjwatson> ok, I hadn't realised it was an immutable page, which makes it a bit less awfl
<mdke> ;)
<mdke> still, you're right that there is nothing on that wiki to indicate to users how reliable a page is
<StevenK> mdke: That's a problem inherient to wikis.
<StevenK> mdke: Case in point, Wikipedia
<mdke> StevenK: wikipedia does a very good job of indicating how reliable its editors consider a page to be, which is much better than ours. But in this case, it's a rather different question
<StevenK> mdke: (on Wikipedia) But only to a point. How do you propose this is fixed/addressed for {help,wiki}.u.c?
<mdke> StevenK: in a similar way. The (unloved) spec is here: https://wiki.ubuntu.com/HelpWikiQualityAssurance
<StevenK> mdke: Looks sensible.
<StevenK> But being sensible doesn't help a spec get implemented. :_)
<mdke> StevenK: that's right
<mdke> needs a coder interested in documentation, or a webmaster with a bit of time on his hands. Both are quite rare beasts
<rburton> hm
<rburton> seeking keybuk
<elpargo> hi how can I get the compiler flags used to build an official ubuntu package?
<ivoks> i see you are a gentoo user :)
<ivoks> every package has debian/ subdir in its source
<ivoks> there's a rules file in which building of a package is defined
<elpargo> ivoks, yes but my gentoo box die a while ago and I haven't been able to get some time to rebuild it :(
<elpargo> ivoks, but that's in the src package right?
<ivoks> elpargo: yes
<StevenK> Could that be because it takes 3 days to install Gentoo?
<elpargo> umm ok let me go get that one
* StevenK ducks.
<elpargo> StevenK, of course specially when you need to compile X and it fails 
<elpargo> but it's worth it I will have fix this issue I had hours ago if I where in gentoo...
<ivoks> all gentoo users and doko should get them selfs a t-shirt "I compile OpenOffice, do you?"
<ivoks> :)
<bluefoxicy> openoffice.org-bin
<elpargo> as bluefoxicy says I use that bin, well actually I don't use it much but yes bin package are in the tree too
<ivoks> when i used it, i compiled everything
<bluefoxicy> I have 2 gigs of RAM and don't want to use OOo ;)
<mjr> bluefoxicy, but it's not about the memory anymore at that point :] 
<ivoks> soon i could throw my battery in trash... then i diched gentoo :)
<elpargo> ok stupid question where can I get hte src package?
<ivoks> apt-get source [name of the package] 
<elpargo> what I like about gentoo is flexibility, I almost want to format my machine when I try to delete some program I don't use and it tries to take "ubuntu-desktop" along with it
<elpargo> oh didn't knew of that switch 
<ivoks> ubuntu-desktop is matapackage for collection of programs
<elpargo> E: Unable to find a source package for vlc
<ivoks> removing it, your desktop doesn't lose anything (in short run)
<Treenaks> ivoks: well, a few files in /var/lib/dpkg/ ;)
<elpargo> ivoks, "in short run" :)
<ivoks> well, you have to enable source repositories in sources.list
<ivoks> elpargo: yes, when you dist upgrade to newer version, ubuntu-desktop could depend on some other packages
<elpargo> umm gack I just can't get into .deb they are too messy :)
<StevenK> Messy?!
<ivoks> lol
<elpargo> ivoks, I got deb-src http://archive.ubuntu.com/ubuntu/ feisty restricted
<ivoks> maybe "i don't understand", but messy... :)
<elpargo> ohh ok nm
<StevenK> elpargo: You probably want more sections than just restricted. :-)
<elpargo> StevenK, yup that's why the nm :)
<StevenK> Ah. :-)
<elpargo> yes deb package are messy ebuild's are beautiful 
<ivoks> universe is what you need for vlc
<StevenK> But ebuilds are just a shell script. They don't contain either source or binaries.
<ivoks> you can't compase deb and ebuild; totaly diferent things
<StevenK> And what ivoks said.
<ivoks> compare
<elpargo> StevenK, not really with the patches dir and such, I was refering to the emerge system for example all the "helper" eclass,etc. 
<elpargo> StevenK, ivoks starting with the 10 or so files you need for a deb src package 
<ivoks> right; those files define much more than ebuild
<elpargo> ivoks, like?
<elpargo> today is my lucky day Failed to fetch http://do.archive.ubuntu.com/ubuntu/pool/universe/v/vlc/vlc_0.8.6-svn20061012.debian-1ubuntu1.dsc  Could not open file vlc_0.8.6-svn20061012.debian-1ubuntu1.dsc - open (13 Permission denied) [IP: 91.189.88.40 80] 
<elpargo> F
<ivoks> descriptions, dependecies, debconf rules, package relations, conffiles, ond source can contain multiple packages, can contain maintaners own binaries (like pixmaps), patches, etc...
<ivoks> sorry, wasn't here for a moment...
<ivoks> elpargo: opens for me
<elpargo> ivoks, don't know how long ago you used ebuilds but all that is in the ebuild file, except debconf :)
<ivoks> and package relations
<ivoks> and conffiles
<elpargo> well the patches are in a special dir and referenced 
<ivoks> and patches..
<ivoks> :D
<elpargo> package relations are calculated by the engine, all you need to say is who you need as usual 
<elpargo> +USE flags which noone else has
<ivoks> right...
<elpargo> all my problems will be solve with media-video/vlc python in /etc/package.use :)
<elpargo> is this what you where refering to http://archive.ubuntu.com/ubuntu/pool/universe/v/vlc/vlc_0.8.6.release-0ubuntu4.dsc I see no build flags there
<ivoks> no, this is a description file
<elpargo> ok the debsrc is downloading now 
<elpargo> <stupidquestion>where r src package installed?</stupidquestion>
<elpargo> huh pwd?? why?
<ivoks> it's not installed
<ivoks> it's downloaded
<elpargo> yes that I notice still weird
<ivoks> different, not weird
<ivoks> someone likes red, someone blue; they aren't weird, altough we all know black is the best :D
<jdong> don't be a poet.
<jdong> you'd be good rhyming competition to emily dickinson.
<bhale> black is the best.
<ivoks> i wasn't trying to be a poest :)
<ivoks> poet
<elpargo> :) is there such a think as a "ubuntu deb developer guide"?
<elpargo> something ala http://devmanual.gentoo.org/
<sharms> elpargo: tons.
<sharms> elpargo: first, your source for all answers + information is at wiki.ubuntu.com
<sharms> elpargo: you get this search free though, http://doc.ubuntu.com/ubuntu/packagingguide/
<`23meg> elpargo, there's the debian new maintainer's guide
<elpargo> sharms, is there any canonical source? ubuntu always has tons of stuff half of it is useless (no offence)
<sharms> elpargo: that is the source, and everyone who works on Ubuntu uses it as a reference. 
<`23meg> https://wiki.ubuntu.com/UbuntuDevelopment
<elpargo> thanks `23meg sharms 
<sharms> elpargo: if you do find a link that is "totally useless", msg me personally
<elpargo> sharms, http://ubuntuforums.org/ :)
<elpargo> anything related to getting vlc or mplayer working in firefox 
<sharms> elpargo: we were on the subject of development documentation.  You are referring to issues that are #ubuntu solvable.
<elpargo> sharms, yes that was a joke 
<jdong> "a distro compiled for i386 costs majorly in speed, in ways that show up in normal desktop use."
<jdong> looks like a digg user commented on slashdot :D
<poningru> rofl
<salty-horse> hi. I think the signatures on libnm-glib-dev in feisty are out of date. i can't authenticate it :/
<codeyman> After I build a package with dpkg -b, where is it saved?
<bhale> one level above the source tree
<bhale> eg ..
<codeyman> sridhar@pico:~/Desktop$ sudo dpkg -b  helix-player-1.0.8/
<codeyman> dpkg-deb: building package `mozilla-helix-player' in `helix-player-1.0.8/.deb'.
<codeyman> I cant find the deb package now :(
<bhale> find /home/codeyman -name "*.deb"
<bhale> ?
<bhale> dpkg-buildpackage puts the debs one level above the source tree
<bhale> and is probably what you want rather than dpkg -b
<codeyman> oh k..
<bhale> 'dpkg-buildpackages -rfakeroot' in the unpacked source
<codeyman> there is a .deb in the directory
<bhale> well there it is :)
<codeyman> gee.. thanks... ".deb "  i hope dpkg -i .deb should take care of the rest??
<bhale> dpkg -i /path/to/my.deb ... sure
<nixternal> http://www.ubuntu.com/getubuntu/releasenotes/704tour
<nixternal> the network manager info, someone just told me that it doesn't look like that on their machine
* nixternal don't know since I use KDE
<mr_pouit> nixternal: it looks like that here (gnome) :|
<grayman> well
<grayman> it don't look like that if you don't have wireless
<grayman> you got wired network and then goes "manual configuration"
<grayman> that's about it
<Lutin> Mithrandir: around ?
<Mithrandir> Lutin: now I am
#ubuntu-devel 2007-04-22
<sharms> should I file a bug report?  When girlfriend reboots computer during upgrade from feisty -> edgy then computer = fubar
<sharms> err rather edgy -> feisty
<Fujitsu> !doesn't work | sharms 
<ubotu> sharms: Doesn't work is a strong statement. Does it sit on the couch all day? Does it want more money? Is it on IRC all the time? Please be specific! Examples of what doesn't work tend to help too.
<sharms> Fujitsu: no no I used "fubar"
<Fujitsu> !fubar
<ubotu> Sorry, I don't know anything about fubar - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<Fujitsu> Damn.
<sharms> :) 
<Paul^> hi
<thepumpkin1979_> hi. what is the *.h file to search packages like synaptic?
<thepumpkin1979_> which header could i use to download packages?
<Hobbsee> thepumpkin1979_: #ubuntu for support, see the /topic
<Burgundavia> Hobbsee: that really isn't a support question
<Burgundavia> thepumpkin1979_: honestly, I would try the devel-discuss mailing list
<Hobbsee> Burgundavia: true.  didnt think anyone was here
<thepumpkin1979_> this is ubuntu-devel... is not for developers?
<Hobbsee> i presume you'd have to look in the synaptic source for it
<Hobbsee> or the apt source
<thepumpkin1979_> I see, sorry.
<Burgundavia> thepumpkin1979_: it si really quiet, as the main devs are away, due to just having a release and needing a break
<thepumpkin1979_> Hobbsee: i want to query ubuntu repositories to download some dependencies.
<Hobbsee> and it's a sunday
<Burgundavia> that too
<thepumpkin1979_> I understand:)
<thepumpkin1979_> Here, is 10:47 AM Saturday:)
<Burgundavia> what language are you writing this in
<Burgundavia> ?
<thepumpkin1979_> *PM
<thepumpkin1979_> I'm using C#+Mono.
<Hobbsee> thepumpkin1979_: hi from sydney, you must be in WA
<thepumpkin1979_> Hobbsee: hi from Venezuela.
<StevenK> Hobbsee: *Saturday*
<Hobbsee> ah, missed it
* Hobbsee cant read
<StevenK> Heh
<grayman> wow, some noise here
<thepumpkin1979_> Well... let me understand: this is the right place to ask but here are not developers right now?
<thepumpkin1979_> :)
<grayman> well
<grayman> not -main- devs
<StevenK> No, it isn't the right place to ask, this channel is about the development of Ubuntu.
<grayman> after release vacation
<thepumpkin1979_> :P
<thepumpkin1979_> ok. no more question... mmm... just one more: which channel is ok to ask?
<thepumpkin1979_> :P
<Hobbsee> ubuntu-devel-discuss ML - see lists.ubuntu.com
<Hobbsee> i think
<thepumpkin1979_> thanks Hobbsee.
<thepumpkin1979_> Enjoy your vacations and Congratulations for Feisty. Is amazing:P
<Hobbsee> i've had a thought for command-not-found
<Hobbsee> why does it only say "you can use sudo apt get install foo" to install it - why not say "do you want to install the package foo, which provides this functionality?" and if the user answers y or something, call apt to do it
<Hobbsee> (if they have sudo access)
<grayman> eh
<grayman> only if you got a way to disable that
<grayman> it might get annoying
<Burgundavia> Hobbsee: I like it just fine right now
<Burgundavia> it is not disruptive
<grayman> yeah
<thepumpkin1979_> well Hobbsee, you are right, i can do that but i want to know how query repositories using C:P
<thepumpkin1979_> Thanks:)
<Hobbsee> Burgundavia: true that
<StevenK> thepumpkin1979_: Install libapt-pkg-dev, look in there, and please stop asking.,
<Hobbsee> grayman: oh of course.  it's just done half the work already, i'm surprised it doesnt prompt
<thepumpkin1979_> StevenK: :|
<grayman> well, it's not a surprise. It can cause a lot of errors
<grayman> from user side
<grayman> so yes, i prefer it the way it is now
<Hobbsee> true
<`23meg> Hobbsee, any feedback on the "Contributing to Gutsy" guide in the forum?
<Hobbsee> `23meg: that'd require me looking, adn i've seen enough forum crack for today
<Hobbsee> `23meg: but, Fujitsu made an excellent post on one of the other threads :)
<`23meg> here: http://ubuntuforums.org/showthread.php?t=411868
<Hobbsee> looking now
<`23meg> i'll search for that post
<Hobbsee> `23meg: http://ubuntuforums.org/showthread.php?t=413733 sums it up quite well :)
<`23meg> yes, read that one
<Hobbsee> `23meg: what concerns me with that spec writing guide is that there's a) no mention that anyone can implement a spec, not just the "ubuntu devs" and b) that the spec process is a wand waving excercise, with the inference of "if i've gone to all the trouble of filing a spec in the right way, then it should be implemented.  because it hasnt for this release, or at all, OMG UBUNTU SUCKS!!!!!!!!!!!!!!!!!!!!eleventyone!!!
<`23meg>  Hobbsee, that's been on my mind, rest assured
<Hobbsee> `23meg: upstream version freeze means bugfixes - when it hits major freezes, beta freezes and such, only critical bugs will be fixed
<`23meg> we'll post a separate guide on writing specs, probably on monday when it gets finished
<`23meg> and that will include both your points clearly
<Hobbsee> `23meg: i'd also point out hte url for searching for bugs by a specific source package - and smacking them with the cluebat over using the search.  there's no need to file 60 dupes of the same thing.
<Hobbsee> it's often easier to search if you know the source package
<Hobbsee> `23meg: it looks good - very good
<`23meg> thank you
<Hobbsee> wouldnt mind yoinking some of it and sticking it on the wiki :P
<`23meg> that would be good
<jml> Hobbsee: could Launchpad get better at directing people to the right package?
<`23meg> i'm replacing UVS with beta freeze 
<`23meg> *UVF
<Hobbsee> `23meg: make sure you have the schedule link in there - then get people to look at what each of the freezes are on teh wiki
<Hobbsee> jml: i wish.  probably.  file  a wishlist bug on malone
<Hobbsee> well doesnt need to be wishlist.  just a bug on malone
<`23meg> hmm, ok
<jml> Hobbsee: right. I was going to suggest that :)
<Hobbsee> seeing as UVF is important too
* Hobbsee --> lunch.  back in an hour or so
<`23meg> i have the schedule link; will add freezes
<Burgundavia> `23meg: one key thing is that features are basically already decided by the end of the UDS
<`23meg> is this not clear? let me see; I thought it would be obvious
<ajmitch> and keep in mind that many specs just can't be discussed at UDS
<Burgundavia> `23meg: it was a general comment, not based on what the forums says
<`23meg> ajmitch, i'll emphasize that in the spec guide i'll post soon
<Burgundavia> basically, I see a lot of people suggesting ideas really late in the feature cycle
<`23meg> Burgundavia, the forum ambassadors team is trying to amend exactly that
<`23meg> we're trying to get people to submit specs until UDS, and helping them do so
<Hobbsee> `23meg: back
* fabbione yawns
<Hobbsee> morning fabbione!
<fabbione> hey Hobbsee 
<Hobbsee> :)
<`23meg> Hobbsee, I've made some edits to the guide
<Omar> hello
<Omar> can we can an official copy of ubuntu for " lebanese faculty of engineering "
<Burgundavia> hello Omar
<Burgundavia> you can download an official copy
<Burgundavia> see http://www.ubuntu.com/getubuntu
<Burgundavia> and this really isn't support, so if you need more help, please use #ubuntu
<Omar> i'm now downloading it from universite de Nante
<Omar> i joined that channel but i can't send to channel !
<Hobbsee> `23meg: looking
<Burgundavia> Hobbsee: linky?
<Hobbsee> Burgundavia: http://ubuntuforums.org/showthread.php?t=411868
<Hobbsee> still doesnt say about that hte forums people can implement them, etc
<Burgundavia> `23meg: link to the ubuntu specific spec page at https://blueprints.launchpad.net/ubuntu/
<`23meg> Hobbsee, I'll backport that statement from the "feasibility guide" in a day or two :)
<Hobbsee> :)
<sharms> Does anyone know if there has been an effort to port over fedora's system-config-display applet to ubuntu?
<Burgundavia> sharms: it needs to be rewritten for xrandr1.2
<Burgundavia> I belive the fedora people are doing that
<Burgundavia> however, I did play with it in the Hoary cycle
<sharms> I was thinking of either doing it or putting a bounty on it
<`23meg> Burgundavia, done, thanks 
<Burgundavia> sharms: there is a gnome soc about a config tool and I belive fedora is working on rewriting it
<Fujitsu> randr 1.2 should make that sort of thing much, much easier.
<sharms> any idea if it would make it into gutsy?  One goal I need to remedy is co-workers telling me Ubuntu doesn't support dual head configuration
<Burgundavia> http://code.google.com/soc/gnome/appinfo.html?csaid=F9CE6F874146B221
<sharms> Burgundavia: thanks for the information
<Burgundavia> sharms: no worries
<Draconicus> brb
<jk-> hi
<ion_> Hi
<shawarma> Is the automatic apport retracer thingie running these days?
<Kmos> shawarma: you must ask pitti
<Kmos> tomorrow :)
<shawarma> It appears so. :-/
<ogra> hrm ... nfsroot on nfs4 seems not to be such a good idea :/
<jk-> full of connection-oriented goodness
<ogra> well, it needs user accounts ... which i dont have in initramfs ...
<delire> having read several forums this fine sunday morning it seems like the three primary problems this release are screen resolution issues with proprietary ATI drivers (or not working at all but working in 6.10), network-manager playing up with realtek cards and showstopper drive boot mapping in grub. 
<Mithrandir> ogra: nfsroot on nfs4 works just fine for other people.
<mjr> I should really get around to reporting my (lesser) problems...
<delire> otherwise it seems the hit rate is quite high compared to last release. seems like Envy and Automatix (unfortunately) are saving the day quite often.
<ogra> Mithrandir, how ? klibc has no nfs4 support at all yet ... i'm trying with util-linux's mount here wich needs idmapd and something to map against
<ogra> it mounts apparently, but only as nobody
<Mithrandir> ogra: yes, and that should be enough to get you started.
<ogra> which then gets all the tmpfs mounts in ltsp wrong ...
<bhale> delire: pontificating is probably best for the forums and osnews. if someone has bugs they would be better served following up on launchpad
<Mithrandir> sounds like an LTSP bug, then, since it works fine for other people.
<ogra> well / is mounted by nobody ... and apparently all actions on the fs are executed as nobody as well ...
<ogra> my prob is that he idmapd i can run in initramfs isnt able to map against anything ...
<ogra> apart from that i havent found any hints that anybody ever implemented nfsroot with nfs4
<Mithrandir> I know people who have.
<ogra> i know there are plans t add support for it to nfsmount of klibc ... 
<ogra> but thats still more an idea than anything else 
<ogra> Mithrandir, do you know any docs for the initramfs side ?
<delire> bhale: good morning. the bugs are flowing.
<bhale> delire: great, thansk
<bhale> not much more frustrating than "bugs" reported on forums
<Mithrandir> ogra: I don't think he ever documented what he did, BICBW.
<ogra> well, google agrees :)
<ogra> he probably used kerberos ... which i dont want ....
<delire> i wonder whether for future releases it might be sane to write an application that greps lspci output looking for what are known to be cards that require manual driver installation (binary only drivers available) and couple it with devices that were known not to work OOTB and dynamically generate a HTML document of links to HOWTOs and fix trajectories for the user. this would then be put on their desktop post install.
<tepsipakki> delire: every card should work with vesa, and if it doesn't then it's a bug (like 89853)
<tepsipakki> we already have those mappings (discover-data)
<tepsipakki> and vesa is used as a fallback
<delire> tepsipakki: agreed, toward an unbreakable X, but this doesn't assist people getting up and running with problem wireless cards or issues with the piix driver, etc.
<delire> new users simply don't have a clue where to start, or what's really wrong. some handholding in the form of a fix path could be good.
<delire> s/path/guide
<delire> just a thought anyway.
<tepsipakki> oh, I thought you were talking about display cards
<jk-> would be good to have the database being distro-independent
<jk-> to save having five+ copies of the same thing..
<delire> yes, good thought. 
<jk-> and the possibility to provide more specific instructions for a distro, if they exist..
<delire> even work with leenooks.com
<ion_> restricted-manager already shows what restricted drivers support the hardware the user has.
<delire> yes this is a good start, but people don't even know that restricted driver manager is actually there!
<tepsipakki> discover is from debian
<tepsipakki> so all the derivates have it
<delire> i must have pointed 50 people to restricted-manager in #ubuntu the last day or so.
<delire> (half of them had already broken things by following old documentation..)
<delire> i guess the point is to give them a document "congratulations you've just installed ubuntu. we notice you've got these devices on your machine, known to be problematic in Linux. are they working properly? if not here's what you can do to get them up and running.." etc
<jk-> and a 'send an email to the manufacturer of this device' button :D
<delire> hehe nice.
<delire> i think a 'Hardware Helper' could be a good addition to Ubuntu, especially for those users who've just installed Ubuntu on a machine with hardware only supported by binary drivers, don't know what a 'restricted driver' is, where to find restricted-manager or have any clue as to why their hardware doesn't work. 
<delire> so, where would i write up such a project if i were interested in starting it/developing it for a future release?
<Hobbsee> delire: file a spec?
<Hobbsee> on launchpad
<Hobbsee> not sure of the exact url
<pochu> https://blueprints.launchpad.net/ubuntu/+addspec
<pochu> delire: ^
<Mithrandir> hiya Sarah
<delire> Hobbsee: pochu cheers
<Hobbsee> hey Mithrandir :)
<ogra> hmm, seems getpwnam doesnt work in initramfs  ... i wonder why ...
<Treenaks> ogra: </sarcasm>
<ogra> Treenaks, ??
<Treenaks> ogra: well. initramfs = always root, right?
<Treenaks> (and there's no /etc/passwd..)
<ogra> well, still, if i add /etc/passwd and friends libc should provide it
<Treenaks> (is there?)
<ogra> no, but i just added one for testing ... 
<Mithrandir> ogra: you're probably missing the nss modules.
<ion_> Yeah, and/or nsswitch.conf
<sivang> hi all
<Hobbsee> sivang!!!
* sivang hugs Hobbsee :)
* Hobbsee hugs sivang! :D
<Hobbsee> sivang: where have you *been*?
<sivang> yeah, yeah , it's not over *yet* !
<Hobbsee> hm?
<sivang> Hobbsee: mostly been caught up with bills paying job, some personal issues etc ;)
<Hobbsee> sivang: ahhh...
<sivang> Hobbsee: I don't know why I said the first sentence - just felt nice to say it :-p
<Hobbsee> ahh ;)
<AaronMT> So which is the best IDE for C/C++ under Ubuntu?
<Hobbsee> vi.  kate.  maybe emacs
<Hobbsee> kdevelop's nice
<Hobbsee> AaronMT: and #ubuntu for support, btw
<AaronMT> Might be a longshot getting VS2005 under wine
<Hobbsee> quite likely.  the question is why you would
<Hobbsee> you can just use g++ for compiling
<cjwatson_> Riddell: bug 108969 is the second package other than ubiquity that's had a KDE frontend direct all its bug reports to ubiquity. I'm getting fed up with this. Can I be sure it won't happen again?
<ubotu> Malone bug 108969 in update-manager "update-manager's KDE frontend directs bug reports to ubiquity" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108969
<ogra> hmm, i really dont get why our nfs server defaults to rsize and wsize values of 131072 
<Treenaks> 128k?
<ogra> yep
<danohuiginn> ogra: for bug 85452 is it enough to just fix the docs? Or should the missing options be added to the program?
<ubotu> Malone bug 85452 in hwdb-client "hwdb-send man page arguments are not valid" [Low,Confirmed]  https://launchpad.net/bugs/85452
<ogra> either is fine
<danohuiginn> ogra: OK,thanks. I'll fix the manpages in that case
<ogra> hwdb-send should probably just move out of /usr7bin so it doesnt need a manpage
<ogra> */usr/bin
<danohuiginn> hmmm....in that case, I'd best leave it to somebody who knows the package
<Artemis3> Sorry if i'm bothering, proposed Edgy package: update-manager 0.45.3 doesn't show the update to 7.04 button anymore, is this intentional? downgrading to 0.45.2 still shows the button.
<Lutin> Mithrandir: can you reject the allegrogl package from NEW ? it's an error, it was an upload to REVU
<Riddell> cjwatson: SRU requested.  it won't happen again if only because apport will be used in future.  sorry about that
<triceratops> Any hint how files in /lib/modules/2.6.20-15-lowlatency/volatile/ are created (esp. fglrx.ko). Due to dpkg-query it seems they don't belong to a package.
<desrt> is there meal allowance for UDS seville?
<ph1zzle> hey guys
<ph1zzle> ... n gals
<ph1zzle> I have a non ubuntu development style question but I still think this room may be the best place to ask...
<grayman> Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu)
<ph1zzle> I am trying to compile some software and it complains about two libs I have installed being too low a version, the libs (libofa from musicip and libmusicbrainz from musicbrainz) I compiled myself and I know are the newest versions and this problem seems to occur on both dapper and feisty, is there a package that I don't have installed or something I may be doing wrong that would cause this?
* ph1zzle read the topic but I still think you guys probably know this better then just about anyone else
<ph1zzle> so I am basically pleading for your help
<grayman> wel hm, not sure. Try the motu channel
<ph1zzle> motu?
<desrt> masters of the universe
<shawarma> ph1zzle: #ubuntu-motu
<ph1zzle> ok, thank you
* ph1zzle wonders if there is also a ubuntu masters of the multiverse channel
<ph1zzle> ;)
<geser> MOTUs also care for multiverse
<ph1zzle> lol, alright
<pygi> siretart: you around? I want some instructions :)
<siretart> pygi: hi
<siretart> pygi: what's up?
<pygi> siretart: you free or shall we talk later? :)
<siretart> pygi: let's try now
<ajmitch> morning
<pygi> siretart: kk, pm
<pygi> ajmitch: morning
<AaronMT> So which is the best IDE for C/C++ under Ubuntu?
<cjwatson_> Riddell: thanks
<pygi> AaronMT: please #ubuntu
<grayman> heh
<grayman> bug 109064 should be confirmed i think
<ubotu> Malone bug 109064 in ubuntu-meta "Boot-up option 'Start or install Ubuntu' scares new users" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109064
#ubuntu-devel 2008-04-14
<jscinoz> hmm
<jscinoz> are there an man-page editors? doing this manually is getting annoying >_<
<RAOF> jscinoz: I've used docbook to man in the past, that wasn't too painful.
<jscinoz> thanks
<jscinoz> ill get it for future use, ended up doing these two manually >_<
<jscinoz> hmm
<jscinoz> I'm currently packaging for debian with the goal of getting my packages synced back to ubuntu for Intrepid, once my packages are in debian, what needs to be done to have them synced and ready for release with 8.10?
<StevenK> jscinoz: Do the packages currently have Ubuntu changes?
<jscinoz> nope, this is the first time they've been packaged for a distro
<StevenK> jscinoz: Then they will get pulled in automatically when Intrepid opens
<jscinoz> ah nice
<saivann> Does someone knows what package should provide /etc/libuser.conf ? system-config-samba does not start because that file does not exist, even after installing libuser (bug #214959)
<ubotu> Launchpad bug 214959 in system-config-samba "system-config-samba.py fails to start due to missing /etc/libuser.conf after apt-get installation" [Medium,Confirmed] https://launchpad.net/bugs/214959
<saivann> Nevermind, this is libuser1 in gutsy, but I don't know why the file is not installed in Hardy
<hyperair> does anybody know if bug #185854 will be fixed in ubuntu hardy's release?
<ubotu> Launchpad bug 185854 in gnome-system-tools "Setting static IP in Network Settings doesn't produce correct data" [High,Confirmed] https://launchpad.net/bugs/185854
<hyperair> as of now the sys->admin>network configuration is broken as it misses out "auto <iface>" in /etc/network/interfaces
<hyperair> it seems it was declined for hardy by Pedro Villavicencioquite quite some time earlier.
<hyperair> before the patch and debdiff were created
<dholbach> good morning
<hyperair> morning
<hyperair> would you happen to know anything about Bug #185854
<hyperair> the one where sys/admin/network is broken and "auto <iface>" is always missing from /etc/network/interfaces
<dholbach> hyperair: I just asked somebody to take a look at it
<hyperair> ah
<hyperair> i noticed
<hyperair> thanks
<pitti> asac: hi (re translations ping)
<pitti> Good morning
<warp10> Good morning
<pitti> hey warp10
<warp10> heya pitti
<emgent> morning
<fabbione> morning guys
<pitti> hey fabbione! how are things?
<fabbione> pitti: hey dude.. pretty good thanks
<fabbione> you?
<pitti> fabbione: arrived back home safely, and I'm mostly over the jetlag
<fabbione> pitti: from where/to where? :) i have no idea where have you been :)
<pitti> fabbione: in Austin, Texas, for https://www.linux-foundation.org/events/collaboration
<fabbione> oh yeah you mentioned that sorry
<fabbione> i totally forgot
<fabbione> pitti: was it good?
<pitti> fabbione: yes, indeed it was; we got a lot of things actually done in our workgroup discussions (driver backports)
<fabbione> nice
<ether_c> er.. so if this isn't the channel for application development ON ubuntu, what is?
<RAOF> ether_c: That depends on the application :).
<RAOF> ether_c: There's nothing special about developing on Ubuntu, basically.
<ether_c> I know.. it's just linux
<ether_c> supposedly
<ether_c> so I'm trying to learn how to use Xlibs
<ether_c> I installed the xorg-dev stuff
<ether_c> I included the Xlib.h library
<ether_c> my program has basically one line
<ether_c> display = XOpenDisplay(0);
<ether_c> and I get "undefined reference to XOpenDisplay"
<RAOF> ether_c: So, you're probably not linking to libX11.  Also, what part of "not for application development on Ubuntu" is not clear :)
<RAOF> ether_c: You probably want #xorg, or at least they'd be able to point you in the right direction.
<ether_c> oh, I just read the channel title
<ether_c> "Development of Ubuntu (not support, not application development on Ubuntu)"
<crevette> ubuntu-devel is related to developement projects around ubuntu (packaging, blueprint,...)
<mdke> gdm has gone all big on me. I can't see the box to change my language, it's way off the bottom of the screen
<mdke> is there any workaround?
<mdke> (bugs 214704)
<ubotu> Launchpad bug 214704 in gdm "GDM login screen too wide" [Undecided,Confirmed] https://launchpad.net/bugs/214704
<pitti> Riddell, ogra: I just added b43-fwcutter to ubuntu's ship+ship-live; you might consider doing the same?
<pitti> Keybuk: there?
<pitti> Keybuk: I think http://gitweb.freedesktop.org/?p=hal-info.git;a=blob_plain;hb=HEAD;f=fdi/information/10freedesktop/10-usb-music-players.fdi should work alright, can you please confirm this? the fix looks small and logical
<pitti> ^ or anyone else with an USB music player which is currently broken under Hardy
<seb128> hey pitti
<pitti> bonjour seb128
<asac> pitti: we have a suboptimal situation. the first ffox update will introduce string changes ... and mozilla doesn't allow us to ship a glorified nightly of RC1.
<pitti> seb128: btw, camera f-spot auto-opening is still broken :/
<Hobbsee> asac: ack.
<pitti> seb128: as a fallback we could always enalbe it in g-v-m again
<asac> Hobbsee: ack what?
<asac> :)
<seb128> pitti: yeah, that's one of the few desktop bugs milestoned
<asac> suboptimal?
<Hobbsee> asac: not that kind of ack.
<seb128> pitti: did you try to debug it?
<pitti> asac: ugh
<Hobbsee> asac: ack as in "oh no"
<pitti> seb128: no, just noticed it yesterday when downloading my Austin photos
<pitti> seb128: btw, does f-spot crash/hang for you as well when you try to close it?
<seb128> pitti: yes
<asac> pitti: so i ask you .... can we roll a lang update in sync with the first RC ... or can we bury the "translations in global langpacks" idea?
<seb128> pitti: bug #199496
<ubotu> Launchpad bug 199496 in gtk-sharp2 "Tomboy.exe crashed with SIGSEGV in exit()" [High,Confirmed] https://launchpad.net/bugs/199496
<pitti> asac: we'll do post-release langpack updates anyway
<seb128> pitti: 165 duplicates
<pitti> asac: so as long as the only effect is "shows English strings" as opposed to "firefox crashes", that seems like a reasonable approach to me
<asac> pitti: yes, this one is difference though. we have two options if we want to guarantee that users end up with a broken UI:
<pitti> seb128: wow
<pitti> asac: :) (for guaranteeing broken UIs we have a lot more options)
<asac> pitti: 1. we make a tight maxVersion in the install.rdf of the language packs
<pitti> hey cjwatson
<asac> pitti: 2. we make tight dependencies on xulrunner-1.9 and firefox ...
<asac> pitti: i guess option 2 is not an option, right?
<pitti> asac: erm, dependencies in the langpacks?
<pitti> no, that's not an option
<pitti> we don't want to force people to install firefox
<asac> pitti: option 1 would mean that users might have a non-translated interface until the update arrives
<davmor2> quick query I did a fresh install of Ubuntu amd 64bit with disc date 20080411 there is no tracker/deskbar and when I plug a device in mp3 player/camera there is no app autostart is this deliberate or a bug?
<asac> pitti: hmm ... we could use conflicts instead of depends ;)
<pitti> asac: if we coordinate the update properly, that shouldn't hurt too much IMHO
<asac> pitti: ok.
<asac> pitti: then lets go for it and hide ;)
<carlos> pitti, asac: I guess you already saw latest language pack with firefox translations included
<pitti> carlos: I did (since it broke langpack-o-matic :) ); for now I just ignore them, until we have a script which processes them properly
<carlos> pitti: did it?
<carlos> pitti: I thought your scripts take care of the new content
<pitti> carlos: nonstandard layout (which is goood, btw, to tell them apart properly)
<asac> pitti: ill give you that script later today.
<asac> as discussed ... installed on rookery
<carlos> I see, ok
<sabdfl> did we have a wiki issue over the weekend? is it addressed?
<Hobbsee> i think it was more than a weekend, from memory?
<davmor2> anyone quick query I did a fresh install of Ubuntu amd 64bit with disc date 20080411 there is no tracker/deskbar and when I plug a device in mp3 player/camera there is no app autostart is this deliberate or a bug?
<YokoZar> sabdfl: Yeah the issue was almost a week ago I think
<cjwatson> pitti: morning
<pitti> sabdfl: I filed an RT a few hours ago
<pitti> sabdfl: #30451 FYI
<\sh> guys, I don't know if it's only me, but did somebody tried to add a new user via system->administration->users and groups ? the user will be created, but actually is not able to login into a new gnome session....
<\sh> (hardy that is). I wonder if it's a flaw on my desktop or if it's repeatable
<emgent> uhm
 * emgent testing
<Fujitsu> \sh: I used that to add a user for the first time, 4 days ago. Worked fine.
<\sh> Fujitsu, hmm...
<emgent> yes
<emgent> work fine
<\sh> Fujitsu, well, the creation worked without problems....I wonder what is happening, that gdm tells me, that the user is not able to login via gdm...
<\sh> login in via ssh works, fine, too....just gdm failes
<emgent> work in gdm too in my hardy box
<Fujitsu> \sh: You must have restricted it in gdmsetup.
<\sh> Fujitsu, how can this happen...strange...
 * \sh has to recheck it this evening when he's back at home
<sabdfl> thanks pitti
<davmor2> mvo: ping
<mvo> davmor2: pong
<davmor2> mvo: dapper -> hardy died a death about 2/3's of the way through
<davmor2> just tracking down the bug report I did for it
<emgent> \sh: saw Bug #211350 and Bug #216813 ?
<ubotu> Launchpad bug 211350 in lighttpd "Lighttpd install changes directory permissions (Ubuntu Gutsy)" [Undecided,New] https://launchpad.net/bugs/211350
<ubotu> Launchpad bug 216813 in lighttpd "Lighttpd enables a login shell for user www-data" [Undecided,New] https://launchpad.net/bugs/216813
<davmor2> mvo: bug 216326 I uploaded the relevant logs for you
<ubotu> Launchpad bug 216326 in ubuntu "Dapper -> Hardy upgrade = Fail" [Undecided,New] https://launchpad.net/bugs/216326
<emgent> www-data:x:33:33:www-data:/var/www:/bin/sh
<emgent> uhm..
<mvo> davmor2: thanks, that log looks good. could you also please attach /var/log/dist-upgrade/apt-term.log ?
<cjwatson> mvo: I don't understand that log. It seems to be a file overwrite in xkeyboard-config/xkb-data, but xkb-data seems to have the proper Replaces
<mvo> cjwatson: yeha, I need to see the terminal log to get a better idea about it
<\sh> ember, yay...+1 for adduser ,->
<\sh> grmpf
<\sh> emgent, bug #211350 is a won't fix, because standard user/group for webserver  is www-data:www-data...self changed defaults can't be our problem...or actually we find a small fix which determines the used user/group and forget about chowning those files
<ubotu> Launchpad bug 211350 in lighttpd "Lighttpd install changes directory permissions (Ubuntu Gutsy)" [Undecided,New] https://launchpad.net/bugs/211350
<\sh> emgent, regarding the /bin/sh to www-data ...
<\sh> emgent, I wonder if this is actually a lighty error, or a general bug somewhere
<\sh> emgent, cause I have the same with apache somehow
<\sh> emgent, at least all system accounts have /bin/sh :(
<emgent> yes i saw now
<emgent> :|
<\sh> guys, what triggers the creation of new users (e.g. www-data/proxy/uucp etc.) and sets by default a /bin/sh shell for non-human-accounts?
<Fujitsu> \sh: Wouldn't that be adduser being called in the postinst?
<Fujitsu> I thought it should default to /bin/false...
<\sh> Fujitsu, If I would find adduser,useradd somewhere in apache2-*/debian/ or whatever
<Fujitsu> At least --system is meant to.
<Fujitsu> Ah.
<\sh> Fujitsu, yes...but proxy/uucp/list/news/irc/gnats/fetchmail all those accounts have /bin/sh
<\sh> even lp
<\sh> mail
<emgent> ok people, i go away. see you later quickly.
<\sh> etc.
<Amaranth> that seems broken
<\sh> bin and sys too :)
<Fujitsu> They're created initially... not by the packages.
<\sh> grmpf
<Fujitsu> Everything created by postinsts is correctly /bin/false.
<\sh> from shadow package or passwd?
<Fujitsu> But those must be in a template somewhere.
<Fujitsu> One of them.
<Fujitsu> base-passwd seems to be i.
<Fujitsu> *it
<\sh> uh yeah
<Fujitsu> william@irranat:~/MOTUing/base-passwd-3.5.16$ grep www-data passwd.master
<Fujitsu> www-data:*:33:33:www-data:/var/www:/bin/sh
<\sh> passwd.master in base-passwd is /bin/sh default
<\sh> cjwatson, any reason for /bin/sh instead of /bin/false or something else in passwd.master? :)
<laga> yay. suspend to ram works in hardy, suspend to disk works in hardy, it doesn't crash anymore when i close the lid.. now i like my hp 6510b even better. thanks :)
<\sh> Fujitsu, anyways...I'm closing bug #216813 and reopen one for base-passwd
<ubotu> Launchpad bug 216813 in lighttpd "Lighttpd enables a login shell for user www-data" [Undecided,New] https://launchpad.net/bugs/216813
<emgent> back
<cjwatson> \sh: there are a couple of Debian bugs about it; it does need to be changed to /bin/false eventually, but I want to be extremely careful not to break anything and I need to debconfise base-passwd first otherwise it'll cause terminal prompts. Please don't change it in Ubuntu.
<\sh> cjwatson, na...I don't want to change anything until a reliable solution is in place :) bug #216813 is for the reminder :)
<ubotu> Launchpad bug 216813 in base-passwd "Lighttpd enables a login shell for user www-data" [Medium,Confirmed] https://launchpad.net/bugs/216813
<cjwatson> I want to make sure that somebody doesn't do a trigger-happy upload and break the world
<\sh> cjwatson, /me <- no main rights...and I don't change those stuff after hard freeze :)
<cjwatson> \sh: maintainer scripts at least used to use su to execute stuff as other users in various places; changing the shell to false will break anything that does that
<\sh> cjwatson, well, regarding www-data e.g. this is an account which is set as chown parameter but I don't know any app which runs or execute scripts as www-data...I think we need to verify those settings and changing them when there is no need for /bin/sh by default
<\sh> cyrus user is e.g. a different issue...
<\sh> but this user is set when installing the package actually
<\sh> (scripts == maintainer scripts ;))
<cjwatson> there certainly used to be maintainer scripts that dropped to some of the other users in passwd.master that ought to be /bin/false
<cjwatson> whether www-data specifically is one such user is not my immediate concern
<MacSlow> I keep getting "svn: error while loading shared libraries: /usr/lib/libsvn_wc-1.so.1: unsupported version 0 of Verneed record" for some days now... I've no clue what's causing this or what a "verneed record" is. Anybody with some ideas?
<\sh> cjwatson, something for the next release :)
<emgent> :)
<pitti> cjwatson: do you have an opinion about bug 211357? should we have IPv6 addresses by default in /etc/hosts?
<ubotu> Launchpad bug 211357 in netbase "No IPv6 addresses in default /etc/hosts" [Medium,In progress] https://launchpad.net/bugs/211357
<creAtion> MacSlow: How is the facebrowser going?
<MacSlow> very slow as I'm mostly battleing with my nvidia-card, the driver, svn (see above) and compiz
<Amaranth> aww, don't fight compiz
<Amaranth> you have no chance of winning :P
<creAtion> MacSlow: I remember seeing a video or screens about it a while ago and it looked pretty cool
<MacSlow> Amaranth, it's more the nvidia-driver than compiz I think... it's working on intel :)
<creAtion> MacSlow: is it something that might be in Ibiz?
<MacSlow> creAtion, mockups of what I attempt to achive
<Amaranth> intrepid, you mean?
<creAtion> yeah :P
<MacSlow> Amaranth, right now on nvidia I cannot start compiz via normal UI-tools
<MacSlow> (read: avoiding the command-line)
<creAtion> MacSlow: what ever happened to the object groupings thing you were working on e.g. moving photos around in groups etc
<\sh> emgent, regarding bug #211350 if there is a simple solution to determine the user:group of the directories which the user changed, we can use it in postinst and change it to his/her user/group..but if it's not (easily) possible, -> won't fix, cause www-data:www-data is distri default
<ubotu> Launchpad bug 211350 in lighttpd "Lighttpd install changes directory permissions (Ubuntu Gutsy)" [Undecided,New] https://launchpad.net/bugs/211350
<Amaranth> MacSlow: I blame your code and/or the nvidia driver :)
 * Amaranth runs
<MacSlow> creAtion, lowfat... collecting dust as I don't find time to continue working on it :/
<MacSlow> Amaranth, no... I'm not talking about any of my code.
<MacSlow> just normal operation
<ogra> pitti, ogra@osiris:~$ apt-cache rdepends ubuntu-desktop|grep edu
<ogra>   edubuntu-desktop
<ogra> pitti, no more sh and ship-live for me, only addon :)
<creAtion> MacSlow: lowfat that's right ... interesting concept
<ogra> s/sh/ship/
<pitti> ogra: ah, I keep forgetting
<MacSlow> creAtion, thanks
<ogra> pitti, thanks for the ping though :)
<tseliot> MacSlow: what's the model of your graphic card?
<cjwatson> pitti: that's odd, it's supposed to be there
<emgent> \sh: I suspected it :)
<cjwatson> pitti: how was the install in question done?
<pitti> cjwatson: ok; if it's supposed to be there, I'll look at it
<pitti> cjwatson: it's from mvo's upgrade tester
<cjwatson> pitti: I know, but what underlying installer does it use?
<MacSlow> tseliot, tried GeForce 7900GT and 8800GTS... same issues
<pitti> mvo: ^ see cjwatson's question?
<mvo> cjwatson: the uprade tester uses the jeos-builder
<cjwatson> both netcfg and ubiquity add those IPv6 entries automatically
<cjwatson> then I claim a
<cjwatson> jeos-builder bug
<tseliot> ï»¿MacSlow: what's the output of compiz?
<cjwatson> s/automatically/unconditionally/
<pitti> hm, my box is a reasonably fresh install
<mvo> I can check it out later
<pitti> and I have the entries, too
<pitti> mvo: so it might be an artifact from the upgrade tester itself?
<cjwatson> it is
<cjwatson> like I say, jeos-builder bug
<pitti> cjwatson: ok, thank you
<\sh> emgent, I trust you, set the bug to whatever you think is ok :)
<MacSlow> tseliot, "Error: Could not acquire compositing manager selection on screen 0 display :0.0", which is odd because it used to work and there's hardly any change I did to my system... it cretainly worked with compiz 0.7.x
<emgent> \sh: hehehe :)
<YokoZar> pitti: Could you upload a new version of ia32-libs for me that adds ï»¿libasound2-plugins (bug ï»¿#182731) ?
<YokoZar> pitti: going through the debdiff/freeze exception process at this point would be difficult for ia32-libs :(
<\sh> YokoZar, I think a spoken "yes, please do" from motu-release is enough ... motu-release can add the acks afterwards to the papers
<pitti> YokoZar: please get approval from motu-release for that, though
<pitti> YokoZar: right, debdiff is pretty pointless for ia32-libs
<tseliot> ï»¿MacSlow: can you try the solution suggested here? http://ubuntuforums.org/showthread.php?p=4691222
<seb128> mr_pouit: bug-buddy displays wrong libexec paths, just for information
<mr_pouit> seb128: ah, ok, thanks.
<tseliot> ï»¿ï»¿MacSlow: did you get my last message before you disconnected?
<MacSlow> tseliot, that hint was helpful... odd that the metacity-compositor was enabled here
<tseliot> ï»¿MacSlow: at least it's not a bug in Compiz ;)
<munckfish> cjwatson: got a mo?
<cjwatson> munckfish: yep
<munckfish> cjwatson: sorry, I'm at work at the mo, I can look at kboot at lunch
<munckfish> did you guys get any further idea what was going wrong?
<cjwatson> my mails have the most recent information I have
<cjwatson> Adam's in .au so probably hasn't seen them yet
<cjwatson> err, no he's not, he's in .ca, sorry
<cjwatson> but still
<Keybuk> mvo: so, err, how did we manage to get two files owning the same conffile?
<Keybuk> two packages, I should say
<munckfish> cjwatson: ok understood
<munckfish> cjwatson: I think we need to agree some sort of goal for this first Hardy release
<munckfish> at the moment I'm guessing it would be get X working
<munckfish> and no more
<munckfish> I looked at the PS3 specific stuff in the repo
<munckfish> I think most of it could be done with back ports
<munckfish> what do you think?
<munckfish> If we can't get X fixed, or if we discover some other complete show stopper
<munckfish> would should we do then?
<munckfish> delay PS3 on Hardy?
<munckfish> or just not release it at all?
<cjwatson> munckfish: not release it, and defer to 8.04.1
<cjwatson> munckfish: this is a *nuclear option* and a bad idea
<munckfish> cjwatson: I don't understand that sorry
<munckfish> nuclear option?
<cjwatson> last resort
<munckfish> yes it would be a big shame
<cjwatson> I agree that the best plan is to concentrate on what is absolutely required; don't worry about fripperies
<munckfish> what about the back ports situ though?
<cjwatson> forget about it for now
<munckfish> right fare enough
<munckfish> *fair
<cjwatson> later, maybe, but it's not worth the distraction of considering it
<munckfish> hmmm spelling
<munckfish> yep
<munckfish> ok
<munckfish> well the X null pointer I have
<munckfish> didn't get time to grab the trace
<munckfish> but from what I remember
<munckfish> it was in the some function called
<munckfish> selectDriver or chooseDriver or similar
<munckfish> I have the X log
<munckfish> I'll open a LP report at lunchtime
<munckfish> ps3fb did seem to be loaded in the kernel ok as far as I could see
<\sh> you are talking about PS3 as in "sony" ? :)
<munckfish> \sh: yes
<\sh> munckfish, sounds like I need to convince my future wife to buy such a gadget then ;)
<munckfish> \sh: it's a very very cool device
<munckfish> I have a supercomputer in my lounge!
<\sh> :))
<munckfish> Our port project needs some care and attention though
<munckfish> \sh: if you get one jump on ubuntu-cell@lists.ubuntu.com to follow progress
<\sh> munckfish, hmm...but still usable as "playstation"? or is it then my next generation build server/webserver? :)
<munckfish> no still usable for games
<munckfish> the only compromise is
<munckfish> you can ever have 10GB for linux and the rest for sony
<munckfish> or vice versa
<munckfish> s/ever/only/
<munckfish> and with only 256MB of RAM, I guess we could do some optimisation at some point along the way
<munckfish> but the cell chip is cool, I can't wait to start exploring it's potential. Which is something I think the guys on #ps3dev are already quite far ahead on
<munckfish> some of those guys are working on some interesting projects
<mvo> Keybuk: I have no idea, I was wondering that too
<ogra> hmm, do we have any xubuntu devs here apart from cody-sommerville ?
 * ogra just discovered they might need some extra preseeding for ltsp on the cd to make it use universe packages ...
<Keybuk> mvo: we just need to find another impossible thing, then we can dine at Millways
<Keybuk> Q for the channel; does anyone running hardy *not* have two answers for: grep rcS-sulogin /var/lib/dpkg/info/*.conffiles ?
<Ng> I see one
<laga> Keybuk: one answer
<seb128> Keybuk:
<seb128> $ grep rcS-sulogin /var/lib/dpkg/info/*.conffiles
<seb128> /var/lib/dpkg/info/upstart-compat-sysv.conffiles:/etc/event.d/rcS-sulogin
<seb128> $
<Ng> upstart-compat-sysv
<ion_> Ditto
<Keybuk> Ng, seb128, laga, ion_: do you have friendly-recovery installed?
<Ng> yes
<seb128> yes
<\sh> yes
<Keybuk> Ng, seb128, laga, ion_: can you nopaste grep -e friendly-recovery -e upstart-compat-sysv /var/log/dpkg.log
<laga> Keybuk: yes.
<ion_> Huh, i don't have it installed, even though ubuntu-standard recommends it.
<laga> http://www.pastebin.ca/984563
<\sh> Keybuk, http://paste.ubuntu.com/6985/
<Keybuk> \sh: one answer or two?
 * Fujitsu has just one too.
<\sh> Keybuk, one...
<Ng> Keybuk: http://pastebin.com/f7f06fbe5
<Keybuk> laga: ok, you have f-r bzr installed, you upgrade to compat-sysv 0.3.9-2, then friendly-recovery 0.1, then compat-sysv 0.3.9-2
<Keybuk> \sh: you have the same
<Keybuk> Ng: likewise
<Keybuk> elmo: don't suppose you can run the same grep?
<Keybuk> mvo: do you see one or two results on your machine?
<cjwatson> Keybuk: one answer here, http://paste.ubuntu.com/6987/
<ion_> keybuk: http://pastebin.com/f4aaf2546 Just installed friendly-recovery, the grep for rcS-sulogin still prints one entry.
<Keybuk> just to prove I'm not going nuts:
<mvo> Keybuk: just one
<Keybuk> quest scott% grep rcS-sulogin /var/lib/dpkg/info/*.conffiles
<Keybuk> /var/lib/dpkg/info/friendly-recovery.conffiles:/etc/event.d/rcS-sulogin
<Keybuk> /var/lib/dpkg/info/upstart-compat-sysv.conffiles:/etc/event.d/rcS-sulogin
<Chipzz> Keybuk: just read your post on upstart couple of days ago... was wondering (but maybe this will be covered in a next post) if upstart also supports actions like 'reload'?
<Keybuk> Chipzz: not yet
<Chipzz> Keybuk: planned?
<Keybuk> Chipzz: considered
<Chipzz> Keybuk: would be *really* needed for apache I think
<Chipzz> s/I think/imho/
<Keybuk> cjwatson: you have the same sequence again
<Keybuk> ftr, I see f-r bzr installed, then compat-sysv 0.3.9-**1**, then f-r upgraded to bzr
<Keybuk> if I upgrade compat-sysv now, I get a conffile prompt
<Keybuk> as did elmo
<Chipzz> not having reload for apache would mean significantly longer delays + downtime when adding a site in apache
<Chipzz> well, you can use apache2-ctrl, but...
<Chipzz> that's ugly imho
<ogra> cody-somerville, hey
<cody-somerville> Hey ogasawara__
<cody-somerville> erm
<cody-somerville> Hey ogra
<ogra> cody-somerville, coud you take a look at the last three comments on bug 214481 ?
<ubotu> Launchpad bug 214481 in ltsp "[hardy] ltsp-build-client builds incomplete filesystem" [Undecided,Fix released] https://launchpad.net/bugs/214481
<ogra> (not sure you still build ltsp on the alternate iso)
<cody-somerville> ogra, certainly
<Keybuk> ok, so channel-wide question -- does anyone else have *two* answers for grep rcS-sulogin /var/lib/dpkg/info/*.conffiles
<ogra> Keybuk, nope, but i'm only up to date with yesterday (no upgrades today yet)
<Keybuk> ogra: I'm briefly theorising that it may be people who did a gutsy->hardy upgrade who have two
<Keybuk> and people who followed who only have one
<Keybuk> or it could simply be that people who have upstart 0.3.9-2 only have one
<ogra> well, that laptop was installed last thursday
<\sh> Keybuk, my amd64 is a gutsy -> hardy install .... but from early stages...
<ogra> indeed with hardy directly
<Ng> Keybuk: I have a PC at home which did gutsy->hardy and I haven't updated it for weeks, it has two matches for the grep
<\sh> Keybuk, and the machine has only one answer to your grep
<Keybuk> Ng: it has friendly-recovery bzr and upstart 0.3.9-1 installed?
<Ng> Keybuk: yes
<Keybuk> Ng: at least that's consistent then
<\sh> Keybuk, so something went wrong between december and now ,-) (in december I upgraded to hardy)
<Ng> I've not updated that machine since the end of february though
<Keybuk> Ng: updating in the last few days seems to "resolve" the problem
<Fujitsu> I reinstalled with Hardy beta, and have but one match.
<Keybuk> but may give you a conffile prompt in the process
<Fujitsu> I last upgraded last night.
<Ng> Keybuk: I'm entirely happy to try that if you want?
<Keybuk> Ng: not just yet, I'd like to capture lots of dpkg debug output in the process
<\sh> Keybuk, but no f-r installed that is
<Keybuk> so let me simulate in vmware first
<Ng> Keybuk: sure
<Mirv> mvo: could you perhaps put the fix for bug 216211 in, since the upstream translation was again broken when 0.7.4 was made?
<ubotu> Launchpad bug 216211 in compizconfig-settings-manager "ccsm Finnish translation broken again" [Undecided,New] https://launchpad.net/bugs/216211
<lamont> Keybuk: gutsy upgraded machine, 0.3.9-2, one copy. OTOH, still no ck-session-daemon
<Mirv> there's a debdiff and .dsc (at PPA)
<mvo> Mirv: thanks, does it have approval of the universe release team yet? IIRC its required to get a exception at this stage
<Keybuk> mvo: oh, and I'm still getting that compiz-crashes-and-randomly-rearranges-workspaces bug ;-)
<Keybuk> this time on nvidia
<mvo> Keybuk: meh :/ what does the crashfile for this one look like?
<Mirv> mvo: oh, good question. I tried to ask at #ubuntu-motu yesterday but I haven't gotten a reply. any other place/way to ask? of course, there was an exception for the compiz 0.7.4 in general.
<Keybuk> mvo: no crash detected
<Keybuk> screen freezes for a second, and then when it comes back, it's all rearranged
<Keybuk> apport stays silent on the matter
<Mirv> pitti: there would be the bug 204155 which was the other i18n bug you asked me to assign you to (but I couldn't). I doubt asac has time for that.
<ubotu> Launchpad bug 204155 in network-manager-applet "Nm-editor translations not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/204155
<mvo> Keybuk: does that mean that compiz keeps on running after the freeze?
<tjaalton> Keybuk: http://bugs.opencompositing.org/show_bug.cgi?id=876 ?
<ubotu> bugs.opencompositing.org bug 876 in -Unknown "windows change the workspace" [Normal,Unconfirmed]
<Keybuk> mvo: I'm not sure, let me find out next time it happens
<Keybuk> just tried to run compiz under gdb
<Keybuk> that doesn't work so well
<Keybuk> ;-)
<Keybuk> tjaalton: no, not that
<Keybuk> all of my windows move
<Keybuk> all to different workspaces
 * ogra pokes vbox ... damned thing, stop messing with my brightness settings ... grr
<tjaalton> Keybuk: ok, I think they are related though.. the freeze and all
<mvo> Keybuk: no :) only via ssh from a different machine
<Mirv> (ok, now subscribe motu-release to the ccsm bug, too)
<asac> Mirv: please commit to bzr branch in case you update nm-XXX
<asac> :)
<Mirv> asac: ok, I can do that.
<ogra> asac, bug 185854, wasnt NM supposed to take over the bring up/tear down part for all interfaces now ?
<ubotu> Launchpad bug 185854 in gnome-system-tools "Setting static IP in Network Settings doesn't produce correct data" [High,Confirmed] https://launchpad.net/bugs/185854
<davmor2_away> ogra: whose the best person to speak to about LTSP?
<ogra> davmor2_away, me
<cody-somerville> davmor2_away, ogra was the one that asked me :P
<ogra> heh
<davmor2> oh
<ogra> davmor2, you need to adjust the preseed value for ltsp-client-builder/build-client-opts
<ogra> currently thats set to "--mirror file:///cdrom --security-mirror none --skipimage"
<ogra> you need "--mirror file:///cdrom --security-mirror none --skipimage --components main,universe"
<davmor2> ogra: I'll hand it over to stgraber he know more about it than me.
<ogra> i'm just checking if i can apply a more general solution
<asac> ogra: no
<ogra> (inside ltsp ... so that preseed change wouldnt be required)
<asac> ogra: same constrains as in gutsy
<ogra> asac, ah, k then i misunderstood ...
<asac> ogra: 0.7 was supposed to be the answer :)
<ogra> was probably 0.7 we talked about :)
<asac> but that doesn't exist ;)
<ogra> snap
<asac> right!
<munckfish> cjwatson: I have a little time now, can we chat again about the kboot build fail
<cjwatson> munckfish: sure
<munckfish> ok
<munckfish> So
<munckfish> q1: uclibc
<munckfish> do you still want to use glibc?
<cjwatson> like I say, disregard the comment in my first mail. Whatever can be made to work in time.
<munckfish> Ok, this is what I was wondering
<munckfish> what of your first email should
<munckfish> be disregarded
<munckfish> I guess the answer is all of it then?
<cjwatson> everything :-) I was under the wrong impression about where things were failing
<munckfish> ok fine fine
<cjwatson> the fact that it builds successfully on davis indicates that the source package isn't completely screwed
<munckfish> ok so all we can do is wait for adam c
<cjwatson> or employ more guesswork :-)
<munckfish> ok I'll scan the build log while I'm eating anyway
<cjwatson> seems to be something building either a 32-bit or a 64-bit object when it should be building the other
<munckfish> right
<cjwatson> which suggests maybe something in the kernel build looking at the current machine type, that isn't being overridden properly?
<munckfish> I'm afraid I didn't look too deeply into the cross compilation stuff, cause after I removed the referecnes to the redhat cross compiler it built ok and run ok
<cjwatson> yeah, I'd missed that patch when I sent my first mail
<munckfish> I'll double check the way the kboot Makefile handles cross comp
<munckfish> I think the way I did it was probably cheating anyway
<munckfish> cause there was some logic in there
<munckfish> to decide based on the host system architecture
<munckfish> I just set CROSS_* variables to ""
<Mirv> asac: ok, added a bazaar branch in the bug 204155 for the fix
<ubotu> Launchpad bug 204155 in network-manager-applet "Nm-editor translations not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/204155
<asac> Mirv: did you verify that its fixed?
<asac> Mirv: ok now i see. why was it filed against applet?
<Mirv> asac: yep, compiled with the modified debian directory with dpkg-buildpackage, and the translations were there
<asac> oh ;)
<asac> sorry ... ETOOMUCHTODO
<asac> :)
<asac> Mirv: will do a break and then do this merge stuff
<asac> Mirv: i have a tarball with finishe translation for xulrunner and firefox
<Mirv> asac: :) thanks, and hopefuly you will get some rest in.. less than two weeks
<asac> Mirv: can you please install those and go through the broken accesskeys and fix those in launchpad?
<asac> Mirv: i would love to to whitelist finish translation for launchpad export
<Mirv> asac: ok, I can install those. I was wondering about the access keys translations.
<asac> Mirv: yeah you will see :)
<asac> Mirv: http://people.ubuntu.com/~asac/translations.tar.gz
<asac> there should be a fi.tar.gz in
<asac> its a complete file system so you need to extract it in /
<asac> and then restart firefox
<asac> it should be translated
<Mirv> asac: whee, it works. and aaagh, I'll start fixing the access keys now :)
<asac> Mirv: you understand how that goes?
<asac> Mirv: if you want to do that accurately you can install the upstream .xpi and see how they are mapped
<asac> Mirv: anyway. as long as all accesskeys have a matching letter in the word it hsould be fine (of course ther emight be clashes with other accesskeys in the same context/menu)
<Mirv> asac: yes, in general, and I think I can manage it with these. I can give you a note when Finnish (fi) is fixed in Rosetta (both firefox and xulrunner)
<asac> Mirv: if you know other translation folks that would like to be whitelisted for hardy, maybe point them tot the translation thing
<Mirv> asac: ok, I'll note on #ubuntu-translators
<asac> Mirv: yes, when i have a free minute ill blog how you can produce your own langpacks ... so translators can test
<asac> Mirv: for now give me the updated .po file for xulrunner and firefox and i will recreate the tarball for you
<Mirv> asac: ok.
<asac> Mirv: but at best go through all accesskeys and check if they have a matchin letter
<Mirv> asac: yes
<asac> Mirv: rock
 * cjwatson eyes the mailing list spam filter, having hit 'd' 185 times on the ubuntu-devel-announce moderation queue
<munckfish> cjwatson: I'm trying to compare the architecture details of these systems we're compiling on
<munckfish> cjwatson: do you think you could run this (http://paste.ubuntu-nl.org/63178/) on
<munckfish> davis?
<munckfish> the buildd (adare)?
<ogra> infinity, ping ?
<munckfish> cjwatson: is your PS3 handy? Could you run it on that too? If not I'll get the details on mine tonight
<cjwatson> munckfish: I don't have shell access to the buildds
<munckfish> cjwatson: I thought as much
<munckfish> how can we most easily get this info do you think?
<cjwatson> munckfish: needs Adam, like I said
<munckfish> Ok I see
<cjwatson> munckfish: http://paste.ubuntu.com/6991/
<munckfish> he's the buildd admin is he?
<cjwatson> yes
<munckfish> cjwatson: thx for davis info
<Mirv> mvo: ok the bug 216211 now has ack in the bug report from motu release
<ubotu> Launchpad bug 216211 in compizconfig-settings-manager "ccsm Finnish translation broken again" [Undecided,New] https://launchpad.net/bugs/216211
<jdong> mvo: btw, too late for Hardy, but what do you think about dist-upgrader being more aggressive about non-Ubuntu packages for next release cycle?
<jdong> mvo: when I upgraded over the weekend some stale non-ABI compatible self-made lib packages from Gutsy caused everything GTK to segfault...
<jdong> and pinning hardy to 9999 and removing all local/obsoletes fixed it
<jdong> that might not be a terrible idea to suggest to the user in an upgrade, or offer as a safety mechanism users can choose later on (i.e. "remove all non-Ubuntu packages")
<Mirv> asac: ok, firefox + xulrunner / Finnish should be fixed now in Rosetta. I downloaded the PO files from Rosetta and now that I received them, uploaded them at http://users.tkk.fi/~tajyrink/firefox_xulrunner_fi/
<asac> Mirv: ok thanks
<asac> let me check
<Hobbsee> jdong: mutter, mutter, prevu and crack?
<jdong> Hobbsee: yeah some of it is just aggressive personal backporting but it's not out of the question for the "average user" to have some non-Ubuntu-origin installed packages.
<Hobbsee> and to use trevhino...
<jdong> Hobbsee: and we already disable 3rd party sources, it's not much of a stretch to force "downgrade" to hardy and remove local/obsolete packages afterwards
<jdong> for that matter, /usr/local/lib could be evil too
<Hobbsee> jdong: that's what i was actually going to look at, somewhere along the line.  it seems i got sidetracked for hardy.
<asac> Mirv: http://people.ubuntu.com/~asac/fi.tar.gz
<jdong> Hobbsee: in the meantime, how about we set up a wiki page describing a procedure to force this downgrade manually before starting the upgrader?
<Hobbsee> jdong: i don't intend to get stuck supporting user-made crack, sorry :)
 * Hobbsee has enough to deal with, with work and freenode mess as it is.
<jdong> Hobbsee: would you yell at me if I wrote such a wiki page? :)
<Hobbsee> no
 * jdong puts an item on his TODO list
<Hobbsee> pitti: looks like you may want to read the riot act (kde-guidance)
<Mirv> asac: works great! all the menus etc. I can see are now as it should be for fi. it's great to see Firefox properly localized!
<Riddell> Hobbsee: hmm?
<Hobbsee> Riddell: kde-guidance changelog
<asac> Mirv: cool
<asac> thanks
<asac> will whitelist fi then :)
<Mirv> asac: thanks a lot!
<Hobbsee> Riddell: oh, so the patch is actually different now, and doesn't come from andreas, but actually comes from ScottK instead?
<JohnPhys> Are there plans to include the fix to bug #195052 in hardy, even though hardy is now in final freeze?
<ubotu> Launchpad bug 195052 in inkscape "Latex formula does not work on Ubuntu Hardy" [Undecided,Fix released] https://launchpad.net/bugs/195052
<Riddell> Hobbsee: it's different yes
<Hobbsee> Riddell: various of us must have misread the changelog (0ubuntu15) that said the patch had been changed, not just readded.
<Keybuk> cjwatson: got a moment?
<cjwatson> Keybuk: yep
<Keybuk> so, dpkg
<Keybuk> is package A contains a file, and package B contains a file
<Keybuk> if you try and install package B, that should fail due to a conflict
<Keybuk> right?
<Keybuk> (file with same name)
<munckfish> cjwatson: I have to get back to work now. But I did find this http://www-128.ibm.com/developerworks/forums/thread.jspa?threadID=193337
<cjwatson> Keybuk: I'd have thunk so ...
<munckfish> The guy has a 64 bit object, but the linker is 32 bit
<Keybuk> ok
<Keybuk> now if package A contains a conffile, and package B contains a conffile with the same name
<Keybuk> and you try and install package B
<Keybuk> should that not fail also?
<munckfish> cjwatson: I have no idea what the problem is yet
<cjwatson> Keybuk: I'd have thought it would fail even harder. That said I'm not sure of the semantics of Replaces+conffiles
<munckfish> I just need more time
<cjwatson> munckfish: right, the question is why
<Keybuk> cjwatson: right
<Keybuk> except it doesn't
<munckfish> cjwatson: yes, right
<Keybuk> what I'm seeing here is simple
<Keybuk> upstart-compat-sysv.conffiles has rcS-sulogin
<Keybuk> friendly-recovery.conffiles *also* has rcS-sulogin
<Keybuk> installing friendly-recovery succeeds without warning
<Keybuk> it does *not* Replace upstart-compat-sysv
<Keybuk> dpkg simply allows it
<Keybuk> so you end up with a conffile changing ownership (and two packages claiming it in their .conffiles)
<Keybuk> now, both have upgrades
<Keybuk> friendly-recovery's upgrade removes the conffile again
<Keybuk> upstart's upgrade changes the conffile
<Keybuk> depending which order you do this upgrade, you will either get
<Keybuk> a) status quo, upstart owns its conffile and content is correct
<Keybuk> b) conffile prompt
<mvo> Keybuk: it might be even funnier, I think I have seen a file overwrite error under certain situations for this conffile (see bug #205911)
<ubotu> Launchpad bug 205911 in friendly-recovery "friendly-recover (ubuntu-standard) conflicts with upstart-compat-sysv (ubuntu-minimal)" [Medium,Fix released] https://launchpad.net/bugs/205911
<cjwatson> Keybuk: that's very unpleasant :-/
<ogra> asac, did you notice there is a flash .115 that came out on th weekend ?
<jdong> ogra: .115? you mean .124?
 * jdong feels out of context
<ogra> jdong, no, 125 :)
<ogra> thanks for the heads up :)
<jdong> ogra: there's ANOTHER new flash?
<jdong> sheesh!
<laga> it must be incredibly hard for adobe to post the change logs where i can find them
<ogra> heh
<ogra> http://justin.everett-church.com/index.php/2008/03/10/preparing-for-flash-player-9-april-2008-security-update/
<ogra> he's talking about 115 btw ..
<pitti> Mirv: I can have a look, but it won't be high priority
<pitti> Mirv: I opened a ffox tab for it for now
<asac> ogra: yet another flash updated. darn
<ogra> asac, http://www.adobe.com/devnet/flashplayer/articles/flash_player9_security_update.html and the restrictions dont really look good
<pitti> Hobbsee: kde-guidance> what's up with it now?
<ogra> asac, apparently it will break wit flash7 content
<asac> ogra: great.
<asac> thats really good news
<asac> is that official or a regrssion?
<ogra> well, i dont have any clue about flash content
<tjaalton> I've got a new xorg pkg ready for upload.. fixes vmmouse handling and an upgrade issue (dapper -> hardy)
<ogra> asac, from teh announcement: "You have SWFs that are exported for Flash Player 7 (SWF7) or earlier that communicate with the hosting HTML by any means"
<asac> ogra: would give gnash a new high if they really stop supporting flash 7 - but i can't believe they do :)
<ogra> might be a corner case, not sure
<pitti> Mirv: oh, that already has a patch? great; yes, if asac is ok with it, I can sponsor that
<Hobbsee> pitti: just saw the newest changelog entry
<pitti> Hobbsee: this time it was done right, I hope :)
<ogra> asac, see the bulletpoints on the last link i posted
 * pitti dist-upgrades and runs the jockey test suite, just to double-check
<asac> Mirv: whats this about?
<asac> pitti: ?
<asac> if i acked in the bug then its certainly ok :)
<asac> ogra: yeah ... i took a quick look. have no time for such amusement right now :(
<pitti> asac: applying the 'set gettext domain' fix in bug 204155
<ubotu> Launchpad bug 204155 in network-manager-applet "Nm-editor translations not loaded" [Undecided,Confirmed] https://launchpad.net/bugs/204155
<asac> ah yeah ... please push the branch to -core-dev if yo do that
<asac> otherwise go ahead
<asac> i would do it in next free minute
<pitti> asac: I'll do it a bit later, too; first I need to fix a time bomb, maybe with seb128's help
<asac> hehe :)
<asac> bryce: did you read what i wrote yesterday?
<pitti> Hobbsee: jockey is happy with guidance 0.8.0svn20080103-0ubuntu15
<asac> about XaaNoOffscreenPixmaps?
<Hobbsee> pitti: nice
<seb128> pitti: what?
<pitti> seb128: gnome bug 15430
<seb128> too small number ;-)
<pitti> argh, sorry
<pitti> freedesktop bug 15430
<ubotu> Freedesktop bug 15430 in GLib "ABI break if compiled against a recent libdbus" [Critical,Assigned] http://bugzilla.freedesktop.org/show_bug.cgi?id=15430
<pitti> seb128: I will reproduce the problem now and verify the fix
<pitti> seb128: and after that hand you a package for testing, if that's fine (just to make triple-sure)
<seb128> ah ok
<pitti> seb128: i. e. our current dbus-glib .debs are fine, but a mere rebuild breaks them
<pitti> (thus "time bomb")
<seb128> pitti: walters is on #ubuntu-desktop if you need to talk to him, he pinged me about that the other day to ask what dbus version has been used to do the current debian build
<seb128> pitti: ok
<tjaalton> pitti: as a member of the RT could you check http://users.tkk.fi/~tjaalton/dpkg/xorg.debdiff ? :)
<tjaalton> pitti: the changes look big, but it's basically reverting to what we had in 10ubuntu7 (now we have CorePointer set so this actually works)
<alex-weej_> seb128: trying to get to this nautilus hanging problem, you read my post about not being able to get GDB to send a SIGINT?
<pitti> tjaalton: first and third points are straightforward, of course
<pitti> tjaalton: what's the benefit of this dynamic detection instead of letting vmmouse do it, as right now?
<seb128> alex-weej_: no
<seb128> alex-weej_: that's weird
<pitti> tjaalton: s/dynamic/one-time/ of course
<alex-weej_> seb128: yeah. :/
<tjaalton> pitti: only i386&amd64 have vmmouse :)
<alex-weej_> seb128: maybe i could do it by a process of elimination, i'll try and nuke the nautilus extensions i'm using. if you can think of anything more efficient let me know!
<pitti> tjaalton: ah, point :)
<seb128> alex-weej_: which ones are installed?
<seb128> alex-weej_: I might get the issue but my disks are fast enough to not notice the 1 second gap there
<tjaalton> pitti: so ok to upload?
<alex-weej_> seb128: it's an external seagate btw, takes about 5-10 seconds to spin up
<alex-weej_> seb128: and just the stock installation + nautilus-open-terminal
<pitti> tjaalton: hm, I don't have vmmouse_detect; are you sure that this is spelt correctly? or another dependency is missing?
<pitti> tjaalton: oh, or is that only in vmware tools?
<tjaalton> pitti: it's from mdetect
<tjaalton> soren: actually, could you patch your dexconf to test this ^^
<tjaalton> or someone with a kvm setup
<pitti> tjaalton: ah, right, I have it removed, but not purged (for some reason; I never manually remove packages, just purge)
<pitti> tjaalton: the logic looks reasonably defensive, so I'm ok with it
<tjaalton> pitti: ok cool
<soren> For it to work, we need the mdetect I uploaded a few hours ago, too.
<pitti> seb128: do you have some minutes to rebuild and install http://incoming.debian.org/dbus-glib_0.74-2.dsc and test it for a bit? I'll do that on amd64 here
<seb128> pitti: sure
 * pitti hugs seb128
 * seb128 hugs pitti
<tjaalton> soren: ah right :)
<tjaalton> bbl ->
<soren> tjaalton: Under KVM, that is. VMWare does "interesting" things to make it work without my patch.
<soren> tjaalton: By "interesting" I mean "rather evil".
<jdstrand> pitti: hi!
<jdstrand> pitti: I was curious on your thoughts on dapper -> hardy cupsys upgrades wrt apparmor
<jdstrand> pitti: in https://wiki.ubuntu.com/ApparmorProfileMigration we put apparmor in complain mode for dapper -> hardy, so as not to break anything
<jdstrand> pitti: OTOH for standard desktop upgrade, there would be no problem, but I can envision potential problems for specialized cupsys servers
<pitti> jdstrand: what's the problem with the upgrade?
<pitti> jdstrand: oh, you mean if someone installed a-p on dapper and then upgrades?
<jdstrand> pitti: oh no-- nothing specific. I am thinking hypothetically
<pitti> jdstrand: did that have a different profile file name?
<pitti> jdstrand: ending up in complain mode under hardy would be bad
<jdstrand> pitti: no, I mean apparmor isn't available on dapper, so they could change the configs at will, then update to hardy and apparmor breaks their configuration
<pitti> since we dropped our derooting patch, and the profile is our only way to reasonably confine it
<pitti> jdstrand: hm; that's outside of our powers, I think
<pitti> dpkg's conffile magic should hopefully catch that
<seb128> pitti: seems to work fine on my laptop
<pitti> seb128: merci
<seb128> de rien ;-)
<jdstrand> pitti: I'm not a cups guru, but my feeling is people would need to do something really exotic with their dapper configuration for the apparmor profile to break things-- would you agree?
<pitti> jdstrand: they could have configured stuff which prevents new features (read: backends) in hardy from working properly, or at all
<pitti> jdstrand: but really, if they went that far, my gut feeling is that they should read the conffile debdiff, or dmesg for the error messages
<pitti> (or not care about the new features)
<jdstrand> jdstrand: ok.  this seemed a little bit different than the other servers that now have enforcing profiles (named, mysqld and slapd), but I at least wanted to talk about it with you. I agree, esp wrt the derooting patch, it needs to be enforcing
 * pitti chuckles while watching jdstrand talk to himself
<jdstrand> oh heh
<jdstrand> pitti: ^ :P
<pitti> 'safer printing'
<pitti> seb128: ok, that dbus-glib patch looks obviously correct to me, too
<seb128> pitti: right
<pitti> seb128: I'll sync it now, and take the bullets
<seb128> pitti: ok, I'll keep an eye on bugs and let you know if I spot something
<Keybuk> FUCK YOU HPLIP
<Keybuk> </stress release>
 * pitti hands Keybuk a piece of chocolate
 * ion_ hands Keybuk a piece of whiskey
 * Hobbsee steals the chocolate from pitti
<pitti> tsk
 * Hobbsee needs chocolate!
 * tedg hands Keybuk an HP printer, baseball bat and the instructions from Office Space
<pitti> Hobbsee: go and give Keybuk some other relaxation then, like a neck massage :)
<Hobbsee> pitti: he'd probably throw me thru the nearest window or something.
<Keybuk> tedg: it's not the printer, it's worked fine in previous ubuntu releases for ages
<Hobbsee> pitti: or decide to snap me into little pieces.
<Keybuk> it's hardy
<tedg> Anger need no rational object to take itself out on :)
<tedg> I would have to say though, in general, while I love that HP is supporting their devices under Linux, I don't like HPLIP.
<Keybuk> I'm not 100% sure it's HPLIP
<Keybuk> since I've now configured the printer to print direct
<Keybuk> there's less OMGTHESKYISFALLING in syslog, but there's still no more printing
<Hobbsee> why do you want to print anyway?
<Hobbsee> it seems like a terribly overrated idea.
<seb128> stop wasting paper!
<Hobbsee> exactly.
 * Hobbsee thinks of the next hissy fit her coworker will do, when next put with the idea that she has to use a computer, with a mouse, and grins
<Hobbsee> seb128: thanks for giving me something amusing to go to sleep to.
<infinity> ogra: Pong?
<ogra> infinity, are you the guy to ask about disabling ports of edubuntu ?
<ogra> in the supported arches we dont build alternate and desktop anymore, i noticed ports.u.c still has it
<cjwatson> surely that's a cdimage thing not ports.u.c?
<ogra> err ...
 * ogra slaps forehead
<ogra> indeed
<infinity> Yeah...
<cjwatson> just needs unlinked, I'll do that
<ogra> thanks :)
<cjwatson> cdimage carries over all images by default, so when we stop building anything somebody needs to unlink by hand
 * ogra notes for next time
<cjwatson> done, modulo mirror propagation
<thekorn> dholbach, hi, is it save to remove some bugs from my 5-a-day file,
<thekorn> or will this mess up the stats page
<dholbach> thekorn: should be safe
<thekorn> dholbach, ok, I will remove some of my entries which does not make any sense
<dholbach> thekorn: rock on :)
<dholbach> thekorn: I wanted to leave the honours to you :)
<cjwatson> infinity: did you see my mail about ps3-kboot weirdness?
<infinity> cjwatson: I'm in the process of getting my mailserver back online (latest hardy kernel seems to have asploded it), so I'll get to reading email in a few mins. :/
<cjwatson> infinity: short version is that it builds on davis but chucks link errors on the buildd
<infinity> cjwatson: linux32 madness?
<cjwatson> infinity: hmm, could be
<infinity> cjwatson: On powerpc, I invoke sbuild with "linux32 sbuild ...", so trying the davis build with linux32 would be nice.
<infinity> cjwatson: Given the 64 versus 32 linking error, I'm guessing that's the issue.
<infinity> cjwatson: If that doesn't allow you to reproduce it, let me know, and I'll delve deeper.
<cjwatson> yep, just trying it on davis now
<_MMA_> cjwatson: Thanx for the language pack preseed tweak. Works great.
<cjwatson> _MMA_: cool
<bryce> asac, sorry I was afk for the weekend
<asac> bryce: please read ;)
<asac> and upload :)
<asac> bryce: http://paste.ubuntu.com/7018/
<asac> those are the relevant bits
<bryce> thanks
<asac> bryce: i can get you more context from cairo channel if you really need to ... in short: not disabling offscreen pixmaps is indeed a very bad idea for xaa ... so we should definitly do that.
<bryce> asac, thanks I'd appreciate additional context you can dig up (so I can more deeply understand the fix)
<asac> bryce: there is nothing to understand
<asac> bryce: offscreenpixmaps need to be turned off
<asac> they are bogus ;)
<asac> bryce: read the line in the paste:
<asac> 22:11 < cworth> vlad_: Not with XAANoOffscreenPixmaps=True, there's not. That fixes  performance and  quality bugs.
<asac> bryce: you said that doing this would hurt performance, but it actually doesn't ... he said that trying to optimize in xaa is never a good thing
<asac> bryce: this is the discussion tha tfollowed after i asked to confirm that performance improves if you disable this optimization:
<asac> bryce: http://paste.ubuntu.com/7020/
<asac> bryce: so performance is better
<asac> bryce: and there are less bugs because you don't depend on hardware specifics anymore
<asac> win-win
<asac> bryce: and fedora has it off everywhere by default too. so we are rather alone - no doubt thats one of the reason why these things don't get fixed
<asac> bryce: firefox will backout the hack they had to disable parts of xrender
<asac> bryce: so if we don't take it, then firefox upstream users will get http://people.ubuntu.com/~asac/corrupted1.png
<asac> on every repeat-reflect tiled background in ubuntu
<asac> (not that i search for more reasons :))
<infinity> cjwatson: Should I assume from the radio silence that you reproduced the failure and are now working on working around it?
<cjwatson> infinity: I'd actually forgotten about that window; but unfortunately (?), it seems to be happily building under linux32 too
<cjwatson> certainly no early failure
<infinity> cjwatson: Damn.
<infinity> cjwatson: Kay, can you file a ticket then, so I don't lose it in the recesses of my rebuild-addled mind, and I'll poke it later?
<jdong> bryce: is texturedvideo usable on the gma950 or is it awful slow?
<bryce> jdong: I've heard fairly mixed reviews, although a lot of the remaining issues sound like they might just be corner cases / config issues
<jdong> bryce: sounds like something I should try :D
<bryce> asac, do you have a pointer to the redhat patch?  I can try packaging it up today
<jdong> bryce: well it works but is very CPU intensive
<jdong> bryce: does that mean I'm doing something wrong or is that a limitation of my hardware?
<asac> bryce: in the paste
<asac> there is a checkout command
<asac> bryce: 22:12 < otaylor> $ cvs -d :pserver:anonymous@cvs.fedoraproject.org:/cvs/pkgs get  xorg-x11-server     look at devel/xserver-1.5.0-xaa-sucks.patch
<bryce> thanks
<asac> np
<bryce> heh, cvs... quaint
<alex-weej> fedora still use cvs!?
<jdong> bryce: seems like while fullscreen and unredirected TV works great but windowed it's CPU-heavy. At least it doesn't hang like overlay for me
<bryce> asac: ok patch looks safe and good.
<seanh> If I want to start developing a Python CGI script on Ubuntu, can anyone point me to instructions on how to get going? I know Python, what I need to know is what packages to install and where to put my CGI scripts in order to be able to test them locally on Ubuntu
<bryce> jdong: sounds like it's doing software acceleration or something.  I don't know enough about texturedvideo's design/implementation to know why it would be cpu intensive, but it's still sort of new-ish so it doesn't surprise me
<asac> bryce: thanks a lot. can we get that into RC1 so we get feedback ?
<bryce> jdong: there may be some settings required to push it into hardware accel mode
<bryce> asac, I think so.  Should be simple to integrate
<asac> bryce: thanks!
 * asac hugs bryce 
<bryce> asac: the thing to watch for is that upstream's comments are all generalizations - "in general we feel this to be better", but the bugs will come from those people not in the general case ;-)
<cjwatson> infinity: RT#30463, thanks
<bryce> asac: however we've been making "deprecation noises" about XAA for a while anyway
<asac> bryce: right. but i'd say that putting more into software is usually a safe thing (without being X matinainer of course)
<bryce> I just hope it affects performance only, and doesn't render systems unusable (they hate that)
<cjwatson> james_w: your last grub-installer patch seems like it'll re-encrypt anything passed with grub-installer/password-crypted. Shouldn't the md5crypt call be in the else branch?
<bryce> yep probably so.  Different code paths though, so different bug risks.  But that software code is probably been heavily tested.
<cjwatson> james_w: (if you agree, I'll just make that change, no need to repost)
<slangasek> james_w: how thoroughly has the change for bug #136837 been tested prior to upload?  I guess this patch isn't committed upstream yet
<ubotu> Launchpad bug 136837 in gnome-applets "Mixer applet randomly decides to consider my sound card to be "muted" when changing volume" [Low,Triaged] https://launchpad.net/bugs/136837
<slangasek> james_w: and I don't understand your comments between 136837 and 215086 - one seems to say that fixing 136837 will /cause/ the problem in 215086, the other says it may /fix/ the problem in 215086...?
<LaserJock> slangasek: would this pass your scrutiny: http://launchpadlibrarian.net/13404149/seahorse-hkp-source.c.diff ?
<slangasek> LaserJock: +hexfpr[2] = 0; <-- gratuitous :)
<slangasek> LaserJock: it /looks/ correct now.  have you verified that there are no memory leaks introduced here?
<LaserJock> I haven't yet
<LaserJock> not sure how to test that actually, but I can find out
<zul> slangasek: hi http://pastebin.ca/984952 for nagios-plugins (fixes a long standing bug)
<kirkland> Keybuk: don't shoot me, but what would you think of adding a couple of commented lines to /etc/inittab that points to the "runlevel" manpage or other documentation (URL?) for experienced RH/SUSE/Debian/UNIX users looking for their accustomed runlevel stuff?  (We just answered that question again in #ubuntu-server)
<slangasek> zul: errm. why does fixing a segfault require pulling in a complete base64 implementation?
<zul> slangasek: because it was taken from their SVN
<slangasek> ah
<zul> and their base64 stuff was horribly broken
<slangasek> zul: ok, go for it then
<zul> slangasek: thanks
<infinity> cjwatson: Other than the general urgency of "RC in 3 days, release in 10", is the ps3-kboot something you need done ASAP, or "in a day or two'?
<james_w> cjwatson: yes, you're right, thanks for catching it.
<james_w> slangasek: I've tested it here, and it is used in Fedora and Mandriva. Unfortunately there's been no comment on it upstream.
<james_w> slangasek: it may in fact be unrelated to the other bug, I was just going on what the Mandriva guy said in the upstream bug report. I don't have an appropriate setup to test that part.
<slangasek> james_w: ok, accepting then
<slangasek> james_w: right, I was just confused as to *what* the expected effect on the other bug would be, since your comments in the two bugs seemed to contradict each other
<james_w> I tried to work with one of the gstreamer devs to get a fix for the second bug, but he didn't confirm that the patch worked.
<james_w> slangasek: sorry for the confusion, the second bug is a typo, it should read "make this happen", rather than "make this work".
<cjwatson> infinity: well, it *is* ports, but the problem is that the current ps3-kboot is utterly buggered because they changed the boot protocol
<infinity> cjwatson: Spiffy.  I'll try to make time for it pre-RC.
<siretart>   
<MarLaw> Hi people, I'm interested in contributing to ubuntu, I'm checking out MOTU and the process, I also heard that I can find a mentor to introduce me a bit, do you have more info on that ?
<james_w> MarLaw: there is
<james_w> a #ubuntu-motu channel for MOTU
<MarLaw> thanks james_w
<mario_limonciell> slangasek, would you mind releasing the last mythtv upload so it squeezes onto our RC disk?
<slangasek> mario_limonciell: done, ya rotten queue jumper :)
<laga> mario_limonciell: did you upload mythplugins too?
<mario_limonciell> slangasek, thanks
<mario_limonciell> laga, no i haven't tested your the diff
<munckfish> cjwatson: I'm off home now, will you be around later so I can depress you with stupid questions if needed? ;)
<laga> mario_limonciell: "your the diff"? i guess i forgot to post that ;)
<siretart>    
<mario_limonciell> laga, i'll test it this evening to verify
<laga> great. i'll test the alternate disk
<slangasek> munckfish: hi, should bug #146230 have been marked as fixed with the upload of ps3-kboot 1.6-1?
<ubotu> Launchpad bug 146230 in ps3-kboot "update ps3-kboot to 1.4.1" [Medium,In progress] https://launchpad.net/bugs/146230
<munckfish> slangasek: umm, if it had built successfully on the buildd yes
<munckfish> it builds fine everywhere else
<munckfish> just not on there
<munckfish> colin and I were looking into it earlier today
<munckfish> I will do best to resolve it later
<slangasek> munckfish: well - the bug requesting the update could be closed, though? :)
<slangasek> or if you prefer to close it by hand when the build is fixed, that's ok
<munckfish> slangasek: ok I see
<munckfish> so it can be closed now
<munckfish> fine
<munckfish> I can see to it later
<munckfish> (if I have the reqd LP permissions)
<munckfish> ok, I'm away home. Hopefully back online in an hour or so. Bye all!
<slangasek> zul: why is nut uploaded with a ~ppa version number...?
<slangasek> zul: I'm guessing that went to the wrong upload target?
<zul> slangasek: yep I was just about to talk to you about that one
<slangasek> ok, rejected ;)
<zul> slangasek: this was the actual debdiff for that one http://pastebin.ca/985021 (it fixes a regression in nut)
<slangasek> yes, I'd seen that in the queue, looks ok
<zul> slangasek: thanks..
<cody-somerville> Gah. I hate it when someone unassigns a bug I've assigned to myself to some team like ubuntu-desktopbugs when the bug is waiting on *me* to do something.
<doko> slangasek: updated versions: http://people.ubuntu.com/~doko/tmp/bash-completion.debdiff http://people.ubuntu.com/~doko/tmp/bash.debdiff
<laga> i'm wondering how i can make tasksel come up on the alternate disk. is it enough to remove the tasksel preseed entries? (i'd try it, but remastering the disk takes a lot of time)
<mok0> Is it necessary to request a sync for new packages in Sid, or will they be sync'ed automatically for ibex?
<Mithrandir> they'll be synced "automatically"
<mok0> Mithrandir: ok, thx
<Mithrandir> ("automatically" because it's a manual process, but it's typically run about daily up until import freeze)
<cjwatson> laga: correct, removing the tasksel preseed entries will do it assuming that there's more than one task on the disk
<laga> cjwatson: yay. great.
<doko> infinity, slangasek: how serious are the failed builds from yesterday's autobuildtst? i.e. mutt failed due to a missing links package for example, but apparently succeeded to build on the normal buildd
<infinity> doko: I'll be going through logs and filing in a bit.
<infinity> doko: But that sounds like a "real" failure to me...
<doko> infinity: why? elinks is in main and provides links
<doko> thought our sbuild can handle this ...
<infinity> doko: Oh, I didn't understand what you were saying until I read the log.
<infinity> doko: It's possible sbuild on the autotest machines is out of sync with sbuild in LP... I'll have to check that before I find out why that failed.
<infinity> doko: Actually, hrm.  It didn't succeed on LP due to sbuild at all.  sbuild called "apt-get install links", it's apt-get that DTRT.
<doko> ok, thanks.
<laga> slangasek: can you please merge r1298 from http://bazaar.launchpad.net/%7Emythbuntu/debian-cd/mythbuntu-debiancd/ ?
<infinity> doko: And there's the bug.  elinks in main no longer Provides links.
<infinity> doko: So, yes, there's a bug.
<infinity> doko: Whether the bug is "no links in main for mutt to build-dep on" or "elinks doesn't provide links anymore", the failure is real.
<doko> ok
<doko> slangasek: should we delay fixing these build failures until after the RC?
<infinity> RC isn't for a few days, I'm sure we can push some fixes out.
<bigon> is soyuz accepting binnary packages?
<infinity> bigon: As in binary uploads from buildds?
<bigon> as binary pkg build from developpers (it's to fix the openhackware FTBFS, the pkg must be builded on ppc)
<Mithrandir> bigon: no.
<infinity> bigon: No, we don't accept binary uploads.
<bigon> so how can this kind of FTBFS be fixed?
<seb128> why couldn't it build on the buildds?
<cjwatson> arch all => built on i386, I imagine
<cjwatson> the traditional answer is to offer infinity beer to build it for you
<Amaranth> someone has been trying to figure out how to fix openfirmware for like 2 years now :P
<Amaranth> either they keep fixing it and it keeps breaking or they gave up
<bigon> and a lp admin using his magical power? (only as workaround in the first time)
<infinity> cjwatson: That answer was shot down by infinity due to the fact that it would have to be done for every upload. :/
<infinity> bigon: Have you looked at how "palo" cheats in this regard?
<infinity> bigon: (It compiles in the clean target, iff the host arch is hppa, and the source package is always built on an hppa developer's machine before upload)
<infinity> bigon: Not ideal, but... Beats begging me to build manually on every upload.
<cjwatson> infinity: ah :-/
<bryce> slangasek: fix for 8.04 milestoned bug #182038 has package xorg-server 2:1.4.1~git20080131-1ubuntu8 queued for approval
<cjwatson> infinity: !
<cjwatson> infinity: uploading binaries by the back door?
<infinity> cjwatson: Did we just learn something we didn't want to know? :)
<cjwatson> what did you say again?
<infinity> I SAID NOTHING.
<infinity> Move along.
<kees> archive admins: when you get a chance, can you manual-shove "refpolicy" (universe), please?
<bdmurray> slangasek: have you seen bug 216209?
<ubotu> Launchpad bug 216209 in pam "package libpam-modules 0.99.7.1-5ubuntu5 failed to install/upgrade:  (Hardy)" [Undecided,New] https://launchpad.net/bugs/216209
<yosch> cjwatson: hi, when you have a spare minute could you please take a look at bug 180011 ? It's for the new package with source, new license and trademark updates to ubuntu-title. Thanks.
<ubotu> Launchpad bug 180011 in ttf-ubuntu-title "Lack of SFD source file breaks LGPL license and makes file unredistributable!" [High,In progress] https://launchpad.net/bugs/180011
<bigon> infinity: the openhackware is quite stable (the version in the archive is 2 years old)
<yosch> cjwatson: I subscribed motu-release
<cjwatson> yosch: I don't mean to be bureaucratic, but since I'm deep in something else right now and will take an hour or so to get round to this, it might be quicker to hunt in #ubuntu-motu for an uploader first; it has my approval in principle though
<infinity> bigon: If it's really that stable, I can do a manual build for now.  I'm filing a soyuz bug to see if maybe we can get some arch:all affinity granularity for bizarre cases like this.
<yosch> cjwatson: no problem. I'll patiently wait for someone in #ubuntu-motu. cheers.
<bigon> infinity: I just see that debian has a -3 revision, maybe uploading this revision first?
 * bigon hides
<slangasek> doko: well, in general build failures should be fixed for release, but they don't have to be fixed before RC - nor do they /have/ to be deferred until after RC
<infinity> bigon: Get it approved by an MOTU release manager, get it uploaded, and get the source in the archive, then we'll talk.
<infinity> bigon: I really don't want to do this manual build more than once. :/
<infinity> bigon: Oh, I see we ship it unmodified.  Well, get it approved as an FFe, then, and get it synced.
<slangasek> bdmurray: hadn't seen that, no... is there a standard incantation to get actual upgrade logs out of the submitter, since apport apparently doesn't attach this?
<infinity> bigon: Err, freeze exception in general, even.
<slangasek> bdmurray: eh, " ErrorMessage: package libpam-modules is already installed and configured" <-- huh?
<bdmurray> slangasek: I'm not certain about that bug anymore.  I thought it might be related to my failure to upgrade from gutsy to hardy due to libpam0g.
<slangasek> bdmurray: well, not that I can see
<bdmurray> slangasek: bug 217435 is what I ran into today
<ubotu> Launchpad bug 217435 in pam "Internal Error, Could not perform immediate configuration (2) on libpam0g" [Undecided,New] https://launchpad.net/bugs/217435
<mvo> bdmurray: that bug you mentioned with pam looks like update-manager is reporting it wrongly, it seems its all a duplicate of #215293
<mvo> bdmurray: mhhh, maybe not, but the /var/log/apt/term.log should give us a clue
<slangasek> right, I was going to say, I don't see how this can be a pam bug
<slangasek> laga: mythbuntu debian-cd merged
<bdmurray> slangasek: When you get a chance could you look at 217435?
<slangasek> bdmurray: can you provide the term.log mvo mentioned?  This is really an apt problem, not a pam problem anyway
<bdmurray> slangasek: Sure, I thought he was talking about that other bug report.
<slangasek> oh, maybe he was
<bdmurray> Actually I've provided everything that existed in '/var/log/dist-upgrade/' and '/var/log/apt/term.log' only contains information about package upgrades.
<soren> Hm... I need to find the appropriate ifdef's for only compiling certain things on i386 and amd64. Now, I *could* just look in some code that does it already, but where is that actually documented?
<slangasek> bdmurray: ok, well, either way, 217435 is not a pam bug (the pam package relationships have been correct and stable since before gutsy), and there's not enough info in that bug report to diagnose the cause of the failure...
<slangasek> bdmurray: but "could not perform immediate configuration", AIUI, normally means that apt had a problem resolving the pre-dependencies of the Essential package set
<alex-weej> pulseaudio is default in hardy right? are we using the pulse ALSA plugin for ALSA apps?
<alex-weej> if so, i've some bugs to file (my system is an upgrade so i don't know what the default setup is)
<bdmurray> slangasek: okay, I'll reassign to update-manager then
<Riddell> doko: you uploaded scim-qtimm to fix a build failture, but it seems to be built https://edge.launchpad.net/ubuntu/hardy/+source/scim-qtimm/0.9.4-2ubuntu2
<slangasek> Riddell: it's probably a build failure that showed up in infinity's autotestbuild run
<Riddell> ah
<slangasek> or autobuildtest, or whichever way 'round that goes :)
<doko> Riddell: was last rebuilt in gutsy, now dpkg doesn't like duplicate attributes in control files
<slangasek> Amaranth: y'know, it makes me uneasy to see that the solution for a buffer overflow is to make a bigger buffer... :)
<slangasek> Amaranth: oh, you didn't upload this
<slangasek> mvo: ^^
<Amaranth> eh?
<Amaranth> what package is that? :)
<slangasek> Amaranth: sorry, I was reading the wrong line in the compiz debdiff :)
<Amaranth> i can't upload anything to main :P
<slangasek> well, no, but it might've been sponsored :)
<wasabi> somebody i have an ubuntu box which allows any and all passwords for any users on the console.
<wasabi> grrrr.
<wasabi> s/somebody/somehow/
<wasabi> silly pam, no cookie for you
<slangasek> curious
<mvo> slangasek: right, this comes directly from upstream (and they are pretty clueful) - but if you feel uneasy I can clarify tomorrow
<munckfish> infinity: hi have you got a minute?
<slangasek> mvo: I've accepted it, it can't be a regression vs. what there is now - but it doesn't look like a very correct fix to me, since if it overflowed once, that means there's code elsewhere that makes hard-coded assumptions about the buffer size that should still be fixed
<Amaranth> slangasek: we make some assumptions like that in bunches of places in compiz
<megabyte405> Can I get someone to review the AbiWord 2.6 upload?
<slangasek> slomo: fwiw, bug #199496 didn't get closed on package accept because the bug was only assigned to gtk-sharp2 (which didn't close the bug), not gnome-sharp2 (which did)
<ubotu> Launchpad bug 199496 in gtk-sharp2 "Tomboy.exe crashed with SIGSEGV in exit()" [High,Confirmed] https://launchpad.net/bugs/199496
<slangasek> slomo: I think the best thing to do in this case would have been to have a task for each package, and close it in both changelogs?
<slangasek> megabyte405: is wv sorted?
<slangasek> Amaranth: that's... bad
<megabyte405> slangasek: at least verbally, yeah - sunday night pitti said that it would be fine since it was in main until gutsy anyway
<Amaranth> slangasek: but it's fast :P
<Amaranth> although i think in most cases we don't use any outside input to fill the buffer so if it overflows we've broken something ourselves
<slangasek> Amaranth: not faster than using sizeof() to get compile-time integer math on your buffers to be sure that nothing can overflow it...
<Amaranth> which bug is he trying to fix? i'm a bit out of the loop here
<slangasek> Amaranth: buffer overflow in gaussian blur with radius > 12
<Amaranth> ah
<slangasek> no bug number mentioned in the changelog, IIRC (it's no longer in front of me)
<mvo> Amaranth: maniac pointed me to the patch today
<infinity> munckfish: Possibly, what's the minute being used for? :)
<Amaranth> although blur is general is pretty broken so i doubt that's a huge issue :P
<Amaranth> it only works on nvidia cards, afaik
<munckfish> Hi, I'm trying to solve a build fail on adare - ps3-kboot
<slangasek> Amaranth: anyway, checking your bounds is surely going to be faster than continuing to write memory past the end of the buffer ;)
<munckfish> It builds fine on ps3, colin watsons 'davis' machine
<cjwatson> (not my machine, it's a powerpc box in the Canonical DC)
<munckfish> but failed on adare
<munckfish> cjwatson: hi thx for clarifying
<munckfish> infinity:
<munckfish> infinity: could you run a script on adare so I can see what certain build vars would end up as? http://paste.ubuntu-nl.org/63186/
<munckfish> Or could you tell me what they'd end up as?
<cjwatson> slangasek: I dunno, the kernel might be able to optimise it if the memory after the end of the buffer is mmapped from /dev/zero :-P
<slangasek> heh
<infinity> munckfish: I can in a sec... I'm just in the middle of something.
<cjwatson> or indeed /dev/null, er, meh
<munckfish> infinity: thx
<slangasek> cjwatson: I'm pretty sure the kernel trap would be more expensive still :-)
<cjwatson> spoil my fun, why don't you
<slangasek> mvo: I totally don't understand the debdiff for bug #216822; the bug report talks about amd64, and your change in the package is s/i386/powerpc/...?
<ubotu> Launchpad bug 216822 in gnome-app-install "Can't install ardour2 from add/remove programs in latest hardy build" [Low,Fix committed] https://launchpad.net/bugs/216822
<mvo> slangasek: amd64 was not listed, that makes the package appear in the list but it is shown with a remark that it is not avilalbe on the given architecure - this is to avoid a situation were people search for software and wonder why we don't have it. we tell them that we have it but can't provide it for their arch for some reason. the problem here is that the ardour desktop file had a incorrect architecure field
<mvo> slangasek: (well, two incorrects even - its available on all arches, so the fields are bogus)
<slangasek> mvo: so how does putting "powerpc" there help anything?
<mvo> slangasek: my debdiff for the ardour.desktop file looks like this: http://paste.ubuntu.com/7052/
<mvo> slangasek: do you see something different?
<slangasek> mvo: only when I'm not looking at it properly
<slangasek> mvo: I thought it was -/+, not -/-; thanks for your patience :-)
<infinity> munckfish:
<infinity> Hostname: adare
<infinity> GCC dumpmachine: powerpc-linux-gnu
<infinity> kboot HOST_ARCH: powerpc
<infinity> Uname -a: Linux adare 2.6.15-28-powerpc64-smp #1 SMP Thu May 10 10:05:07 UTC 2007 ppc GNU/Linux
<mvo> slangasek: no problem :) thanks for your review!
<munckfish> infinity: thx v much!
<infinity> munckfish: Do I even want to know why ps3-kboot ships with its own linux source tree? :)
<cjwatson> infinity: Ben gave the OK for that for this release - we don't have time to build it from our kernel :-/
<munckfish> infinity: the bootloader for PS3 needs USB, and Bluetooth support so it runs it's own compact kernel
<cjwatson> infinity: it's just a bootloader, so security implications are minimal
<munckfish> infinity: networking disabled etc
<infinity> Scary...
<munckfish> infinity: would you have any idea
<munckfish> why we get "ld: Relocatable linking with relocations from format elf64-powerpc (init/do_mounts.o) to format elf32-powerpc (init/mounts.o) is not supported"
<munckfish> on adare but nowhere else?
<infinity> I'm doing a test build on adare right now...
<munckfish> I'm currently needling thru makefiles trying to work it out
<munckfish> infinity: oh cool thx
<infinity> Oh, good, it fails without sbuild in the equation.  That makes it definitely Not My Bug.
<slangasek> munckfish: what does the build log show as to how it's built?  Do you see each of those object files being built in the build log?
<munckfish> As far as I can see the kernel makefile is passed exactly the same stuff on all the machines we've built on so far
<munckfish> slangasek: yes
<munckfish> it doesn't get very far
<infinity> munckfish: For reproducibility's sake, I'm using a debootstrap --variant=buildd chroot, upgraded to latest hardy, /proc and /dev/pts mounted, then "linux32 chroot test-chroot", installing build-deps, and building.
<munckfish> the first time it tries to link it fails
<infinity> slangasek: The log is rather opaque, it's the kernel make filter.
<slangasek> meh
<slangasek> try a test build with V=1?
<munckfish> V=1?
<munckfish> oh verbose i c
<slangasek> to tell the kernel make rules to be verbose
<slangasek> and show you what they're really doing
<munckfish> Yeah I'd like to see that
<infinity> slangasek: will a kernel make being run from dpkg-buildpackage pick it up if exported in the shell, or do I need to get to mangling debian/rules in this thing?
<slangasek> I have no idea
<infinity> Also, a build system that doesn't involve unpacking linux.tar.bz2 would make me less sad.
<slangasek> heh
<munckfish> infinity: me too
<munckfish> there's a lot of untidyness
<munckfish> but i left out everything not reqd to just get it to build
<munckfish> apologies
<munckfish> these things can be addressed in subsequent updates
<munckfish> infinity: the call to the build the kernel happens in {source dir}/kboot-11/Makefile line 645 if that helps, trouble is that's the 3rd
<munckfish> nested Makefile by the time we've called rules as well
<munckfish> cjwatson: this error, it's saying that a 64bit linker isn't available right? Well 'davis' isn't 64 bit so where's it gonna be coming from on that machine?
<munckfish> Are we likely just missing another build-dep?
<munckfish> but then I used pbuilder with the bare minimum
<munckfish> :(
<cjwatson> munckfish: davis is running a 64-bit kernel, as it happens ...
<cjwatson> I doubt magic cross-linkers would be used automatically though
<munckfish> duh stupid me yes it's in that report you made for me earlier
<munckfish> (munckfish needs sleep)
<munckfish> so that's exactly the same setup
<munckfish> :(
<infinity> munckfish: As soon as this "hahaha, bzi2 forever!" build system is done failing again, I'll toss a verbose log your way.
<infinity> munckfish: Which may or may not be enlightening.
<munckfish> infinity: thx, I guess you're referring to the backup upstream makes of the kernel source before patching
<infinity> munckfish: http://people.ubuntu.com/~adconrad/ps3-kboot-verbose.log
<munckfish> infinity: thx, I'll go analyse it
<infinity> "ld -m elf64ppc -m elf32ppclinux ..." looks pretty special to me.
<munckfish> yep
<munckfish> I just spotted that
#ubuntu-devel 2008-04-15
<infinity> munckfish: Anyhow, like I said, a "debootstrap --variant=buildd" with the build-deps installed after the fact (copy 'em straight from the "apt-get install" in the launchpad build log, if you want to make sure you're getting exactly the same build environment), should reproduce it.
<infinity> munckfish: Making sure to "linux32 chroot" not just "chroot", if you're on a 64-bit machine.
<cjwatson> -m elf32ppclinux comes from LDFLAGS in ps3-kboot/kboot-11/Makefile
<munckfish> cjwatson: dare we just kill that variable I wonder?
<cjwatson> just looking for where the other one comes from
<cjwatson> but yeah, I have to say that -m elf32ppclinux doesn't sound very sane for a 32-bit kernel; does it make sense for the userspace bits though?
<infinity> s/32/64/ I assume you mean?
<cjwatson> 32-bit -> 64-bit I meant, yes
<munckfish> cjwatson, infinity: as far as I understood it only the kernel needs to be 64 bit, everything else can be 32.
<munckfish> I'm trying to work out
<munckfish> how LDFLAGS ends up with the two -m
<munckfish> I think the
<cjwatson> munckfish: I have a feeling I'm almost there ...
<munckfish> first -m
<munckfish> is constructed in /arch/powerpc/Makefile
<munckfish> e.g.
<munckfish> line 67
<munckfish> override LD	+= -m elf$(CONFIG_WORD_SIZE)ppc
<cjwatson> yeah, ahead of you :-)
<cjwatson> (though keep going)
<slangasek> megabyte405: you asked for a review of the abiword 2.6 package, where is this?
<slangasek> megabyte405: is http://launchpadlibrarian.net/13344323/updatetoabi26.debdiff.gz the most current (eew, giant debdiff)?
<infinity> If the second one is being used for userspace overrides, it can probably be dropped entirely, since -m32 is the default anyway.
<cjwatson> munckfish: the other one comes from kboot-11/Makefile, of course
<cjwatson> infinity: right
<slangasek> wasabi: did you find out what was wrong with pam on your console?  something that wouldbe an Ubuntu bug?
<cjwatson> I'm just waiting for linux.tar.bz2 to unpack, to test this hypothesis
<megabyte405> slangasek: the abiword bug is 202174 but since it involves a new upstream package the debdiff is only of academci interest.  You'll want to see my ppa, linked in that bug or https://launchpad.net/~abiryan/+archive/
<megabyte405> erm, bug 202174
<ubotu> Launchpad bug 202174 in abiword "Please update to version 2.6" [Medium,New] https://launchpad.net/bugs/202174
<infinity> cjwatson: Infinitely curious why this doesn't trigger on davis, but even an infinity amount of curiosity is not enough for me to take the time out to find out why...
<cjwatson> bingo
<megabyte405> there we go :)  I have a fairly complete summary in the bug comments there.
<infinity> s/infinity/infinite/
<cjwatson> my tests were with debian/rules binary; fakeroot debian/rules binary
<cjwatson> er, s/binary/build/ first one there
<slangasek> megabyte405: ah, ok, was reading from the bottom and missed the link to your ppa, thanks
<infinity> dpkg-buildpackage produces different behavior from debian/rules build, I take it?
<cjwatson> but if you use 'dpkg-buildpackage -b' instead, then LDFLAGS is exported by dpkg-buildpackage, and even though it gets reset, the exportedness survives
<infinity> Ah-ha.
<infinity> Yay for the "new" dpkg.
<megabyte405> slangasek: np
<cjwatson> LDFLAGS in kboot-11/Makefile was only meant to be local to that Makefile
<cjwatson> 'unexport LDFLAGS' right after it should fix this
<cjwatson> (that's the most minimal fix; removing LDFLAGS altogether may well also work but is a bigger change)
 * slangasek mutters at the unseasonable hail
<infinity> cjwatson: Okay, if this is under control, I'm going to wipe out my test env and turn adare back on.
<cjwatson> yep, I have it reproduced on davis now
<cjwatson> just testing the unexport approach
<munckfish> cjwatson: so how do you want to proceed? do you want to add this to my disable cross-compile patch ?
<cjwatson> yeah, that does the trick
<cjwatson> I think that's probably best
<megabyte405> slangasek: I'm out - if you need something email me at abiryan at ryand dot net
<slangasek> megabyte405: ok, cheers :)
<cjwatson> munckfish: shall I go ahead and do that? I'm happy to now that we see the problem, and I'm pretty confident that it will yield a working image since it's solely working around the build strangeness without which you produced a working image
<munckfish> cjwatson: pls go for it
<munckfish> It's late here anyway so I wouldn't be able to address this till tomorrow morning at best anyway
<cjwatson> ok
<munckfish> Sorry I couldn't fix it on my own, I know you didn't want to get distracted too much by this project at the mo
<cjwatson> well, this was a pretty tricky one to see
<cjwatson> you get to test the result though :)
<munckfish> cjwatson: yeah, next job is to dive into the Xorg prob
<munckfish> ok I have to go sleep now
<munckfish> or I'll be useless to my employer
<infinity> munckfish: Don't worry too much about it.  Every time a member of the distro team accuses my buildds of causing a build failure and we later prove it's a packaging bug, I get a free beer so, in essence, you're just contributing to my alcoholism.
<infinity> munckfish: Clearly a win.
<munckfish> infinity: :)
<munckfish> cjwatson, infinity: good night guys, thx for all the help. I look forward to testing the ps3 Xorg problem. cheers!
<cjwatson> munckfish: sleep well :)
<jdong> kees: does apparmor support subprofiles, like when /bin/foo launches /bin/bar, use this profile, but otherwise leave /bin/bar alone?
<kees> jdong: yup -- through the exec, either inherit or switch profiles
<kees> jdong: oh, but you mean "only isolate /bin/bar if /bin/foo launched it" ?
<jdong> kees: right, parent-aware profiles
<kees> jdong: not in a simple fashion, no.  see if anyone is around on #apparmor, though.  they might be able to discuss "changehat" and other odd things
<kees> (#apparmor is on oftc, btw, sorry)
<jdong> kees: meh I'll go for a simplicity workaround. I'm trying to write a clamscan apparmor profile specific to dealing with my mail
<jdong> the amount of security bugs found in clamav's unpackers really concerns me
<kees> heh, no kidding.
<jdong> btw, whoever in u-m-s is listening, bug 184238 needs sponsorship and is wanted for Hardy release....
<ubotu> Launchpad bug 184238 in transmission "Menu entry should be named "Transmission BitTorrent Client" Instead of only the unclear "Transmission"" [Medium,Confirmed] https://launchpad.net/bugs/184238
<jdong> kees: how safe are apparmor restrictions? I'd expect as long as a root account isn't compromised I'd be totally safe, and even some forms of root compromise are not problematic?
<crimsun> any root compromise would allow /etc/init.d/apparmor stop.
<kees> jdong: in theory, AA profiles are as strong as the kernel.  :P  I've done things like run /bin/bash as root listening on an open port, and no one could do anything with it since they didn't have an exec prvis
<kees> *privs
<cjwatson> I hope you locked it down more than that; bash doesn't need to exec subprocesses in order to (say) overwrite files
<jdong> crimsun: well to call apparmor stop I think writing to sysfs is necessary to clear out the profile
<jdong> an unrestricted root compromise, sure you're totally screwed :)
<kees> cjwatson: right, of course -- I didn't let it do anything.
<kees> jdong: I think there is a changehat syntax for profile names... it's been a while since I've looked at that.
<kees> crimsun: yeah, without the write perms to the aa security tree in /proc you can't shut it down.
<jdong> kees: yeah the syntax for profiles is pretty easy, the question is how much effort it'd take for me to hook that into my scripts
<jdong> kees: and whether or not it's easier than just hardlinking a new clamscan ;-)
<jdong> (rhetorical, most likely)
<kees> jdong: if you run with clamd (and use clamc for the scanning) you could probably just isolate clamd itself.
<kees> using clamc is way faster too.  ;)
<jdong> that's another good idea :)
<jdong> AAAH OH FSCK!!!
<kees> ???
 * jdong angrily aliases rm to rm --one-file-system
<jdong> follow up lesson: ALL mountpoints should go in /media!
<bryce> ouch
<jdong> alright, damage control time... fortunately XFS ain't too fast deleting files
<RAOF> jdong: :(
<jdong> RAOF: this kinda thing also makes me worried about gvfs....
<jdong> because I simply mounted a sshfs in a temp workdir in my ~/
<jdong> but if someone tried to rm -rf a homedir with a gvfs FUSE auto mountpoint....
<RAOF> Awkward, yeah.
<Fujitsu> More than awkward.
<Fujitsu> That'd be a fairly critical bug.
<jdong> Fujitsu: well we do it for Hardy by default.... ~/.gvfs often contains fuse mounts of stuff you've browsed in nautilus
<jdong> and for things like ssh:// it's identical to a sshfs backend in functionality
<Fujitsu> So I note. This is probably a severe problem.
<Fujitsu> I don't expect ~/.* to include my server's filesystem.
<jdong> right
<jdong> but SOMEONE's gonna argue that this is somehow a feature :)
<Fujitsu> And a lot more people are going to lose their remote home directories.
<jdong> yeah I'm concerned. I wouldn't ever expect a recursion down my home directory to include network shares I've browsed.
<jdong> even if removal is not invovled, it's still an annoyance that things like Baobab will recurse down a 7.5TB SFTP server I browsed 10 minutes ago.
<Fujitsu> Haha.
<Fujitsu> It is very convenient, but also dangerous...
<LaserJock> is volumeid meant to be removed?
<crimsun> yes, by udev.
<LaserJock> ok, cool
<LaserJock> anybody around who could help me figure out valgrind output?
<LaserJock> I'm trying to find memory leaks in seahorse
<jdong> In Soviet Russa, ValGr... oh never mind.
<LaserJock> I ran valgrind --tool=memcheck --leak-check=yes seahorse
<jdong> this sounds more interesting than an English paper :)
 * jdong sits and watches
<LaserJock> and I get:
<LaserJock> definitely lost: 72,750 bytes in 160 blocks.
<LaserJock> indirectly lost: 124,747 bytes in 3,902 blocks.
<LaserJock>  possibly lost: 332,563 bytes in 278 blocks.
<LaserJock> is that memory leaking?
<slangasek> it's memory not freed on exit
<slangasek> but I'm not sure how accurate valgrind's leak checking is
<LaserJock> slangasek: is there a recommended way to do it?
 * StevenK wonders how he can find all the packages that install a particular alternative
<slangasek> LaserJock: way to do what?
<slangasek> to find memory leaks?
<LaserJock> yeah
<slangasek> understanding the code :)
<LaserJock> yikes
<LaserJock> ;-)
<slangasek> the variable should be locally scoped, in this case
<slangasek> so you should have a finite number of ways to leave that scope
<slangasek> and you just need to make sure the memory is freed, or control of the memory is passed somewhere else, before leaving the scope
<LaserJock> slangasek: hmm, I guess I would have thought it was in a local scope already :/
<slangasek> yes, that's what I mean - so there's a finite number of places the memory can leak
<slangasek> i.e., anywhere that you leave that scope without taking care of the memory
<LaserJock> slangasek: so would freeing the memory within the for loop instead of outside be better?
<LaserJock> I don't see how you would particularly leave the scope without freeing the memmory unless you crash somewhere in there
<LaserJock> gosh I need to learn C
<lamalex> Hey, does anyone in here know how the subset of packages that get put in add/remove are chosen?
<lamalex> what characteristics do those packages have
<LaserJock> lamalex: I think in general it's packages that have .desktop files
<lamalex> does it have its own cache somewhere? If I wanted to do something with just those packages do you know of a clean way?
<LaserJock> lamalex: look in /usr/share/app-install/desktop/
<lifeless> slangasek: valgrind is pretty good
<lifeless> slangasek: 'definitely lost' is: memory that was allocated, and there are no pointers to it, but free(base) was not called.
<lamalex> LaserJock: thanks
<lifeless> slangasek: I believe 'indirectly lost' is memory that is pointed too from definitely lost memory
<lamalex> hmm, i'd be surprised if this read from desktop files, but it's a place to start, thanks for the help
<LaserJock> lamalex: what do you mean?
<LaserJock> lamalex: what is it that you're trying to do?
<lamalex> well to read all of those files for the package descriptions would be slow
<LaserJock> lamalex: it caches them
<lamalex> are you familar with gnome do?
<LaserJock> sure
<lamalex> gnome do apt plugin
<lamalex> but indexing 23000 packages is not reasonable
<LaserJock> hmm
<lamalex> so I was going to choose the subset of packages in add/remove
<lamalex> i figured it was running off of an sqlite db or something
<LaserJock> see /var/cache/app-install/
<lamalex> heh and the problem with binary files is you can't cat them :P
<emgent> morning
<fabbione> morning
<fabbione> emgent: early bird or late night owl?
<emgent> fabbione: lol
<emgent> i dont like sleep :P
<emgent> Hobbsee: have you time for some ACK ?
<slomo> slangasek: yes
 * Hobbsee waves to fabbione
<fabbione> hey Hobbsee
<slangasek> LaserJock: well, the point is I haven't had a chance to look at this code myself yet to /know/ whether there are memory leaks...
<LaserJock> slangasek: sure, I'm just not sure
<LaserJock> slangasek: it looks ok to me, but I'm not confident as you pointed out problems with my first upload
<LaserJock> should I leave it for somebody else?
<LaserJock> I just don't want it to fall through the cracks
<fabbione> morning
<fabbione> again
<fabbione> nevermind
<fabbione> wrong window
<Hobbsee> remorning.
<Fujitsu> Mourning.
<pitti> Good morning
<fabbione> hey pitti
<Hobbsee> guten morgen, pitti
<Hobbsee> hey, is anyone offering to be a projective missile?
<fabbione> Hobbsee: eh?
 * Hobbsee needs to use something big as a projective missile.
 * fabbione doesn't really know what "projective missile" means in this case
<Hobbsee> fabbione: heard of a missile?
<Hobbsee> fabbione: something large that you throw at someone, or something.  it goes through the air.
<fabbione> yeah i heard about that ;)
<Hobbsee> yeah.  i need one.
<fabbione> what for?
<Hobbsee> my boss.
<Hobbsee> he fails in crucial ways about "notifying people about important changes in the workplace"
 * Hobbsee has no idea if, and when, the power will go out tonight there.
<elemjay> Latest Google Tech Talk on the future of Linux: http://www.youtube.com/watch?v=4A6ImflixL8
 * Hobbsee is going to be absolutely stuffed, along with my coworkers, if the power *does* go out while we're still there.  Although we certainly won't get hungry.
<fabbione> Hobbsee: you really don't need a missile for that
<fabbione> it would be a waste of good resources to kill a fly
<TheMuso> Hobbsee: And why would the power go out?
<Hobbsee> TheMuso: planned maintenance on the local power station.
<TheMuso> Oh.
<Hobbsee> TheMuso: one says it only happens on monday at 10pm, the other says it happens on both monday and tuesday at 10pm.
<TheMuso> Oh right.
<Hobbsee> I wouldn't have found out about either notice, if i hadn't been browsing back through the supervisor book, over the last week, nor reading random pieces of paper in teh managers office.
 * Hobbsee does *not* call this decent warning.
<Hobbsee> especially seeing the rosters still schedule us all to finish after that point.
 * Hobbsee looks for her torch
<asac> pitti: langpacks ;)
<asac> anything left we need to figure?
<asac> Riddell: kubuntu offline startpage localization :) ... did you figure why the links are broken?
<pitti> asac: I'll have a deeper look after I went through my email
<pitti> asac: but it looks fine so far
<pitti> asac: what is 'revpath'?
<asac> pitti: did you rerun the command i gave you to tsee if it works now properly with your permissions?
<asac> pitti: psst.  :)
<asac> pitti: i didn't know about it until i found that its missing on rookery
<asac> pitti: davidm made use of it ... i had to copy the binary from ronne
<pitti> ugh
<laga> slangasek: great, thanks for the merge
<laga> mjg59: regarding https://bugs.launchpad.net/bugs/157691 - is there any way we can make detection of the graphics driver a bit more robust? autodetection is becoming common these days i guess..
<ubotu> Launchpad bug 157691 in hotkey-setup "Hardy/Gutsy crashes when the lid is closed on a HP 6710b, HP 6510b and HP 2510p" [Undecided,Fix released]
<laga> hum. are there no daily builds today?
<slangasek> no, we're ramping up for candidate images
<laga> too bad. oh well, i guess i get to try the candidate image for mythbuntu then :)
<pitti> slangasek: seb128 and I just agreed on how to fix camera handling eventually; we can't fix nautilus properly, so we'll enable it in gnome-volume-manager again
<pitti> slangasek: I'd like to upload this change now, so that it will work again in RC; ok for you?
<pitti> slangasek: (simple gconf default change in the .schema file, no code changes)
<slangasek> pitti: corresponding bug #?
<dholbach> good morning
<pitti> seb128: what's the bug# for that?
<seb128> bug #208467
<ubotu> Launchpad bug 208467 in nautilus "Camera Device button "Open F-spot Photo Manager" doesn't work" [High,Confirmed] https://launchpad.net/bugs/208467
<pitti> thanks; I'll add a g-v-m task and an explanation
<seb128> thank you
<seb128> slangasek: I've uploaded a new gtk, I synced the new debian revision which fixes the gtk im setting change patch backported some time ago (1 liner) and the dbg packages to work again (not really required since the dbgsym works alright)
<seb128> slangasek: the update should not be an issue but it's not a priority either, feel free to accept it or not
<slangasek> pitti: yep, go for it
<slangasek> seb128: ok, putting it in the "later" pile for now, thanks :)
<seb128> slangasek: ok ;-)
<emgent> morning
<sabdfl> why would f-spot depend on sqlite and sqlite3 at the same time?
<tjaalton> slangasek: vdr-plugin-console and -osdserver are waiting on the queue, uploads approved by sistpoty
<tjaalton> slangasek: fixes FTBFS
<slangasek> sabdfl: database upgrade support :/
<slangasek> tjaalton: can you give me a pointer to this approval?
<tjaalton> slangasek: a sec
<tjaalton> slangasek: http://irclogs.ubuntu.com/2008/04/11/%23ubuntu-motu.html towards the end
<slangasek> tjaalton: right, accepted
<tjaalton> slangasek: cool, thanks
<sabdfl> slangasek: ah, right. read from the old, write to the new. yowser
<pitti> mvo: is bug 211978 an issue for hardy?
<ubotu> Launchpad bug 211978 in update-manager "do-release-upgrade -d doesn't work immediately after running do-release-upgrade" [High,In progress] https://launchpad.net/bugs/211978
<pitti> hey sabdfl, how are you?
<StevenK> pitti: Hey, time for a dorky CDBS question?
<pitti> StevenK: I'll answer eventually
<mvo> pitti: its fixed in hardy
<pitti> mvo: ah, can you please close it then? thanks *hug*
<s|k> hi
<s|k> I know a little python and C and was thinking of maybe contributing
<s|k> :/
<StevenK> pitti: Heh. CDBS is symlinking the Debian changelog only, and I thought there was a magic button to make it symlink the entire doc dir?
<pitti> StevenK: it never symlinks entire directories, since that's evil with dpkg's handling of dirs vs. symlinks
<pitti> StevenK: it will symlink individual files in doc/pkg/ if they are identical in any of its direct dependencies
<pitti> except copyright
<StevenK> pitti: Should I ignore lintian's bleating that the Debian changelog is a symlink?
<pitti> StevenK: I do, anyway :)
<StevenK> Heh
<s|k> :/
<soren> pitti: "/usr/share/doc/package may be a symbolic link to another directory in /usr/share/doc only if the two packages both come from the same source and the first package Depends on the second. " Straight from Debian Policy?
<pitti> soren: right, but dpkg wreaks havoc if you ever replace the symlink with a proper dir again
<pitti> so I don't do it
<pitti> s|k: anything in particular you'd like to work on?
<pitti> s|k: usually people do not contribute "to C programs", but to a set of packages that interest them :)
<soren> pitti: Oh, really? I did not know that.
<soren> pitti: Surely that can be fixed?
<pitti> soren: that's rather deliberate, I think
<soren> pitti: Surely that can be fixed? :)
<pitti> soren: e. g. you might have /usr/share point to a different partition if your /usr becomes full, and similar situations
<pitti> you want dpkg to honor the symlink
<s|k> pitti: by working on the project itself?
<megabyte405> FYI - addressed concerns in the abiword 2.6 bug
<soren> pitti: Hmm... Sounds reasonable, I suppose.
<s|k> as in work on epiphany or something and not ubuntu
<pitti> s|k: of course we always welcome people who want to work in a 'horizontal' approach, i. e. fix lots of bugs in lots of different packages
<s|k> I see
<pitti> s|k: in fact we probably have too few of those :)
<s|k> so is it mostly C?
<megabyte405> s|k: if you take the horizontal approach please make sure to send patches upstream :)
<pitti> s|k: What I'm trying to say is, we usually don't "dump" work on new contributors; you should rather know what you enjoy working on
<s|k> I see
<pitti> s|k: I'd say the vast majority of packages are C, but there's a good chunk of Python, Perl, and C# nowadays
<megabyte405> s|k:  really varies from project to project - find something that interests you, then use your skills: unlike a job where you have your skills and might be told what "interests you"
<megabyte405> and c++ too
<pitti> right ^
<s|k> I see
<pitti> s|k: if you want to work on little chunks in various packagages to use and improve your C skills, you might consider looking into fixing confirmed/triaged bugs
<s|k> ok, those are listed on launchpad?
<s|k> how well do I have to know stuff like gobject and gtk+? Pretty well huh?
<pitti> s|k: https://wiki.ubuntu.com/UbuntuDevelopment is a good introduction and link collection about how to get into Ubuntu development, the necessary packaging bits, how to apply patches, etc.
<sabdfl> anybody else seeing evince get stuck during the document loading?
<s|k> yeah I have that page open in my tab
<stgraber> sabdfl: I do
<pitti> s|k: people usually learn those while they work on something
<stgraber> sabdfl: changing the window's size usually help to unstuck it
<pitti> sabdfl: hm, works fine for me; only on some documents, or on all of them? pdf? ps?
<sabdfl> seems to be on all the .pdf's i've opened recently
<Amaranth> sabdfl: sometimes, it doesn't actually get stuck it just doesn't update the drawing
<Amaranth> sabdfl: if you minimize it then restore it it works again
<sabdfl> interesting - yes, that works
<sabdfl> could it be a compiz interaction?
<Amaranth> I am sure that is where the blame will end up
<megabyte405> s|k: if you just find something that interests you (an itch to scratch, so to speak) the skills will come with a bit of googling and some experimentation. Remember, nobody needs to know how many builds don't compile on your machine as you learn :)
<tkamppeter> pitti, hi
<s|k> megabyte405: ok :)
<pitti> hey tkamppeter! made it back in one piece?
<tkamppeter> yes, pitti, I arrived yesterday, with United.
<pitti> sabdfl: could be, I am using metacity on my desktop
<tkamppeter> pitti, it is about bug 195782.
<ubotu> Launchpad bug 195782 in hplip "Users not automatically added to "scanner" group: No scanning functions of HP multi-function in Hardy" [Undecided,New] https://launchpad.net/bugs/195782
<tkamppeter> The HP devices get there "scanner" capability without problem, but there seems to be nothing which sets the permissions then.
<tkamppeter> Permissions must be set that both "lp" and the user who is currently logged in on the desktop have read and write access.
<pitti> tkamppeter: that needs a hal debug output, I'm afraid (https://wiki.ubuntu.com/DebuggingHal)
<pitti> tkamppeter: I thought it worked for you?
<tkamppeter> pitti, I checked only the "lshal" output and that was OK.
<pitti> you didn't actually try to scan something?
<pitti> tkamppeter: well, my scanner (not HP) has the same property, it works fine for it
<pitti> so there's something wrong in hal and the auto-ACL magic
<tkamppeter> pitti, I have also removed the UDEV rules files of HPLIP, as they should not be needed any more.
<pitti> carlos: will Rosetta exports have XPI stuff for dapper to gutsy, too? if so, I need to filter them out in langpack-o-matic (since we don't want them for stables)
<carlos> pitti: that's up to asac to decide it
<carlos> if we import them, yes, it will
<pitti> carlos: ok, so I better filter them out on my side?
<carlos> pitti: not really, unless we really import them
<carlos> if we import them, I guess is because we need them
<pitti> so we won't for dapper to gutsy? asac?
<carlos> so if you filter them out... we don't need them and thus, don't neeed to import it in first place :-P
<pitti> right
<asac> pitti: he? i don't think this is an issue is it? if the translation is in langpacks users will auto get that?
<pitti> asac: but we don't want that for dapper to gutsy
<pitti> it conflicts with the mozilla-firefox-locale packages
<pitti> and we haven't tested it
<pitti> maybe later, but not right now
<tkamppeter> pitti, I have tried the debug logging of hald, but I did not find anything useful in there. The word "scanner" does not appear.
<pitti> tkamppeter: do you see anything matching 'acl'?
<asac> i don't understand why suddently _gutsy_ pops up while we are preparing hardy?
<pitti> tkamppeter: in particular, the setfacl call?
<asac> if you just want to know if we want rosetta exports in gutsy: no!
<pitti> asac: right, that was my question; whether i need to special-case hardy in langpack-o-matic or not
<asac> pitti: yes ... all this should not happen right now for anything else than hardy
<asac> pitti: we don't even have ffox 3 in << hardy
<asac> and no templates for gutsy afaict
<tkamppeter> pitti, there are calls of the /usr/lib/hal/hal-acl-tool
<pitti> tkamppeter: can you put the log somewhere?
<tkamppeter> pitti, you can see it as http://www.linux-foundation.org/~till/tmp/hal.log now.
<pitti> ci-tracker.c:366: Error doing GetSessionForUnixProcess on ConsoleKit: org.freedesktop.DBus.GLib.UnmappedError.CkManagerError.Code0: Unable to lookup session information for process '5747'
<pitti> tkamppeter: ^ do you have a consolekit sessin? ck-list-sessions
<tkamppeter> Session1:
<tkamppeter> 	uid = '1000'
<tkamppeter> 	realname = 'Till Kamppeter,,,'
<tkamppeter> 	seat = 'Seat1'
<tkamppeter> 	session-type = ''
<tkamppeter> 	active = TRUE
<tkamppeter> 	x11-display = ':0'
<tkamppeter> 	x11-display-device = '/dev/tty7'
<tkamppeter> 	display-device = ''
<tkamppeter> 	remote-host-name = ''
<tkamppeter> 	is-local = TRUE
<tkamppeter> 	on-since = '2008-04-14T14:37:30Z'
<tkamppeter> 	idle-since-hint = '2008-04-14T16:39:45Z'
<pitti> ok, that's fine
<tkamppeter> pitti, is that the expected output?
<pitti> tkamppeter: do you still have process 5747?
<tkamppeter> ps auxwww | grep 5747
<tkamppeter> root      5747  0.0  0.1 134944  3100 ?        Ssl  Apr14   0:05 /usr/sbin/NetworkManager --pid-file /var/run/NetworkManager/NetworkManager.pid
<tkamppeter> till     14546  0.0  0.0   5164   852 pts/0    R+   12:05   0:00 grep 5747
<pitti> tkamppeter: ah, that shuold be unrelated then
<pitti> tkamppeter: at which point did you plug in/switch on the scanner?
<tkamppeter> pitti, now I have uploaded a file hal2.log to the same place. There is the plugging at or at least near the beginning.
<jordi> hey
<tkamppeter> pitti, sorry, I will retry
<pitti> tkamppeter: but lshal does have the 'scanner' and 'access_control' properties?
<pitti> tkamppeter: and info.callouts.add = {'hal-acl-tool --add-device'} ?
<pitti> tkamppeter: hal2.log doesn't exist; but maybe post your lshal output first?
<jordi> I need some quick advice: my ubuntu derivative is currently using a xubuntu-7.10-alternate CD which adds the necessary packages for my project. our client decided to go with IceWM instead of XFce, and there are some hardware limitations in the project. Now that it's time to migrate to 8.04, should I rebase using a ubuntu or xubuntu CD? iow, are there any significant differences in the alternate CD installers between the two?
<Mithrandir> jordi: alternate should be very much the same.  Different package selections, naturally
<jordi> I chose xubuntu previously for xfce, but now that I'm not going to use it, I wonder if I should just go with the (better supported?) Ubuntu CD
<jordi> Mithrandir: *nod*
<jordi> Mithrandir: what about LTS support for xubuntu main packages?
<jordi> 5 years as well, for those that  differ from Ubuntu?
<pitti> jordi: xubuntu is in universe now
<jordi> oh
<jordi> see, that's a good reason to go with Ubuntu. :)
<jordi> so kubuntu and ubuntu remain in main now?
<pitti> yes, and the edubuntu bits
<jordi> oh, right
<jordi> finally, should I expect changes to the installer from today's daily alternate image to the final thing?
<tkamppeter> pitti, I have posted lshal.log now.
<Mithrandir> jordi: from experience: yes.  Not big changes, but some changes.
<pitti> asac, Riddell: hm, should we install xulrunner and firefox translations into the generic or the ubuntu langpacks? IOW, do we need them in Kubuntu, too?
<asac> pitti: interesting point. firefox is not in default kubuntu, not sure about the percentage that actually uses it though
<tkamppeter> pitti, hal2.log is uploaded now.
<pitti> tkamppeter: ah, that would be it; no access_control capabilities
<asac> tkamppeter: you know if HP DJ D1460 works out of the box in ubuntu since feisty?
<tkamppeter> pitti, and why does a scanner get this capability and an HP device not?
<pitti> tkamppeter: give me a second
<tkamppeter> asac, should do, I have other HPs which worked all the time, also inkjets.
<tkamppeter> pitti, second is over ...
<cjwatson> jordi: there will definitely be some small changes; today's daily build is actually yesterday's, and we made some changes after the build yesterday
<jordi> cjwatson: nod
<jordi> nothing I can't track during this week I guess
<jordi> thanks for the advice
<asac> tkamppeter: Works perfectly using hplip 2.7.7 when assigned as a D1300 (from linuxprinting.org) do we have at least that version in feisty?
<cjwatson> added warning before deleting contents of partitions, password handling fixes in grub-installer, a couple of other small things
<asac> tkamppeter: hmm feisty has 1.7.3?
<tkamppeter> asac, do not really know what feisty had. See Launchpad.
<asac> tkamppeter: i look at apt-cache show in feisty chroot
<asac> yes, launchpad confirms 1.7.3
<pitti> tkamppeter: ok, I see the problem, I think; the scanner property is on the usb_device, not on the scanner interface (which is /org/freedesktop/Hal/devices/usb_device_3f0_1c02_CN6B92118304R4_if1)
<tkamppeter> pitti, how does hal-acl-tool determine which ACLs to set for which devices? Is there a config file somewhere?
<pitti> tkamppeter: it looks for linux.device_file on the parent node, which should be /org/freedesktop/Hal/devices/usb_device_3f0_1c02_CN6B92118304R4
<pitti> tkamppeter: yes, it is in /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
<pitti> tkamppeter: it almost seems  like hplip attaches the property to info.subsystem = usb_device, not usb?
<pitti> tkamppeter: let me grab the hplip package
<pitti> tkamppeter: indeed, that's it
<pitti> tkamppeter: can you please try to change this in the fdi:
<Riddell> pitti: I don't mind about firefox translations, I think I'd prefer not to have them but I can see they'd be useful to others
<pitti> tkamppeter: s/usb_device/usb/ in <match key="info.subsystem" and <match key="usb_device.vendor_id" and <match key="usb_device.product_id"
<pitti> tkamppeter: try: sudo sed -i sed 's/usb_device/usb/g' /usr/share/hal/fdi/preprobe/10osvendor/20-hplip-devices.fdi
<pitti> tkamppeter: erm, drop the second 'sed', of course
<jordi> wtf
<jordi> Host packages.ubuntu.com not found: 3(NXDOMAIN)
<pitti> Riddell: hm; so rather 'no' at this point?
<jordi> hm, seems the uni's ns is fubar
<Riddell> pitti: that's my preference, but either way is fine
<pitti> Riddell: ok, installing them into the ubuntu packages then
<pitti> s/ubuntu/gnome/
<tkamppeter> pitti, reuploaded lshal.log now, lokks better, but actual permissions did not change.
<pitti> tkamppeter: right, lshal looks fine now
<pitti> tkamppeter: so xsane still fails now? sane-find-scanner doesn't find anything?
<pitti> tkamppeter: can you please do the hal debugging procedure again? (start in debugging mode, switch on scanner, send log)
<tkamppeter> pitti, xsane and hp-toolbox work, will try printing now ...
<pitti> tkamppeter: didn't you just say the permissions were wrong?
<pitti> tkamppeter: it'll still appear as root:lp, but you shouldhave an ACL on it (getfacl /dev/bus/...)
<tkamppeter> pitti, I forgot about that the ACLs are separate from the permissions. The ACLs are OK for me and with this non-printing functions work.
<pitti> \o/
<pitti> tkamppeter: so, want to prepare a new hplip source with s/usb_device/usb/ in the FDI generator?
<pitti> tkamppeter: please reopen the bug, and close it again in the changelog
<pitti> tkamppeter: would be nice to get this fixed for the release
<tkamppeter> pitti, I see now, I have moved away the 55-hpmud.rules UDEV rule file as I have considered it as obsolete. It sets the user "lp" for the /dev file of the printer. seems that I have to put it back in. Is this correct?
<pitti> tkamppeter: you need it for getting group lp to the device node, but I don't know whether you need it in the first place
<pitti> tkamppeter: you would if the hplip printing backend runs as 'lp' instead of as user
<pitti> s/user$/root/
<pitti> tkamppeter: if it works with the udev rule, and fails without, then I'd say you need it :)
<tkamppeter> pitti, so I will leave the UDEV rule in. If there are sites where it should be desired to scan when sshed in one can also add users to the scanner group then.
<asac> bryce: did you upload new xserver already? please comment on bug 186186 about the offscreen pixmap fix so i can finally close the firefox target as well
<ubotu> Launchpad bug 186186 in xulrunner-1.9 "web page background render errors" [High,Confirmed] https://launchpad.net/bugs/186186
<pitti> tkamppeter: will that actually help?
<bryce> asac, it is uploaded
<asac> bryce: can you set the bug to fix released for xserver then?
<asac> and paste the changelog. thanks
<tkamppeter> pitti, with UDEV rule I get lp:root and not lp:scanner, so something else is setting the group to root afterwards.
<jordi> cjwatson: btw, do you know who in Debian/Ubuntu would know how to write non-trivial partman-auto-raid recipes? Simon Huggins?
<bryce> 'night
<cjwatson> jordi: probably; we haven't really touched partman-auto-raid much hereabouts
<cjwatson> I might be able to make a stab at it, but I bet Simon would be better
<pitti> Riddell: ok, with that little buildd power we don't need to worry about CD builds any time soon
<jordi> cjwatson: okay. I'm not looking for something spectacular, I just can't get it working for a raid1 setup on two SATA disks with non-raid swap space and a non-raid ext3 for /srv/backups
<jordi> cjwatson: I always get "no root partition defined"
<jordi> I'll mail simon, and Cc you to see, debian-boot wasn't too helpful
<cjwatson> jordi: please attach the syslog
<jordi> cjwatson: ok
<james_w> pitti: I'm sorry, but I didn't find a sponsor for bug 153625
<ubotu> Launchpad bug 153625 in ca-certificates "update-ca-certificates error. ca-certificates.crt empty (with pt_BR locale)" [High,Fix committed] https://launchpad.net/bugs/153625
<Silicium> hi there
<Silicium> are there any problems to upgrade from hard beta to stable?
<Silicium> i can't wait :D
<RussellGee> no, you should be fine
<RussellGee> just keep applying updates and you have the final release
<Pici> !final
<ubotu> If you installed a Alpha/Beta/RC version of Ubuntu 8.04 (Hardy Heron) and have been keeping it up to date, then you are already running the latest version of Hardy. To make sure, type Â« sudo apt-get update && sudo apt-get dist-upgrade Â» in a console.
<zul> doko: ping nagios-plugins MIR question
<doko> zul: ?
<zul> doko: couldnt we put nagios-extras-plugins back?
<zul> doko: since Im not really sure what to do
<doko> zul: sure, but then you would need to build the fping and qstat plugins from this source
<zul> doko: gotcha
<doko> it's still in hardy/universe
<zul> k Ill get that done today
<doko> zul: the other possibility would be to build the -extra package from nagios-plugins and keep the binary in universe
<zul> doko: ok that would be easier
<pitti> hi james_w
<pitti> james_w: that's for stables, right? how has testing been gone for the hardy version so far?
 * Hobbsee waves
<james_w> pitti: There is a proposed update for Hardy there as well.
<pitti> james_w: ugh, the hardy task is 'fix released'
<pitti> james_w: ah, I see now; darn, nobody was around to upload this last week?
<james_w> ah, sorry, I forgot to update the status.
<Fujitsu> How do I escape from a situation like the following?
<james_w> nobody offered to sponsor, perhaps that's why.
<Fujitsu> dpkg: too many errors, stopping
<Fujitsu> dpkg: ../../src/packages.c:252: process_queue: Assertion `!queuelen' failed.
<Fujitsu> Aborted (core dumped)
<pitti> james_w: hardy uploaded
<james_w> pitti: thanks.
<pitti> mvo: simple-ccsm> there is no bug# in the changelog; is it critical for RC? where has it been ack'ed?
<pitti> mvo: (string changes, too)
<mvo> pitti: that is universe, I got a FFE from the motu-team
<pitti> mvo: ok
<pitti> tkamppeter: any luck with an updated hplip?
<mvo> pitti: hm, but have a ccsm translation update in the queue too
<hubuntu> Where can i see the code to make the Edubntu Add-on CD?
<hubuntu> I want to make an Add-On CD but with localized packages, drivers, codecs, etc.. and I do not want to make an ubuntu fork. So using the Edubuntu Add-on CD base should do the trick, right?
<hubuntu> and as a side effect we would have an add-on CD framework that do not break or fork ubuntu
<Riddell> pitti: is apport going to be on or off in gnome?
<pitti> Riddell: we'll switch it off right after RC
<pitti> Riddell, seb128: I'm still pondering whether we'll again disable it in adept/update-notifier, or disable apport completely in the default file
<pitti> I'll bring that up in Thursday's meeting
<seb128> pitti: will disabling apport make it stop hanging the program for several minutes?
<cjwatson> hubuntu: http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ and http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/
<pitti> seb128: yes
<cjwatson> hubuntu: checkout with bzr; the best place to start is probably by grepping for CDIMAGE_ADDON
<seb128> pitti: ok then disable apport completely
<pitti> and we can disable it in one location, which is more obvious to find than a gconf key
<seb128> pitti: I've enough to wait for 5 minutes when evolution crashes to be able to start it again and there is likely users annoyed by that too
<pitti> yeah; and devs can still re-enable it if they want
<pitti> seb128: that was my feeling, too
<pitti> Riddell: what's your opinion on that?
<Riddell> what seb128 said
<seb128> (not that evolution crashes often nowadays but that's an example)
<pitti> seems we alredy have a consensus then :)
<hubuntu> thanks cjwatson I'll see what i get out of it ;)
<mpt> Oh, so *that*'s the reason I never got an explanation when program's crashed in 7.10?
<mpt> programs, rather
<mpt> because I was using a final release?
<\sh> seb128, evolution crashes always, when using evolution as exchange replacement in a company with a crappy mail environment
<\sh> tbh, not evolution, but the backend part of it
<\sh> seb128, regarding imap and pop3 you are right...
<seb128> \sh: the exchange connector might crash, I've no idea about that
<\sh> seb128, it's hard to debug....there are problems while sending (e.g. attachments with more then 100k are likely to work in the first try...restarting evolution helps) and sometimes the calendar <-> evolution sync backend is crashing...whysoever...
<emgent> heya people
<afflux> sorry, dumb question: linux-restricted-modules installs some .mod.o files (fglrx, nvidia, ath_hal...). How are they supposed to get loaded into the kernel? I've for example /lib/modules/2.6.24-15-generic/volatile/nvidia.ko on my system, but it has no package and I wonder where it comes from.
<afflux> err, maybe this is rather something for #ubuntu. I'll ask there
<Amaranth> afflux: lrm-manager
<afflux> Amaranth: ah, that was the trick. Thanks a lot!
<dholbach> TheMuso: can you take a look at http://paste.ubuntu.com/7121 and tell the archive admins if you like it? (I'm asking you, because Alberto fixed the apt/sources.list thing in envyng in a different way and some other bugs along with it)
<TheMuso> dholbach: ok
<Kopfgeldjaeger> are there any plans to include disc encryption in ubiquity for 8.10?
<TheMuso> dholbach: Looks fine to me. Is there a bug open about this?
<cjwatson> Kopfgeldjaeger: it's on my list, although I am conscious that it's not a straightforward job so could slip despite the best-laid plans
<munckfish> Hi guys, xorg question - Am I correct in presuming the 'vesa' driver should not be available for the powerpc build?
<munckfish> I'm investigating LP 217647, and I noticed in the x log that it's trying to load the vesa and failing
<ubotu> Launchpad bug 217647 in xorg-server "Crash at startup on PS3 (hardy)" [Undecided,New] https://launchpad.net/bugs/217647
<cjwatson> vesa is usually a property of the graphics card, not the CPU architecture
<cjwatson> (well, ish ...)
<carlos> pitti: hi, I have a question for you about latest language pack for Hardy before release
<pitti> carlos: sure, shoot
<carlos> pitti: When will you do that final upload?
<pitti> carlos: I requested a full export, so we should get that Wednesday night, right?
<pitti> carlos: I'll build the new packages on Thursday, and have them accepted right after the RC
<carlos> right, so the plan is to upload that as the final one
<pitti> right
<carlos> ok
<carlos> pitti: hmm, we should handle LanguagePackTranslationDeadline better for next release...
<cjwatson> munckfish: but in any case it's supposed to default to fbdev on powerpc; that may not necessarily prevent it probing vesa, but at the same time that may not be what's actually failing
<carlos> pitti: it's supposed to be on Thursday, instead of today
<pitti> carlos: hm, I interpret that as "final packages must be ready by then"
<munckfish> cjwatson: ok thx for the info
<carlos> pitti: as a translator, I interpret it as, the last day to do translations that will be included in the final release
<pitti> carlos: I'd like to keep the possibility of yet another upload/rebuild before the release
<carlos> maybe we just need some clarification for next release
<pitti> in case something gets horribly wrong
<cjwatson> munckfish: that backtrace rather looks like memory corruption
<carlos> pitti: I'm not asking you to delay it
<pitti> carlos: right, we should document that better
<carlos> pitti: but to take care of it in Ibex :-D
<zul> pitti: hi http://pastebin.ca/986056 (this is for the nagios-plugin reports) I ripped out fping and qstat out of nagios-plugin-standard and put it in nagios-plugin-extra which we can keep in universe
<munckfish> cjwatson: oh oh really? I see
<cjwatson> munckfish: the sort of thing that happens if you overflow a buffer and trample on malloc's internal structures, say
<cjwatson> unfortunately, those failures aren't usually very local
<MacSlow> due to https://bugs.launchpad.net/ubuntu/+bug/215833 I'm forced to boot my laptop with 2.6.24-15 in order to try updating to 2.6.24-16.22... but with 2.6.24-15 I cannot get wifi to work anymore
<ubotu> Launchpad bug 215833 in linux-ubuntu-modules-2.6.24 "system won't boot after kernel 2.6.24-16-generic update" [Undecided,Fix released]
<pitti> zul: ah, I see; did you change the seeds for -plugins -> -plugins-standard?
<MacSlow> I tried to compile it (linux-ubuntu-modules-2.6.24-16.22) on another box but there it fails to compile
<zul> pitti: no I havent
<pitti> zul: the -plugins depends: plugins-extras will require that
<pitti> zul: or, drop it to a suggests, as you see fit
<munckfish> cjwatson: so I've no experience with these sorts of things yet. Am I likely to nail it with the normal X debugging stuff as doc'd on the wiki? Or is something like valgrind needed?
<zul> pitti: ok
<pitti> zul: the maintainer scripts are copy&paste from the existing ones?
<zul> pitti: yes
<MacSlow> is there a way to just grab a .deb from the repository-server?
<pitti> zul: diff looks good to me, modulo above issue
<zul> pitti: thanks...
<pitti> MacSlow: from archive.ubuntu.com? sure, firefox, browse to it, and click on it, gdebi will take care of it
<cjwatson> munckfish: valgrind may help if you can get it to work on the X server; I did a visual inspection but didn't see anything obvious
<cjwatson> munckfish: talk with bryce once he's up
<cjwatson> munckfish: could you attach /etc/X11/xorg.conf too?
<munckfish> cjwatson: umm I could but I probably won't be able to get it till tomorrow
<munckfish> I should have grabbed that too bother!
<TheMuso> mvo: You're not planning any final tweaks to compiz between now and final are you? If so, we may want to conider freedesktop bug  12292
<ubotu> Freedesktop bug 12292 in App/compiz "No accessibility events issued by gtk-window-decorator when Alt+Tabbing" [Normal,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=12292
<StevenK> There's an Ubuntu bug about that too
<TheMuso> StevenK: I know.
<TheMuso> StevenK: I have been contacted about trying to get it in for hardy.
<mvo> TheMuso: we discussed this in #compiz-fusion-dev, the fix seems to be not complete, but its a great start, I think I need to commit one or two small tweak for compiz for RC
<TheMuso> mvo: Oh ok.
<munckfish> cjwatson: what tz is bryce in?
<mvo> TheMuso: but my information is already ~4h old, its quite likely that the remaining bits are fixed now too, I will check. the initial patch was small and obvious enough to include it IMO
<cjwatson> munckfish: US/Pacific
<munckfish> ok i c
<munckfish> I may prepare a mail to the ubuntu-x list, I won't be able to work in this tonight
<TheMuso> mvo: Ok, thanks a lot.
<munckfish> thx for your help again
<cjwatson> munckfish: it looks like it ought to be soluble, but this is just an instinct thing
<cjwatson> I mean, soluble without anything very difficult - because it's so early in the startup process and the crash is in ordinary library functions
<cjwatson> munckfish: it also seems possible that if all else fails it might be soluble with explicit configuration just for ps3, since it's in the autoconfiguration code
<munckfish> cjwatson: yes this is one thing I wanted to try tomorrow morning
<munckfish> I want to grab the xorg.conf from the gutsy install
<munckfish> and bung it over the auto-gen'd one
<munckfish> see if that solves it
<cjwatson> it would certainly explain the regression from gutsy to hardy; I expect it will, though you may have to tweak a bit
<munckfish> cjwatson: if this was the case, how would be get PS3 specific xorg.conf to happen in the install process?
<cjwatson> setting DISCOVERED_VIDEO="fbdev" somewhere appropriate in xserver-xorg.postinst if the current machine is a PS3 would be sufficient
<munckfish> e.g. what packages would need to be updated to carry that extra knowledge (I don't know the installer system very well at all)
<cjwatson> it's all in X; xorg is the source package in question, xserver-xorg is the binary package
<cjwatson> we like delegating this sort of thing to packages rather than trying to encode all the knowledge in the installer
<munckfish> ok xorg like our glue package isn't it?
<cjwatson> right
<munckfish> ok, how long are we looking at for this now btw? e.g. RC build is 17th
<munckfish> is that our cut-off?
<cjwatson> can't really do it before RC now, but if you have a tested fix ready for right after RC then it should be possible
<cjwatson> the RC builds have to be ready well before it actually releases, for testing
<munckfish> ok
<Mirv> mvo: would you now happen to have time to upload the bug #216211, it has ack in the bug report now from the motu release
<ubotu> Launchpad bug 216211 in compizconfig-settings-manager "ccsm Finnish translation broken again" [Undecided,New] https://launchpad.net/bugs/216211
<seb128> pitti: is bug #215948 something which needs an exception? cheese is a GNOME package and not on the CD, would be nice to have but if it's not updated that's alright too
<ubotu> Launchpad bug 215948 in cheese "Update cheese to 2.22.1 (include hildon patch)" [Undecided,In progress] https://launchpad.net/bugs/215948
<pitti> seb128: it's part of gnome, so I'd say it's just subject to the general RC freeze
<seb128> pitti: which means upload and wait?
<pitti> yeah, please go ahead
<seb128> pitti: it's not on the CD so should not be too much trouble
<seb128> pitti: ok, thanks
<mvo> Mirv: thanks, doing that now
<Mirv> mvo: thanks.
<kees> slangasek: can you let refpolicy 0.0.20071214-0ubuntu3 into universe?  This will let SELinux folks have a more useable RC experience.  :)
<emgent> heya kees :)
<kees> hi emgent
<mvo> Mirv: uploaded
<asac> bryce: i am not sure what your patch did, but it definitly didn't turn off offscreen pixmaps
<asac> maybe you forgot to port it for 1.4?
<asac> bryce: i 1.4 the setting is negated: XaaNoOffscreenPixmaps ... vs XaaOffscreenPixmaps in 1.5 (fedora)
<asac> bryce: i have: ii  xserver-xorg-core                       2:1.4.1~git20080131-1ubuntu8
<tkamppeter> pitti, I have made a new HPLIP package with the fdi file updated. see bug 195782
<ubotu> Launchpad bug 195782 in hplip "Users not automatically added to "scanner" group: No scanning functions of HP multi-function in Hardy" [High,In progress] https://launchpad.net/bugs/195782
<pitti> tkamppeter: ah, did you test it with a full package build/install/scanner test?
<pitti> tkamppeter: thanks, I'll get to it
<pitti> tkamppeter: how did you end up with "hplip-dbg_2.8.2-0ubuntu8_source.changes"? it should be "hplip_..."
<tkamppeter> pitti, I simply copied the wrong line to get the name. The file is the correct one, I should better find a way to auto-generate the name, otherwise I produce simply white noise. The content is correct.
<asac> bryce: you forgot to enable it in series :)
<asac> i am doing a test build and will upload
<tkamppeter> pitti, file name is corrected now.
<pitti> tkamppeter: "way to auto-generate" -> what do you use, debuild -S and dpkg-buildpackage -S automatically create the source.changes?
<ion_> asac/bryce: Confirmed, the bug with firefox and scaled images still exists.
<asac> ion_: the patch is not applied :)
<asac> currently fixing that
<ion_> :-)
<pitti> tkamppeter: accepted, thanks
<asac> ion_: takes a bit :) ... doing a test build to be sure ;)
<tkamppeter> pitti, I do "dpkg-buildpackage -rfakeroot" to generate source and binary packages. Then I install the binaries to see whether they install and work. The only missing file after that is the _source.changes. I use "dpkg-genchanges -S" to generate it, only this command generates it on stdout and not in a file.
<pitti> tkamppeter: oh, I see; IMHO "debuild -S" and then "debuild -us -uc -b" is a bit easier, but your's works, too (although it's pretty unusual)
<asac> tkamppeter: its handy to first run -S ... and then -b :)
<asac> that will give you the chance to trash all and unpack the clean .dsc again
<cjwatson> I often do debuild -S, unpack in temporary directory, debuild -b
<munckfish> cjwatson: are you on the ubuntu-x list? do you want me to CC you in my mail there?
<tkamppeter> pitti, HPLIP now appears as in "waiting for approval" state. Are you a distro manager to approve it? If not, is additional info needed to add to the bug report?
<cjwatson> munckfish: I suggest CCing ubuntu-cell
<cjwatson> I'm not on ubuntu-x
<munckfish> ok cool
<Hobbsee> tkamppeter: it's already picked up
<Hobbsee> assuming teh queuebot doesn't lie, anyway
<tkamppeter> Thanks, pitti and Hobbsee
<pitti> tkamppeter: as I said, I just accepted it; it's already building
<Hobbsee> y/w
<pitti> yay for new soyuz insta-build-record creation \o/
<cjwatson> pitti: particularly since the publisher is down :)
<pitti> cjwatson: but that would affect build-from-done (instead of published archive), right? or what do you mean?
<cjwatson> pitti: I mean that it's particularly good that it's fixed since we don't have to wait for the publisher ...
<pitti> cjwatson: right; what I meant is, now we do not even need to wait for this horribly slow buildd queue-builder
<tkamppeter> pitti, bug 217787. Seems that /lib/security/pam_smbpass.so got taken from the distro lately.
<ubotu> Launchpad bug 217787 in cupsys "cups crashes when using web-gui and refuses to print" [Undecided,New] https://launchpad.net/bugs/217787
<cjwatson> pitti: I hope it's not just because the publisher is down ...?
<cjwatson> as in, it's not going to slow back down again once I restart it?
<tkamppeter> pitti, "Accepted" notification for HPLIP has arrived.
<pitti> cjwatson: when I praised the soyuz guys for it, they didn't seem surprised, so I hope it'll stay that way :)
<cjwatson> tkamppeter: pam_smbpass.so was only recently added in the default stack, but the error should be cosmetic
<pitti> (this was one of my pet nags for soyuz, and I complained very often)
<cjwatson> tkamppeter: I doubt it's actually the cause of that bug - it's just some log messages that people noticed at around the same time!
<asac> bryce: ok attached all the pieces that will go up to bug 182038
<ubotu> Launchpad bug 182038 in xorg-server "Black rectangle instead of image in FF3 [Hardy]" [Medium,Fix committed] https://launchpad.net/bugs/182038
<kees> cjwatson, pitti: can one of you release refpolicy (universe)?
<pitti> hey kees
<kees> heya pitti :)
<pitti> I had a look at it earlier, but it looked very intrusive; let me look again
<pitti> kees: right, most of the changes don't even have bug refs, so I couldn't check approval status
<pitti> and the patch -- description ordering in the changlog is ... confusing
<kees> pitti: hrm, true, it's cosmetic though.  only selinux would be affected by that upload, and is currently not installable without it.
<pitti> kees: not installable? how come? it's just patches, no dependency changes etc?
<kees> pitti: right, I don't mean packaging-uninstallable, but rather one cannot get SELinux up and running.
<pitti> kees: you can vouch that the new version doesn't aggravate it?
<kees> pitti: upstream vouches, but if you want me to test it as well, I can do that first.
<seb128> pitti: can you reject the libgweather upload I just did?
<pitti> seb128: not in queue yet
<seb128> ok
<pitti> seb128: also, you can just reject it yourself if you want
 * pitti waits another 3 minutes, when it should appear
<seb128> pitti: ok, that was a "don't accept it" rather ;-)
<pitti> :)
<seb128> pitti: in case you were quicker
<max_> I LOVE UBUNTU :)
<pitti> max_: :)
<pitti> seb128: kicked
<seb128> pitti: thanks
<seb128> I'll reupload after diner a fixed version
<seb128> I've to go now
<zeld> hi to all : )
<zeld> i've read about genbuntoo...
<zeld> : )
<zeld> what about the project at the moment?
<laga> ask the author?
<Pici> zeld: https://wiki.ubuntu.com/GenBunToo - As you can see, its not an Official Ubuntu derivative.
<jdong> we have nothign to do with the project
<laga> you can also install portage and emerge on ubuntu. i guess. probably nobody has tried it, but it should be possible ;)
<jdong> it's not, by any means, a ground breaking concept
<jdong> IMO the authors need to read up on apt-build
<jdong> which ALREADY does what this set of primitive pseudo broken "shell scripts" does.
<zeld> ok thanks guys : )
<zeld> but i want only ubuntu with precompiled package : D
<zeld> only for information...
<zeld> in front of portage i prefere pkgsrc : )
<jdong> well what's clear is anyone who uses this methodology is on their own in terms of bug reports.
<laga> i dont think "optimization" will benefit many people
<jdong> laga: agreed
<jdong> maybe 1-2% speed up at most in 99% of scenarios
<zeld> jdong:  u think?
<jdong> most of the things that benefit from compiler-flag optimization already do so in their build scripts
<jdong> zeld: yes.
<zeld> but i386 is obsolete...
<zeld> : S
<jdong> zeld: do you want to list exactly what -march=nocona does over -march=generic?
<zeld> jdong: i know the arch and the list : D
<jdong> zeld: rough answer is not much. tiny microoptimizations that can either reduce or improve performance
 * laga debuilds vim with -O99
<zeld> many cpu are based and compatibly with 386
<ion_> One kind of optimization that would be beneficial would be somehow measuring the branches programs typically choose and take that into consideration when compiling. But i don't know a generic way to implement that.
<zeld> laga: LOL!
<jdong> zeld: on x86 based architectures compile-time instruction set optimizing is not helpful.
<laga> zeld: then use amd64, most cpus are compatible and these builds are often more optimized
<jdong> ion_: kind of done already
<jdong> ion_: firefox supports building with PGO
<jdong> ion_: which essentially runs that spidermonkey test suite while profiling the browser, and rebuilds according to that data
<zeld> : )
<zeld> understod jdong laga  : )
<jdong> ion_: I've heard that it could increase performance 7-fold on some routines compared to our existing firefox
<jdong> zeld: my point is optimization is not just blindly sticking three options to GCC
<jdong> zeld: I was a Gentoo user for far longer than I'm an Ubuntu user/developer
<jdong> zeld: and even back then I failed to notice much if any difference between various compiler-time flags
<ion_> jdong: Yes, that's a way to do it, but it's not a generic way. Every program would then need to have a test suite and have it run with profiling on during the build process.
<jdong> ion_: how much more generic could one make it though?
<jdong> ion_: a test suite could be as easy as scripting firefox to load some website, mencoder to encode a test video, etc
<ion_> jdong: Have a repository section with packages built with profiling on and a cron job that posts the results to an Ubuntu server, have the server average the results and then rebuild packages based on them to the normal sections, tell people to use the profiling sections while informing them of the implications? :-P
<\sh> if someone from ubuntu-release is so kind and review bug #211326 and think about upgrading rsync ...:)
<ubotu> Launchpad bug 211326 in rsync "[Freeze Exception] Please update rsync to 3.0.x for hardy" [Wishlist,New] https://launchpad.net/bugs/211326
<jdong> ion_: haha
<jdong> ion_: interesting idea
<davmor2> help! please.  I have to keep rebooting to burn test cd's.  It's only happened over the last few days.  If I leave the dvd-rw for any length of time it becomes unusable until I reboot then it works fine until I leave it again.
<zeld> bye peopple : )
<slangasek> kees: refpolicy> please get approval from motu-release
<kees> slangasek: okay
<psyke83> hi, I'd like to bring bug #192888 to everyone's attention (the problem where firefox crashes sporadically due to flash). I found a workaround that we could have ready for Hardy's release. See my comments there
<ubotu> Launchpad bug 192888 in pulseaudio "firefox crashes on flash contents" [Undecided,Confirmed] https://launchpad.net/bugs/192888
<psyke83> basically, I found out that Fedora 9 (i386 version) comes preinstalled with pulse, libflashsupport *and* nspluginwrapper). It seems that having flash isolated in the npviewer.bin process prevents firefox from crashing
<psyke83> I manually compiled nspluginwrapper for i386, installed the wrapper plugin and flash, and firefox doesn't crash anymore in Hardy
<mario_limonciell> er doko_, it looks like you messed up on the color prompt stuff in bash?  your variable to be uncommented is force_colored_prompt, where as later in the bashrc you check for force_color_prompt
<mario_limonciell> i
<mario_limonciell> ll file a bug :)
<\sh> psyke83, please add your observations to the bug, pls :)
<psyke83> \sh, I already did, but I thought that I'd ping everyone in here in case I grab someone's attention that isn't subscribed
<psyke83> my findings are in the last two entries (my name there is Conn)
<\sh> psyke83, asac is the man for that problem actually...and yes, we saw the crash on i386 without the wrapper but not on amd64 where we need the wrapper
<psyke83> \sh, right
<ion_> Yeah, getting rid of the flash crashes would be nice indeed. :-)
<psyke83> \sh, flash seems to continue crashing at times (the pulseaudio developers realized that the problem is in the flash plugin), but using the wrapper means that the firefox process will never crash - you just get a grey box and an error dialog, and reloading the page fixes the problem
<\sh> ion_, getting rid of a closed source, crashing flash would be nice, yes :)
<psyke83> this behaviour is the same as in Fedora 9 (with flash sometimes turning grey; I presume it is crashing)
<\sh> psyke83, actually the crash come later...on amd64 I'll have the crash after I closed firefox actually...
<psyke83> \sh, damn :(
<\sh> psyke83, and ubuntus crash dialog tells me, it's pluginwrapper which is crashing
<psyke83> I didn't notice firefox crashing yet, but I'll continue testing... nevertheless, it seems better to use the wrapper if it offers some protection against the entire firefox process segfaulting
<\sh> not flash actually..but I think it's the trigger for this
<psyke83> \sh, this is the real problem: http://www.pulseaudio.org/ticket/267
<psyke83> it just so happens that nspluginwrapper lets us recover from flash (and the wrapper) crashing
<psyke83> ...and if the bug is in flash, we can't really solve it directly.. damn closed source :P
<\sh> psyke83, right :)
<\sh> psyke83, no...damn adobe to add some different behaviour to the sec fixed flash player...
<\sh> psyke83, which is not even documented, at least not on the adobe web page...
<saivann> Some people reported that they had wrong Swap partition UUID in /etc/initramfs-tools/conf.d/resume in bug 205990, can someone take a look at this? Looks that it might be a side effect of replacing volumeid by uuid-runtime that might cause upgrade issues between gutsy and hardy
<ubotu> Launchpad bug 205990 in usplash "[hardy] splash screen disappears after a few seconds" [Medium,Triaged] https://launchpad.net/bugs/205990
<psyke83> \sh, I downgraded flash and it still seemed to crash, IIRC
<psyke83> should I add the flash bug to track nspluginwrapper so the maintainer can consider creating an i386 build, or should I leave it, do you think?
<\sh> psyke83, well, actually the .115 never crashed for me on i386
<psyke83> \sh, with libflashsupport enabled?
<\sh> psyke83, no just leave it to flashplugin-nonfree, I think the decision will be a critical one regarding the time of release
<\sh> psyke83, really, I don't want to make this decision...because listening to ogra and his ltsp stuff, it works somehow...regarding i386 user, they are freaked away because of this, and amd64 users are happy
<cjwatson> saivann: volumeid wasn't replaced by uuid-runtime
<cjwatson> saivann: worth checking whether multiple Linux installations were involved
<saivann> cjwatson : when updating initramfs-tools, volumeid is uninstalled and uuid-runtime is installed
<psyke83> \sh, I can imagine it's a tough call, since a) there will be many unhappy users due to firefox constantly crashing, b) we can't tell when Adobe will fix this issue (or if they will at all) and c) using nspluginwrapper on i386 will require lots of changes for plugin detection etc, unless you use it exclusively for flash, and handle it in the flashplugin-nonfree package's scripts
<cjwatson> saivann: sure, but you've drawn the wrong conclusion :)
<saivann> cjwatson : Ha, sorry :)
<cjwatson> saivann: volumeid was merged back into udev, and the uuidgen program was split out of e2fsprogs into uuid-runtime
<psyke83> I think a decision should be made soon though, for or against
<saivann> cjwatson : I just looked at the changelog.. yes
<cjwatson> anyway, this doesn't really help you with the bug as such, just wanted to clarify that
<saivann> cjwatson : You believe that having multiple linux system on the same computer using the same swap partition might cause the UUID to change?
<cjwatson> there have been bugs in that sort of general area
<cjwatson> we've never tracked them down for certain
<saivann> at least if having wrong values in /etc/initramfs-tools/conf.d/resume can't have a real negative impact..
<cjwatson> it would be interesting to know if any non-Ubuntu Linux systems are involved (though may not be)
<saivann> cjwatson : I asked the question in the bug report
<saivann> thanks
<\sh> psyke83, well, it's 9 days before release...I hope that everyone is sane enough to not introduce another serious regression...if the bug is known, and we can document a workaround or push a fixed flashplugin later into hardy...I would say: stay with it..but that's me...I have to work with flash all day long in my company :)
<cjwatson> saivann: I don't see how this can possibly be related to the usplash crash Scott diagnosed earlier in that bug report. Are you sure that you aren't helping to make the bug report more confusing by conflating several different issues? People with different issues from the original reporter should be directed to file a new bug.
<stgraber> pitti: any idea about bug 217815
<ubotu> Launchpad bug 217815 in debian-installer "When selecting LVM Crypt, erase never ends" [Undecided,New] https://launchpad.net/bugs/217815
<cjwatson> I just commented on that ...
<\sh> psyke83, actually I know now what's not working and I can do something against it: 1. installing amd64 on 64bit dual core machine, or stay with the crash on i386 :)
<stgraber> pitti: I don't usually wait for the erase disk step to complete so haven't experienced it myself but it has been reported twice already (two different reporters)
<saivann> cjwatson : I'm also suprised but this has been confirmed by three persons + people from the ubuntuforum. Don't forget that it happens when "Reading files needed to boot"
<cjwatson> saivann: it is *not related* to the usplash segfault. It is a different problem that may happen to have the same symptoms.
<cjwatson> it's entirely possible for different bugs to have the same symptoms - if they all end up piled into the same bug report then the bug report ends up impossible to deal with
<psyke83> \sh, heh... and the common opinion held is that Ubuntu x86_64 is less stable than x86... how ironic that it's now more stable because of propitiatory software, heh
<pitti> stgraber: so cancelling works?
<kees> cjwatson: which bug is the usplash crash?
<cjwatson> kees: 205990
<pitti> stgraber: hm, last time I tried that, it finished successfully, but that's some weeks ago already
<cjwatson> <Keybuk> "usplash segfault in bogl_tcfb_put" and attach the trace
<cjwatson> <Keybuk> it looks to me like it's gone out of the bounds of the framebuffer
<psyke83> *proprietary
<saivann> cjwatson : So I might have complicated things.
<stgraber> pitti: cancelling works for me (just finished my alternate i386 lvm-encrypted test)
<cjwatson> of course it's hard to tell that *that's* the same issue as the original reporter, too
<cjwatson> the original reporter said "
<cjwatson> the original reporter said "I have tried without quiet and splash options and I don't see any segfault ...
<cjwatson> "
<\sh> psyke83, well, that I can't underline, I'm working at home on amd64 only...and I have to say, it's at least stable for me to do my daily tasks...which is compiling, using openoffice and playing nexuiz ;)
<cjwatson> but, at any rate, there are at least two different problems in that bug, and many different users
<psyke83> \sh, heh. I can't comment, as I've never owned a 64bit system :(
<stgraber> pitti: I'm doing another testcase now (LTSP) but will install on encrypted LVM and will wait this time instead of immediatly canceling it
<pitti> stgraber: thanks; maybe do it on a small HD in VMWare :) (that's what I usually do)
<stgraber> pitti: the HDD in this computer is 10GB large, that shouldn't take very long
<saivann> cjwatson : Mmh.. the initial reporter dmesg file does not contain any segfault, only the w00t one. It seems clear that there is two bugs here.. as you just noticed
<cjwatson> saivann: ok, if that's the case then the segfault people need to be redirected :)
<cjwatson> either way ...
<cjwatson> I'm not sure that a usplash segfault would show up in dmesg, mind you
<cjwatson> after all it's just an ordinary userspace application - why would it show up in the kernel ring buffer?
<jdong> cjwatson: on x86-64 segfaults show up in dmesg
<jdong> [243994.160735] tomboy[18006]: segfault at b5d7fb40 eip b5d7fb40 esp bfa2e53c error 4
<jdong> not just x86 actually
<jdong> it's happening on 32-bit in Hardy too
<jdong> that's new, but x86-64 has done it for a while
<stgraber> cjwatson, pitti: about bug 217815 couldn't it be that the eraser is lacking of random values to write on the disk and is waiting for input device activity to generate real random values ?
<ubotu> Launchpad bug 217815 in debian-installer "When selecting LVM Crypt, erase never ends" [Undecided,New] https://launchpad.net/bugs/217815
<saivann> cjwatson : the segfault appears for woot, but not other users that posted their dmesg
<pitti> stgraber: it sounds unlikely to me, since /dev/random would be empty *very* fast, and urandom isn't supposed to be blocking
<pitti> stgraber: but of course anything is possible, IANAKD
<cjwatson> jdong: is that true for all possible kernel paths that could raise SIGSEGV? It seems to be just in the page fault code
<stgraber> ok, the "moving the mouse in the guest" part made me remember of GPG and some other encryption tools like that
<pitti> stgraber: but that would be a funny situation: urandom being blocked on disk I/O to get entropy, disk I/O being blocked on urandom for delivering more data :)
<stgraber> pitti: indeed :)
<jdong> cjwatson: that might be true. Killing arbitrary processes with SEGV doesn't do it
 * jdong might be confusing the pagefault mechanism with grsec's signal audit framework
<cjwatson> stgraber: as far as I can see, partman-crypto doesn't use random data, it uses zeroes
<cjwatson> (for the erase)
<cjwatson> stgraber: so, no, I don't think that is possible
<cjwatson> stgraber: did you reproduce it in kvm, or elsewhere?
<stgraber> I'm trying to reproduce on real HW
<cjwatson> Apr 15 16:27:37 main-menu[3032]: (process:14634): [:
<cjwatson> Apr 15 16:27:37 main-menu[3032]: (process:14634): /: unknown operand
<cjwatson> hmm, what's that about
<cjwatson> joy, *somewhere* in partman
<stgraber> cjwatson: http://iso.qa.ubuntu.com/qatracker/result/1453/195
<stgraber> this one is on real HW
<cjwatson> very odd
<saivann> cjwatson : Well do you still believe that I should ask the people that gets a backtrace to open a new bug report?
<saivann> cjwatson : s/backtrace/segfault/
<cjwatson> saivann: yes please
<saivann> cjwatson : Ok thanks for your guidance
<cjwatson> stgraber: oh, I suppose it could be that it's writing zeroes to the encrypted device and access to the encrypted device is blocking due to lack of randomness. or something
<cjwatson> we do seem to set up dm-crypt using /dev/urandom though
<cjwatson> unless cryptsetup is using /dev/random somewhere else
<stgraber> cjwatson: reproduced in KVM
<stgraber> cjwatson: I created a VM without network access, 128MB of RAM and with a 1GB HDD. It first got stuck at 8%, then at 33% and finally found enough entropy to complete
<stgraber> for both 8% and 33% moving mouse or any other kind of activity seems to make it continue
<stgraber> erase disk worked correctly on real HW (never got stuck)
<cjwatson> I reassigned the bug to partman-crypto, but I don't think it really belongs there
<seb128> pitti, slangasek: I've just uploaded a libgweather update, would be nice to get for hardy, is it late to get it accepted now?
<cjwatson> does /dev/urandom exist, out of interest?
<stgraber> it does
<mo__> i have ha problem, any kernel above 2.6.24-12 freezes while booting at "loading device drivers" . INFO: AMD Phenom/Ubuntu 8.04 Beta
<amitk> mo__: upgrade your kernel, it was fixed
<kirkland> anyone know of a website that hosts Ubuntu Manpages?  Something similar to manpages.debian.net, or linuxmanpages.com, but Ubuntu-specific manpages?
<mo__> amitk, i did upgrade it today, still the same
<stgraber> Just tried once again with kvm and a "standard" VM (kvm -hda test.img -cdrom blah.iso), if you don't leave the VM and don't press any key or move your mouse it'll freeze after only a few %
<cjwatson> kirkland: I've never heard of one
<amitk> mo__: are you running -16?
<kirkland> cjwatson: bummer, okay.  I'm building one now.
<mo__> amitk, for the moment -12, -16 fails
<mo__> amitk, as -14 does
<amitk> mo__: try -16 again, there should be a new version of linux-ubuntu-modules for -16
<cjwatson> kirkland: excellent
<cjwatson> kirkland: I'm happy to help from the groff/man point of view if you run into toolchain problems
<cjwatson> (I assume you're going to be using groff to build the HTML output; it would be a good idea ...)
<kirkland> cjwatson: i might like your review of the pair of scripts I'm using to generate it
<cjwatson> sure, send me mail?
<amitk> mo__: does waiting for it to boot (for a long time) continue the boot? Just to be sure that we are talking about the same problem....
<mo__> amitk, yes, the modules update came a few days ago, it did not solve the problem (for me)
<kirkland> cjwatson: i was actually just building flat text, but HTML might be nice too
<mo__> amitk, yes of course, it skips after a minute or smth
<cjwatson> kirkland: oh, ok, either way
<mo__> amitk, or after pressing ctrl+alt+del
<amitk> mo__: strange... let's move to #ubuntu-kernel
<asac> anyone knows why bash completion is completely broken here on my laptop (up-to-date), while it still works on my desktop (up-to-date)
<davmor2> asac: cause it's you laptop :P
<asac> you mean TAB is broken?
<megabyte405> try compressed air ;)
<kirkland> evand: I hit an error testing Kubuntu i386 Alternate ISO, OEM installation.  I'm filing a bug against oem-config, curious if there are particular logs that might be useful.  Riddell pointed me your way.
<tgillespie> hi, is it just me or is the latest boost build broken?
<evand> kirkland: depends on the error, but typically running the installer in debug mode (`ubiquity -d` in a terminal) and attaching /var/log/syslog, /var/log/partman, and /var/log/installer/debug is sufficient.
<kirkland> evand: install succeeded, boots into Kubuntu, installed an additional application (audacious), clicked oem-config-prepare, rebooted; on reboot X fails to come up, drops to a root shell
<kirkland> i'm sitting at that root shell, will grab /var/log/syslog, /var/log/partman, and /var/log/installer/debug, file the bug, and move on with my testing
<mario_limonciell> kirkland, if X is failing to come up, you may consider grabbing /var/log/Xorg.0.log too
<kirkland> mario_limonciell: yup, i had that one
<cjwatson> kirkland: also /var/log/oem-config.log, please
<kirkland> cjwatson: okay
<kirkland> evand: cjwatson: Riddell: FYI: https://bugs.edge.launchpad.net/ubuntu/+source/oem-config/+bug/217884
<ubotu> Launchpad bug 217884 in oem-config "Kubuntu OEM failure on second boot" [Undecided,New]
<mdke> asac: just noticed the existence of start.ubuntu.com - is someone working on keeping that synched with changes to ubuntu-docs or is it automatic?
<asac> mdke: oh, you are the  creates the content of ubuntu-docs
<asac> right?
<asac> sorry if i forgot. but i think my brain just wiped everything not of immediate concern :)
<mdke> asac: well, the ubuntu-core-doc team has commit access to the bzr branch, but I tend to take care of most changes in the package, with dholbach's help :)#
<asac> mdke: so you know how all this works?
<asac> good ... please join #ubuntu-mozillateam
<asac> ill get someone for you
<asac> mdke: ?
<mdke> on my way
<kees> slangasek: bug 216132 ack'd by motu-release (refpolicy).
<slangasek> kees: ok, accepted, thanks
<evand> kirkland: thanks, found the problem and uploading a fix momentarily.
<kirkland> evand: oh, cool.  i was trying it again in case it was something i had done wrong ;-)
<mjg59> laga: No
<tjaalton> slangasek: new xorg with the fix for bug 217724 uploaded
<ubotu> Launchpad bug 217724 in xorg "xqbiff prevents x11-common from removing /usr/X11R6/bin" [High,Confirmed] https://launchpad.net/bugs/217724
#ubuntu-devel 2008-04-16
<corevette> where does ubuntu get the logos on the main site ( http://www.ubuntu.com/ ) (e.g. the blue question mark on the left, or the cd's in the download section...)
<d3lf1n0> Know tell me if my modem trustmd4050 serves to force a spitter ... because does not connect to ubuntu: (
<d3lf1n0> splitter*
<slangasek> TheMuso: ping
<slangasek> Amaranth: have you looked at james_w's patch in bug #118936, by chance?
<ubotu> Launchpad bug 118936 in alacarte "Alacarte does not recover deleted menu items" [High,Triaged] https://launchpad.net/bugs/118936
<Amaranth> yeah, that was a goofy bug on my part
<Amaranth> but it only makes undo work, not revert
<Amaranth> i have no idea how to make revert work
<slangasek> well, should we be trying to get the fix for "undo" in at least?
<Amaranth> yeah
<slangasek> ... and is this patch a good one for it? :)
<Amaranth> it looks like it, haven't tried it
<Amaranth> will do so tomorrow
<slangasek> ok, thanks
<nenolod> slangasek, about bug #191027, i can't reproduce it on my hardy machine
<ubotu> Launchpad bug 191027 in totem ""Failed to connect stream: Invalid argument"" [High,Invalid] https://launchpad.net/bugs/191027
<slangasek> nenolod: well, nor mine
<nenolod> however, i saw something else on pulse 0.9.10 which seems related
<nenolod> i'll try to reproduce that
<nenolod> slangasek, anyway, "Invalid argument" says to me that it's trying to connect to a dead socket
<nenolod> which I have seen before
<nenolod> follow sent :)
<nenolod> followup*
<slangasek> nenolod: ok, cheers
<nenolod> i made a scary amount of typos there
<TheMuso> slangasek: You called?
<slangasek> TheMuso: yes, was hoping you could have a look at bug #191027
<ubotu> Launchpad bug 191027 in totem ""Failed to connect stream: Invalid argument"" [High,Invalid] https://launchpad.net/bugs/191027
<StevenK> slangasek: I'll be uploaded moblin-{applets,media} in the next hour or so if I can bug you to accept them?
<StevenK> Sigh.
<StevenK> I can type, some days
<TheMuso> slangasek: I see its marked invalid. Is there still an issue?
<slangasek> StevenK: you should get it approved by motu-release so I don't have to think about it :)
<Hobbsee> StevenK: looks like i can accept them, too
<StevenK> slangasek: It's all in bug 181150
<ubotu> Launchpad bug 181150 in moko "[FFe] moko contains a shared library with no soname/dev package handling" [Critical,Confirmed] https://launchpad.net/bugs/181150
<Hobbsee> *and* am part of motu release
<Hobbsee> oh, meh, that's new package
<StevenK> That's done
<Hobbsee> slangasek: can deal with them
<slangasek> TheMuso: it's "invalid" for totem, "new" for pulseaudio
<slangasek> Hobbsee: thanks :)
<TheMuso> slangasek: Oh ok.
<StevenK> This is part #2, and #3, getting the rdepends to use it
<slangasek> TheMuso: someone should've reassigned it to pulseaudio much, much earlier :)
<TheMuso> slangasek: Right. Will have a look.
 * StevenK wonders if he has free reign to upload the other two packages 
<fabbione> morning guys
 * TheMuso sighs.
<TheMuso> The trouble with things like this is when you have working hardwrae, this sort of thing is hard to track down by asking the users to do things for you...
<slangasek> well, yes :)
<slangasek> I was hoping you might be more adept at it than I given this particular piece of software though :)
<TheMuso> Right, for some of it at least, I think its to do with alsa, but I'm not 100% sure yet.,
<TheMuso> slangasek: The problem with setting up alsa apps to use pulseaudio in alsa-lib, is doing it in a way tha tdoesn't affect those desktops not using pulse, i.e KDE and XFCE.
<slangasek> mm, ok
<slangasek> yes, trickier then
<TheMuso> And while all applications can use the default alsa device, not all apps can be set to use a custom asoundrc config, let alone choose another card to use.
<TheMuso> Due to either their UIs, configs, or alsa support implementations.
<slangasek> yes
<TheMuso> Added to that, we'd have to seed libasound2-plugins.
<slangasek> it may be to better effect if you were to say this in the bug log - you don't need to convince me that it's a hairy proposition, I've had enough trouble just trying to get ekiga to work with my bluetooth headset ;)
<TheMuso> Yeah I will. Just letting you know where things stand.
<Hobbsee> remorning fabbione
<fabbione> hey Hobbsee
<TheMuso> In python, is it possible to wait forever, until say a file exists? As in wait for an undefined length of time. The file will exist, but I just have to wait for it to do so.
<TheMuso> nvm worked it out
<dholbach> good morning
<dholbach> TheMuso: did you check out the envyng-core update?
<\sh> moins
<\sh> pitti, when you have time, could you review bug #211326 IMHO it's good when we would go with this version for hardy, regarding sec issues in future etc.
<ubotu> Launchpad bug 211326 in rsync "[Freeze Exception] Please update rsync to 3.0.x for hardy" [Wishlist,New] https://launchpad.net/bugs/211326
<TheMuso> dholbach: It seems alright with me, but my python is not exactly strong.
<TheMuso> dholbach: iS THERE A BUG ASSOCIATED WITH IT?
<TheMuso> gah capslock
<dholbach> TheMuso: a few - hang on
<dholbach> bug 216303 (for one), looking for the others not referenced from the changelog
<ubotu> Launchpad bug 216303 in envy "EnvyNG crashes on latest hardy" [Medium,Fix committed] https://launchpad.net/bugs/216303
<TheMuso> ok will have a look.
<dholbach> bug 216009 and bug 216184 too
<ubotu> Launchpad bug 216009 in envyng-core "pulse.py crashed with KeyError in process()" [Medium,Triaged] https://launchpad.net/bugs/216009
<ubotu> Launchpad bug 216184 in envyng-core "pulse.py crashed with KeyError in process()" [Undecided,In progress] https://launchpad.net/bugs/216184
<dholbach> bug 216967 too
<ubotu> Launchpad bug 216967 in envyng-core "duplicate deb lines in envyng.list" [Undecided,In progress] https://launchpad.net/bugs/216967
<dholbach> so 3 of 4 open envyng-core bugs :)
<TheMuso> dholbach: If you are looking for a MOTU release ACK, then you have it. if you want me to officially do it in a bug, which one?
<dholbach> TheMuso: no, should be enough to let the archive admins know that you've ACKed the envyng-core upload
<dholbach> pitti, slangasek: ^
<slangasek> dholbach, TheMuso: accepted
 * dholbach hugs TheMuso and slangasek
<dholbach> cjwatson, evand: in an oem install is there suppoed to be a "oem-config-prepare icon"? http://wiki.ubuntu.com/Testing/Cases/OEMInstall says so in point 5
<dholbach> cjwatson, evand: nevermind - my mistake
 * calc hopes 3ubuntu5 is the last upload for OOo for hardy release :)
<afflux> I guess it's too late for fixing grammatical mistake in the system-config-printer dialogue?
<seb128_> yes
<seb128_> string changes break translations
<afflux> that's why I'm asking :)
<bitraiser> hello, I could use some help with distcc here, if anyone is available this late :)
<doko> asac: are there any firefox2 based browsers in hardy, do we need to register plugins for those?
<slangasek> there's firefox-2, if that counts as "based" :)
<Mithrandir> cjwatson: is there any way to embed environment variables in ~/.ssh/config ?  I'd like to set GSSAPIAuthentication depending on my host name and location.
<Mithrandir> (and would avoid rewriting that file on login, if possible..)
<davmor2> mvo: morning
<davmor2> mvo: just FF3 on eng upgrade do you want the log files uploading to the bug I opened for comparison?
<pitti> Good morning
<\sh> moins pitti
<dholbach> why does the encrypted lvm installation take ages to complete in the mke2fs step?
<TheMuso> dholbach: Is it zeroing the partition/drive?
<dholbach> TheMuso: I created a new disk image using qemu-img before
<TheMuso> dholbach: Right.
<afflux> what exactly do I have to do when I have a debdiff for a package in main that propably needs ACKing/sponsoring? (bug 195508)
<ubotu> Launchpad bug 195508 in system-config-printer "applet.py crashed with AttributeError in check_for_jobs()" [Undecided,Triaged] https://launchpad.net/bugs/195508
<pitti> afflux: subscribe ubuntu-release and ubuntu-main-sponsors
<afflux> does timing matter? ie. both at the same time or -sponsors after I got the ack?
<mvo> davmor2: thanks for confirming this, I think its fine, just a note should be enough
<pitti> zul: nagios is still problematic; can you please fix the seeds to not have nagios-plugins? (since you kept the strict dependency to -extra)
<TheMuso> mvo: I was asked to look at bug 91814, and since lowering the priority of the question doesn't help, cjwatson suggested that perhaps it should be preseeded in the dist-upgrader. Do you have any thoughts/other suggestions?
<ubotu> Launchpad bug 91814 in openssl "libssl0.9.8 config asking me 'which services should be restarted to make them use the new lbraries?'" [Medium,Confirmed] https://launchpad.net/bugs/91814
<slangasek> hrm, why is lowering the question priority not enough?
<TheMuso> slangasek: I don't know at this point... was critical, I tried high, but made no difference.
<davmor2> mvo: no problems
<mvo> TheMuso: high is the level we display, medium will not be displayed. let me have a quick look at the report
<slangasek> TheMuso: the default behavior is to show debconf questions of priority high or greater
<cjwatson> dholbach: it doesn't know you zeroed it - but there should be a "Cancel" button on the progress bar to skip the erasing
<TheMuso> Right. cjwatson also thought that if one was using apt-get on the console to upgrade, it might be a question that should be asked.
<slangasek> that's fair
<dholbach> cjwatson: ahhhhh, I thought that's completely cancel the installation
<cjwatson> the bug was all "if I'm doing a complete OS upgrade and going to be shutting stuff down anyway"
<dholbach> cjwatson: that's very nice then
<cjwatson> dholbach: nah, there's a bug about the UI I think
<cjwatson> at the moment the text of that particular button is installer-wide
<cjwatson> so it's a bit of work to improve ...
<cjwatson> Mithrandir: I don't think so, sorry :( you can certainly set it in individual Host blocks, but that might not be good enough
<dholbach> cjwatson: if it's planned to be fixed at some stage - that's cool
<mvo> TheMuso: I will add some information to the bugreport, we had a similar issue with libc6
<TheMuso> mvo: Ok.
<Mithrandir> cjwatson: yeah, though what I want to do is have it in revision control and having different configs for that value (and possibly others) depending on what machine I'm on.
<Mithrandir> cjwatson: and I'm trying to avoid using branches, since branches = work.
<mvo> TheMuso: updated
<TheMuso> mvo: Ok will look into that further, thanks.
<Xcfdj> dfsfs
<Xcfdj> hey !! any 1 wonna chat a litle
<dholbach> Xcfdj: try #ubuntu-offtopic
<davmor2> mvo: I new the upgrade machine now so are you sure you don't need any logs before I wipe it?
<davmor2> s/new/need
<mvo> davmor2: hm, yeah, attach them to be on the safe side :)
<davmor2> mvo: np's
<mvo> thanks!
<Xcfdj> so guys , I've got some stupid old machine that runs on ubuntu . and the 3d effectes are not anabled . so any one knows what are the minimal requarments for anabling the effects ?
<tseliot> ï»¿Xcfdj: you should join the ï»¿#ubuntu channel if you need support
<\sh> if anyone is testing vmware + ubuntu-server (or desktop) please test the guided partioning step...I just had grub failing to install with this...manual partitioning with separated /boot partition works
<cjwatson> \sh: I would appreciate the logs from your installation
<cjwatson> (I haven't used vmware for a while, and my installation has almost certainly bitrotted given how much maintenance it needed when I was using it actively)
<\sh> cjwatson, I'll redo the installation later on, and provide it in a bug report...I'll ping you with the bug number then :)
<cjwatson> \sh: also, what image were you installing?
<\sh> cjwatson, ubuntu-server from cdimages
<\sh> the last daily which is available up to now...
<cjwatson> ok
<mitsuhiko> hi all
<mitsuhiko> does ls sort by unicode on hardy now
<mitsuhiko> +?
<mitsuhiko> it's very odd having dotnames in the middle of the ls output
<mitsuhiko> even folders appear now in the middle
<slangasek> mitsuhiko: "sort by Unicode" is not meaningful; the sort order is defined by the value of LC_COLLATE in your locale, which for most languages causes dots to be ignored for sorting, yes
<cjwatson> if you don't like it, export LC_COLLATE=C
 * slangasek nods
<mitsuhiko> hmm
<mitsuhiko> that would affect applications too
<slangasek> anything that uses glibc's idea of alphabetical sorting, yes
<YokoZar> Hmm, the last two days my system has been in a state where firefox would fail to open and clicking system->shut down wouldn't bring up a shutdown window (while System was highlighted in orange)...
<YokoZar> Doing this also locks up the entire top bar really
<mvo> doko: could you please have a look at bug #215839 ?
<ubotu> Launchpad bug 215839 in python-central "Hardy upgrage gedit update fails and crashes X" [High,Confirmed] https://launchpad.net/bugs/215839
<doko> mvo: ok, trying to do so today
<pitti> hi tkamppeter
<pitti> tkamppeter: what are foomatic-db-gutenprint and ijsgutenprint? They do not have any reverse dependencies any more, and want to go to universe
<lool> Is http://people.ubuntu.com/~ubuntu-archive/queue/hardy/new/ the correct place to check whether a particular upload is waiting for approval?
<lool> I'm looking for mobile-basic-flash 0.43
<pitti> lool: no, that would be 'unapproved', not 'new'
<lool> Thanks
<Fujitsu> lool: You want https://launchpad.net/ubuntu/hardy/+queue
 * seb128_ lunch too
<seb128_> I'll be back in an hour
<lool> Fujitsu: Cool, thanks
<slytherin> Hi all, is anyone looking into the 'missing binaries from bluez-utils' bug?
<cjwatson> slytherin: hadn't heard of it, what's that?
<slytherin> cjwatson: binaries like hidd, pand are removed in favour of some new dbus method. But users are not able to use newer method and complaining about this drastic change in user experience. Due to this they are not able to connect keyboards/mice or make PAN connections.
<ogra> slytherin, do you have a bug about that ?
<slytherin> ogra: there are two, let me find them.
<cjwatson> slytherin: oh, sorry, I thought you meant missing binary packages (which would have been an archive problem)
<ogra> "some new dbus method"  is a bit vague :)
<slytherin> ogra: yes it as vague as I am telling. Even I am not sure how it works. Tollef agreed to buy a bluetooth keyboard and look into the matter but I am not able to find him online for some time. So not sure of the status.
<slytherin> ogra:  bug 191704 and bug 192043
<ubotu> Launchpad bug 191704 in bluez-utils "hidd binary removed form bluez-utils package unable to connect as a result" [High,Confirmed] https://launchpad.net/bugs/191704
<ubotu> Launchpad bug 192043 in bluez-utils "latest bluez-utils is missing /usr/bin/pand" [Undecided,Confirmed] https://launchpad.net/bugs/192043
<zul> pitti: done
<pitti> zul: thanks
<Fujitsu> Good god.
<Fujitsu> WTF
<Fujitsu> Something overwrote my LSB release details with some SkoleLinux/etch info.
<lool> Fujitsu: You're running SkoleLinux/etch now!
<Fujitsu> I do have every Gutsy package possible installed on that system, but I wouldn't have expected them to overwrite such things...
<ogra> Fujitsu, likely debian-edu
<ogra> have fun sorting out what cfengine changed all over your system :P
<Fujitsu> Yay, do-release-upgrade works now.
<\sh> cjwatson, re: grub phew...hating wget for not overwriting files but adding .N where N gt > 0 ;) the problem was an old -server daily iso image :( now using the correct one *grmpf*
<ogra> \sh, another reason o use rsync :)
<cjwatson> ah yes, I asked because it was a known bug in at least one image
<ogra> *to
<Fujitsu> Should a package really do nasty evil things merely by being installed?
<ogra> Fujitsu, in case od debian-edu thats a yes
<ogra> it mangles lots of stuff in /etc via cfengine
<\sh> ogra, _if_ you can rsync ;)
<\sh> +use
<Fujitsu> Blurgh.
<ogra> \sh, another reason to have zsync on the servers then :)
<\sh> ogra, well, too late..it cost me at least 4 installation tries to prove that layer 8 had a bug ;)
<munckfish> cjwatson: am I right in presuming that our updated kboot should be in the daily live today?
<jeromeg> could someone of motu release team review bug 216698 ?
<Fujitsu> jeromeg: Subscribed motu-release?
<Fujitsu> You might want to poke in #-motu
<jeromeg> Fujitsu: yes
<jeromeg> Fujitsu: ok i'll
<cjwatson> munckfish: only once it gets built ... ;-)
<cjwatson> munckfish: it's release time, so images tend to be built only when necessary; but I understand there's a new batch building at the moment
<munckfish> cjwatson: oh I c
<munckfish> it's difficult to tell whether we're on it, cause
<\sh> pitti, thx :)
<munckfish> it's not in a package, and ofcourse otheros.bld doesn't include a version number in it's title
<stgraber> Can someone please remind me how to turn off SCIM ? I have created an Ubuntu chroot and for some unknown reasons SCIM appeared. Of course I don't need it as those computers will run on fr_CH.UTF-8
<asac> pitti: so language-pack-gnome-de-base is the one i should put this mozilla thing in for the important languages, right?
<asac> (or without -base) ?
<pitti> asac: it doesn't matter much whether it's -base or -de; however, my first upload will have them in -base
<cjwatson> munckfish: yeah, I know, sorry
<cjwatson> munckfish: the code is:
<cjwatson>     KBOOTDEB="$($BASEDIR/tools/apt-selection cache show ps3-kboot | \
<cjwatson>                 grep ^Filename | awk '{print $2}')"
<cjwatson>     ar p "$MIRROR/$KBOOTDEB" data.tar.gz | tar -xzf - -C . ./boot/otheros.bld
<cjwatson>     mv boot/otheros.bld PS3/otheros/
<cjwatson>     rmdir boot
<cjwatson> munckfish: so it just needs to be in the archive in advance of the build
<pitti> asac: but I don't have an LP export yet, so I can't prepare new ones until tomorrow
<asac> pitti: ok ill do that too now
<asac> pitti: thats fine
<asac> ill use the ones i produced on rookery for now
<pitti> asac: ok; so you'll do manual uploads of the top-5 languages or so?
<asac> pitti: right. starting with -de now :)
<asac> pitti: version will just have CURRENTubuntu1
<munckfish> cjwatson: eh? you mean that's how it gets on the cd then?
<asac> in case you bother
<pitti> asac: right, to pick a *completely* arbitrary language :-P
<pitti> asac: version is fine
<asac> great
<cjwatson> munckfish: yes
<munckfish> :)
<ogra> slytherin, hmm, that intresting, nothing in any of the changelogs indicates why it was dropped
<munckfish> cjwatson: are the cd build daemons monitor thru LP like the normal daemons?
<asac> pitti: ok -de-base is tested and going up
<cjwatson> munckfish: no, afraid not
<munckfish> ok
<slytherin> ogra: any chance it was dropped on debian side?
<munckfish> I'll just wait then
<asac> anyone can tell me why my bash completion doesn't work here sine a week or so?
<slytherin> munckfish: what are you looking for?
<asac> e.g. tab doesn't show any suggestions :(
<cjwatson> slytherin: 11:55 <munckfish> cjwatson: am I right in presuming that our updated kboot should be in the daily live today?
<slytherin> cjwatson: thanks. :-)
<munckfish> slytherin: what he said
<ogra> slytherin, probably, i dont know
<ogra> slytherin, but it looks like a droped ./configure option
<slytherin> munckfish: When did you upload it? The build time is specified on the iso list page. I am assuming the time is UTC. You can make a guess about if it was included?
<cjwatson> slytherin: I already dealt with the quetsion
<cjwatson> question
<asac> pitti: in which seeds are the language packs that get on CD again?
<cjwatson> slytherin: I indicated that it is not in the current build, but will be in the next one
<cjwatson> slytherin: no need for further analysis :)
<cjwatson> asac: ship and live
<munckfish> slytherin: yes I noted yesterday's live daily was done just a few hours before the new ps3-kboot was uploaded
<pitti> asac: ship -> alternates, ship-live -> desktops, dvd -> well, dvd :)
<slytherin> cjwatson: Ok, I will keep my mouth shut. :-D
<asac> pitti: there are zero langpacks in ship-live
<cjwatson> pitti: the language packs are actually in live, not ship-live
<pitti> ah, right, my fault
<cjwatson> (because they need to go on the live filesystem; ship-live is the apt archive that lives alongside it
<slytherin> ogra: The changelog entry for 3.26-0ubuntu4 is - enable dund, so that palm pilot ppp-over-BT works. - But it doesn't mention how it was done. I will try to check it tonight and if done then will submit debdiff.
<cjwatson> )
<asac> hmm we ship es xh??? and pt
<asac> whats xh?
<elmo> xhosa?
<asac> why is that on CD?
<ogra> slytherin, ping me if nobody reacts in time for a post RC upload, i'll see what we can do
<ogra> asac, for africa
<asac> and no fr/de?
<asac> strange
<ogra> its tiny
<slytherin> ogra: I will ping you as soon as I upload debdiff.
<ogra> thanks
<cjwatson> we prioritised xh because it was a specially commissioned translation for Ubuntu
<cjwatson> it hasn't been maintained, and over time it has become a bit useless due to staleness, but at the same time that means the language packs are small and not much of a cost
<asac> ok thanks
<asac> so where can i find a list of most popular ones?
<ogra> asac, pitti usually has one hidden on rookery
<cjwatson> http://people.ubuntu.com/~pitti/scripts/langpacksize has the priority order up top
<cjwatson> I believe that's still our canonical ordering
<pitti> right
<asac> ok ill levave out xh :)
<asac> ogra: xh has no translation for firefox ... you think you can kick someone in africa to do that translation? or isn't it worth it? it can be done in launchpad now ;)
<pitti> seb128: hm, seems the patch in bug 150193 didn't work as expected? shall I remove it from -proposed?
<ubotu> Launchpad bug 150193 in gdm "Remote Login via XDMCP is not working in Ubuntu Gusty/7.10" [High,Fix committed] https://launchpad.net/bugs/150193
<asac> ogra: its just 7000 strings ;)
<seb128> pitti: I don't really care either way, the patch is from upstream and fixes some issues I think but maybe not everything, but I don't expect many people will keep running gutsy and I've enough to do without chasing this one
<pitti> seb128: a test for 'does not introduce apparent regressions' would be enough for me FWIW
<pitti> seb128: ok, I'll followup on the bug again, thanks
<seb128> pitti: thank you
<asac> pitti: ill do de, fr (both done) ... and now es, pt. maybe ill do chinese and jp as well
<pitti> asac: you might want to check if the CJKs are on the CDs anyway, since they are very big
<asac> pitti: they are not on CD i guess. ill just do those for the funkyness :)
<pitti> asac: I wouldn't mind; for network installs, people will get the fresh ones from Thursday anyway
<ogra> asac, heh, ask sabdf1 :)
<ogra> he might know africans to help out
<pitti> s/mind/bother/
<asac> ogra: hehe ... thought it was your edubuntu that lead to xh :)
<ogra> nah
<ogra> that pedates edubuntu
<ogra> *pre
<asac> ok sorry for bothering you then ;)
<asac> pitti: do you remember to remove mozilla- language packs from any depends?
<cjwatson> ogra: xh isn't a major commercial interest any more, afaik
<pitti> asac: yes, that's done
<asac> pitti: those shouldn't be installed anymore.
<pitti> asac: I demoted it this morning
<cjwatson> it would obviously be good to have a community actually maintaining that translation
<asac> pitti: ok. so it makes sense that stgraber still got them installed today?
<asac> pitti: thanks
<pitti> asac: hm, actually not
<pitti> 'got' them installed, or 'has' them installed? they won't be removed automatically
<pitti> at least not until today, since they were in main until a few hours ago
<pitti> for final hardy, update-manager will uninstall them
<stgraber> pitti: it's in a chroot where I manually install ubuntu-desktop so I don't get exactly the same package list as on a standard system
<stgraber> pitti: the chroot was regenerated at ~11:00 this morning
<ogra> cjwatson, well, but mark is african, he surely knows more africans than me or asac ... i didnt mean that in commercial context ;)
<stgraber> UTC+2 that's
<pitti> erk, apparently Arne forgot to rebuild some l-support packages; doing that now
<pitti> stgraber: but these only affect -be, -fy, and -mn; I doubt that you have those?
<stgraber> pitti: I don't
<stgraber> pitti: I don't see any reason why it would get installed, so probably something wrong with my chroot builder scripts ...
<asac> stgraber: can you verify please?
<stgraber> asac: I updated my script to fix some SCIM and locale problems, it's generating a new chroot at the moment
<cjwatson> Riddell: dunno if you noticed bug 210443?
<ubotu> Launchpad bug 210443 in kmplayer "file overwrite error in hardy" [High,Triaged] https://launchpad.net/bugs/210443
<Riddell> cjwatson: hmm, no, thanks will look
<seb128> cjwatson, pitti: could you consider the nautilus update in the queue?
<cjwatson> seb128: I'm inclined to leave nautilus to post-RC, since it's largely cosmetic (well, a little more than that, but not a blocker)
<slytherin> If I am specifying more than one bug in changelog then is this format correct? LP: #191704, 192043
<soren> (LP: #191704, #192043)
<soren> To make sure, you can check the resulting .changes file.
<soren> It's dpkg-source that parses the changelog entry.
<soren> It puts a Launchpad-Bugs-Fixed: header into the .changes file which launchpad in turn parses.
<soren> slytherin: ^
<slytherin> soren: Ok. Thanks.
<slytherin> ahh, vi now shows both the bug numbers in yellow colour. :-D
<soren> slytherin: Eh? What does?
<soren> Oh, vi.
<soren> I somehow read "vi" as "it".
<soren> reading is hard!
<thom> soren: it's actually dpkg-parsechangelog, but eh ;) (dpkg-parsechangelog |egrep '^Clo')
<soren> thom: Right you are.
<cjwatson> seb128: I'm inclined to leave nautilus to post-RC, since it's largely cosmetic (well, a little more than that, but not a blocker)
<seb128> cjwatson: is there some space between rc and hardy for changes?
<cjwatson> I think so
<seb128> ok
<seb128> because I would prefer to get the "cd player starts after login if you have a cd in the drive" to be fixed for hardy
<seb128> but your call
<seb128> after rc is fine anyway
<tkamppeter> pitti, foomatic-db-gutenprint and ijsgutenprint are not needed for standard Ubuntu. Standard Ubuntu has everything needed in cupsys-driver-gutenprint.
<pitti> tkamppeter: so we can safely demote them to universe?
<tkamppeter> foomatic-db-gutenprint and ijsgutenprint are needed by Kubuntu, as the KDE Printing Manager does not support the PPD generators of CUPS 1.2.x. KDE Printing Manager needs ready-made PPDs or the Foomatic XML database, it does not look up PPDs with "lpinfo -m".
<tkamppeter> Riddell, ping
<Riddell> tkamppeter: ok
<pitti> so they should become dependencies of something or get seeded to desktop?
<tkamppeter> Riddell, is this correct, that Kubuntu still needs these two packages?
<Riddell> tkamppeter: yes I expect so
<Riddell> adding to kubuntu seed
<pitti> cheers
<tkamppeter> Riddell, did you look at my mails about the GSoC students for the Common Printing Dialog? Is it OK with you to mentor them?
<Riddell> tkamppeter: you split them, one for UI and one for technical stuff?
<tkamppeter> Yes, but the technical stuff needs also to be mentored by an UI expert, as it is the communication between UI apps and the printing dialog.
<cjwatson> bdmurray: did you get a chance to retest bug 181121?
<ubotu> Launchpad bug 181121 in linux-restricted-modules-2.6.24 "[fglrx] gl screensavers crash on amd64" [Critical,Incomplete] https://launchpad.net/bugs/181121
<lool> ScottK: I read you were working on a devscripts update to allow debsigning's Debian uploads; correct? O:-)
<lool> -'s
<ScottK> lool: It's waiting for approval by the release manager.
<lool> Cool
<ScottK> lool: I just grabbed the current debsign from Debian and stuffed it into our devscripts package.
<lool> Ok
<lool> Thanks
<ScottK> lool: No one has accepted it yet, so maybe you can help me out.  The question I got, that I don't know the answer to is "do you know why the $DEBSIGN_ALWAYS_RESIGN variable is no longer honored in the new debsign?"
<lool> soren: Thanks for merging my ubuntu-jeos branch
<ScottK> I couldn't figure that one out.
<soren> lool: Thanks for doing it! :)
<lool> ScottK: Could it be a bug?
<ScottK> lool: It could be.  It's not mentioned in debian/changelog.
<ScottK> lool: Would you have some time to look into it?
<afflux> ScottK: are you a member of ubuntu-release?
<lool> ScottK: I'm still unpiling 4/5 days of email/TODOs, and I simply needed the new debsign, I don't have any strong interest in it
<lool> ScottK: I'm not particularly more powered to deal with it, I think
<ScottK> lool: OK.  Thanks anyway.
<ScottK> afflux: I'm a member of motu-release (cares for Universe packages).
<lool> ScottK: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447955
<ubotu> Debian bug 447955 in devscripts "[debsign] Add "always resign" variable" [Normal,Open]
<lool> ScottK: Could it be that the DEBSIGN_ALWAYS_RESIGN was an Ubuntu specific feature that you dropped when moving to the new debsign?
<ScottK> lool: Thanks.
<ScottK> lool: I'll look into that.
<afflux> ah, okay. So your ACK for 195508 is not enough for me to get this sponsored? :)
<slytherin> ogra: I have attached debdiff to bug 191704.
<ubotu> Launchpad bug 191704 in bluez-utils "hidd binary removed form bluez-utils package unable to connect as a result" [High,Confirmed] https://launchpad.net/bugs/191704
<ScottK> lool: It it is, it wasn't a documented one (I always love it when that happens).
<ScottK> afflux: The ack I gave was an OK to upload from a distro perspective.  It still needs a normal sponsors review.
<afflux> I think the package is in main *confused*
<ScottK> Ah.
<cjwatson> devscripts (2.10.9ubuntu2) hardy; urgency=low
<cjwatson>   * scripts/debsign.sh: implement DEBSIGN_ALWAYS_RESIGN variable to skip the
<cjwatson>     "Would you like to use the current signature?" question.
 * ScottK looks at the bug.
<cjwatson>  -- Kees Cook <kees@ubuntu.com>  Wed, 24 Oct 2007 15:54:58 -0700
<ScottK> cjwatson: Thanks.
<cjwatson> looks like StevenK forgot to mention that in the merge statement
<ScottK> Yeah.
<ScottK> I'll go back and fix it.
<StevenK> Argh
<jordi> is it deliberate that a recent ubuntu alternate cd pops up the language menu just after gfxboot loads?
<evand> yes
<lool> soren: Hmm the vbox type seems broken in ubuntu-vm-builder
<lool> /usr/bin/ubuntu-vm-builder: line 880: vm_target_conversion: command not found
<lool> mv: missing destination file operand after `/root/ubuntu-vm-gutsy-amd64'
<jordi> hrm, evand: is that going to stay on the final build?
<smallfoot-> hardy is on 8 days, please hurry up and fix the pink shadows & window decoration bug in the nvidia-utils drivers package
<evand> jordi: Yes, it is.  Is it causing trouble for you in some way?
<jordi> I've been looking but I don't see where to disable it
<jordi> evand: I don't need it, and would prefer to just show the main menu on my custom cd
<soren> lool: Yeah, I got an e-mail about that a few days ago.
<pitti> soren: I just installed kvm/virt-manager/libvirt-bin on current hardy (i386), and created a VM with a 5 GB image; this grinded for a while, and finally crashed with a "libvirtError: virDomainCreateLinux() failed"; is that known?
<evand> jordi: check with cjwatson as he wrote the change and knows much more about gfxboot than I currently.
<lool> soren: Hmm the code seems to be simply missing
<pitti> soren: (I have the full stack trace here if you need it)
<jordi> ugh, cjwatson, sorry for hammering you lately... :) I can't find where to configure gfxboot back to its previous behaviour where it didn't show the language selection screen on startup
<soren> lool: It sort of got left out in the cold during the refactoring I did.
<soren> lool: The code is sort of there.
<soren> lool: It used to do the same as either vmware or qemu.
<soren> pitti: Do you have enough space for a 5GB disk image?
<pitti> soren: yes, that's fine
<cjwatson> jordi: remove 'panel.lang' from common.inc
<pitti> soren: I just noticed that I wasn't in group "kvm" (recent reinstall)
<cjwatson> the call to it from the MenuInit function
<soren> pitti: "virDomainCreateLinux() failed" is sort of a very genereal "dear, oh dear, something went wrong".
<soren> pitti: Ah, yes, that would do it.
<pitti> soren: I addgroup'ed myself and ran it under newgrp kvm, but I get the same errror
<jordi> cjwatson: ok
<lool> soren: I'm trying to find out what type the .vdi files are
<soren> pitti: Try running "virt-manager --no-fork". That might give some useful info.
<lool> Interestingly, this led me to discover that vbox supports iscsi for virtual disks
<cjwatson> jordi: do you have an /isolinux/lang file?
<soren> lool: Oh, really? That's pretty cool.
<cjwatson> jordi: I'm wondering if we should skip language selection when that's present
<soren> lool: fwiw, libvirt will do the same in Intrepid.
<lool> Yeah, I think most people will want to use iscsi as a "lightweight" disk abstraction rather than lvm or nbd
<jordi> cjwatson: just "langlist"
<pitti> soren: I get three identical lines saying "libvir: QEMU Fehler :"
<soren> pitti: Don't worry about those.
<jordi> cjwatson: and yes, if the user already selected a language there, I'd skip it in the installer
<cjwatson> mm, s'what I thought
<cjwatson> drat, getting late for hardy
<pitti> soren: ah, I see I have a libvirtd process running; might be that this one isn't running in kvm
<cjwatson> </understatement>
<jordi> heh
<soren> pitti: Oh, you newgrp'ed rather then logout/login. YEs, then you're probably right.
<pitti> soren: hah, there we go; killing my libvirtd did it
<soren> pitti: Ok, cool.
<pitti> soren: so I guess this boils down to "give a friendlier error message about kvm membership"
<pitti> soren: maybe something coudl access("/dev/kvm", W_OK) and give a message box?
<pitti> soren: other than that, it looks great! UI-ized image creation, hardy desktop CD boots, etc; kudos!
<jordi> cjwatson: what about lang? did you mean langlist?
<cjwatson> jordi: http://paste.ubuntu.com/7199/ ought to do that
<cjwatson> jordi: no, langlist is the list of all available languages, but you can also stick e.g. 'ca' in a file called lang and that sets the default language
<jordi> cjwatson: ooo, that's even better
<soren> pitti: :) Wait until you see the stuff that'll land in Intrepid. :)
<emgent> ScottK: thanks for ACK.
<jordi> cjwatson: just doing that, or adding lang *and* the change to common.inc?
<ScottK> emgent: You're welcome.
<cjwatson> jordi: both
<jordi> cjwatson: okay, I'll have a go now.
<pitti> soren: now I just need to convince it to not use a 2 by 2 million pixel resolution, so that I can actually use the VM :)
<cjwatson> jordi: committed for (hopefully) post-RC
<jordi> cjwatson: cool
<pitti> soren: drat, it just doesn't let me use the VM menu; as soon as I click on it, the VM grabs the mouse again
<soren> pitti: When you click where?
<ScottK> cjwatson: Thanks again for the debsign pointer.  Fixed version just uploaded.
<soren> pitti: Re: insane resolutions: Talk to the X guys :)
<pitti> soren: when I click into the VM window menu (Virtual machines / Display / Send key / Helf)
<pitti> Help, even
<soren> Hm... Interesting.
<laga> cjwatson: any idea why the new mythbuntu tasks want to install the "wrong" packages? tasksel wants to install mythbuntu-backend-master instead of mythtv-backend-master.. http://www.pastebin.ca/987371
<soren> pitti: I haven't seen that. WM?
<pitti> soren: compiz outside, metacity inside
<soren> pitti: I'm on compiz, too. Hm..
<pitti> soren: so, I get lots of display bugs (screen update, mouse pointer, etc.), but works well otherwise
<soren> pitti: Which graphics driver are you using inside kvm?
<cjwatson> laga: but that's correct - the *task* name (as distinct from the package name) is mythbuntu-backend-master
<pitti> soren: hm, whatever the default on the live CD is; lemme check
<cjwatson> laga: note the '^' after the task name which tells apt-get that it's a task
<cjwatson> laga: it'll only work on CDs, not netboot
<soren> pitti: It'll probably be either vmware, cirrus or vesa.
<laga> cjwatson: it doesnt work on CDs. or on a normal gutsy box, for that matter
<pitti> soren: erk, it doesn't boot from CD again
<soren> pitti: Right. Only the first time. It expects it does the installation the first time and the removes the CD after first boot.
<laga> cjwatson: err, on a hardy box of course.
<pitti> soren: ok, I added a CD-ROM with the .iso, now it boots
<cjwatson> laga: it won't work on a normal hardy box, I'm afraid (that's equivalent to netboot; mythbuntu-desktop won't work either I imagine)
<cjwatson> laga: I'll look into the CD problem as soon as I have some bandwidth - rsyncing down a DVD right now
<laga> cjwatson: okay. i'll try again w/ the CD to make sure i'm not wasting your time.
<cjwatson> laga: ok, something wrong with the CD, one moment
<pitti> soren: yep, cirrus
<soren> pitti: Thought so.
<pitti> soren: I can repair the screen corruption by moving the VM's mouse cursor over them
<soren> pitti: Changing that is more involved than you would think, so it probably won't be any different in hardy :(
<pitti> yeah
<soren> pitti: For Intrepid, we'll probably be using the vmware driver.
<soren> pitti: ..or depending on how far upstream gets with it: Some sort of gl-passthrough-coolness.
<cjwatson> laga: please apply http://paste.ubuntu.com/7201/ (fix common seed's inheritance, and make backend-master implicitly include common)
<jordi> cjwatson: works great, many thanks!
<cjwatson> jordi: cool
<cjwatson> laga: we have a few cdimage fixes to make as well, though
<cjwatson> but at least the second half of that patch is a prerequisite for being able to fix it
<laga> cjwatson: but that won't make backend-master install everything from common, right?
<cjwatson> hence "a few cdimage fixes" :-)
<cjwatson> err, backend-master *should* cause everything from common to be installed, shouldn't it?
<cjwatson> I thought that's what you wanted
<twi_> if I wanted to write a blueprint for intrepid, should I wait until the intrepid series is added to launchpad or should I tag it with [intrepid] like it's done for some specs?
<cjwatson> twi_: is it an idea, or do you have a detailed software design document?
<laga> no. "common" is common because it's needed in live and in ship :) but backend-master should only pull in mythtv-backend-master and the mythbuntu-desktop package
<jordi> cjwatson: and thanks to looking closer, I found my "black" background is actually hex 030601
<jordi> so thanks again :P
<twi_> cjwatson it's only an idea for now
<cjwatson> laga: oh, ok, skip the second bit then
<cjwatson> laga: please do apply the STRUCTURE fix though
<cjwatson> laga: do you want backend-slave to be on the CD too? (if so, you should have pinged me for a tasksel upload)
<cjwatson> laga: and frontend?
<tkamppeter> pitti, ping
<laga> cjwatson: i believe tasksel has the correct tasks right now for backend-slave, too?
<cjwatson> twi_: please use brainstorm.ubuntu.com rather than a spec, then
<pitti> tkamppeter: just ask your question, please, don't ping
<cjwatson> laga: oh, yes, it does, wonder how I missed that
<cjwatson> laga: but do you want them on the CD?
<laga> yes
<twi_> cjwatson no, I want to work on a spec. So I guess the workflow is to write a detailed spec on a wiki page and then link it later to a blueprint?
<cjwatson> laga: then you need something like http://paste.ubuntu.com/7204/
<cjwatson> twi_: it's just that we try to discourage people from writing specs unless they're software engineers who are prepared to carry them through to completion; it's quite hard to find anything now because there are so many specs that are essentially wishlist bugs
<tkamppeter> pitti, I have fixed bug 213624, bug 211867, and bug 195508 in system-config-printer now.
<twi_> cjwatson i am and i'm planning to  go to UDS that's why I am asking
<ubotu> Launchpad bug 213624 in system-config-printer "system-config-printer.py crashed with error in _probe_queue()" [Medium,Triaged] https://launchpad.net/bugs/213624
<cjwatson> twi_: but if you are prepared to do that, then just register it at https://blueprints.launchpad.net/ubuntu/+addspec for now, and don't make it release-specific
<ubotu> Launchpad bug 211867 in system-config-printer "system-config-printer.py crashed with TypeError in getNPPPD()" [Medium,Triaged] https://launchpad.net/bugs/211867
<ubotu> Launchpad bug 195508 in system-config-printer "applet.py crashed with AttributeError in check_for_jobs()" [Undecided,Triaged] https://launchpad.net/bugs/195508
<cjwatson> twi_: ok, cool
<twi_> cjwatson ok thanks
<cjwatson> twi_: sorry, we've just found we need a bit of a firewall :)
<twi_> cjwatson heh yeah I can imagine :)
<cjwatson> twi_: if you want to discuss it at UDS, there's a "propose for meeting" (or similar) link that you can use
<twi_> cjwatson yeah I saw that I just wasn't sure about the release
<cjwatson> (unfortunately that's not restricted to meeting attendees yet, but to everyone else, please only use that if you're attending the meeting in question)
<tkamppeter> pitti, they are all small patches from upstream to fix crashes. I have put the new package files and the debdiff to the ususal place. Can you please upload this to Hardy. Thanks.
<twi_> but if I can not assign it i'll just do that for now
<cjwatson> twi_: those look like Canonical staff dumping in their team roadmaps
<pitti> tkamppeter: please send me a mail with the URLs to the debdiffs and packages
<twi_> I see
<cjwatson> twi_: but putting [intrepid] in there isn't required, I think it's just for tracking purposes since they have lots
<pitti> tkamppeter: or, rather, just subscribe ubuntu-release to the bugs and put the URLs/debdiffs to the bug reports; that's better
<cjwatson> (for avoidance of doubt Canonical staff don't as a rule have extra privileges with regard to blueprints, that wasn't what I meant)
<twi_> cjwatson yeah I'll just keep it unassigned until they add intrepid to launchpad
<laga> cjwatson: thanks a lot, i've applied the fix
<cjwatson> twi_: normally, the "series goal" stuff is filled in after UDS by release planners based on what seems plausible and has people prepared to work on it
<cjwatson> twi_: it's not actually a requirement to fill that in ever in order for something to make it into the release
<cjwatson> twi_: again it's something that's useful if you have lots and lots of specs that you're tracking
<ogra> you should also have a look at brainstorm.ubuntu.com i bet there are some suggestions already that might give some additional POVs
<twi_> cjwatson oh perfect then
<tkamppeter> pitti, done.
<Kaleo> cjwatson: about UDS, is there a specific place where the planning is stored? Actually, is there a general planning at all or is it only convention between interested people around specifications?
<bdmurray> cjwatson: I'm looking into the fglrx bug now
<slytherin> hi all, now that OOo has built properly on powerpc, does anyone know why it is not included in alternate cd?
<slytherin> Ok. I have found the problem and added debdiff to bug 164491
<ubotu> Launchpad bug 164491 in ubuntu-meta "[ppc] openoffice.org not present on alternate CD" [Undecided,New] https://launchpad.net/bugs/164491
<tkamppeter> Riddell, are you still around?
<Riddell> tkamppeter: hi
<tkamppeter> Riddell, Lars has modified his application on the Google Summer of Code web app to reflect his new project. Can you look into it and click "I am willing to Mentor"?
<lool> slangasek: There's this power saving patch for pygobject / pygtk at http://bugzilla.gnome.org/show_bug.cgi?id=481569 which has now been fixed; is this something too intrusive to push to hardy now?
<ubotu> Gnome bug 481569 in gtk "Calling gobject.threads_init() causes a lot of wakeups" [Normal,Reopened]
<Riddell> tkamppeter: "Develop a DBUS interface.."?
<kees> ScottK: erk? did debsign lose my patch?
<ScottK> kees: No.
<lool> kees: (See also the backlog about 3 hours ago)
<kees> ScottK: Ah, you were comparing debian debsign to ubuntu debsign?
<ScottK> kees: You patch didn't get documented after the last merge, so I was about to drop it, but slangesek noticed and I fixed it.
<ScottK> You/Your
<kees> ScottK: was that a mistake on my part or the merger's?
<ScottK> Mergers
<kees> okay, cool.  I still need to convince the debsign maintainer better to take that change.
<laga> ssh screwless
<laga> oops.
<tkamppeter> Riddell, some form of inter-process communication is needed to couple the application with the dialog. One possibility is DBUS. As you probably have more knowledge about GUI apps, you know perhaps something better, especially as the app and the dialog are usually running as the same user.
<ScottK> kees: You might also look at Bug 218210 - I think a patch for the documentation (man page) might help your odds.
<ubotu> Launchpad bug 218210 in devscripts "debsign: $DEBSIGN_ALWAYS_RESIGN not documented" [Undecided,New] https://launchpad.net/bugs/218210
<kees> ScottK: heh, good call.
<kees> hunh, it got missed by both StevenK and ogra.  I must be very sneaky!  :)
 * ogra looks up
<ogra> what did i do ?
<lool> kees: BTW I discovered this feature thanks to today's discussion and would be happy to use it for purely Debian uploads; it happens from time to time that I have broken checksums or similar in .changes or .dsc which I then need to resign, and I hate the confirmations
<kees> lool: please comment on the Debian bug -- I'd like to see it there too, I find it handy for sponsoring Debian uploads too.
<lool> kees: I was about to
<pitti> mvo: replied in the bug
<kees> lool: cool.  I'm really not clear on the maintainer's objections.
<kees> when doing sponsored uploads (debian or ubuntu) you're over-writing the sponsoree's signature.  that's the whole point -- they're not in the keyring yet.
<kees> ... and they removed the 'patch' tag?  pfft
<james_w> what's the preferred way to submit a new package version for sponsorship?
<james_w> the debdiff in this case is tiny, even with the upstream changes.
<ScottK> james_w: Attach the diff.gz to a bug and subscribe the appropriate sponsorship team.
<ScottK> james_w: At this point you'll probably need to look at a freeze exception too.
<james_w> with a pointer to the upstream tarball?
<james_w> is the watch file sufficient for that?
<ScottK> Watch file should be sufficient.
<james_w> yeah, it will be a freeze exception request first.
<james_w> thanks ScottK
<ScottK> No problem.
 * lamont wants to know which source package and where to modify to fix compiz' window focus back to his preferred focus
<lamont> or if compiz is just not for me
<mathiaz> slangasek: are we still planning 20080415 as the ubuntu-server iso for RC ?
<cody-somerville> pitti, Hobbsee: It appears that Ryan is ready for you re: abiword.
<cjwatson> mathiaz: hope not
<mathiaz> slangasek: I've noticed a new daily build for ubuntu-server on cdimage (20080416)
<cjwatson> mathiaz: we rebuilt everything today, and will rebuild at least all desktops again
<mathiaz> cjwatson: ok - so there is no point in testing 20080415
<slangasek> mathiaz: yes, please test 20084016 instead
<slytherin> cjwatson: Can we discuss issue of OOo on powerpc CD if you have time?
<cjwatson> slytherin: not right now (I have to go), but please leave messages
<mathiaz> slangasek: ok - could you update iso.qa.u.c ?
<slytherin> cjwatson: Ok. I will add comment on bug
<slangasek> mathiaz: now that I'm awake, yes :)
<slangasek> lool: eew, the pygobject/pygtk power issue didn't get resolved right the first time?
<pitti> tkamppeter: please do not add milestones to all bugs you encounter/fix; milestones are for bugs which block the release, not for bugs which would be nice to fix
 * pitti removes the milestones again
<slytherin> ogra: ping
<seb128> pitti: somebody should clarify how milestones are supposed to be used but I don't think they are considered as reserved to blockers right now
<pitti> seb128: hardy task > 'pool of nice to fix', milestones > blockers, AFAIUI
<pitti> slangasek: ^
<seb128> pitti: "nice to fix for 8.04.1 = ???"
<slangasek> seb128: -> hardy task
<pitti> seb128: hardy task
<seb128> how do you know what is 8.04 and 8.04.1 then?
<pitti> we just need to find a convention which works for everyone
<slangasek> if it's "nice to fix" only, do we need to distinguish?
<seb128> I don't agree with that workflow
<seb128> I don't see what is wrong with milestone + priority < high = target of opportunity
<seb128> doesn't really make sense to take a wishlist milestoned as a blocker
<pitti> seb128: we just need a way to tell apart milestone blocker bugs from 'would like to get eventually'
<seb128> it would not be a wishlist if it was a blocker
<seb128> pitti: that's what the importance is for no?
<pitti> that clutters the +milestone list a lot, though
<seb128> that's a launchpad UI bug
<pitti> and it's very hard to see what's actually important on it
<seb128> sort by importance?
<slangasek> well, I'm amenable to that in theory, but we do need to nail down a workflow, and in particular one that doesn't require the RM to manage the wishlist milestoned bugs when they miss the milestone
<pitti> then you get the states all mixed up
<pitti> right, and moving milestones all over is hard, too
<Mithrandir> it sounds like a greasemonkey script to hide unimportant bugs might be needed.
<slangasek> also, I think a different set of people can set milestones than can set bug severities, so what happens when someone raises the severity of a milestoned bug that wasn't meant to be a blocker
<seb128> we should really have a team discussion about that
<slangasek> ?
<seb128> and not have people deciding workflow and not communicating those
<pitti> seb128: yeah
<pitti> well, TBH I think there were several announcements about this some months ago
<seb128> slangasek: that's a launchpad bug ;-)
<seb128> pitti: launchpad ones or ubuntu ones?
<pitti> seb128: we could also say it's a workflow bug :)
<seb128> pitti: I'm using milestones to do my todos for ages and nobody ever told me otherwise until recently (one week ago)
<pitti> personal TODOs are best managed with 'confirmed/assigned/in progress' IMHO
<seb128> the "nominate for hardy" thing sucks imho, you can't select it in the advanced search options for example
<pitti> no need to clutter the RM lists with personal TODOs
<seb128> pitti: not when you have 3000 bugs on your list
<pitti> seb128: it doesn't matter whether you set a milestone or set it as 'in progress'
<pitti> same effort
<seb128> no
<seb128> "in progress" would mean I'm working on it
<seb128> and I can't possibly work on all the desktop bugs myself
<pitti> but having a milestoned bug without anyone working on it makes no sense
<seb128> I need a way to make a list of things the desktop team should consider for hardy and for 8.04.1
<seb128> it does
<seb128> that's what I can point at the weekly meeting saying "we should fix those please give a hand"
<pitti> seb128: ok, seems we should have a discussion about that on u-devel@; perhaps not at this time, though
<seb128> pitti: right, or at uds
<kees> slangasek: can you examine bug 218110?  this seems related to the PAM changes.
<ubotu> Launchpad bug 218110 in samba "PAM [error: /lib/security/pam_smbpass.so" [Undecided,New] https://launchpad.net/bugs/218110
<seb128> pitti: sorry for bothering about workflow details when you have other things to do ;-)
 * seb128 hugs pitti
<pitti> seb128: no need to be
<seb128> I'll do the way it has been decided for hardy and let's have a talk about that at uds
<slytherin> Can someone please sponsor debdiff attached to bug 191704? I had discussed this with Tollef sometime back, but I am not able to find him online today.
<pitti> seb128: I wasn't actually aware that the current (what I regarded as) best practice was in fact still disputed
<ubotu> Launchpad bug 191704 in bluez-utils "hidd binary removed form bluez-utils package unable to connect as a result" [High,Confirmed] https://launchpad.net/bugs/191704
<pitti> since from my POV that didn't change for months
<slangasek> kees: is that not the same bug that cjwatson assigned to me?
<seb128> pitti: well, I didn't read the mail about that being the official workflow apparently
<seb128> pitti: or decided it didn't work for me and didn't bother ;-)
<slangasek> there wasn't a mail about it, totally my fault
<seb128> I still think it's weird to have 2 similar things, nominations and milestones
<seb128> but that's a launchpad issue
<pitti> seb128: yeah, it's indeed confusing
<seb128> especially that you used to not be able to nominate for the coming version I think
<pitti> I think it's sensible to have two different tools, but it's not immediately obvious which one to use as a developer
<pitti> seb128: you can't add tasks?
<seb128> pitti: no, I mean that previous cycle it was possible to use the nomination only for stable distributions
<pitti> ugh; well, *that* would be an LP bug
<seb128> +not
<seb128> or that's me who just associated nomination = SRU
<seb128> anyway, let's sort that later
<pitti> it's actually quite similar; "would like to fix in the hardy release" as opposed to "eventually"
 * ScottK has too, but has seen a fair number of nominations for Hardy from end users.
<seb128> slangasek: that's alright, just something to clear for next cycle ;-)
 * pitti -> off to Taekwondo, cu later
<seb128> pitti: have fun!
 * pitti hugs seb128
 * seb128 hugs pitti
<kees> slangasek: I don't think so -- this was a private security bug until I just un-privated it.
<slangasek> kees: ok, then it's a duplicate, I'll fix it up
<slangasek> (the bug state, I mean...)
<kees> slangasek: okay, cool thanks
<marcreichelt> hi there
<marcreichelt> I want to try out Apache2 with IPv6, but I can't access to localhost
<ScottK> marcreichelt: Try #ubuntu-server
<marcreichelt> oh, thanks :)
<kees> mvo_: Amaranth: slangasek: I've milestoned bug 201330 as it is a regression from gutsy, a patch is available, etc.
<ubotu> Launchpad bug 201330 in compiz "[regression] need to whitelist multiple ATI cards, or remove blacklisting" [High,In progress] https://launchpad.net/bugs/201330
<zul> slangasek: hello http://pastebin.com/m2a7fa75 (fixes from regression from MIR requirements)
<slangasek> zul: you know you don't need to get approval from the RM before each upload? :)
<slangasek> zul: looks sane enough; won't be accepted now until after RC
<slangasek> zul: but you can still upload in the meantime
<slytherin> any chance that debdiff for bug ï»¿191704 will get accepted before RC?
<stgraber> bug 191704
<ubotu> Launchpad bug 191704 in bluez-utils "hidd binary removed form bluez-utils package unable to connect as a result" [High,Confirmed] https://launchpad.net/bugs/191704
<slangasek> nope
<slytherin> slangasek: after RC?
<zul> slangasek: thnks..
<slangasek> slytherin: possibly
<ogra> slytherin, i looked at the bug, i think that is rather a bug in hal than in bluez
<slytherin> ogra: LOL. So what do you suggest now?
<ogra> slytherin, also do you have any idea how enabling the two binaries will influence the new behavior for people for whom i works now ?
<slangasek> it won't
<slytherin> ogra: AFAIK, it won't.
<ogra> slytherin, well, talk to a hal person probably ... but i guess pitti is to busy with pre RC stuff to even take a look
<slytherin> ogra: Can you tell me how you figured out it is hal bug?
<ogra> a proper fix for the situation would be to build a bluez-extra package containing the two
<slangasek> er, I don't see why there's anything proper about creating a new package here
<slytherin> me too, these binaries were present in bluez-utils previously, so creating new package doesn't make sense.
<ogra> slangasek, vs unpredictable results the re-enabling of two deliberately upstream disabled binaries might cause
<slangasek> there's nothing unpredictable
<slangasek> the binaries are never executed automatically
<ogra> slangasek, well, your call, i'm no RM
<slangasek> and there's some functionality that it's not straightforward to get using the new bluetooth "services"
<ogra> i just dont know in which ways hal breaks f someting else claims the HW
<slangasek> if the something else claims the hardware, it's because the user asked it to
<slangasek> I don't see a problem there :)
<ogra> slangasek, i'm by no means a bluetooth knowledgeable person, i just took a look at the bug because slytherin asked me :)
<ogra> and to me it occued as if upstream had a reason (even though not well documented) to disable it
<slangasek> because they believed it obsolete
<slangasek> practically speaking, a number of people disagree
<kees> mvo: based on the bug reports, I think ati should be un-blacklisted -- more and more pci-ids are getting added to the whitelist.  Also, I think we should support the open driver.
<hcoal> does the open ati driver support 3D yet?
<laga> xserver-xorg-video-ati does
<kees> hcoal: yes
<slytherin> ï»¿ogra: Can you please tell me why do you think it is hal problem?
<ogra> slytherin, well, as slangasek stated above 'there's some functionality that it's not straightforward to get using the new bluetooth "services"'
<ogra> slytherin, there is a new way that doesnt seem to work for all yet
<slytherin> ah, ok
<ogra> so the *right* fix is to get the new way woking for everyone instead of having two ways to do a thing in the default
<mario_limonciell> for that exact reason, i agree a stop gap solution (if HAL doesn't get fixed in time for 8.04 to go gold) would be having an extra package with those binaries
<hcoal> Do you think I'll get better performance using the open driver rather than ati's own restricted driver?  I'm using an HD 3850, performance is pretty good but video playback and full screen video/graphics are pixelated and jerky.  Video looks awful fullscreen.
<mjg59> No
<slytherin> hcoal: The open driver doesn't yet support 3D for all cards
<slytherin> hcoal: And it is also not necessarily better for latest cards.
<hcoal> Thanks slytherin.  That's a pity, this is the only thing stopping me from ditching Windows completely, I love ubuntu but not being to play video properly on is stopping me from making the switch at the moment.
<slytherin> ogra: The problem is that most of the developers working on bluetooth, AFAIK, don't have bluetooth input devices. Tollef promised he would buy one and try to fix it. But we are too late in hardy cycle.
<hcoal> I'll stick with restricted while I wait for now.  Beryl/Compiz runs really well, I just can't figure out why video quality is so poor.
<mvo> kees: its tricky stuff, Amaranth blacklisted them because we got a lot of failures for them now we get a lot of "it works" :-/
<ogra> slytherin, well, i own a bluetooth dongle i used ... umm... twice i think in two years
<slytherin> :-)
<ogra> but only a mobile to test it
<kees> mvo: well, I'm in the list of "annoyed" ati users.  we absolutely need a whitelist at the very least.
<kees> mvo: I'm currently freshening the patch and adding more IDs
<mvo> kees: what ati do you have?
<kees> mvo: I think it's a mistake to blacklist the open-source drivers.  the bugs should be fixed, not hidden.  I have 1002:4e50
<mario_limonciell> slytherin, i actually have a BT keyboard and mouse, but i've not ever run into any issues pairing and using w/ the new services
<mvo> kees: right, I agree in general - we do only blacklist ati laptop cards currently because we got a lot of failure reports for those. I'm happy to add a whitelist
<slytherin> mario_limonciell: Find. But when it doesn't work, users resort to using the mentioned binaries. And not finding those binaries in package is frustrating for them
<ogra> slytherin, slangasek is the one to decide about your debdiff and he didnt look resistant to your debdiff :) (compared to my idea to split them out to a universe package at least :) )
<mvo> kees: the trouble is that I don't have the knowledge to fix stuff in the ati driver myself, so all I can do is add them to the blacklist
<mario_limonciell> slytherin, right, i understand what you mean.
<slytherin> ogra: Yes, Even I don't agree with separate package because then we need to add 'Replaces' and test the upgrades. So let's wait till RC is out.
<ogra> slytherin, so just wait until the RC dust settles a bit and the release team has half a hand free again :)
<kees> mvo: I'd prefer a ID-blacklist rather than a driver blacklist.  :P  Anyway, once I test the updated patch, can you add it?
<mvo> kees: sure, the repository is in ~ubuntu-core-dev, feel free to commit it yourself
<slytherin> mario_limonciell: Recently many users have been complaining about obex transfers. I initially thought it was a Nokia only phone problem. But looks like the problem is with Symbian based phones. Such bugs are hard to pinpoint. So it is better to push the workaround if we know it will work for sure, than to try fixing new buggy workflows. :-)
<kees> mvo: okay -- I'm unclear if it should be done via quilt (other things quilt-patch stuff in debian/ ) or done directly.
<mario_limonciell> slytherin, i've noticed obex transfers only work (for me at least) when the gnome BT applet has the setting "visible and connectable for other devices"
<mario_limonciell> slytherin, so that might be worthwhile to mention in bugs you come across for that
<mvo> kees: quilt please, the debian/compiz-manager script is a checkout from a git repository that we heavily patch up - that sucks a bit and will go all upstream again
<slytherin> mario_limonciell: Will do. Time to go to bed now. Bye.
<Amaranth> kees: I'd say everything from X300 Mobility and newer should stay blacklisted
<xhaker> jdong: charles updated the bug report about transmission's patches backport. I'm just pinging, so it doesn't get forgotten.
<kees> Amaranth: do you have a way to gauge "newer than"?  :P
<Amaranth> kees: the trick being that's a _lot_ of cards and i'd rather compiz not run at all on your machine then make it crash at login
<Amaranth> newer then is bad, maybe "better than" :)
<kees> Amaranth: well, I'm fine with the default being disabled, but if people are already configured to use compiz from gutsy, or they explicitly try to enable it, it should work.
<kees> Amaranth: at present, people with previously-working ati-driver compiz suddenly have it vanish without notice (like me)
<Amaranth> I'm not fine with default being disabled but if we have a regression in the driver from gusty then those people are out of luck
<Amaranth> And actually most of these were a problem in gutsy too, we just didn't get reports for all of them
<kees> Amaranth: I'll defer to you on the general methodology, but at least the people that noticed the problem should be whitelisted.  what do you think of the pciid whitelist solution?
<Amaranth> If you can get the driver from feisty to work with the current X server we're good to go
<Amaranth> kees: I think a whitelist on top of a blacklist sucks :P
<kees> Amaranth: hrm?  I'm not following.  my ati laptop worked under compiz in gutsy (and it works in hardy if I disable the ati blacklisting)
<Amaranth> What chip do you have?
<kees> 1002:4e50
<Amaranth> yeah, don't plan to whitelist that one...
<Amaranth> rv350
<kees> The problem I see here is that is feels like blacklisting the entire open-source ati driver for compiz is a mistake -- clearly it at least works for me and all the other people complaining on that bug report.
<Amaranth> Well, what I wanted to do was only block for r300 and newer
<kees> why shouldn't it be whitelisted?  it works fine.
<Amaranth> kees: I also have a bunch of people saying their X300 and X700 Mobility chips work fine too
<Amaranth> But those are the main ones that seem to have problems
<kees> Amaranth: then it sounds like some other solution is needed -- if compiz crashes, disable it.  if not, let it run happily.
<Amaranth> kees: I can't think of a good way to do that without catching other people
<kees> Amaranth: disabling compiz on the whole for an open source driver that breaks only some people is a mistake.  there must be some better way to work around it.
<kees> Amaranth: how about a gconf switch to block it in the case of repeated crashes?  Documentation seems to be the way to win this.
<laga> do people read documentation?
<kees> allow ati/radeon unless the gconf setting exists.
<kees> laga: not initially, but once they have a problem, yeah.
<laga> what about a popup? "there's a lot of compiz breakage, do you want to disable?"
<kees> at the very least, if not gconf, pull in /etc/default/compiz or something like that.  and have BLACKLIST_LAPTOP_DRIVERS="ati radeon" by default, so I can tweak a config file.
<Amaranth> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/108527/comments/19
<ubotu> Launchpad bug 108527 in xserver-xorg-video-ati "X freezes when compiz is enabled on ATI X300" [High,Fix released]
<Amaranth> this guy has the same chip as you, for example
<kees> Amaranth: gross.  :P  the problem is we don't have any indication of which is more common: working or non-working, and it seems that PCI ids aren't a way to distinguish it.
<laga> kees: a config file might be better for kde, too.
<Amaranth> that bug status lies, people reported a million different problems in that report :P
<kees> therefore, we need a different solution to allow people to enable compiz without changing a file in /usr/bin
<kees> laga: true
<Amaranth> kees: you can always use the generic SKIP_CHECKS
<Spads> we need a way to shatter clusterbugs off
<kees> Amaranth: where is SKIP_CHECKS defined?
<Amaranth> in /etc/xdg/compiz/compiz-manager or ~/.config/compiz/compiz-manager
<Amaranth> kees: it isn't, by default
 * Amaranth is lagging very badly
 * Amaranth blames freenode
<kees> Amaranth: how about documenting it with a commented-out example in /etc/xdg/compiz/compiz-manager and making it more discoverable via messages from compiz-manager itself "your compiz is disabled since.... if you really want to use it anyway, set ..."
<kees> Amaranth: or, frankly, move the blacklist list to that file...
<Amaranth>                 verbose "SKIP_CHECKS is yes, so continuing despite problems.\n"
<Amaranth> so stick SKIP_CHECKS=yes in one of those places
<tkamppeter> slangasek, still around?
<slangasek> tkamppeter: yes
<tkamppeter> It is about bug 214579  as I have already packaged a new s-c-p with fixes for three other crashers (0ubuntu8) and made FF exception requests on the appropriate bugs, should I add this to 0ubuntu8 or make a 0ubuntu9?
<ubotu> Launchpad bug 214579 in system-config-printer "my-default-printer.py crashed with TypeError in response()" [Medium,Triaged] https://launchpad.net/bugs/214579
<slangasek> tkamppeter: if the fix is reasonable, include it in 0ubuntu8 please
<lool> slangasek: Concerning the pygobject / pygtk issue: what happened was that 1) we included the patch for python in gutsy (perhaps even earlier, not sure) 2) we included the patch for pygobject/pygtk 3) we noticed it wasn't included in python/hardy and it was then added 4) we saw it caused issues to have such support and removed the pygobject/pygtk patch
<slangasek> ah
<lool> slangasek: We're now at the point where the pygtk/pygobject part has been fixed
<tkamppeter> slangasek, the fix is a small patch of ~10 lines, so I will add it to 0ubuntu8
<slangasek> lool: so what's the current impact, though?  I understood that the symptom was "landscape-client sets people's laps on fire"?
<lool> slangasek: it's a story of watching the proper file descriptors at the proper side of the patch for read or write or both type of events, I don't know what was wrong or broke expectation, but it's fixed they say
<lool> slangasek: That was the symptom at 4)
<lool> slangasek: When we decided to remove this support
<slangasek> ah
<lool> The symptom motivating the change is that you'll see python apps in powertop without it
<lool> without the patch
<slangasek> yes, yes I do ;)
<slangasek> lool: yes, I'll accept that patch post-RC with an appropriate amount of pre-upload testing
<lool> slangasek: seb128 was more in favor of hardy-updates
<slangasek> that would be fine by me too
<lool> slangasek: Let's do it post release then
<lool> I hope $someone thinks of it
<lool> slangasek: Thanks for your time
<Amaranth> maybe card.freenode.net is just broken
<Amaranth> anyway
<_MMA_> slangasek: You release manager ATM?
<slangasek> _MMA_: ah... normally? :)
<ScottK> _MMA_: Unless there's been some spectacular screwup I haven't noticed, I'd guess the answer is yes.  ;-)
<Amaranth> kees: i suppose we could be a bit more verbose but that only helps english speakers
<kees> Amaranth: true
<_MMA_> Ok. I thought it rotated a bit. I thought Riddell did it a time or 2. :P n.
<_MMA_> ï»¿ï»¿slangasek: Do I need to sign off on a image for Studio's RC?
<_MMA_> s/n/np
<slangasek> _MMA_: if you want me to release UbuntuStudio as part of the group RC, it needs to be validated via http://iso.qa.ubuntu.com/qatracker/build/all/all and blessed by the developers, yes
<_MMA_> slangasek: Cool. I did test todays image. Ill add my results and get others to do so. This image ï»¿(20080416) will most likely be fine.
<kommander> I'm trying to install a small ubuntu with a unionfs but without casper, anyone ever tried ?
<slangasek> _MMA_: yes, we do have some late-landing packages that we need to reroll other images for, but I don't see that they warrant a reroll of UbuntuStudio
<kommander> this is mean to go on a CF card
<laga> kommander: why do you think you need caspeR?
<kirkland> evand: ping
<evand> kirkland: pong
<kirkland> evand: wondering if the OEM Kubuntu fix is in the latest iso snapshots, shall i retest bug # 217884?
<kommander> laga: I googled and saw a lot of page speaking about casper
<_MMA_> slangasek: np. Should be fine.
<laga> kommander: you can use custom initramfs scripts
<evand> kirkland: it's not yet, it will be once http://cdimage.ubuntu.com/kubuntu/daily-live/current/hardy-desktop-amd64.list shows oem-config 1.35
<kommander> laga: I used debootstrap to put a small beginning on the cf
<kommander> laga: do you have an example online ?
<evand> so whenever the next run of kubuntu cds occurs
<kirkland> evand: coolio
<laga> kommander: not off-hand, but i'm sure google will have one, or wiki.ubuntu.com or the initramfs-tools documentation. if you cant find anything, then you can look at /usr/share/initramfs-tools/scripts/nfs and at the stuff in ltsp-client for some unionfs inspiration
<kommander> laga: very good, thank you :-)
<tkamppeter> slanagasek, done and all bugs updated.
<laga> kommander: have fun :) in ubuntu hardy, you can also use aufs instead of unionfs.
<kommander> laga: is aufs better than unionfs ?
<laga> kommander: depends. i like it better because it works better with NFS
<kommander> laga: ok, thanks for all these informations :-)
<laga> no problem :)
<Adri2000> is it still possible to sync packages from debian?
<Adri2000> (with the appropriate ack from the -release team of course)
<Adri2000> reading hardy-changes I figured it's still possible :) so archive admins, please sync xpad, it's bug #216698, thanks.
<ubotu> Launchpad bug 216698 in xpad "Please sync xpad 2.14-1 from Debian Unstable (main)" [Medium,Triaged] https://launchpad.net/bugs/216698
<mario_limonciell> laga, did you end up getting a follow up DVD done so mythbuntu can go out with the rest of the RCs?
<mvo> blueyed: hello! have you seen my comment for #63450 ? it hangs for me in a test upgrade, have you seen anything like this?
<basslingo> Probably a common question, but why is ubuntu's gcc spitting out   "C compiler cannot create executables." messages
<lifeless> basslingo: thats not gcc, thats autoconf
<lifeless> basslingo: do you have build-essential installed?
<basslingo> *checking*
<ceekay> really simple packaging question... if my package changes versioning schemes, i.e. 1.0.2 and then 1.0.080416 , is there a way i can tell the 1.0.080416 package that it is a higher version than 1.0.2 ? i could've sworn i saw this somewhere but now that i need it i can't seem to find the link
<basslingo> ah, that would do it >.>     spelling error = no package found
<LaserJock> ceekay: that would be an epoch, use 1:1.0.080416, but it can't be undone (you have to bump the epoch) so use it carefully :-)
<lifeless> ceekay: 'epoch'
<ceekay> ah thanks guys
<ceekay> just as you sent that i found http://people.debian.org/~calvin/unofficial/ which mentions epoch as well
<corevette> https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/catalyst_84_linux.html
<blueyed> mvo: no, haven't seen this.. have you looked into using "hald --verbose=yes --daemon=no"?
<mvo> blueyed: not yet, I have to change the package for this, I think I will do it to see what it outputs
<jdong> xhaker: thanks though I won't have time to review until sometime Friday :(
#ubuntu-devel 2008-04-17
<raboof> say some package (alsa-plugins) wants to be in main, but also has some dependencies in universe (libjack)
<raboof> as I understand, the common solution is to make the alsa-plugins source package provide 2 binary packages: 1 for in main (which depends on jack), 1 for in universe (which doesn't depend on jack)
<TheMuso> raboof: Its not that easy.
<TheMuso> raboof: Jack's source has to be in main also.
<slangasek> specifically, alsa-plugins source has to be in main, and it probably build-depends on libjack-dev, so libjack-dev has to be in main, so jack source has to be in main
<raboof> last time I was here I was told that it's okay for source packages in main to have build dependencies in universe, as long as the binary packages that go into main depend only on binary packages in main
<raboof> that's not right then?
<slangasek> it's not, no
<slangasek> I'm afraid whoever told you that was mistaken
<raboof> (or I misunderstood him, but I believe it was quite explicit ;) )
<cjwatson> yeah, that sounds like somebody being quite confused
<cjwatson> I can understand why they came to that conclusion, but it isn't correct; when packages in main are built, they're given an /etc/apt/sources.list in the build chroot that contains only main
<cjwatson> now, it *is* possible for a source package in main to build binary packages in universe
<cjwatson> provided that it doesn't need any build-dependencies over and above what's in main to do so
<cjwatson> sometimes this does make sense and does happen
<raboof> so if I want to have an alsa-plugin-jack, I should lobby for the jack-audio-connection-kit being included back into main
<raboof> (which may or may not be easier by proposing that the resulting jack binary packages still go to universe)
<_MMA_> raboof: I was there for that chat and cjwatson is correct.
<_MMA_> raboof: I will hopefully be able to get JACK back in Main for Intrepid to help with packages like you are asking for.
<cjwatson> raboof: at least one of the binary packages would have to go in main - can't have a source package in main that builds *only* binary packages in universe and nothing else
<cjwatson> if nothing else, build-dependencies are declared on binary packages, not on source packages
<_MMA_> raboof: Work will be needed on this: https://wiki.ubuntu.com/MainInclusionReportJACK Please add anything you can.
<raboof> cjwatson: uh, yeah, right :)
<raboof> obviously :)
<raboof> _MMA_: what's Intrepid? what are you doing to get jack back in main?
<raboof> where should I look for information as to why jack was demoted from main? I guess we need to fix whatever cause that before proposing to put jack back in main :)
<_MMA_> raboof: Don't worry then. I'll be working on it.
<ogra> raboof, intrepid == 8.10
<raboof> ah, right :)
<cjwatson> AFAIK jack-audio-connection-kit has never been in main
<cjwatson> except perhaps in very early releases
<TheMuso> Yeah it was in main very early on.
<cjwatson> you may find some early changelogs that refer to it
<cjwatson> but it's before we kept track of things in any other way
<ogra> the alsa thing needs sorting though ... we should ask upstream if the source of th plugins could be separated
<krux0> is it possible to grep two words simultaneously?
<TheMuso> krux0: If you mean one word after another, then grep "words here" would work. So just put them in quotes.
<cjwatson> or grep oneword | grep otherword
<krux0> two seperate words ....im looking for two diff words coming from a pipe i want it to filter both and show me the lines containing them
<cjwatson> or egrep 'oneword|otherword'
<cjwatson> depending on whether you want AND or OR
<krux0> i got it... this doesn't make sense to me but: grep 'foo|bar|baz' seems to filter foo, bar and baz. I thought '|' was "or" when it came to logic
<krux0> for grep it seems to be used as AND
<cjwatson> you're thinking of it wrongly
<cjwatson> that pattern matches any string that matches any of 'foo', 'bar', or 'baz'
<cjwatson> and therefore returns all lines containing 'foo', all lines containing 'bar', and all lines containing 'baz' - but the pattern matching is the level at which the OR-ness applies
<Caesar> slangasek: do you have any thoughts on #215904 ?
<slangasek> Caesar: well, "eew" comes to mind
<slangasek> Caesar: backtrace would help
<krux0> thanks
<Caesar> slangasek: there's more info in the related Debian bug
<Caesar> We're working on a backtrace at the moment, it's currently a bit non-deterministic
<slangasek> Caesar: hmm.  would help if that bug were actually assigned to the openldap2.3 package in Debian, I think
<slangasek> ah, looks like there is a backtrace
<slangasek> is NTLM a common denominator here?
<Caesar> slangasek: we don't use NTLM
<slangasek> ok
<Caesar> at least we shouldn't be
<Caesar> Where would that be coming into play?
<slangasek> dunno - it shows up in that evolution-exchange backtrace, so it could've been some NTLM-specific breakage
<slangasek> OTOH, the two assertions could be completely unrelated bugs
<Caesar> slangasek: I mean how can I check we're not accidentally using it here? Is that a PAM thing or an NSS thing?
<slangasek> probably a SASL config thing
<slangasek> asac: is 195013 still applicable to firefox, or do we have the necessary langpacks in the archive now?
<ogra> slangasek, 3am here ... he's probably asleep ... but there was a lot discussion in here about ff and langs today
<slangasek> ogra: yes, I'm anticipating a delayed response :-)
<ogra> :)
<slangasek> I'm asking because this bug is currently listed as a caveat on https://wiki.ubuntu.com/HardyHeron/RC, so wanted to check that it still applies
<ogra> hmm, since when is my shell command history written inside of chroots ...
<Caesar> ogra: when you bind mount your home directory in there?
<mathiaz> slangasek: are you planning to rebuild the ubuntu-server iso for rc ?
<ScottK> mathiaz: Earlier he said not.
<slangasek> mathiaz: no, TTBOMK the one that's there is already viable; do you know anything to the contrary?
<ogra> Caesar, no, as root in / of the chroot ...
<ogra> i suddenly can browse a command histroy even if i exit and re-enter ... i'm pretty sure that wasnt the case before
<ogra> woah
<ogra> thats just evil
<slangasek> ?
<ogra> root@ceron:/# ls -al home/
<ogra> total 4
<ogra> drwxr-xr-x  3 root root   17 Apr 17 00:33 .
<ogra> drwxr-xr-x 20 root root 4096 Apr 17 01:24 ..
<ogra> drwxr-xr-x  3 root root   40 Apr 17 01:26 ogra
<ogra> thats a fresh chroot, i definately didnt create a user or homedir for ogra
<slangasek> and you're sure it's not bind-mounted?
<ogra> did chroot change or is that a sudo vs environment fallout ?
<ogra> there is nothing that wuld bnd mount it
<ogra> and i re-checked as well
<ogra> it created /home/ogra/.bash_history
<slangasek> superm1: I see you've milestoned bug #218262 and uploaded a new mythbuntu-diskless; are you wanting this in advance of RC?
<ubotu> Launchpad bug 218262 in mythbuntu-diskless "various failures in mythbuntu-diskless-client-builder.postinst on alt disk" [High,Fix committed] https://launchpad.net/bugs/218262
<superm1> slangasek, yes laga needs it for the alt disk
<ogra> ... which contains all my root commands i just executed ... phew, thats weird
<slangasek> superm1: ok, accepted; if one of you happen to be in a position to watch for the binaries to be installed, I can reroll the alternates
<slangasek> sigh, who came up with the brilliant idea to bind shift-ctrl-w to 'close terminal', anyway
<superm1> slangasek, yeahc providing its made before i go to bed, i can check
<superm1> and laga will be up right about when i go to bed
<slangasek> superm1: hmm, unless you're on a weird virtual timezone right now, shouldn't take nearly that long to get built :)
<superm1> still CST, just wasn't sure if we were behind some other stuff in  the queue
<slangasek> queue should be rather desolate right now
<superm1> ok i'll keep an eye then
<cjwatson> ogra: HOME is probably still set to /home/ogra despite sudo chroot
<ogra> cjwatson, well, it was as well in gutsy or some weeks ago when i last time did manual work inside chroots but it never bothered to create a homedir or .bash_history until now
<ogra> i usually delete /root/.bash_history at the end of my work if i do something manual in a chroot i want to squash up
<ogra> thats why i noticed it first place
<syke> hi
<syke> I attached my lspci output to bug 197558
<ubotu> Launchpad bug 197558 in linux "ssb module breaks BCM4328 with ndiswrapper (regression from 2.6.24-10)" [Medium,Incomplete] https://launchpad.net/bugs/197558
<_MMA_> haha
 * _MMA_ is trying to cope with that ATM as well. :P
 * _MMA_ just says F-it and buys this: http://cgi.ebay.com/New-Intel-Pro-Wireless-2200-Mini-PCI-802-11g-MiniPCI-I1_W0QQitemZ200214729388QQihZ010QQcategoryZ101281QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
<superm1> slangasek, laga, the binary for mythbuntu-diskless ended up clearing an hour ago if you can re-roll the mythbuntu alt disk
<ion_> asac: Does it actually look like we might get nspluginwrapper for x86 for hardy?
<JohnPhys> Apologies if this is not the correct channel, but is it still possible for the fix to Bug #195052 to be included in hardy even though it's in final freeze?  As far as I can tell, the patch only affects the latex rendering effect in inkscape (which is currently broken), so I think it would be a low-risk patch.
<ubotu> Launchpad bug 195052 in inkscape "Latex formula does not work on Ubuntu Hardy" [Undecided,Fix released] https://launchpad.net/bugs/195052
<ScottK> JohnPhys: That's not actually even a bug against the Ubuntu package right now, so I'd say the odds are very low.
 * ScottK gives bad news and heads off to bed ...
<ScottK> It's filed against upstream and in Fedora, but not here.
<JohnPhys> ScottK:  thanks for the info, how does one file it against hte ubuntu package?  File a new bug and mark as a duplicate of that one?
<ScottK> No.  Use also affects (IIRC).
 * ScottK really goes to bed ...
<JohnPhys> ok, thank you
<slangasek> superm1: mythbuntu alternate rebuilding
<superm1> thx
<bdmurray> slangasek: somebody brought up bug 195929 to me
<ubotu> Launchpad bug 195929 in gtk2-engines-murrine "Cosmetic bug: rectangular white outline surrounding rounded buttons" [Low,Fix committed] https://launchpad.net/bugs/195929
<bdmurray> slangasek: it's fixed upstream and has a small patch afaict
<slangasek> hmm, "fix committed" is wrong here, yes?
<bdmurray> I think for that task it might be right
<bdmurray> see comment 5
<ScottK> slangasek: Not according to the Launchpad developers who decide all this stuff.  If it's anywhere publically available, it's Fix committed according to them.
<slangasek> there's no Ubuntu bzr branch for that package though
<slangasek> ScottK: ... erm
<slangasek> ok, would be nice if that were applied consistently then
<slangasek> anywho
 * ScottK recalls a long Launchpad blog post last year where it was explained how we were using the system wrong.
<slangasek> ScottK: well, it seems counterproductive to me to label distro-specific tasks as 'fix committed' when we have the capability of opening upstream tasks separately
<bdmurray> slangasek: Where did you hear about Fix Committed = Ubuntu bzr branch?
<slangasek> bdmurray: I am intrigued that the fix appears to involve /dropping/ a firefox workaround from the theme
<ScottK> slangasek: I agree, but since I'm not a LP developer, clearly I don't know how to use the system properly.
<slangasek> bdmurray: either on IRC, or picked up by osmosis through how I've seen LP used
<bdmurray> slangasek: Okay, I'm back to it shouldn't be Fix Committed since it isn't an upstream task
<ScottK> http://news.launchpad.net/general/of-bugs-and-statuses - OK, it's not quite a broad as I'd remembered.
<ScottK> slangasek: ^^^ supports your position.
<slangasek> hurray!
 * ScottK goes to bed.
<LaserJock> I was told  Fix Committed = fixed somewhere
<LaserJock> I think that's a common #ubuntu-desktop way of doing it
<bdmurray> I think it is important to take each task into account when looking at the status.
<bdmurray> slangasek: I think that fix was for Firefox 2 but I'm not certain
<LaserJock> bdmurray: what do you think Fix Committed should be used for?
<slangasek> bdmurray: yes, that's what I gather from the bug log.  anyway, it looks suitable to me for a post-RC fix, but needs someone (not me) to take on doing the actual upload
<bdmurray> LaserJock: If it is about an Ubuntu package then fix committed to that package, not upstream.  If the bug is upstream there should be an upstream task / affects line reflecting that.
<LaserJock> bdmurray: but my concern that it is misleading to have the Ubuntu task as Fix Committed when nothing has been done in Ubuntu
<LaserJock> *is that
<bdmurray> LaserJock: I think we are on the same page here.  I flipped bug 195929 to Triaged and it really should have an upstream task open and that should be Fix Committed.
<ubotu> Launchpad bug 195929 in firefox "Cosmetic bug: rectangular white outline surrounding rounded buttons" [Unknown,Confirmed] https://launchpad.net/bugs/195929
<LaserJock> bdmurray: but like the desktop team makes the Ubuntu task Fix Committed if the upstream task is Fix Released, that's what I'm talking about
<bdmurray> LaserJock: okay, I haven't seen that personally but will check with them if you like
<slangasek> LaserJock: hey, btw, bug #215729 - the patch did have a memory leak... :)
<ubotu> Launchpad bug 215729 in seahorse "Seahorse fails to import keys" [Medium,In progress] https://launchpad.net/bugs/215729
<LaserJock> bdmurray: well, I don't care too much. I just find a lot of inconsistency on what statuses are used for
<LaserJock> bdmurray: like the great Incomplete debate
<LaserJock> slangasek: darn, I had a suspicion
<slangasek> LaserJock: fixed patch is in the bug now, if you're interested in comparing
<slangasek> but from your valgrind output, this probably isn't the /only/ memory leak either... :)
<ScottK> Well I've seen firefox bugs flipped to In Progress because they'd been REPORTED upstream.
<ScottK> Who knows.
<slangasek> heh, twitch
<LaserJock> slangasek: yeah, I noticed from my valgrind input a slight increase in leaked memory, but I didn't know if that was due to the patch or just random leakage
<Hobbsee> slangasek: you should really make sure, at UDS, that you have a debate with kiko, and mdz, and anyone else interested, on hwo to use launchpad statuses.  It's very enlightening.
<slangasek> hmm :)
<Mirv> in case there are any ppc folks around, openoffice.org-voikko would need a binary-only upload. bug #218503.
<ubotu> Launchpad bug 218503 in openoffice.org-voikko "[hardy] openoffice.org-voikko has unmet dependencies on PowerPC" [Undecided,New] https://launchpad.net/bugs/218503
<Mirv> rebuild, that is
<StevenK> It may just need a giveback
<LaserJock> Hobbsee: hmm, did we do that in Sevilla?
<Hobbsee> LaserJock: i certainly did.  I think you were there too.
<Hobbsee> LaserJock: it was over lunch - far left hand corner of the room, looking from the lifts.  Same day as the sign next to a plate of meat saying "not vegitarian"
<LaserJock> yeah, I vaguely remember a lunch
<LaserJock> hah
 * Hobbsee recalls going "yeah, ah, no shit!"
<LaserJock> not nearly as bad as Paris
<LaserJock> I remember people wondering why all the "Vegitarian" cards at dinner had a pig on them
<LaserJock> and Jeff Bailey sending his plate back I think 3 times to get something vegan
<LaserJock> "no, mash potatoes with bacon is not vegan"
 * slangasek grins. Dining in a foreign country with Jeff is fun.
<slangasek> vegan food at DebConf 4 in Brazil:  oh, rice and beans, that should work, except you put *ham* in it, good job.
<LaserJock> yeah, you gotta watch the beans
<dholbach> good morning
<emgent> morning
<emgent> morning
<emgent> oops, loop :P
<Hobbsee> morning dholbach
<dholbach> hi Hobbsee, hey emgent
<LaserJock> hi dholbach
<dholbach> hiya LaserJock
<emgent> dholbach: When you have time see query, Thanks.
<superm1> slangasek, the resultant build should have been 20080417 right?  It looks like the old udeb was still used?  That's weird - it was available from a.u.c at the time i mentioned it to you...
<slangasek> superm1: hmmmm. well, I confess that I didn't double-check that before triggering the build
<slangasek> should I try again?
<superm1> yeah I guess.
<superm1> 0.8 of another of the debs is definitely showing up from apt-cache policy
<superm1> so i assume the udeb should have been there too
<slangasek> oh, this is in universe, grrrrr
<superm1> is that the problem?
<slangasek> the mirror syncing stuff fails royally for the derivs that build out of universe
<superm1> so it needs manual prodding or what not?
<slangasek> yes
<superm1> that is rather annoying.  sorry :S
<slangasek> ah, heh, this is a nice bug
<slangasek> ... where by "nice" I mean "oh argh, I need to rebuild the ubuntu and kubuntu dailies as well"
<superm1> they shouldn't be touching anything in universe though should they?
<slangasek> no
<superm1> oh, so unrelated bug that will require their rebuildings
<slangasek> it turns out there's a bug in build-image-set wrt mirror handling that one can trigger quite nicely if one, er, hard-kills some previous daily builds
<slangasek> which affected all of the above
<superm1> ah
<superm1> oh well it sounds like that bug is there just for entertainment value then
<slangasek> it's a "surely no one with access to this would be mad enough to force-kill a daily job and break this semaphore, nope"
<slangasek> ... bug
<superm1> you can't just reset the semaphore?
<slangasek> now that I've noticed it's there, absolutely ;)
<superm1> ah the joys of file locking and data sharing
<dholbach> could it be that 20080417 is broken?
<slangasek> dholbach: yes, the whole day is broken, I confirm this ;)
<dholbach> amd64-alternate in this case - it's sitting at "ldconfig deferred processing now taking place"
<slangasek> mmm, that's news to me
<slangasek> I've just rerolled 20080417.1 anyway, can you rsync that and give it a try?
<dholbach> slangasek: will do
<slangasek> /shouldn't/ be any changes that affect this, but then, that shouldn't have been broken in the first place :P
<munckfish> If I have 256mb of RAM how much memory should I expect to see reported by "free -m" on the hardy live CD?
<munckfish> currently it reports 86mb
<slangasek> munckfish: "little enough that you can't run ubiquity"
<slangasek> superm1: so thanks for pointing this out, that could've been quite messy otherwise :)
<munckfish> so that sounds about right?
<munckfish> thx
<slangasek> munckfish: honestly, I don't know, I just know that 256 isn't enough to run the installer to completion
<superm1> slangasek, no prob.  will ours be behind the other dailies, in parallel, or who'es up next then?  (I'm debating bed now or wait/test)
<munckfish> slangasek: thx
<slangasek> superm1: behind; the whole series will only take another 10 minutes to finish though
<superm1> alright, i'll stick around then
<munckfish> ha kernel just killed bash out from under me :D just as I was about to try and enable swap! haha. PS3 needs more memory
<superm1> munckfish, if you aren't booted into only-ubiquity mode, i would recommend doing so on the ps3
<Ng> even in gutsy you have to kill a lot of stuff so ubiquity will run to completion on a ps3
<munckfish> well, I'm trying to debug and X crash
<munckfish> but also having only 1 PS3 I'm trying to keep my stable gutsy install
<munckfish> around till I'm sure I won't need to rebuild things on it again
<munckfish> *an X crash
<munckfish> doesn't seem to have any swap setup auto, I'm trying to mount that now, see if that eases things
<munckfish> Alt+SysRq+e just took me down to a shell again luckily
<TheMuso> munckfish: Is it true that you can only use 10GB for Linux?
<munckfish> TheMuso: you can either use 10GB for linux or 10GB for sony
<munckfish> you take your pick
<munckfish> but no custom partition sizes
<superm1> but external hard drives are still usable
<superm1> for storing stuff
<munckfish> oh sure
<munckfish> what's the correct way to re init the normal run level?
<munckfish> Now I've added swap I want to fake a restart (cause I don't have time for a real restart)
<munckfish> (work time is looming)
<slangasek> superm1: mythbuntu 20080417.1 done, should be visible from cdimage shortly if it's not already there
<pitti> Good morning
<superm1> thanks
 * slangasek waves to pitti
<StevenK> Morning pitti
<pitti> CD testing o'clock, I suppose?
<davmor2> slangasek: how are all the iso's doing?
<slangasek> davmor2: well, aside from having to do a last-minute respin of the alternates and DVDs because the last batch built from an out-of-date mirror, pretty good
<slangasek> and the alternates are all updated again anyway, with the DVDs to follow shortly
<davmor2> slangasek: cool :) downloading :)
<laga> morning.
<superm1> hey laga
<superm1> new alternate just finished generating with that udeb
<dholbach> slangasek: 20080417.1 looks better
<slangasek> dholbach: ah, good, then I can pretend the failure never happened and ask no questions ;)
<pitti> argh, the current ubiquity TZ selector got much worse than the one from beta
<pitti> evand: ^ is that still considered a bug, or is the current one considered 'final'?
<slangasek> define "worse"?
<pitti> it's utterly hard to pick a city, since the moment you move the cursor, the map slides away under you
<stgraber> it should only slide when your mouse hit one a corner IIRC
<slangasek> indeed
<slangasek> that's what I understood was /supposed/ to be going on
<seb128> didn't try today's image yet, but on the 20080415 image the tz selector was not usuable for me, it zoomed on the wrong region and scrolled in a non correct way
 * slangasek tests, and gets sane behavior from the package in the archive...
<slangasek> pitti: which image?
<pitti> slangasek: amd64 desktop Ubuntu
<pitti> testing i386 desktop now
<slangasek> pitti: image date?
<pitti> 20080417
<pitti> cjwatson: hm, bug 218549 looks like a recent (small) regression
<ubotu> Launchpad bug 218549 in rescue "Choosing "Reboot" in rescue menu jumps to main menu" [Undecided,New] https://launchpad.net/bugs/218549
<asac> ion_: no ... that was a typo ... i ment intrepid
<ion_> asac: Alright
<pochu> soren: hi. I'd appreciate your input in bug 206227 when you have some time. thanks
<ubotu> Launchpad bug 206227 in gtk-vnc "vinagre fails to connect" [Low,Fix committed] https://launchpad.net/bugs/206227
<calc> how can you determine which entry in ~/.ssh/known_hosts to delete for an ip?
<calc> i thought it used to stick the ip address in that file
<soren> calc: ssh-keygen -F
<soren> calc: It's hashed now a days.
<soren> WEll, actually.
<calc> ah ok
<soren> calc: ssh-keygen -R host_to_remove
<soren> -F just finds it.
<calc> ah
<calc> soren: thanks! :)
<soren> np
<laga> cjwatson: i've just tried today's daily for mythbuntu and the tasks still don't work. i get "task mythbuntu-frontend not found", for example. here's the diff i committed last night: http://bazaar.launchpad.net/~mythbuntu/ubuntu-seeds/mythbuntu.hardy/revision/1105
<pitti> evand, slangasek: it seems that, depending on whether I boot at an even or odd second, the scroll area of the TZ widget changes; last boot I had something like a 20 pixel border, now almost all of the widget triggers scrolling
<pochu> Anyone knows if Tormod Volden is on IRC?
<stgraber> pochu: he isn't
<stgraber> pochu: his nick is "tormod"
<pochu> stgraber: ok, thanks
<pochu> stgraber: congratulations for your Europe Council membership :)
<stgraber> pochu: thanks
<pitti> ScottK, Hobbsee: does Jani have motu-release delegated power for xubuntu? (bug 217697 and bug 217702 have no ack, but are in unapproved)
<ubotu> Launchpad bug 217697 in sugar-chat-activity "Please include Chat-35" [Undecided,New] https://launchpad.net/bugs/217697
<ubotu> Launchpad bug 217702 in sugar-read-activity "Please include Read-45" [Undecided,New] https://launchpad.net/bugs/217702
<Hobbsee> pitti: erm.  unsure.  i *think* so
 * Hobbsee checks the mail
<Hobbsee> pitti: cody-somerville does, not jani
<pitti> Hobbsee: ok, thanks; I'll sub m-r and ask
<Hobbsee> bug 218133
<ubotu> Launchpad bug 218133 in sun-java6 "UVF exception for hardy" [Undecided,Confirmed] https://launchpad.net/bugs/218133
<Tonio_> hi
<Tonio_> anyone here using a macbook ?
<Tonio_> my battery monitor stopped working a few days ago (2 or 3)....
<Tonio_> I tried installing old hal-info package but that didn't help....
<Tonio_> is that known problem or should I report the bug ?
<Tonio_> hum right that bug 215074
<ubotu> Launchpad bug 215074 in linux "macbook battery info not readable, appears empty" [Undecided,Confirmed] https://launchpad.net/bugs/215074
<davmor2> mvo: Dapper -> Hardy with all the lang pack went fine.  :)  However,  I found another minor bug.   I changed the backdrop in Dapper to the ubuntu tree.  Once the system upgrade had finished I just had a black (or maybe dark brown) Backdrop.  I know it's a right click to change it but I thought I'd let you know.
<mvo> davmor2: no picture in the background anymore, just a dark color?
<davmor2> mvo: basically yes.  You don't get the heron just darkness.  I think it maybe that I changed from the default background and it isn't in hardy so there was nothing to display
<davmor2> mvo: I asked heno just to double check if he gets chance
<mvo> davmor2: is that in a VM or on real HW? (just curious, may not be releated to the problem)
<davmor2> mvo: I only really test on real hardware :)
<heno> I'm starting a test soon, just need to install some more random packages
<soren> Could a release team member please give kvm a gentle nudge through the unapproved queue?
<davmor2> mvo: do you need anything off this system before I drop XP on for wubi tests?
<mvo> davmor2: is it running compiz when you see the black background?
<davmor2> no
<mvo> davmor2: what happens if you restart metacity (metacity --replace) ?
<pitti> asac: m-f-locale-all> IMHO the depends should be language-pack-CURLANG, not language-support; mind if I reject this and you fix that?
<davmor2> mvo: still black#
<asac> pitti: it was that way before
<asac> i just try to cure things right now
<pitti> asac: ah, wait; seems I misinterpreted the idea of the chagne
<asac> pitti:  i didn't change anything ... only the order
<pitti> asac: those are not supposed to become transitional packages for language-pack for ffox 3
<asac> right
<pitti> but meant to be used for ffox2
<asac> pitti: the bug is that when you upgrade from gutsy with langpacks you automatically get ffox 2
<pitti> right
<pitti> makes sense then
<asac> thats because of the order
<asac> (i hope) :)
<pitti> well, if you already have l-support-XX installed, it shouldn't matter
<pitti> since the | is satisfied
<asac> pitti: i think after the upgrade they should be autoremovable in best case
<asac> pitti: it mattered
<asac> pitti: at least it was in the log
<pitti> if you don't have it installed (because you don't want it), then now you'll get l-support instead of ffox2
<asac> hmm
<asac> davmor2: ^^
<pitti> so, not sure what is better
<asac> didn't you install the complete language suppor thing when testing?
<asac> davmor2: ?
<davmor2> asac: last nights that completed this morning yes only FF3 is now installed :)
<asac> davmor2: my question is if you installed the complete language support when testing
<asac> davmor2: or just the locale- packages?
<davmor2> asac I used sudo apt-get install language*
<asac> davmor2: what is language?
<asac> davmor2: please give me a concrete example ;)
<asac> pitti: oh it was accepted now ;/
<asac> pitti: roll back?
<pitti> asac: what was accepted?
<asac> pitti: the package ;)
<pitti> asac: firefox-locale? ugh, wasn't me
<asac> -> -release
<davmor2> asac: that is enough to install all the language package in the ubuntu repos.  All the packages in dapper start language-pack-"whatever language"(-base)
<asac> maybe we should have this conversation there :)
<pitti> asac: well, I don't mind much, it's fine
<asac> pitti: ^^
<Mirv> at least currently there's a problem that if one opens language support in hardy after upgrade, the application recommends installing mozilla-firefox-en-gb and mozilla-firefox-locale-my-locale. dunno if it's a problem of the tool or package dependencies?
<asac> pitti: he had the language stuff installed  ... and got ffox 2 still
<pitti> asac: davmor2 only mentioned having -pack installed; davmor2, please confirm?
<asac> ok ... lets better not get distracted by this now ;) ... i have a ffox security update to do while we are releasing :)
<davmor2> pitti: language* pulls in the packs and the base and any files as dependancies
<pitti> davmor2: I mean, you did not have language-support-XX installed
<pitti> davmor2: otherwise this wouldn't have happened, since teh alternate dependency would have been satisfied
<davmor2> pitti: hang on
<davmor2> pitti: yes all the support too
<pitti> weird
<pitti> that would be a bug in apt then, but I cannot believe that we wouldn't have noticed that until now
<davmor2> pitti: anything with language at the beginning
<asac> davmor2: what was the bug id again? :)
<asac> we have all the logs in there
<asac> maybe we should open an apt bug for that until we know for sure
<davmor2> bug 217876
<ubotu> Launchpad bug 217876 in ubuntu "Firefox 2 remains in gusty -> hardy upgrade when lang-packs are installed" [Medium,Fix committed] https://launchpad.net/bugs/217876
<davmor2> asac is that the right one?
<davmor2> that was the one done with 3 or 4 language packs if memory serves
<davmor2> asac: pitti: do you want me to upload my latest logs before I kill it?
<pitti> davmor2: sure, would be nice to have them on the bug, just as a reference
<pitti> davmor2: thank you!
<davmor2> pitti: uploading
<dholbach> does anybody get "Could not stat /dev/sda1 --- No such file or directory" using ubiquity (use whole disk)?
<dholbach> all I have here is /dev/sda{,5,7}
<davmor2> pitti: logs are up now
<davmor2> killing it now :)
<mvo> pitti: what is the right way to reload the policykit config after a upgrade?
<pitti> mvo: hm, I don't think you explicitly need to, it should have inotify magic
<pitti> mvo: let me confirm that
<pitti> mvo: at least changes to /etc/PolicyKit/PolicyKit.conf get effective immediately
<pitti>      - drop /var/lib/PolicyKit/reload and rely on inotify to detect
<pitti>      changes to
<pitti>        - /etc/PolicyKit/PolicyKit.conf
<pitti>        - Policy files in /usr/share/PolicyKit/policy
<pitti>        - privileges in /var/lib/PolicyKit and /var/run/PolicyKit
<pitti> mvo: ^ so if it's just those files (which I assume), live is good
<seb128> mvo: what is the issue?
<mvo> seb128: still #63450
<seb128> mvo: walters replied after you closed IRC yesterday btw, he said that doing a dbus reload is not a good idea
<mvo> it hangs for me on gutsy->hardy
<seb128> mvo: the old dbus is running and the new config is on disk, and they is no real way to get that working
<mvo> seb128: we do a dbus force-reload in the hal.postinst
<seb128> mvo: people should just reboot after upgrade or accept small glitches, there is no real way around it
<sjoerd> mvo, seb128: dbus reload is jsut a config file reload, not a daemon restart
<seb128> sjoerd: well, the old dbus doesn't like the new config format apparently
 * sjoerd didn't know anything changed in the config format
<seb128> so maybe that's something else, see current comment on bug #63450
<ubotu> Launchpad bug 63450 in acpid "acpid install fails (because of hal running)" [High,In progress] https://launchpad.net/bugs/63450
<laga> any chance of https://bugs.launchpad.net/ubuntu/+source/hal/+bug/210748 getting fixed for hardy, btw?
<ubotu> Launchpad bug 210748 in hal "hal can't upgrade in chroot: polkit-auth call in postinst fails" [Undecided,New]
<mvo> yeah, I'm currently mostly guessing, but I see the hang pretty consistently
<soren> kvm and libvirt in unapproved queue... Could someone please give them a shove? They fix bug 218204, bug 213991, and 1/3 of bug 218574 and possibly others I haven't spotted.
<ubotu> Launchpad bug 218204 in kvm "kvm crash when clicking on pause" [Undecided,New] https://launchpad.net/bugs/218204
<ubotu> Launchpad bug 213991 in libvirt "libvirt should allow for 'model' of nic" [Wishlist,New] https://launchpad.net/bugs/213991
<ubotu> Launchpad bug 218574 in virtinst "Virtio devices from libvirt" [High,In progress] https://launchpad.net/bugs/218574
 * soren -> lunch
<cjwatson> soren: are these fixes release-critical? that would require respinning server CDs at the moment
<cjwatson> and the DVD
<cjwatson> soren: otherwise, post-RC
<Keybuk> tkamppeter: hey, you around?
<mvo> sjoerd: if you have a idea about the bug, I'm very open for suggestions, it is posslbe that its a bad ordering of unpack/configure during the upgrade, e.g. that hal is unpacked, but not configured yet when acpid.postinst runs
<pitti> mvo: simple hack would be to add a dependency to acpid?
<sjoerd> mvo: hmmm, iirc we (=debian and i assume ubuntu) have a patch that prevents hal to open /proc/acpi/event
<sjoerd> lemme doublecheck
<mvo> pitti: a hal dependency? I'm not sure that people would like that
<pitti> sjoerd: yes, if /usr/sbin/acpid exists we don't open it
<pitti> 23_addon_acpi.patch
<sjoerd> but that doesn't help on acpid install ofcourse
 * pitti personally blames soren for bug 218583 :-)
<ubotu> Launchpad bug 218583 in linux "KVM oops in kvm_vm_ioctl_get_dirty_log" [Undecided,New] https://launchpad.net/bugs/218583
 * pitti hugs soren
<seb128> is openoffice supposed to be translated after selecting a language in the language selector?
<cjwatson> assuming it then went and downloaded language-support-* ...
<seb128> it downloaded 15 packages but I didn't look at the detail
<seb128> let me check
<seb128> yes
<seb128> language-support-fr is installed
<seb128> and openoffice-l10n-fr too
<seb128> but openoffice is still all english
<cjwatson> laga: I'll look into it, thanks
<cjwatson> seb128: you don't need to log out and log back in to get a different $LANG or something?
<seb128> cjwatson: I did restart the session
<seb128> cjwatson: I'm looking at how well hardy is french translated
<seb128> so I usually boot the cd, go to the language selector, select french and restart the session
<seb128> everything is translated correctly out of openoffice
<soren> cjwatson: I thought we delayed RC till Friday so that we could actually get more stuff fixed before then?
<seb128> but I'm not sure how the openoffice translations work
<soren> pitti: You know... It's not entirely impossible :)
<soren> pitti: Which graphics driver are you using?
<soren> pitti: Oh, we already covered that, didn't we? It was cirrus?
<pitti> soren: cirrus inside, intel outside
<soren> In that case, it's *probably* not my fault. I did some work on the vmwarevga emulation, actually dealing with the dirty page tracking and such, so you had me scared there for a second :)
<pitti> I got it about four times in a row now, always when doing partitioning
<pitti> soren: nevermind for now, but I reported it just in case it is useful for someone
<pitti> soren: since you have the exact same machine, you might get it as well :)
<cjwatson> soren: we delayed it in order to actually be able to test it, since we knew we weren't going to have testable images until last night
<cjwatson> soren: changes at this point will push it out even further
<soren> cjwatson: Ah, ok.
<soren> cjwatson: I'm not sure how to respond to the question about whether it's release critical... I think it *is* release critical, but I'm not sure if I think it should delay the RC release.
<soren> ...but your question implied those two things to be equivalent.
<cjwatson> soren: I meant RC-critical, sorry
<soren> Oh! Yes, that makes more sense. :)
<cjwatson> as in, do we need to respin RC-candidate images for this
 * cjwatson finally figures out how to make the Edubuntu CD health check mails shut up
<pitti> mvo: argh, we need to drop the mozilla-firefox-locale-* special case from the language selector
<pitti> mvo: I suppose it also has a special case for openoffice-*?
<heno> *** General ISO testing Ping! *** The images on http://iso.qa.ubuntu.com/qatracker/build/all/all are on track to be released as RC. Please help test them!
<pitti> mvo: can we please replace this with language-support-translations-*?
<heno> see https://wiki.ubuntu.com/Testing/ISO/Procedures for details and join #ubuntu-testing to coordinate
<heno> Thanks!
<pitti> mvo: I filed that as bug 218588 and assigned that to you; is that ok?
<ubotu> Launchpad bug 218588 in language-selector "use language-support-translations-* instead of special cases" [Undecided,New] https://launchpad.net/bugs/218588
<cjwatson> dear Col, pointing rsync at the directory that has a previous copy of the image you want rather than the one that doesn't will probably make it go faster, love Col
<pitti> ogra: sigh, bug 203954 is still there :/
<ubotu> Launchpad bug 203954 in ltsp "amd64 server installation has wrong default dhcpd.conf (s/i386/amd64/)" [Undecided,Confirmed] https://launchpad.net/bugs/203954
<tkamppeter> Keybuk, hi
<Keybuk> tkamppeter: been having some problems with my printer, it just doesn't work under hardy
<Keybuk> bug #217215
<ubotu> Launchpad bug 217215 in hplip "HP LJ 1018 regression in hardy" [High,New] https://launchpad.net/bugs/217215
<Keybuk> someone on that bug who sounds authorative says we need hplip 2.8.4
<Keybuk> is he on upstream "must have latest version or I won't talk to you" syndrome
<Keybuk> or is it genuinely likely to be fixed
<ogra> pitti, yes, on purpose, i onder if i just skip that setp on amd64 in two years of ltsp i met exactly one user who used amd64 clients
<ogra> s/onder/ponder/
<mvo> pitti: I have a look now
<pitti> ogra: well, I think it isn't hard to fix in intrepid
<pitti> ogra: I guess it should be optimized for creating an i386 chroot on an amd64 server
<ogra> pitti, while it would solve the config file change it breaks for all users wanting to use i386 client on amd64
<ogra> pitti, right
<ogra> intrepid will get a network check ad if network is up ltsp-client-builder will offer an i86 root
<ogra> *i386
<pitti> ogra: right, was just going to ask about that; this would be great
<ogra> but thats nothing for hardy ... i either disable it completely or leave it as is (which means a long standing documented situation)
<pitti> ogra: in hardy it's primarily a documentation issue IMHO
<ogra> right
<ogra> in gutsy and feisty as well :)
<pitti> there's nothing that tells me what to do to create an i386 chroot
<ogra> oh, i read documented :)
<pitti> well, I guess with some googleing/forum lookup I'd find out quickly enough
<ogra> well, i should probably add anoter note to the installer telling you about it
<ogra> grr ...
<ogra> why cant i set values in sysfs from an initscript ?
<pitti> ogra: apt-get install sysfstools
<pitti> ogra: then you can
<ogra> hmm, dont we have that in by default ?
 * ogra waits for the cmpc to boot
<pitti> no, we don't
<ogra> ah
<tkamppeter> keybuk, Aaron is from HP and he is watching Ubuntu bug reports on HPLIP.
<tkamppeter> Keybuk, when he is sure that the shown problem is fixed by 2.8.4, he should send us a patch.
<Keybuk> tkamppeter: though I should probably mention now that I've set the printer up without hplip (direct usb) and it's still breaking on hardy
<Keybuk> any idea on that?
 * ogra curses about /sys 
<ogra> amitk, is there any other way to enable the persistence than to echo a 1 to the /sys path ?
<ogra> i seem not to be able to write to that value from an initscript (and sysfsutils doesnt offer me teh value)
<ogra> intrestingly if i cal the script manually after boot all is fine :/
<ogra> probably someone else has an idea before i waste even more time for a damned three liner  http://paste.ubuntu.com/7278/
<TheMuso> I noticed earlier that slangasek was talking about somethign to do with issues with mirroring universe bits when previous builds have been failed. He then re-spun mythbuntu disks. I'm just wondering if UbuntuStudio needs the same treatment, if so, if someone could take care of it, that would be much appreciated, thanks.
<_MMA_> TheMuso: ï»¿slangasek mentioned that Studio probably wont need to be. I *thought* it was some OO.o issue and therefore won't effect us. But would be best to let him chime in I guess.
<TheMuso> _MMA_: Ok it can wait then, as I won't have time tonight to test them, well, not if I want a sane amount of sleep.
<_MMA_> :P
<davmor2> evand: PING
<TheMuso> After having a few late nights, I do want that. :p
<cjwatson> _MMA_: OOo was something else; this bit was due to slangasek killing build processes and forgetting to clean up a bit of debris :)
<_MMA_> Ahh.... :)
<smarter> ConsoleKit sessions are stopped when DBUS is restarted, this prevent applications from using the "at_console" policies(like changing cpu frequency), I've found this bug with Kubuntu and guidance-power-manager, can someone confirm?
<smarter> pitti: ^
<amitk> ogra: no other way at the moment. With 2.6.25, persist will become default.
<ogra> amitk, ok, then i'll dig further to get the echo working ...
<amitk> ogra: putting it in rc.local should be enought AFAICT
<amitk> ogra: with a fixed path even, since the USB HDD shouldn't be moving around
<ogra> amitk, well, it seems to not get permission to write while run from the initscript ... though running it through sudo works
<ogra> the instaler offers to install to any blockdevice it finds ... so i need to catch the whole first bus (where all usb ports can have disks)
<ogra> oh !
<ogra> hmm, it works
 * ogra wonders whats wrong with "echo 1 >$file >>/var/log/syslog 2>&1;" vs "echo 1 >$file"
<ogra> oh, hmm
<pitti> smarter: yes, confirmed; dbus restart> just don't do that, please
 * ogra blushes 
<smarter> pitti: dbus is restarted on upgrade, no?
<pitti> smarter: no, since upstream does not support that
<smarter> okay, thanks
<pitti> debian does, we don't (since it breaks too much)
<ogra> smarter, it shows a reboot notification in ubuntu so it gets restarted during next boot ...
<ogra> but doesnt restart itself
<mvo> pitti, sjoerd: could you please check my comments 29 and 30 on bug #63450 - what is your opinion on this?
<ubotu> Launchpad bug 63450 in acpid "acpid install fails (because of hal running)" [High,In progress] https://launchpad.net/bugs/63450
<sjoerd> mvo: i'd say either 1) or have acpi restart hal if it's running
<mvo> sjoerd: trouble is that its not safe to just restart hal - I have a testcase where on upgrade hal is unpacked but not configured yet when acpid.postinst is run. then hal restart hangs forever (for some reason that I don't know)
<sjoerd> the ``if it's running'' part is important there :)
<sjoerd> but yeah that might be a bit tricky indeed
<mvo> hm, I missed the "is running" bit :) let me check that out
<sjoerd> mvo: adding a status command to the hal init script would be fine by me btw (like for example postfix has)
<hcoal> when shutting down, Ubuntu doesn't actually switch off at the end, it just stays on the Ubuntu splash screen and I have to switch the PC off by the switch.  Restarting works fine, could this be a power managenet setting in my bios?
<hcoal> whoops, wrong channel... sorry.
<cody-somerville> pitti, What were the bugs requiring an ack?
<pitti> cody-somerville: bug 217697 and bug 217702
<ubotu> Launchpad bug 217697 in sugar-chat-activity "Please include Chat-35" [Undecided,New] https://launchpad.net/bugs/217697
<ubotu> Launchpad bug 217702 in sugar-read-activity "Please include Read-45" [Undecided,New] https://launchpad.net/bugs/217702
<cody-somerville> Thats not Xubuntu. Thats Jani's OLPC project.
<pitti> ah
<pitti> I sub'ed motu-release, so they should ack it
<mvo> pitti: I attached a patch on bug #218588 could you have a quick look at it?
<ubotu> Launchpad bug 218588 in language-selector "use language-support-translations-* instead of special cases" [Undecided,New] https://launchpad.net/bugs/218588
<pitti> mvo: will that take care of installing language-support-translations-*? or is that handled anyway by checking the dependencies of language-support-*?
<mvo> pitti: its a hard dependency on langugae-support-$foo - if that one is not instaleld (langauge-support-$foo) then the language is not shown as installed in the langauge-selector gui
<pitti> mvo: ah; but it won't offer you to install missing bits if you have language-pack-*, but not -support? (e. g. you did a networkless install)
<mvo> pitti: I need to double check, but I think in this case l-s considers the language as not installed in its gui
<mvo> pitti: this could be changed of course
<pitti> mvo: otherwise it looks fine to me
<pitti> mvo: 63450> replied in the bug
<Keybuk> MacSlow: #ubuntu-meeting
<mvo> pitti: just checked, it does not tell you about the missing langauge-support-$lang packages. that is trivial to add though if that is what we want. I think in the past the idea behind not showing it was that langauge-support-$lang tended to be pretty huge
<pitti> mvo: right; I think we should leave it like it is for now
<pitti> mvo: well, maybe you should just change the special case for OO.o to l-support-translations-*
 * mvo nods
<pitti> mvo: that would keep existing behaviour
<pitti> and drop the ffox special case
<evand> dholbach: re could not stat /dev/sda1> that was fixed and uploaded last night, but didn't make it into the RC.
<pitti> mvo: or move firefox to firefox-2
<pitti> mvo: ^ even better IMHO
<dholbach> evand: excellent - I'm happy to hear that - let me know once it has landed and I should test it
<stgraber> ogra: anything in particular you want to be tested for LTSP ? Standard setup boots correctly here
<mvo> pitti: right, that makes sense, same as openoffice.org for thunderbird I assume?
<pitti> mvo: right
<dholbach> evand: you can mark bug 218578 as a duplicate then
<ubotu> Launchpad bug 218578 in ubiquity "Could not stat /dev/sda1" [Undecided,Confirmed] https://launchpad.net/bugs/218578
<evand> pitti: what's the screen resolution on the machine where you're having trouble with the tz widget?
<ogra> stgraber, well, only the standards should be fine ... play around a bit if you want to and try to break it :)
<pitti> evand: 800x600, and 1280x800 (the latter is slightly better)
<stgraber> ogra: bah, even sound works at first try ... not funny :)
<evand> pitti: and it moves the widget no matter where the cursor is on the map?
<pitti> evand: the window where it isn't moved is extremely small
<seb128> the map autozooming thing is really confusing and zoom and unzoom quickly and on wrong place
<ogra> stgraber, gah, file a but "ltsp unbreakable" :P
<evand> pitti: ok, I can widen that area (and shrink the areas that trigger movement)
<pitti> evand: maybe you can do it relative to the widget size?
<stgraber> ogra: I tried one of those 7-in-1 card reader, and guess what ? It worked ... :) /me goes to LP filing a "LTSP is unbreakable" bug
<ogra> haha
<evand> seb128: can you elaborate?  I'm not sure I understand what you mean by zoom and unzoom quickly and on wrong place?
 * ogra hugs amitk 
<pitti> evand: the scrolling border is extremely big in those small resolutions
<evand> pitti: indeed, that's a good idea.  Thanks
<seb128> evand: well, it zooms at soon as the mouse cursor enter the map area
<pitti> evand: thank you!
<ogra> amitk, all working, the 20080417.1 has the proper modifications (just pushing up to the server)
<seb128> evand: which means if the cursor enter on the left it zooms on america for example before getting a chance to go to europe
<seb128> evand: and I tend to move too quickly the mouse on the right to do fast scrolling which makes it unzoom
<seb128> evand: too quickly = the cursor goes out of the map area
<seb128> and it unzoom automatically
<evand> seb128: so a delay on zooming and unzooming would fix the problem for you? (I'm pretty sure the former exists, but perhaps it's not long enough)
<seb128> evand: the zooming when entering the widget takes one second right, but it zooms wrongly
<seb128> if I put my cursor over the french area it zooms in a way which doesn't display france at all
<seb128> evand: and yes, a delay before zooming out would be nice
<seb128> evand: it's easy to move the cursor too far and to be out of the widget
<evand> seb128: ok, sounds reasonable.
<evand> thanks for the input
<seb128> you are welcome
<seb128> maybe increase the zoom in delay would be better
<seb128> I don't manage to go on my area before having the zoom kicking
<seb128> and since I'm not on target yet it zoom on the wrong location
<evand> ok
<evand> I'll play around with it and try to find a more reasonable value.
<seb128> thanks
<seb128> maybe that's just me being slow or something if other people have no issue with it though ;-)
<evand> haha
<mpt> evand, is it 0.5 seconds at the moment?
 * mpt downloads a new daily image to try it
<stgraber> ogra: I found a bug !!!
<ogra> hey
<ogra> what is it ?
<stgraber> ogra: edubuntu add-on CD, it tried to download khelpcenter
<ogra> hmm, i didnt have that on a completely non networked install
<stgraber> ogra: oh, it's because the one we have on the addon CD is obsolete
<ogra> did you have a net connection during install (and have package lists updated from teh server)
<stgraber> ogra: we ship ubuntu6 and it's trying to get ubuntu7
<ogra> ah
<stgraber> ogra: yes, my package list is up to date
<ogra> needs a rebuild then i guess
<stgraber> ogra: indeed
<evand> mpt: yes, it is and input welcome.  We had to switch to a different style map as the previous iteration moved too quickly (bug 195159)
<stgraber> slangasek: ^
 * amitk hugs ogra back :)
 * mpt discovers a bug in the Nautilus disc burner thingy
<cjwatson> evand: maybe a longer zoom plus the ability to click to force zoom would work
<mvo> pitti: language-selector fix is upload
<cjwatson> evand: longer delay, I mean
<ogra> stgraber, i suspect he's no tup yet
<ogra> *not up
<cjwatson> evand: or maybe we should revert to the gutsy widget with a bit of extra code to resize the image to something smaller, if that's going to be too hard
<cjwatson> (context: the zoom map from gutsy was replaced with a new implementation largely in order to make the widget smaller. However there were other ways to do the same thing and it ought not to have been necessary to completely change the UI at the same time.)
<stgraber> ogra: hmm, right 6:30am or something in his timezone. Who else can trigger a CD rebuild ?
<cjwatson> stgraber: #ubuntu-relase
<cjwatson> err, #ubuntu-release
<ogra> stgraber, worst case i can do it myself, but i dont want to step on peoples toes
<evand> cjwatson: I think we're close enough that we don't have to revert to the old widget, though I'm obviously biased and wouldn't mind being told to do otherwise.
<xhaker> cjwatson: i've installed todays daily-live, i find that the map should not zoom out when you click
<xhaker> also, there were some nautilus windows still popping out.. var/lib/os-prober
<seb128> xhaker: the nautilus fix has been uploaded but not accepted
<xhaker> nice
<stgraber> cody-somerville: How's Xubuntu ISO testing going ? I only see half of Xubuntu desktop i386 tested yet.
<cody-somerville> stgraber, I'm begging for more testers now :)
 * ogra pokes a11y for using popunder windows
<cjwatson> xhaker: your comment is unclear; are you saying that it zooms out and shouldn't, or that it doesn't zoom out and should?
<elmargol> Kennt jemand einen guten WYSIWYG html editor fÃ¼r linux? (nicht kompozer) oder einen fÃ¼r windows der gut mit wine funktioniert?
<stgraber> cody-somerville: ok :) #ubuntu-testing may be a good place to find more testers and having someone from Xubuntu would probably help for bug reporting/triaging/fixing
<elmargol> oh wrong channel
<xhaker> sorry cjwatson if i was vague. the map zooms in when you hover over it. and it is zooming out when you click your location. i think it'd be better not to zoom out on click
<cjwatson> it should only zoom out when you move the mouse out of the map area ...
<cjwatson> I see no code there to zoom out on click
<xhaker> it is zooming out on click though
<xhaker> ubuntu-restricted-extras is lacking depends on icedtea-gcjwebplugin for the i386 arch
<xhaker> it's a dependency on most archs
<Hobbsee> now that's interesting.
<xhaker> Hobbsee: ping
<Hobbsee> pong
<xhaker> hah, didn't see your msg before. it's interesting yes, i think i didn't look carefuly when the package was uploaded
<xhaker> i386 lost it somehow
<Hobbsee> so, which do we want it on, out of i386, hppa, lpia and ppc?
<Hobbsee> yeah, i'd say that was a bad sed line or something
<xhaker> i think that is all we need. +amd64
<xhaker> maybe ask doko if sparc and ia64 should have it too
<Hobbsee> they already have it
<Hobbsee> does hppa have it, i wonder...
<Hobbsee> ooh, gnome do actually works for that
<xhaker> currently.. amd64, ia64 and sparc
<Hobbsee> yeah, i can see that
<Hobbsee> yeah, they do
<Hobbsee> xhaker: fixed, thanks
 * Hobbsee assumes realplay is ubuntu mobile stuff?
<xhaker> Hobbsee np
<Hobbsee> wrong versioning, at least.
<doko_> xhaker: why should it be in restricted at all?
 * ogra doesnt get that either
<slytherin> right, it is in universe.
<Hobbsee> ogra: because it's morphed into a package full of useful bits and pieces, which includes java, and at least in some cases, the free verison was said to work better.
<ogra> and its GPL
<Hobbsee> feel free to NMU
<laga> cjwatson: had a chance to look at the mythbuntu seeds?
<xhaker> doko_: i was under the impression openjdk was still in multiverse? and debian was also making a fuss about it?
<cjwatson> laga: I have some idea of what the problem might be but no thoughts on how to fix it yet. Sorry, quite busy
<laga> cjwatson: i understand.
<cjwatson> laga: briefly, the reason it doesn't do anything is that all the packages in frontend are also in desktop, and you've labelled the frontend seed as inheriting from desktop, which means that the frontend seed is in fact empty
<cjwatson> laga: perhaps you should consider making desktop inherit from frontend rather than the other way round
<cjwatson> laga: (and unfortunately tasksel doesn't know how to follow inter-task dependencies properly at the moment)
<pitti> mvo: thanks! *hug*
<Hobbsee> pitti: requirement of multiverse is that it has to be redistributable, right?
<pitti> Hobbsee: correct; and reasonably DP conformant
<Hobbsee> pitti: good.  Then i can reject this canonical piece of crack, which clearly hasn't been through any form of QA at all.
<Hobbsee> unless i've very much gotten what the licence says wrong.
<cjwatson> what package is this?
<Hobbsee> cjwatson: realplayer
<Hobbsee> cjwatson: looks to be a mobile package.
 * Hobbsee got suspicious looking at the version number, so decided to take a closer look
<cjwatson> is that the realplay package targeted at partner (not multiverse)/
<cjwatson> ?
<ogra> uh
<cjwatson> that's the only thing matching 'real' I see in the queue
<doko_> xhaker: openjdk-6 is in universe
<cjwatson> note that partner ends up on archive.canonical.com not archive.ubuntu.com
<cjwatson> Hobbsee: ^--
<doko_> hmm, no sound on a MacBook Pro (amd64)
<Hobbsee> cjwatson: oh, curse the LP UI.
<Hobbsee> cjwatson: there's no indication of it being in partner at all.
<Hobbsee> er, realplay, yes
<cjwatson> please do pass on your QA concerns to the uploader though
<cjwatson> Hobbsee: you can see it from the .changes file, for the record
<cjwatson> I agree that it's not terribly obvious; the queue redesign I've seen would make it obvious
<Hobbsee> cjwatson: ahh.  missed that the first 3 times of checking it.
<Hobbsee> yeah, it should do
<Hobbsee> cjwatson: if they're within the realms of parther, and all sorts of shady stuff there, then i'm inclined to leave it alone
<Hobbsee> interesting choice of standards version and such, though
<xhaker> doko_: yeah, i see now. so should it be removed from restricted-extras in your opinion?
<doko_> at least it's not "restricted", it's free to be in universe
<xhaker> doko_: that'd probably mean getting sun-java6-plugin there again
 * Hobbsee cries.  loudly.
<Hobbsee> this is some of the more interesting packaging iv'e seen in a while.
<xhaker> another bug: gdmsetup takes ages to open from the menus atleast
<xhaker> i think i've seen this happen before.. and it happened to be a dbus thing
<seb128> there is several bugs or comments about that on launchpad
<seb128> but nobody provided useful informations yet
<cjwatson> Hobbsee: well, "leave it alone" is one thing, but it really is useful to pass on any concerns you've already developed in the time you've spent looking at it
<cjwatson> (not asking you to spend any more time on it, but since you already have ...)
<xhaker> seb128: bug number? i'll try to extract something
<Hobbsee> cjwatson: i'm looking at this reimplemenation of dpatch, and going....yeah...
<seb128> xhaker: not sure, I think most submitter comment on different bugs
<seb128> let me look
<cjwatson> it's not all that pretty, but on the other hand there doesn't seem anything actively wrong with that code
<Hobbsee> cjwatson: the whole lack of licencing text that it says will be in the current directory, mentioend from debian/copyright is interesting, too.
 * Hobbsee isn't quite sure which i'ts under, either
<Hobbsee> indeed.  but why not use dpatch directly?
<ogra> seb128, i can confirm that here
<cjwatson> for the record, a similar package is already in feisty-commercial
<Hobbsee> right
<seb128> ogra: so you volunteer to fix the issue? ;-)
<ogra> seb128, if someone adds 2 extra hours to the 24 this day has :P
<ogra> seb128, it sems to not come up at all atm, i see it in the processlist though
<seb128> ogra: switch your clock to utc now and you are on track ;-)
<ogra> haha
<cjwatson> debian/copyright is an interesting issue in partner; the fact of a package being there indicates an active relationship with the software provider, so by presumption it's distributable; however that doesn't mean that the copyright file shouldn't be kept correct
<xhaker> or just travel west really fast
<xhaker> ogra, it takes some time but eventually pops up when you least expect
<Hobbsee> cjwatson: i think i'm just becoming more and more glad i don't deal with partner stuff, without the rulesheet on what is and isn't OK.
<ogra> oh, there it is
<seb128> xhaker: I think people were commenting on the bug about the warning displayed on the command line and which was something different and has been closed
<ogra> that took about 4 munites
<xhaker> ogra: now try that again.. it will popup instantly
<slytherin> ogra: your keyboard seems to be broken
<seb128> ogra: the comments stated 1 minutes
<seb128> and it seems to be only on the first run
<seb128> really a weird bug
<ogra> seb128, i confirmed it at 16:22 above where it was already MIA for a minute osr so
<\sh> seb128, actually it takes longer when you wait for it and clicking on the same app entry 5 times in a row
<ogra> it came up at 16:24
<ogra> so at least 3 min
<seb128> ogra: see, time starts moving slowly for you, you will get your extra hours to debug this today ;-)
<ogra> anyway, to long :)
<ogra> haha
<xhaker> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/202716
<ubotu> Launchpad bug 202716 in gdm "Login Window in the System menu, takes a long time to appear. (dup-of: 199942)" [Undecided,Incomplete]
<ubotu> Launchpad bug 199942 in libgnomeui "Error messages when starting gdmsetup" [Low,Fix released]
<xhaker> found this
<xhaker> the first one
<seb128> right, people got confused by the libgnomeui warnings
<seb128> you can reopen it
<ogra> it opens instantly the second time like xhaker says
<elmo> are there any known issues with the RC hanging after keyboard layout part of ubiquity?
<elmo> or RC candidate or whatever it is :)
<jdstrand> elmo: could it be bug #217815 ?
<ubotu> Launchpad bug 217815 in partman-crypto "When selecting LVM Crypt, erase never ends" [Undecided,New] https://launchpad.net/bugs/217815
<elmo> jdstrand: doubtful, I didn't get anything on screen after selecting next in keyboard layout
<jdstrand> elmo: I don't know if you're using seeds or anything
<elmo> i.e. never go tthe chance to select lvm or lvm crypt
 * jdstrand nods
<ogra> xhaker, are you on a normal ubuntu or is that xubuntu ?
<cjwatson> jdstrand: that bug is not applicable to ubiquity
 * elmo face stabs the vaio and tries again
<xhaker> ogra:  fresh gnome install from today
<cjwatson> xhaker: I can't reproduce your comment about the zoom map. For me (current Ubuntu desktop i386), it only zooms out when I leave the map area. Are you using Kubuntu by any chance?
<ogra> xhaker, ah, i thought it could be something with the linked config file we use in xubuntu and edubuntu
<xhaker> i'll have to try again, but it certainly did zoom out. live sesssion, not ubiquity only. with compiz enabled
<xhaker> ogra:  https://bugs.launchpad.net/ubuntu/+source/dbus-glib/+bug/71248
<ubotu> Launchpad bug 71248 in dbus-glib "Applications using dbus hang when ran with sudo" [High,Fix released]
<xhaker> nvm the description
<ogra> did you try the workaround ?
<cjwatson> xhaker: compiz might be a relevant difference, I suppose; live session vs. ubiquity only won't matter
<xhaker> ogra: not yet, but i remember that it workedwhen i saw that bug
 * xhaker brb. reproducing .> bugs
<cjwatson> elmo: is the machine in general still working? i.e. not a kernel hang?
<elmo> cjwatson: well the  screen blank/saver eventually kicked in
<elmo> cjwatson: but, keyboard/mouse wasn't responsive
<elmo> cjwatson: it had been on, for like 5 hours, in Live CD mode, doing a backup to external HD first.  it's possible the CDROM drive just got bored and lost it
<cjwatson> elmo: I'd like /var/log/syslog and /var/log/partman please
<cjwatson> oh
<cjwatson> keyboard/mouse not responsive might make that a problem
<cjwatson> sorry, I misread
<cjwatson> sounds like not an installer bug, quite possibly a bug lower down though
<cjwatson> unless you selected something unusual at the keyboard layout stage?
<elmo> cjwatson: nah, just UK
<elmo> I'll retry from live cd proper.  doing it from 'install ubuntu now' got further
<jdstrand> cjwatson: are there other odd hangs reported that you know of with the alternate or server iso?  I am doing server iso testing in kvm, and it was just sitting there at 'Detecting cdrom' until I gave some keyboard input
<cjwatson> jdstrand: I've heard reports of that kind of thing, yes, but haven't encountered them myself. If you can try to figure out what's going on (since you can reproduce it) I'd much appreciate it.
<jdstrand> cjwatson: this is my 3rd iso test, and it hung in different places... :/
<xhaker> cjwatson: it is indeed compiz messing with mouve events. with compiz disable no zoom ou takes place. i could not test the ubiquity only install, it bailed out to initramfs
<xhaker> maybe because i am using an usbdisk
<xhaker> ogra: no luck testing gdm, after a reboot it starts normally. i think the hang only happens the very first time then
<ogra> weird
<xhaker> ogra: maybe the first time it runs something gets written to /root
<xhaker> and the runs after dont stall since they find the data promptly
<xhaker> guesswork(tm)
 * pitti creates https://help.ubuntu.com/community/UbiquityEncryptedFilesystems as a permanent documentation for the hackery he just did
<doko> is the lack of the gij runtime on the CD done by intent?
<mvo> cjwatson: should update-manager automatically transition the sparc users on upgrade to ports.ubuntu.com ?
<kirkland> evand: ping, retesting kubuntu oem
<evand> kirkland: pong
<kirkland> evand: Bug #217884 appears fixed
<ubotu> Launchpad bug 217884 in oem-config "Kubuntu OEM failure on second boot" [Undecided,Fix released] https://launchpad.net/bugs/217884
<evand> fantastic!
<kirkland> evand: it boots into a graphical "Choose your language, etc."
<kirkland> evand: however, graphics on that screen are kinda ugly
<evand> can you elaborate or link to a screenshot?
<kirkland> evand: like it didn't detect my monitor properly
<kirkland> evand: can't screen shot at this point, but I take a picture with a digital camera ;-)
<evand> ok :)
<kirkland> evand: looks like a bad xconfig possibly
<emgent> hello people
<kirkland> evand: http://ubuntu.dustinkirkland.com/IMG_0936.JPG
<evand> hrm, the resolution looks ok, but I'm not sure why it's not painting the entire background image there.
<evand> Riddell: ^ any ideas?
<evand> oh, it is getting cut off a bit thoguh
<evand> though*
<kirkland> evand: bug worthy, you think?
<evand> kirkland: for tracking it yes, though I obviously don't think it's a blocker
<kirkland> evand: right, it seems functional, just kinda ugly :-)
<jcastro> I just tried it and mine looks fine, but it's in a vm
<kirkland> evand: whoa...  as i move the arrow keys up and down, scrolling through the other languages, it repaints the screen all blue, but the dialog box kinda jumps all over the screen
<soren> cjwatson: Any reason why you didn't comment on stgraber's guess about entropy starvation in bug 217815?
<ubotu> Launchpad bug 217815 in linux "When selecting LVM Crypt, erase never ends" [Undecided,New] https://launchpad.net/bugs/217815
<soren> pitti: Does  https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/218583
<ubotu> Launchpad bug 218583 in linux "KVM oops in kvm_vm_ioctl_get_dirty_log" [Undecided,New]
<soren> pitti: ...happen consistently?
<pitti> soren: from the moment when it happened the first time, I can't do a single ubiquity install (in kvm) any more without it happening
<pitti> soren: although it happens on different times, but all around partitioning
<soren> pitti: Interesting.
<pitti> soren: I'm beginning to suspect that the disk image file got broken
<soren> pitti: I'm assuming you've not rebooted in between?
<pitti> soren: I rebooted after every oops
<soren> O_O
<soren> er... ok.
<soren> Can you upload the disk image somewhere?
<pitti> after an oops I cannot even cleanly shut down kvm
<pitti> soren: erm, no... it's 5 GB!
<soren> How did it get that large if you didn't even get to install anything in it?
<pitti> soren: (1) I did several succesful installations into it before, and (2) I just created it as a 5 GB image file
<soren> How much does it compress to?
<cody-somerville> cjwatson, will you add me to the ubuntu-cdimage team please?
<pitti> soren: I can try to fill it with zeros and check if it still crashes, and also to create a fresh image
<pitti> and compare whether the crashes happen with that
<pitti> soren: if it still crashes after (mostly) zero'ing it out, I'll send it to you
<soren> Can you keep a copy of it around (in its current form)?
<pitti> soren: I'll just remove all files and create a single huge file on the fs which contains only 0 byts
<pitti> soren: sure
<soren> I might be interested in getting you to test things.
<pitti> absolutely
<soren> Coolness.
<cjwatson> soren: because that's not the problem - it's happening elsewhere than in just the crypto case
<cjwatson> soren: as Quentin already said
<cjwatson> cody-somerville: no, you can't commit to that branch, it's a read-only mirror of the primary copy which is on the cdimage master build machine
<soren> cjwatson: Oh, ok.
<cjwatson> cody-somerville: I'm happy to merge for you
<Riddell> kirkland, evand: not sure, I noticed that on a KDE 4 OEM install but not on a KDE 3 one, and jcastro didn't see it on a KDE 4 install.  so it seems a bit random
<kirkland> Riddell: also, if i move around, highlighting different language, a long slow repaint happens
<ogra> seb128, http://paste.ubuntu.com/7298/ i also have a gvfs running for root as well as a session dbus
<kirkland> Riddell: with the dialog jumping around each time, presumably due to the changing size of the translated text on the left
<ogra> smells like it starts halsf a session
<ogra> *half
<Riddell> kirkland: ho hum, report as bugs then please
<kirkland> Riddell: it's like those fields on the left should be in a fixed with table/widget/whatever-in-kde-world :-)
<kirkland> Riddell: Bug #218727
<ubotu> Launchpad bug 218727 in oem-config "Kubuntu OEM Config Screen on Second Boot" [Undecided,New] https://launchpad.net/bugs/218727
<cjwatson> I don't think that's new; I remember seeing it ages ago
<cjwatson> at least the ugly display
<kirkland> cjwatson: you're speaking to me or ogra?
<cjwatson> kirkland: you
<cjwatson> IIRC it was graphics-card-dependent or something annoying like that
<cjwatson> but this is just vague memory
<kirkland> cjwatson: i thought it might be X config related
<kirkland> fwiw, this is an nvidia chipset with a 22" wide display LCD
<kirkland> I'll add that to the bug
<Riddell> cjwatson: we had it before when it wasn't loading the background image (because the filename had changed) but I fixed that
<cjwatson> Riddell: this was way old, like when Anirudh first did that new UI
<ogra> seb128, hmm, i even have a trackerd running as root
<ogra> seb128, i'm scared !
<ogra> http://paste.ubuntu.com/7300/
<\sh> ogra, where? yesterdays daily of hardy didn't have trackerd actually enabled...
<ogra> \sh, no, i have tracker running on purpose
 * laga hugs slangasek for delaying the RC
<\sh> on a sitenote...please add lvm2 package to the installation when d-i parted determines that the user has lvm devices
<ogra> but thats still no reason to start it for root if i run gksu gdmsetup
<xhaker> ogra: thats some wierd *removed*
<ogra> xhaker, can you confirm that ?
<xhaker> ye, i noticed the trackerd created folders some minutes ago
<xhaker> the .gvfs permissions are ok?
<xhaker> what does ??? mean?
<cjwatson> \sh: it adds it if you actually configure lvm
<\sh> cjwatson, and what about already configured LVM devices? :) I have a 500G HD configured as one LVM device ;) d-i recognizes it, but it didn't add the lvm2 parts to the installation...
<jwendell> pochu, you also need to backport that vinagre patch I pointed out, in order to debug gtk-vnc 0.3.5
<\sh> cjwatson, but I don't think it's critical
<cjwatson> presumably you wanted them mounted somewhere, which would involve stepping into "Configure the Logical Volume Manager" at least briefly ...
<cjwatson> ./choose_partition/lvm/do_option:587:   apt-install lvm2
<\sh> cjwatson, actually on it are snapshots which I use for sbuild ;) so no, I don#t wanted them to be mounted on startup
<elmo> is it possible to rerun the migration assistant after install?
<ogra> xhaker, that only means the user ogra cant read it ... gvfsd should be started at all for root
<seb128> ogra: what?
<seb128> ogra: what did you run?
<ogra> seb128, running gksu gdmsetup
<ogra> that starts a session bus for root and gvfsd at least
<ogra> i go tracker installed so that gets started as well
<ogra> it also mouts /root/.gvfs for root
<ogra> *mounts
<ogra> seb128, and apparently xhaker sees that as well
<seb128> ogra: and that's an issue?
<ogra> it fills /root with dirs for one
<seb128> ogra: gdmsetup has filechooser widget and the default backend is gio, so gvfs gets started
<ogra> ah
<seb128> ogra: the reply to that is to stop running graphical programs under sudo
<seb128> and to switch to policykit
<seb128> but that's not for hardy
<ogra> yeah, i understand
<ogra> well, but i guess one of the three services that start causes the delay
 * ogra removes tracker for a start and tries again
<ogra> seb128, yup, its tracker
<seb128> ogra: weird
<ogra> well, it explains the delay, and also why it starts instantly the second time
<ion_> davmor2: Eh
<seb128> ogra: but why tracker should be that slow to start?
<ogra> ogra@osiris:~$ time gksu gdmsetup
<ogra> real	3m36.130s
<ogra> user	0m0.840s
<ogra> sys	0m0.128s
<ogra> ogra@osiris:~$
<ogra> ogra@osiris:~$ time gksu gdmsetup
<ogra> real	0m3.419s
<ogra> user	0m0.716s
<ogra> sys	0m0.128s
<ogra> first one is with tracker installed
<ogra> seb128, well, it builds its initial DB i think
<seb128> well you said only the first run has the issue
<seb128> so the second one is not revelant, is it?
<ogra> the second one is without tracker installed
<seb128> ogra: we disable indexing and watching so it should not be doing anything and the app should not be blocking on the indexing anyway
<seb128> ogra: otherwise you would not be able to start applications for a week if you have datas ;-)
<ogra> probably that applies not to root ?
<seb128> that should
<seb128> I patched the sources to change the default options
<ogra> hmm
<seb128> run the tracker gui under sudo
<jamiemcc_> ogra: you should not run tracker as root
<ogra> jamiemcc_, tell that to gdmsetup :P
<jamiemcc_> ogra~: you should not log into gnome as root either :)
<seb128> he doesn't
<seb128> he run a gtk software using sudo
<ogra> jamiemcc_, i run gksu gdmsetup
<seb128> that's likely the recently used thing in the fileselector dialog
<jamiemcc_> ahh yes
<ogra> yeah, it creates a file
<seb128> not the recently used one
<seb128> rather the search for files thing there
<ogra> well, gksu tracker-search-tool starts instantly
<ogra> (sorry, cleaning up /root takes a while for every test)
<ogra> oh, it doesnt start dbus, gvfs or trackerd
<ogra> but creates the .gnome an .gconf dirs
<pitti> heno: FYI: http://iso.qa.ubuntu.com/qatracker/result/1500/47
<seb128> ogra: weird, would be worth trying using an another application using filechoosed widgets
<seb128> ogra: maybe sudo gtk-demo
<seb128> ogra: I'll give it a try later
<ogra> gksu nautilus --no-desktop ?
<seb128> I'm not sure nautilus uses filechooser widgets
<ogra> and it doesnt like to be started that way
<jamiemcc_> ogra gksu gedit and then open a text file
<heno> pitti: looks good, thanks
<ogra> seb128, gtk-demo works fine
<seb128> ogra: ok, I've to go now, no real idea, and not sure why it does it only once and not again after that, I'll have a look later
<ogra> oki
<ogra> if i stumble over something i'll ping
<Keybuk> pitti: apport is catching valgrind segfaults again
<seb128> ogra: ok, thanks
<pitti> Keybuk: you mean valgrind itself segfaults?
<Keybuk> pitti: yes
<pitti> evand: indeed, it seems to behave much better when installing on my desktop (1280x1024); is the widget bigger in this case?
<evand> pitti: yes
<pitti> evand: BTW, I noticed that ubiquity started to actually be usable at 800x600; didn't do that in the past, great!
<slangasek> TheMuso: UbuntuStudio shouldn't have needed a respin because we didn't change anything in the archive after the last UbuntuStudio build that should be critical to those images, AFAICS
<evand> pitti: indeed, that's a side effect of the new timezone widget
<_MMA_> slangasek: Yeah. He and I chatted. We should be good to go.
<slangasek> stgraber, ogra: ah, it didn't occur to me that edubuntu add-on would've also been impacted by the KDE packages that were accepted; I can respin if you think there's time for testing the new images afterwards, otherwise I would just ship as-is
<ogra> done already :)
<ogra> (i can triger builds myself)
<ogra> *trigger
<ogra> heh, thats nice, edubuntu-desktop depends on exactly 100 ackages on the addon cd now
<ogra> *packages
<megabyte405> hey, I'm having a problem with finishing up the AbiWord package here.  I created a patch with dpatch-edit-patch, and it built fine with a dpkg-buildpackage but now that I just want to roll a src package I'm getting that unapplying this latest patch failed, with no further detail
<cjwatson> pitti: I noticed that you (and possibly other people) said earlier that you had /dev/sda{,5,7} or some such
<cjwatson> pitti: was that set up by auto-resize? it's supposed to always ensure a primary partition after autopartitioning
<lamont> pitti: any plans to roll the fix for debian bug 364446 et al into dapper-security/et al postgresql-8.1?
<ubotu> Debian bug 364446 in postgresql-8.1 "postgresql-8.1: upgrade fails if server is not running" [Normal,Fixed] http://bugs.debian.org/364446
<infinity> lamont: The bug claims to have been fixed in psql-common_50, and dapper has 53...
<lamont> interesting
<lamont> infinity: postgresql-8.1_8.1.11-0ubuntu0.6.06.1 has an init.d that fails if stop fails, so a non-running daemon kills the upgrade.
<davmor2> What would cause a dvd-rw to randomly not become available anymore?
<infinity> lamont: Yeah, the init script should fail, AFAICT, it's the scrpit calling it that shouldn't.
<infinity> lamont: At least, if I'm reading changelogs right.
<lamont> policy says that init.d/foo stop when foo is not running --> success
<infinity> lamont: Well, there's that too, I didn't mean "should" as in policy, but "should" as in "that's how it seems to have been working back then, and the caller was papering over it".
<lamont> ah, ok
<jdstrand> cjwatson: I don't have a reliable test case, but I do seem to get frequent random hangs with the iso from http://iso.qa.ubuntu.com/qatracker/info/1523. it will hang until a keyboard event is found. This is using virt-manager and kvm with x86_64, 256 RAM (max and used), 4000MB non-preallocated disk.  everything else is the default
<pitti> cjwatson: yes, by combined 'entire disk' (which puts swap into an extended partition) and then autoresize; NB that I did have /dev/sda1 physically, but the node in /dev was missing
<jdstrand> cjwatson: oh, and 2 vcpus
<jdstrand> cjwatson: I asked others in #server to try this configuration out too
<pitti> lamont: what infinity says; the postinst should ideally ignore a failed init.d stop
<lamont> pitti: this is preinst
<lamont> IIRC
<lamont> see also policy
<infinity> lamont: prerm, even, if it's the same as the bug you linked to...
<lamont> infinity: uh... didn't look, smacked it around, and such
<pitti> lamont: hm; on a closer look this can't have been fixed in p-common alone, since the preinst etc. are owned by p-8.X; I'll have a deeper look
<pitti> as soon as my workstation finished reinstalling (yay CD test day)
<lamont> hehe
<lamont> pitti: I just ran into it upgrading a machine which has 7.4 and 8.1 installed (don't ask).. 8.1 of course, doesn't run, but it's installed.
<pochu> jwendell: what do we need to debug?
<jwendell> pochu, everything
<jwendell> pochu, the first thing I ask on a bug report is the debug output
<pochu> jwendell: but apport is disabled on stable releases, so it's probably better to use that patch for Intrepid
<pochu> jwendell: does the vinagre patch add a --debug option or will it show the debug output always?
<jwendell> pochu, add a --gtk-vnc-debug option
<cjwatson> jdstrand: Ben reckons it's probably a kernel interrupt generation issue, and I reassigned the bugs that way
<pochu> jwendell: ok. anyway I haven't got an approval for gtk-vnc yet, and I want to test it further before subscribing ubuntu-release to the bug report...
<pochu> jwendell: and the vinagre change would need to be approved by the release team too, providing they approve the gtk-vnc one first
<pochu> anyway the one fixing bugs is gtk-vnc... I don't think it's that important to add a debug option to vinagre
<pochu> jwendell: but we will update to GNOME 2.22.2 so if you get that upstream we will get it ;)
<jdstrand> cjwatson: is there a different bug than the lvm+encrypt bug?
<cjwatson> jdstrand: hard to say for sure but I think it's the same
<jdstrand> cjwatson: my feeling was that it was easier to trigger with lvm+encrypt for some reason
<jdstrand> cjwatson: so yeah, I agree
<dendrobates-> cjwatson: we have not been able to reproduce these d-i hangs in any real hw, at this point.
<cjwatson> dendrobates-: ok. but a bug reporter did.
<dendrobates-> cjwatson: I'm not sure he had the exact same issue.  He don't believe he indicate that a key press or mouse click restarted things.
<cjwatson> he did, I believe
<cjwatson> dendrobates-: bug 217849: "Once I hit any key, drive activity picks up again and things carry on"
<ubotu> Launchpad bug 217849 in linux "Hardy 64-bit beta and nightly alternate installation stalls" [Undecided,New] https://launchpad.net/bugs/217849
<cjwatson> "The behavior is most pronounced if choosing the whole drive encryption option, though it also exists elsewhere"
<slomo> so, i have a patch for #199496 that really fixes the issue now... shall i just go ahead and upload?
<cjwatson> slomo: in general, if you think something's appropriate for release, go ahead and upload; the worst that can happen is that the release team rejects it
<cjwatson> wow, wotta lotta dups
<slomo> ok, sounds good
<cjwatson> no explanation in that bug of why it was reopened/
<cjwatson> ?
<slomo> cjwatson: well, the bug still exists in many applications but not all
<slomo> there were some new dupes
<cjwatson> ah
<mario_limonciell> hey slomo you pinged me the other day, but i never caught up with you.  what'd you need?
<slomo> mario_limonciell: can't remember anymore, sorry :/
<mario_limonciell> oh okay :)
<cjwatson> dendrobates-: hmm, just reproduced it myself in kvm/i386 too
 * mvo wonders if anyone had success with qemu-sparc ?
<slangasek> slomo: hi, why is bug #199496 reopened?
<ubotu> Launchpad bug 199496 in gtk-sharp2 "Tomboy.exe crashed with SIGSEGV in exit()" [High,Confirmed] https://launchpad.net/bugs/199496
<slomo> slangasek: because of new duplicates and because it's only fixed for some applications... new fix uploaded already, this time fixing all apps
<slangasek> slomo: ok
<dendrobates-> cjwatson:  It is very easy to reproduce in kvm, however I could not reproduce it with an image of 1GB or smaller.
<pitti> 23063 root      39  19 69196 3144 2360 D  0.7  0.1   0:00.18 trackerd
<pitti> ugh, what the heck?
<pitti> I thought we disabled tracker by default nowadays? and why is it running as root?
<stgraber> pitti: I also noticed that here, happens usually after doing a sudo on a gnome tool IIRC
<pitti> argh, and it's unkillable
<pitti> stgraber: it started when I ran "sudo gdmsetup"
<pitti> jamiemcc_: ^ any idea about this?
<jamiemcc_> pitti: it appears the file chooser is activating trackerd via dbus
<ogra> pitti, i debugged that for some hours with seb today
<ogra> pitti, its the filechooser from the gui wanting to have recent documents in place, seb knows about it
<pitti> ogra: ah, thanks; that started gvfs for root as well, indeed
<ogra> yeah
<ogra> i dont think we get around gvfsd here as i understood
<ogra> (which is a bit odd, it puts stuff into /root and keeps it mounted as well )
<jdong> the random mounting thing is quite annoying
<jdong> I had to restore quite a bit of data after nuking an account the other day that had gvfs mounts dangling :(
<compbrain> can make-kpkg be convinced to produce a source package instead of a binary package?
<cjwatson> does anyone here have a G5 PowerMac/
<cjwatson> ?
<compbrain> Yea
<cjwatson> compbrain: could you help me out with a few commands? I'm looking at http://ubuntuforums.org/showthread.php?p=4733940 and wondering if we can fix the fans thing easily
<cjwatson> compbrain: firstly, 'lsmod | grep therm'
<cjwatson> compbrain: (I'm assuming you're running hardy?)
<compbrain> actually, looks like my officemate put osx back on it.. doh!
<compbrain> sorry :/
<cjwatson> compbrain: argh, no chance to boot with a live CD?
<jwendell> pochu, it IS important to have debug stuff in vinagre
<jwendell> pochu, otherwise, I can't help Ubuntu
<compbrain> cjwatson: hang on, ill see what I can do
<jwendell> pochu, in the bug comment, I said "IMHO", I just said my opinion. Ubuntu is free to accept or not
<jwendell> I just want the best for Ubuntu...
<cjwatson> compbrain: the other thing I need is 'sudo tar czvf device-tree.tar.gz /proc/device-tree' and then device-tree.tar.gz put somewhere I can see
<compbrain> cjwatson: will do, may take a few minutes...
<compbrain> at least 30 to get the damn iso...
<cjwatson> compbrain: ok, thanks
<cjwatson> compbrain: I'd also like to know if you get lots of fan noise
<jdong> whooooooo!!!! go ubuntu devs!!!!
<jdong> or not that kind of fan noise?
<cjwatson> not so much :)
<cjwatson> compbrain: instead of grep therm, egrep 'therm|wind'
<laga> cjwatson: re our conversation a few hours ago about the seeds/tasks: is this what you had in mind? http://www.pastebin.ca/988663 (context attached)
<doko> on two out of three cd boots/installs my keyboard doesn't work. that's annoying
<cjwatson> laga: I think something like that ought to help, though you'd also have to take desktop out of the {frontend,backend-{master,slave}} seeds
<cjwatson> both Task-Seeds and the package entry
<cjwatson> I don't think it's workable to have those automatically load a desktop in hardy, unfortunately
<laga> cjwatson: that'll mean the desktop wont be installed, right?
<laga> cjwatson: by "take desktop out of the seeds", you mean that i need to remove "* mythbuntu-desktop", right?
<cjwatson> laga: yeah, that's what I meant
<cjwatson> laga: I just don't have the time to fix up tasksel :-(
<laga> cjwatson: i guess i could duplicate mythbuntu-desktop inside  {frontend,backend-{master,slave}}
<pitti> asac: ah, I just tested the brand new langpack-o-matic built langpacks; firefox stuff seems to be good
<pochu> jwendell: I know. and I want to help Vinagre. But we first need gtk-vnc, and the comments in the bug I opened don't look very promising...
<cjwatson> laga: hmm, actually, give me a minute, there might be a possible cdimage workaround here without those seed changes
 * laga lights another candle in his cjwatson shrine
<cjwatson> laga: I'm thinking of something gross and wrong like http://paste.ubuntu.com/7324/
<laga> cjwatson: let's try it. :)
<cjwatson> laga: is it correct for mythbuntu-frontend to be in the desktop? that means all backends get the frontend too
<slangasek> the backends install a desktop?
<cjwatson> slangasek: that too ...
<cjwatson> cjwatson@antimony:~$ grep '^apport ' mythbuntu-test/tasks/hardy/tasks.i386      apport mythbuntu-desktop
<cjwatson> apport mythbuntu-backend-master
<cjwatson> apport mythbuntu-backend-slave
<cjwatson> apport mythbuntu-frontend
<cjwatson> this looks about right given the input data
<jwendell> pochu, yes, that's why I need debug stuff in vinagre, in order to know what's going on
<jwendell> pochu, but clearly mac's vnc server is breaking the RFB protocol...
<pochu> jwendell: ok, I'm gonna upload it to my ppa too... I'm worried about the libvirt comments, though
<pochu> jwendell: I'll ask him to paste the debug output from vinagre
<jwendell> ok
<laga> cjwatson: sorry, was afk for a while. i fail to see how the frontend is included into desktop, maybe you can show me
<cjwatson> laga: mythtv-theme-mythbuntu is seeded and depends on mythtv-frontend
<cjwatson> laga: how about slangasek's question of whether backends should install a desktop at all/
<cjwatson> ?
<laga> yeah, they should.
<laga> so only mythtv-theme-mythbuntu needs to go i guess
<cjwatson>  lver
<cjwatson> er
<cjwatson> move to the frontend package maybe
<cjwatson> ?
<cjwatson> sorry, tired and losing typing skills
<laga> yeah, good call
<laga> no worries
<cjwatson> ok, I'll commit the bad-and-wrong cdimage hack for now
<laga> hum, the other mythtv themes in desktop are recommends
<laga> i assume i dont have to take them out
<laga> cjwatson: and the patch for STRUCTURE isn't needed anymore
<cjwatson> laga: correct
<emgent> heya
<cjwatson> laga: don't know about the other themes, unfortunately germinate only (easily) shows me the first one
<compbrain> cjwatson: booting and info coming
<cjwatson> laga: check reverse-dependencies of mythtv-frontend
<compbrain> are the openvz patches going to make it into hardy-release, given the broken state of affairs
<laga> cjwatson: hum, apt-cache rdepends also lists mythtv-themes
<cjwatson> laga: it's probably not a showstopper if the backends install a frontend too?
<cjwatson> given they're installing a desktop
<laga> true. it doesn't exactly work as advertised, but it's less broken than the current state
<laga> i need to talk superm1 how shuffling things around will affect our live disk.
<cjwatson> so how about I rebuild for you now and you can see how it looks?
<laga> the themes probably should live in 'common'.
<laga> cjwatson: the alt disk? i'd like to sneak in one preseed change, if you dont mind waiting a few minutes
<cjwatson> ok
<mario_limonciell> laga, as long as the metapackages are available 'mythbuntu-desktop' and 'mythbuntu-live' nothing will break.  i wasn't moving the live disk to tasks until you sorted this stuff out
<laga> mario_limonciell: nothing will break if mythtv-theme-mythbuntu isn't available anymore?
<mario_limonciell> why would that disappear ?
<mario_limonciell> i didnt follow everything
<laga> mario_limonciell: basically, mythtv-theme-mythbuntu pulls in mythtv-frontend in the desktop task
<laga> mario_limonciell: it'd be good to get rid of that, but we live with that for the RC
<davmor2> doko: ping
<doko> davmor2: just ask
<davmor2> doko: http://iso.qa.ubuntu.com/qatracker/result/1543/233 here you failed it but on whole disk install you passed it both have the same message which is right?
<doko> hmm, I should change that
<mario_limonciell> laga, well we won't update the meta package if it comes down to it
<davmor2> doko: Just thought I'd let you know :)
<compbrain> cjwatson: the latest iso doesnt get very far.
<compbrain> http://cdimage.ubuntu.com/ports/daily-live/current/hardy-desktop-powerpc.iso
<compbrain> After the loader I get a white flash, and then the monitor shuts off.
<laga> cjwatson: can you sync rev 1299 from mythbuntu-debiancd before building the alternate disk? http://bazaar.launchpad.net/%7Emythbuntu/debian-cd/mythbuntu-debiancd/
<bokey> i needed linux-source-2.6.24 but my apt can't seem to find it. even packages.ubuntu.com doesn't say it's available? am i looking in the right place?
<bokey> hardy's main universe restricted points to .22 latest
<bokey> :s
<laga> bokey: apt-cache show linux-source-2.6.24?
<Nafallo> bokey: you want tot run an apt-get update I'd say.
<bokey> laga: nothing
<bokey> Nafallo: i did
<laga> then your mirror is out of date
<Nafallo> laga: not really. hardy never had .22 ;-)
<bokey> laga: Nafallo sorry dudes :-) was pointing to gutsy in my hardy.list in sources.list.d
<bokey> sorry!!!!
<bokey> did surmandal_ just leave?
<bokey> from this channel?
<laga> Nafallo: i think hardy had .22 back in the day?
<bokey> laga: gutsy runs on .22
<bokey> laga: i had it wrong in hardy.list
<bokey> :s
<bokey> all good now
<bokey> sweet
<bokey> for some reason my kvirc's fu'ed up
<bokey> shows surmandal_ msg'ed me from this channel
<bokey> :s
<cjwatson> compbrain: err, try live video=ofonly ?
<compbrain> cjwatson: no dice
<bokey> .24's sweet
<bewst> Hi; I've been working desperately on trying to sort out https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/121653 for the past few days, and I just wanted to check whether such a long issue is likely to get attention from the devs?
<bokey> running like a charm
<ubotu> Launchpad bug 121653 in linux-restricted-modules-2.6.22 "[gutsy] fglrx breaks over suspend/resume" [Wishlist,Confirmed]
<cjwatson> compbrain: damn
<cjwatson> compbrain: stuck, then
<Nafallo> laga: doubt it.
<cjwatson> hardy did have .22 for a while, due to inheriting from gutsy
<bokey> ahh.. i see
<Nafallo> cjwatson: baah. now you need to come to the London releaseparty and get beer :-D
<bokey> Nafallo: dude, i'd come to london if you send me a ticket one way for beer party
<bokey> :)
<bokey> Nafallo: when i get there, i'll buy you a beer in exchange
<bokey> :D
<Nafallo> lol
<bokey> !lol
<ubotu> Please don't use "LOL" and "OMG" and so forth on a regular basis. This is IRC, not IM, and using those lines on their own is not required, and it is rather annoying to the rest of the people in the channel; thanks.
<bokey> :D
<bokey> :DDDDDD
<bokey> ok guys.. thanks for the help.. see ya around!!! :-))) bye Nafallo & laga
<cjwatson> Nafallo: for some reason, my wife often seems to be keen to see me right after release, after I've nearly ignored her for two weeks
<Nafallo> cjwatson: like I said last time, bring her with :-)
<bewst> Really am desperate to get #121653 addressed before the release and have made valiant debugging efforts.  Am I pinging the wrong place?
<ScottK> bewst: You might have more luck in #ubuntu-kernel.  Dunno.
<bewst> ScottK: thanks; enjoy the beer
<cjwatson> laga: merged, image building
<laga> cjwatson: great, thanks
<asac> pitti: still on?
<emgent> kees: upstream released all fix for CVE-2007-6013, can i work to fix wordpress in ubuntu ?
<ubotu> Wordpress 1.5 through 2.3.1 uses cookie values based on the MD5 hash of a password MD5 hash, which allows attackers to bypass authentication by obtaining the MD5 hash from the user database, then generating the authentication cookie from that hash. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6013)
<crimsun> asac: I've tested http://pastebin.ca/988804 as a workaround for Flash+PulseAudio+ALSA
<_max_> id like to report what i concider a bug
<_max_> in the installer (both alternate and regular) there is no way to force gpt label.
<_max_> i tried booting with the normal installer, entering console, changing to gpt using parted, creating partitions using the gui, and its still gpt all the way until i click [install]
<kees> emgent: yeah, sure, go for it
<_max_> then it changes it back to friggin msdos, and my remaining 4tb are useless
<emgent> ok thanks kees
<crimsun> asac: in summary, it allows Flash (which uses ALSA's "default" virtual device") to use ALSA concurrently with PulseAudio, so there's no fallout from losing libflashsupport aside from being unable to migrate the Flash stream (or changing its volume)
<crimsun> asac: this change also unbreaks dist-upgrades where users have selected ALSA in non-GSt-based apps
<crimsun> (back later, meeting)
<cjwatson> _max_: changing to gpt with parted won't help, at least not if you do so after the partitioner's started up. Try starting the installer in expert mode; then when you ask to create a new partition table it should let you select the label type.
<cjwatson> _max_: (and, for this, use the alternate install CD)
<cjwatson> _max_: curious that it doesn't default to gpt on such a large disk though
<_max_> im friggin amazed aswell!
<cjwatson> I believe it's meant to
<_max_> thing is if i fire up parted, change to gpt, select "manual" for disc partitioning, then do my partitions, go on to [install] but dont press it
<asac> crimsun: you sure that this alone is enough?
<_max_> just back to console, its still gpt and has gpt partitions!
<cjwatson> partitioning isn't committed until you hit install
<asac> crimsun: whats your rational :)?
<cjwatson> there is definitely code in partman-partitioning to use gpt for a new disk label if it's >2TB
<_max_> well im running a 3ware 9500s-12, with a raid5, linux detects it as 5000GB
<cjwatson> _max_: starting up parted in the middle of things is only likely to introduce confusion, FWIW
<cjwatson> don't do that :)
<cjwatson> I'll see if I can construct something to reproduce your problem once I'm done with my current round of testing
<_max_> well iv done it the "normal" iv spent two days solid on this so im trying desperate sollutions
<cjwatson> _max_: you should report this as a bug on https://bugs.launchpad.net/ubuntu/+source/ubiquity/+filebug, if you haven't already
<cjwatson> you were lucky that I happened to be around; IRC is not a good medium for reporting bugs
<_max_> will do, if you need any probing results or whatever im around with this nick :)
<_max_> *grumble* ubuntu -really- needs a unified login database.
<_max_> i think i have registered on atleast 3 different ubuntu websites sofar
<cjwatson> Launchpad's growing towards that (see OpenID implementation)
<cjwatson> at this point it's mostly a matter of gluing them all together)
<_max_> that "brainstorm" forum was worth the register though.
<_max_> excellent idea
<stgraber> _max_: brainstorm and the ISO tracker share the same user DB and we are planning integration with LP using OpenID in the (near) future
<cjwatson> I don't have any multi-TB disks around to test with, but I'll hack up the installer to reduce the threshold at which it selects GPT
<cjwatson> _max_: please attach /var/log/syslog and /var/log/partman from the running installer to any bug you file; if you've already completed installation, attach /var/log/installer/syslog and /var/log/installer/partman
<_max_> its installing alternate atm, when i get it online il attach the files :)
<_max_> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/218918
<ubotu> Launchpad bug 218918 in ubiquity "ubuntu 8.04 wont use gpt for 2tb+ devices" [Undecided,New]
<_max_> is the bug atm.
<_max_> hah, i like that bot :)
<TheMuso> slangasek: No problem, wasn't sure.
<_max_> cjwatson, may i ask where you are located?
<cjwatson> _max_: England
<_max_> not too far, been trying to get ahold of some people that are "involved" with ubuntu for a computer festival.
<_max_> i tried emailing canonical's pr department but noones answering :(
<_max_> do you have a email addy i could send a short mail to describing the festival, maybe you would like to attend or if not might know someone that would like to? (as sort of an exhibiter/promoter for ubuntu)
<cjwatson> _max_: http://www.canonical.com/aboutus/contactus says that pr@ is only for "enquiries from legitimate media outlets. No other enquiries can be replied to"
<cjwatson> _max_: I'd suggest the relevant local community team, who are usually best placed for this kind of thing and can involve Canonical if appropriate; https://wiki.ubuntu.com/LoCoTeamList
<_max_> okey i got gpt working, this is what i did: booted regular cd, -> console -> parted -> mklabel gpt -> quit
<_max_> reboot -> alternate cd -> normal setup -> grub failed -> installed lilo
<_max_> okey, well if your interested in comming to sweden in the end of november, the event is called dreamhack, with ~10.000 participants in the LAN, and a few more thousand visitors :)
<_max_> im trying to organize a seperate linux area where distro's can motivate people to use linux, and tell them more about what their distro can do.
<_max_> sweden loco was only 2 ppl =/
<cjwatson> _max_: it would have been more useful to test whether it worked with the expert mode suggestion I gave
<cjwatson> that would at least have eliminated one possible mode of failure
<_max_> cjwatson; if i have time monday il try re-install it :) its my media center and im having folks over during the weekend for a Matrix marathon :P
<_max_> im goin to bed now :) thanks cjwatson for the help.
<megabyte405__> There, source package for abiword-2.6.2-0ubuntu1 (ready to upload) has been uploaded to my PPA
<LaserJock> megabyte405__: \o/
<megabyte405__> LaserJock: my thoughts exactly :)  Now we just need an uploader to see that I updated the bug, and everyone will become happy in a short period of time
<ogra> slangasek, would you be very resistant to get the fix in bug 218231 in after RC ?
<ubotu> Launchpad bug 218231 in ltspfs "ltspfs in hardy doesnt work with LDM_DIRECTX=True set in lts.conf" [Undecided,New] https://launchpad.net/bugs/218231
<ogra> (LDM_DIRECTX is not on by default but the most used featue in ltsp5, users will complain if their usb keys ad floppies stop working, so i'd love to get that regression fixed)
<ogra> *feature
#ubuntu-devel 2008-04-18
<azeem> 01:13  * ubuntu found a bug in hardy beta disk
<azeem> 01:13 < ubuntu> if you install konversation, it comes to #debian with the ubuntu nickname :D
<azeem> euh
<ion_> Haha. Let's make the other clients do that as well. ;-)
 * lamont notices bug 197311, considers reassigning it to udev as "udev (libvol_id doesn't support ext4"
<ubotu> Launchpad bug 197311 in util-linux "In order to support ext4, util-linux must use blkid (and not vol_id)" [Undecided,New] https://launchpad.net/bugs/197311
<azeem> ion_: it's pretty demotivating that Ubuntu didn't manage to fix this in all those years
<lamont> azeem: blame the kubuntu guys. :)
<lamont> xchat got fixed quite some time ago
<cjwatson> how can I put this - it doesn't seem like the most important bug in the list
<lamont> cjwatson: +5
<azeem> cjwatson: which one?
<ln-> you know, there are other distributions where bugs actually get fixed.
<soren> ln-: Use those, then?
<lamont> cjwatson: bug 205327 is a bit annoying, although the trivial workaround of "LANG=C cfdisk ..." is available to at least parts of that world..
<ubotu> Launchpad bug 205327 in util-linux "[Hardy] cfdisk unusable in the whole hispanic world" [Undecided,New] https://launchpad.net/bugs/205327
<ln-> soren: that is precisely what i am doing.
<lamont> interestingly, the konversation-connects-to-debian-irc-by-default bug is not filed...
<lamont> 'maybe that would explain it not getting fixed
<azeem> konversation (1.0.1-3ubuntu1) gutsy; urgency=low
<azeem> [ Jonathan Riddell ]
<azeem> * Drop channel patch, default channel is changed in kubuntu-default-settings and it can fall back to freenode if that's not installed
<azeem> hrm
<azeem> apparently this user booted the Ubuntu live CD and then manually installed konversation
<azeem> which took him to #debian by default
<cjwatson> azeem: the konversation bug
<cjwatson> ln-: given the number of bugs I've personally fixed in the last week, that comment is uncalled for and you should retract it
<azeem> cjwatson: ok, but Ubuntu users are getting harassed and executed in #debian
<azeem> it's difficult to destinguish between the set of Ubuntu users which get there due to this bug and those which get there because they don't get help in #ubuntu
<cjwatson> #kubuntu-devel's probably a good place to get attention for it
<azeem> am filing a bug now, thanks
<azeem> (but this is only a problem if you
<azeem> *don't* run kubuntu)
<cjwatson> lamont: not helped by the fact that dead keys don't work at the console (bug 218746, unfortunately I only heard about this today)
<ubotu> Launchpad bug 218746 in console-setup "dead keys don't work using spain keymap" [Medium,Confirmed] https://launchpad.net/bugs/218746
<cjwatson> azeem: sure, but they're the ones best-placed to fix it quickly
<lamont> "dead keys"?
<cjwatson> in many keymaps, some keycodes are mapped to a sort of automatic compose+diacritic symbol
<cjwatson> so you press dead_acute followed by i and you get Ã­
<cjwatson> correct composition tends to be rather locale-dependent
<lamont> ah, ok
<slangasek> ogra: 218231 looks ok to me for post-RC
<ogra> slangasek, indeed, its all post rc (dont accept the upload i jus did until next week :) )
<ogra> i just want it in
<ogra> when doesnt matter as long as its befoe the final spin :)
<slangasek> well, yes, you asked if I would be resistant
<ogra> to get them in at all :)
<slangasek> I had no intention of accepting it /prior/ to RC :)
<ogra> thanks then :)
<ogra> stgraber, (still awake ?) is the peseeding fix in xubuntu ?
<ogra> *preseeding
<ffm__> What's the process for getting a DEB package provided by upstream (in this case truecrypt) into the repos?
<ffm__> Also, is work started on the still-thawed ibex yet?
<RAOF> ffm__: Throw upstream's package away; it's generally crap, and then package the source yourself :)
<cjwatson> ffm__: intrepid can't+won't open until hardy is released
<ogra> cjwatson, rescue mode says "restart system" but that menu option drops me back to the installer menu ... do you consider that a bug ?
<cjwatson> (can't: Launchpad doesn't support initialising a new distrorelease without basically marking the previous one as done, and it's hard to specify how that should behave; won't: we absolutely don't want to distract developers from stabilising hardy, which is much more important than getting a jump on intrepid development)
<cjwatson> ogra: yes, it's bug 218549, fix queued for after RC
<ubotu> Launchpad bug 218549 in rescue "Choosing "Reboot" in rescue menu jumps to main menu -- sync rescue from Debian" [Medium,Fix committed] https://launchpad.net/bugs/218549
<ogra> ah, k
<ffm__> RAOF, It's actually pretty nice. (And it's by the true crypt devels...)
<ffm__> What's the equivilent of rmplint on DEB-based distros?
<ffm__> *rpm
<cjwatson> not knowing rpmlint in detail, that sounds like lintian
<cjwatson> also, .deb is not an acronym. :-)
<ogra> i wonder if an autoresize install works on a former encrypted lvm2 one ...
<ogra> hmm, sad, the foremr install indeed defaulted to ext3 ...
<ffm__> cjwatson, I realize that.
<ffm__> cjwatson, Deb == short for Debra
<mneptok> cjwatson: Debian's Enervating Breakage?
<RAOF> ffm__: Anyway, https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages is what you want to look at.  Upstream's debian packaging may help you, but you'll want to package from their (preferably debian/ less) tarball.
<ffm__> RAOF, Debian/ less? They packaged spesifcially for ubuntu gutsy. (if only I had a srpm...)
<ffm__> or whatever the equivilent of a srpm is in the debian world.
<RAOF> ffm__: You _don't_ have a source package?
<ffm> RAOF, ATM, no.
<RAOF> ffm: The binary .deb is useless for us, basically.
<joshk> has anyone noticed GDM segfaults in 8.04beta?
<slangasek> not here
<ffm> RAOF, I'll ask upstream if I can have their source deb.
<RAOF> ffm: Of course, if they distribute the source you can just package that up.
<ffm> RAOF, yes, they do, but I'd prefer not to duplicate work and effort if I can avoid it.
<RAOF> Yeah, fair enough.  I'd be careful, though.  Upstream's source packages are often not archive-ready.  But they should give you something to start with.
<lamont> :-[ FLUSH CACHE failed with SK=0h/ASC=00h/ACQ=03h]: Input/output error
<lamont> meh.  short of rebooting, how do I eject the dvd-rw?
<ffm> lamont, eject
<lamont> nope.
<lamont> well, the command finishes just fine, the drive just doesn't open
<ffm> lamont, use a paperclip?
<lamont> only happens with the dvd-rw media... dvd-r, dvd+r are fine.
<lamont> heh.  either I'm a muppet, or it doesn't eject via the button
<ffm> lamont, paperclip through the pinhole.
<lamont> yeah
 * lamont considers uploading util-linux_2.14~rc1-1ubuntu1 just so slangasek has something to reject.  decides to _NOT_
 * lamont wanders off
<Hobbsee> azeem: crap, thanks for the bug (konversation)
<TheMuso> slangasek: I'd like your thoughts on bug 210423 and bug 188986 for release. Basically the first bug has a link to a patch that improves pulseaudio buffering for sdl audio playback.
<ubotu> Launchpad bug 210423 in libsdl1.2 "patch to fix sound problems when using pulse backend" [Undecided,New] https://launchpad.net/bugs/210423
<ubotu> Launchpad bug 188986 in libsdl1.2 "Audio output crackling" [Undecided,Confirmed] https://launchpad.net/bugs/188986
<dholbach> good morning
<ion_> ing
<dholbach> hi ion_
<Johninky> hello all
<Johninky> Can I ask a quick question please, might take a long answer
<ion_> Hello all. Please tell me whether I can ask whether i can ask a question.
<RAOF> Johninky: Is it about the development of Ubuntu (not development _on_ Ubuntu, or some other topic)? :)
<Johninky> it is about creating a wireless driver or did i hit the wrong room again
<RAOF> Chances are you want a kernel-related room, yes.
<Johninky> ok I will see if I can find one, and thank you
<slangasek> TheMuso: that doesn't look like a very good patch; gratuitous whitespace changes, magic numbers with no explanation of why they should be used, and functional changes that are outside the scope of "basically just fixes the bogus buffer metrics"
<slangasek> TheMuso: I'd reject that without a clearer rationale for why it's correct
<TheMuso> slangasek: Ok sounds fair.
<calc> wow i ls'd at just the right time
<calc> d????????? ? ?    ?            ?                ? openoffice.org_2.0.2.orig.tar.gz.tmp-nest
<calc> hehe
<ion_> calc: Heh
<pitti> Good morning
<slangasek> does anyone here know whether the ubiquity po's under the debian/po directory are in rosetta, and if so, how I find them?
 * slangasek waves to pitti
<seb128> hey hey pitti
<pitti> ugh, I lost scrollback during the night (server reboot); if someone said something to me, please repeat
<seb128> pitti: I complained a lot about you but will not repeat ;-)
<pitti> slangasek: I'm pretty sure that ubiquity translations are in rosetta, but I don't know where
<seb128> (just joking)
 * seb128 hugs pitti
<seb128> mvo: hey
<pitti> seb128: rightly so!
<pitti> I found a solution for my ssh problem :)
<seb128> does anybody knows what the migration is supposed to import from linux installs?
<seb128> not the wallpapers, etc?
<seb128> pitti: oh?
<slangasek> pitti: hmmmm. this makes it hard for me to suggest a fix to a typo :)
<pitti> seb128: does it anything for linux? it never shows anything to me
<pitti> seb128: I installed openvpn on my boxes and my colo server, and tunnel ssh connections through that VPN
<pitti> silly, but works
<mvo> hey seb128
<seb128> mvo: I think the bug you reported about totem is a duplicate, if you effectively don't have a soundcard
<seb128> pitti: ah, nice idea ;-)
<pitti> slangasek: https://translations.edge.launchpad.net/ubuntu/hardy/+source/ubiquity/ *should* have them
<slangasek> pitti: it doesn't, it only has the translations for ubiquity/po, not ubiquity/debian/po
<pitti> but doesn't apparenlty
<slangasek> right
<pitti> the upstream product hasn't either
 * slangasek nods
<mvo> seb128: aha, ok - thanks
<cjwatson> slangasek: https://translations.launchpad.net/ubuntu/hardy/+source/debian-installer/+pots/debian-installer
<cjwatson> due to complicated magic
<slangasek> ok
<slangasek> thanks :)
<cjwatson> it's the closest simulation we could manage for bubulle's master files
<slangasek> heh :)
<slangasek> ouch, this typo has been in the catalan ubiquity translation since 2007-03-11
<StevenK> slangasek: What's the typo?
<slangasek> StevenK: poques preguntes -> poquesp reguntes
<StevenK> Not that I speak Catalan, I'm curious.
<slangasek> it's cosmetic, but the fix has also been available in rosetta for quite a while, unapplied
<m0u5e> i noticed that the readme file when you update-manager -d has changed to "hardy heron RC" ... does this mean the RC is ready to download?
<slangasek> it means that certain changes have been made in preparation for the RC
<m0u5e> slangasek: do you happen to know the timeframe for the RC release? or is it just sometime today xD
<slangasek> m0u5e: if all goes well, sometime within the next 7 hours
<m0u5e> mm no hurries, I would rather the devs took their time, had a polished release, and then had time to have a hardy celebration party :)
<slangasek> oh, well, we don't start in on that until after the final release. :)
<hubuntu> Question: I need top ship Hardy CDs within the 26th of april, but bandwidth speed will NOT allow me to complete the download within the 24 and send them country wide the same day so they can be there the 25th of april (a friday). Do you think that It is an idea to burn the daily build, say on monday and distribute that? The event will have 7.10 as their main version but I really want to push 8.04 to the masses
<seb128> I guess that ubiquity beeping on the installation summary screen is a known issue?
<Hobbsee> hubuntu: they'll be an almost-final, or fully final copy a fwe days before, that gets tested, if that helps.
<Hobbsee> hubuntu: if you can grab the one 2 days before release, you're probably OK.  check with the testing team, etc, about that
<Fujitsu> hubuntu: Grab a daily a couple of days before, and rsync.
<slangasek> hubuntu: what about downloading on Monday, then using rsync to update it with any changes between Monday's image and the final release?
<Fujitsu> 'swat I thought.
<Hobbsee> that too
<hubuntu> slangasek, I thought about that.. Specially since I'm thinking of building a Local mirror for faster install
<hubuntu> Is it difficult to do? I have very limited on hands use of rsync, but I do understand what it does
<hubuntu> I will be building such a server and a how-to this weekend, I will keep you all informed ;)
<hubuntu> and weill keep asking.. so bare with me
<Fujitsu> hubuntu: https://help.ubuntu.com/community/RsyncCdImage
<slangasek> sorry, what do you mean by "faster install"?  If you're using desktop images, a local mirror won't make a standard install any faster
<slangasek> if you're using alternate CD images, a local mirror can help for downloading the images themselves faster using jigdo, but that's more arcane than rsync :)
<Fujitsu> How'd jigdo arcane?
<hubuntu> Faster in the sense of optimized (few CDs, few people being able to start an installation can be solved by a LAN with automatic PXE booting and CDs downloading form the local server (no internet in many of the events...)
<slangasek> Fujitsu: way less documentation available on the internets? :)
<Fujitsu> jigdo-file somefile.jigdo
<Fujitsu> Hmm. When did graphical jigdo lose the `Blah blah blah incomplete blah blah buggy\n[Great!] [Awesome!] [Excellent!]' or similar dialog?
<hubuntu> ok I've tried jigdo and never understood a thang
<hubuntu> but I have to admit that I did gop deep into it.. I'm lazy at times ;)
<hubuntu> I am going to write this all down in a spec and work it trhough the weekend
<hubuntu> stay tuned ;)
<Whoopie> Keybuk: Hi, FYI, don't know why but usplash is now working. no segfault anymore.
<Keybuk> Whoopie: always the way :-/
<hubuntu> I just love how things get fixed just in time before releases.. remember Evo crashing everyday till the day before RC in feisty and getting fixed just one day before (just to crash 6 months later.. Exchange Su2#%!  You guys do a superb job! Thank you so much!!
<hubuntu> you make ubuntu rock!
<Whoopie> anyone knows how I could relax firefox's SSL certificate check? I can't access dev.openwrt.org and bugs.freedesktop.org
<Keybuk> Whoopie: click the Add Exception button
<Whoopie> there's non for bugs.freedesktop.org. Just a message about self-signed certificate
<seb128> what webbrowser are you using?
<Whoopie> firefox 3b5. with version 2, I got a popup if I want to temporaryly accept the certificate.
<Whoopie> ok, but I can add an exception in the preferences.
<Whoopie> seb128: do the suspend and hibernate buttons in the gdm menu normally work?
<seb128_> Whoopie: I don't know, we have a bug about hibernate not working but I didn't verify
<seb128_> Whoopie: I don't think many users use those and I don't consider it high priority at the moment but you are welcome to confirm the bug
<Whoopie> seb128: ok, do you have a launchpad bug number by chance?
<seb128_> Whoopie: should be as fast to find for you than for me so I will let you search hibernate in the gdm bugslist
<Whoopie> seb128_: ack
<Whoopie> seb128_: do you need any infos or can I just put launchpad bug 208136 into confirmed state?
<ubotu> Launchpad bug 208136 in gdm "system cannot hibernate with GDM" [Undecided,New] https://launchpad.net/bugs/208136
<seb128> hum
<seb128> I've several cases where ubiquity fails creating partitions
<seb128> Apr 18 09:52:34 ubuntu partman: Could not stat /dev/sda5 --- No such file or directory
<seb128> Apr 18 09:52:34 ubuntu partman:
<seb128> Apr 18 09:52:34 ubuntu partman: The device apparently does not exist; did you specify it correctly?
<seb128> is that a known issue?
<seb128> indeed there is no dev entry for this one, but I just created the partition in ubiquity and fdisk lists it correctly
<slangasek> seb128: looks like the same issue cjwatson identified last night, where parted creates the partition and then disagrees with the kernel about what its name should be
<slangasek> seb128: GPT?
<seb128> slangasek: GPT? what is that?
<slangasek> seb128: the partition tables used by newer systems, that accomodate multiple TB partitions
<seb128> how do I know about that
<slangasek> (also the ones you have to use on x86 Apple hardware)
<slangasek> I don't know, sorry
<seb128> slangasek: the box is an intel desktop using a 250G disk
<seb128> anyway I've most of my manual installs which are failing due to that on this one, so if somebody needs informations let me know
<seb128> preferably before lunch because I'll not be in front of this box this afternoon
<cjwatson> slangasek: that's a different one, actually
<cjwatson> slangasek: I think seb128's bug is the one Evan fixed in partman-base for post-RC
<slangasek> ok
<cjwatson> I *think*
<tjaalton> slangasek: ping? there's a new fglrx release (8.4) which includes a couple of fixes (aticonfig should no longer segfault etc.). I've packaged a new lrm, uploaded and built on my PPA and now asking people to check for possible regressions. rtg & bryce acked it already, bug 218345
<ubotu> Launchpad bug 218345 in linux-restricted-modules-2.6.24 "fglrx 8.4 released today. Any chance for hardy?" [Medium,In progress] https://launchpad.net/bugs/218345
<tjaalton> post-rc of course
<slangasek> tjaalton: I think we should really defer that until 8.04.1
<slangasek> so we can test it from all angles at our leisure
<laga> tjaalton: re your comment in https://bugs.launchpad.net/bugs/202164 - do you think it's the fault of xrandr?
<ubotu> Launchpad bug 202164 in xorg-server "[hardy] displayconfig-restore causes X to crash" [Wishlist,New]
<tjaalton> slangasek: ok, I'm not sure if post-release lrm's fit the kernel team policy, but I'll ask :)
<tjaalton> laga: I'm not that familiar with multiseat tbh.. that was just a guess, although it might not have anything to do with this problem
<tjaalton> laga: get a proper backtrace: https://wiki.ubuntu.com/X/Backtracing
<laga> tjaalton: good idea. for now, i've just disabled displayconfig-restore, i'll try to get a BT in a few days. will the functionality in displayconfig-restore eventually moved into X itself? it looked like it corrects some auto-detection problems
<tjaalton> laga: I don't know what it does :)
<laga> tjaalton: ah. ok, i'll get a backtrace :)
<slangasek> laga: are the current mythbuntu alternates ready for release as RC?
<laga> slangasek: depends. :) if RC happens now, then they're ready. if not, then i'll need to test a change to ltsp.seed.. i was too tired last night and messed up the change i did then. but that's not critical.
<slangasek> laga: the RC is happening within the next few hours for Ubuntu et al.; so the question is whether the current mythbuntu images are appropriate to push out at the same time as an RC
<laga> slangasek: give me 15 minutes and i'll tell you if the updated ltsp.seed works for me now, then the disk would need to be respun. if that's too much work right now, we can just release as-is
<slangasek> laga: it's "too much work" in the sense that I don't think that leaves you enough time to fully test it between now and the RC announcement going out :)
<slangasek> laga: but if this is something that should be a showstopper for mythbuntu, I can respin and let you guys do your own RC announcement a little bit later
<slangasek> laga: but I would like to know soon which way you'd prefer, so that I can get the images ready to mirror :)
<laga> slangasek: i doubt that a simple preseed option will break much :) if something went wrong, it'd have to be something with the build process
<laga> slangasek: we do our own RC announcement anyways :) the live disks will be ready, though (AFAIK, superm1 knows more)
<slangasek> laga: as a matter of covering my own butt, I'm not going to include pointers to any images in the RC announcement I send out that haven't been tested
<slangasek> laga: but beyond that constraint, you get to tell me what you want to happen - so please direct me
<laga> slangasek: i think only two people are testing the mythbuntu alternate disks anyways :) okay, i think we can do this: in the RC announcement, you can link to the RC announcement on mythbuntu.org. people will find our live disk there and i'll add the alternate disk to the mythbuntu announcement once i'm sure it's sane.
<slangasek> laga: ok, so the desktop images are ready for release now?
<laga> let me check the logs
 * laga yells at superm1 for being asleep
<slangasek> heh :)
<laga> < tgm4883> there are only 3 mirrors out of sync < tgm4883> we are able to release
<laga> assuming that we tested the disk before pushing them to ten mirrors or so, the desktop disks should be good :)
<Daviey> laga: i fixed one of them.. so should only be 2 now
<\sh> slangasek, just release a very stable and good RC for -server, which I can deploy two days before final on our server farm ;)
 * soren is suddenly reminded that he has a mythbuntu mirror.
<ion_> Let's switch to Van Jacobson's new Internet already, then mirrors become completely irrelevant. :-)
<laga> gah, screw this. slangasek, is there any room for "known issues" in the release notes? :) although these probably belong into the mythbuntu release notes
<laga> slangasek: let's use the current daily alternate disk.
<slangasek> laga: yes, please put known issues in the mythbuntu release notes
<laga> slangasek: sure.
<slangasek> ok, setting the current daily alternate up for publishing
<laga> 20080417.2
 * slangasek nods
<psyke83> asac, what's the status of bug 192888? Did you change your mind about nspluginwrapper?
<ubotu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents" [High,Confirmed] https://launchpad.net/bugs/192888
<pitti> *blink* 0417.2? for ubuntu or a different flavour?
<pitti> asac: argh, do you know about the broken 404 error page in current ffox 3? Just try "http://foo" and be greeted with an "invalid XML blabla"?
<slangasek> pitti: the 0417.2 was for mythbuntu
<pitti> slangasek: ok, *phew* :)
<pitti> slangasek: oh, still awake? is your plan to get the release out before you go to bed? :)
<slangasek> pitti: well, yes. :)
<seb128> slangasek: any idea if there is a bug about the linux and installer not agreeing on partitions available issue?
<slangasek> seb128: you'd have to ask cjwatson; anyway, he highlighted a different bug that he thinks is yours
<asac> pitti: yes. i am aware of that. i think its some combination of properly encoding the dtd strings.
<seb128> ok
<slangasek> seb128: <cjwatson> slangasek: I think seb128's bug is the one
<slangasek> ...  Evan fixed in partman-base for post-RC
<seb128> ah ok
 * seb128 looks at the changelog
<dholbach> good to know, so I don't need to test that with 20080417.2
<asac> pitti: ill fix that on over weekend. in worst case we have to workaround. but ill surealy have a fix by sunday if not sat.
<pitti> asac: thanks!
<asac> pitti: i suspect that some chars are not properly escaped in the dtd generation code
<seb128> slangasek: ok, might be bug #218394
<ubotu> Launchpad bug 218394 in partman-base "partman fails to swapoff all swap partitions on the target device" [High,Fix committed] https://launchpad.net/bugs/218394
<slangasek> ah, clever :)
<seb128> thanks
<pitti> soren: qemu depends on bochsbios-qemu, but the latter is NBS, so I need to remove it for the release; do you care enough about qemu to want to fix it?
<soren> pitti: Yes.
<soren> I'll fix. Hang on.
<pitti> soren: thanks; I can wave it through unapproved, since it's universe, and obviously RC
<soren> pitti: Er.. It only conditionally depends on bochsbios-qemu?
<pitti> soren: ah, right; the | bochsbios is satisfyable
<cjwatson> seb128: I'm not absolutely certain, so worth checking after RC once that lands (it needs a new ubiquity upload too)
<seb128> cjwatson: will do
<soren> Right. That's when the file it needs moved frrom bochsbios-qemu to bochsbios and we dropped -qemu. I *did* think that I fixed it back then :)
<pitti> soren: -qemu is still the preferred dependency, but probably 'good enoughh'
<soren> pitti: Yeah. I'll fix that in intrepid.
<pitti> soren, dendrobates-: do we care about cyrus 2.2? it depends on libasn1-6-heimdal, which is NBS, too (thus I remove it now0
<soren> I personally couldn't care less.
<dendrobates-> pitti: Me as well.
<pitti> well, I'll try a no-change rebuild and upload that if it builds cleanly against libasn1-8-heimdal (which I suppose)
<mjung> Hi. I was not able to find source which cites which xen-patches have been applied to linux-image-2.6.22-14-xen and where to find them to recompile the package.
<mjung> (I am missing the 'connmask' module, which has unfortunately not been enabled by the maintainer.)
<james_w> soren: I cherrypicked a fix for bug 205011, but I am not able to test it, do you have the setup to do so?
<ubotu> Launchpad bug 205011 in lvm2 "LVM2 doesn't recognise 'virtio' virtual disks (/dev/vd*)" [High,Confirmed] https://launchpad.net/bugs/205011
<soren> james_w: I do, yes.
<james_w> soren: liw has also offered to test, but he says he needs exact instructions if you want him to.
<soren> james_w: Complete an installation that uses lvm. Install patched lvm. Shut it down. STart it again like so: kvm -drive file=nameofdisk.img,if=virtio,boot=on
<soren> If it works, all is good.
<ogra> slangasek, is that doc closed already ? https://wiki.ubuntu.com/HardyHeron/RC ?
<slangasek> ogra: no - what do you need added?
<ogra> LTSP in "new and improved support" woudl be nice with "The alternatd CD provides an out of the box treminal server installation now" with a link to https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall
<ogra> *alternate
<ogra> *terminal
<ogra> *sigh*
<Randall> The Beginning  1 In the beginning God created the heavens and the earth.  2 Now the earth was [a] formless and empty, darkness was over the surface of the deep, and the Spirit of God was hovering over the waters.
<Randall> 3 And God said, "Let there be light," and there was light. 4 God saw that the light was good, and He separated the light from the darkness. 5 God called the light "day," and the darkness he called "night." And there was evening, and there was morning.the first day.
<Randall>  6 And God said, "Let there be an expanse between the waters to separate water from water." 7 So God made the expanse and separated the water under the expanse from the water above it. And it was so. 8 God called the expanse "sky." And there was evening, and there was morning.the second day.
<Randall>  9 And God said, "Let the water under the sky be gathered to one place, and let dry ground appear." And it was so. 10 God called the dry ground "land," and the gathered waters he called "seas." And God saw that it was good.
<ogra> !ops
<ubotu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<ogra> ?
<Randall>  11 Then God said, "Let the land produce vegetation: seed-bearing plants and trees on the land that bear fruit with seed in it, according to their various kinds." And it was so. 12 The land produced vegetation: plants bearing seed according to their kinds and trees bearing fruit with seed in it according to their kinds. And God saw that it was good. 13 And there was evening, and there was morning.the third day.
<Randall>  14 And God said, "Let there be lights in the expanse of the sky to separate the day from the night, and let them serve as signs to mark seasons and days and years, 15 and let them be lights in the expanse of the sky to give light on the earth." And it was so. 16 God made two great lights.the greater light to govern the day and the lesser light to govern the night. He also made the stars. 17 God set them in the expanse of the s
<ogra> thanks
<Hobbsee> ogra: thanks
<Hobbsee> thought i recognised the reference
<slangasek> Riddell, Hobbsee: are there any Kubuntu-specific errata that should be pushed out as release notes currently?  (If not, no sweat, the errata we currently have are fairly generic anyway)
<lamont> Hobbsee: but they spelled "Big Inning" wrong
<slangasek> heh
<Hobbsee> slangasek: no idea, sorry.  i don't do much in kubuntu anymore
<slangasek> Riddell: all on you then :)
<cjwatson> slangasek: it might be worth errataing that non-Latin keymaps are buggered (218754) and that ports architectures fail to install at least from the desktop CD (218801)
<cjwatson> err, 218754 is alternate/server only
<pitti> anyone from Ubuntustudio here? TheMuso? ubuntustudio-audio depends on rosegarden4, which is NBS (current is rosegarden)
<_MMA1> pitti: That should have been fixed months ago AFAIK.
<Riddell> slangasek: none that I can think of
<pitti> I remove the package now, since rosegarden Provides: rosegarden4, but it should be fixed nevertheless
<pitti> _MMA1: obviously not :)
 * _MMA1 looks at seeds.
<hadess> superm1: around?
<soren> cjwatson: It seems that the bug about grub failing is slightly more general.
<slangasek> ogra: LTSP added
<_MMA1> pitti: Damn. I *know* that got changed. I'll have Luke fix that today.
<superm1> hadess, what's up?
 * ogra hugs slangasek 
<pitti> _MMA1: thanks
<soren> cjwatson: Actually, attempting to run any i386 binary from the amd64 livecd environment results in a "Bad RIP value".
<hadess> superm1: did you see my updated patch for the lirc include stuff?
<slangasek> er.. except not added, because someone edited the page out from under me. :)
<superm1> hadess, no i haven't.  where would it have been?
<hadess> superm1: on lirc-devel
<superm1> hadess, ah okay.  i'll look it over when I return home later on
<superm1> thanks!
<hadess> superm1: in reply to your original patch
<slangasek> there, now it's added
<hadess> superm1: i haven't received any updates from christoph though
<superm1> hadess, he is a bit slow sometimes
<cjwatson> soren: which bug?
<pitti> seb128: any idea about http://launchpadlibrarian.net/13075917/buildlog_ubuntu-hardy-i386.gtk-doc_1.10-1_FAILEDTOBUILD.txt.gz ?
<cjwatson> soren: "grub failing" *is* a general symptom. It could happen for all kinds of entirely separate reasons.
<pitti> After installing, the following source dependencies are still unsatisfied:
<seb128> pitti: soyuz bug?
<pitti> openjade(still installed)
<pitti> seb128: I give it back, let's cross fingers
<seb128> pitti: slangasek and slomo_ discussed it some time ago I think
<slomo_> yes, sbuild simply doesn't like conditional dependencies when resolving build dependencies iirc
<seb128> pitti: the package didn't change but it has an alternatives build-deps and it's not really clear how the buildd resolve that
<pitti> lool, StevenK: is anyone working on the hildon-control-panel FTBFS? looks like a pointer declaration bug, which breaks 64 bit?
<pitti> slomo_: what's a conditional dependency?
<pitti> erk, build-conflicts
<soren> cjwatson: Sorry, I though my mentioning it provided enough context. The bug about grub failing to install consistently using an amd64 live cd.
<slomo_> pitti: some package depends on "openjade | jade", buildd selects one of them and gtk-doc build conflicts with that
<slangasek> cjwatson: is 218754 selecting a non-Latin keymap, or a non-Latin language?
<lool> pitti: I'm not; I could have a look this WE
<soren> cjwatson: heno should have sent the dmesg output to you.
<cjwatson> soren: I've looked at about 20 or 30 bugs in the last day or two :(
<StevenK> pitti: I will look at it
<cjwatson> (in some depth)
<lool> StevenK: Thanks
<soren> cjwatson: Sorry. Hang on, I'll find the bug no..
<cjwatson> you mean 219165?
<lool> StevenK: Check upstream and Debian, probably fixed it
<slangasek> pitti: gtk-doc: enjoy, dpkg-dev ignores the ordering of build-depends in your source package and instead sorts them in the generated .dsc
<soren> cjwatson: Yes, that's the one.
<cjwatson> slangasek: keymap, but only if you select it at the boot menu
<cjwatson> soren: ok, yes, definitely doesn't look like a d-i problem
<pitti> seb128, slomo_: indeed, docbook-dsssl depends on openjade, and gtk-doc-tools build-depends on that, but build-conflicts on openjade
<slangasek> pitti: there's a fix for this: build-depend on a-horrible-kludge | jade :P
<cjwatson> soren: losing 32-bit compatibility is very bad ...
<cjwatson> soren: I'll punt it over to the kernel
<pitti> TBH that's quite hard to sensibly resolve automatically
<soren> cjwatson: I talked to upstream, and they run 64-bit kernels with 32-bit userspace all the time inside kvm.
<soren> Well, not "all the time", but "routinely" at least.
<slangasek> pitti: the build-deps in the source package *were* set right, the only issue is that they're being reordered along the way
<cjwatson> soren: is it just in kvm?
<soren> cjwatson: As far as I know.
<soren> cjwatson: liw would know..
<seb128> slangasek: btw the text about gvfs in the hardy notes is slightly misleading
<cjwatson> soren: the report says that amd64 server works in kvm, so maybe it isn't all the time
<seb128> slangasek: I mentioned that by mail to you before I think, that was around beta
<slangasek> seb128: can you propose some correct text, please?
<seb128> "such as the inability to restore files from trash, pause and undo file operations, and will make it possible to escalate user privileges for certain operations using PolicyKit for authentication."
<seb128> none of those are possible in hardy
<pitti> slangasek: fun
<seb128> slangasek: I would just remove this part of the text I think
<\sh> pitti, octave2.1-forge ??? I thought we got rid of all octave2.1* stuff during octave3.0 transition?
<\sh> pitti, re: NBS
<pitti> \sh: I don't know; we can kill that, if it's obsolete
<\sh> pitti, well, we don't have octave2.1 in our archives anymore ;)
<\sh> pitti, for hardy that is
<\sh> pitti, could be that we lost the ports.ubuntu.com archives? ;)
<slangasek> seb128: which part? everything about gvfs?
<seb128> slangasek: what I just copied on the channel
<seb128> slangasek: the "such as <list of things not possible in hardy> yet"
<seb128> slangasek: the "such as <list of things not possible in hardy yet>" rather ;-)
<soren> cjwatson: True. I'm trying to find out what combo of things makes it appear.
<soren> Why is grub an i386 binary anyway?
<\sh> pitti, got the bugger...
<soren> non amd64-valid assembly code somewhere in it or something?
<\sh> pitti, octave2.1-forge is not a result package of octave2.1...please get rid of it, thx :)
<slangasek> cjwatson: 218801> hmm, is that going to be fixed for final?  and is using the alternate CD a valid workaround?
<heno> soren: desktop 64 bit installs (both live and alt CDs) fail, 386 desktop and 64 bit server install fine
<heno> cjwatson: ^
<soren> heno: Even outside kvm?
<heno> soren: I've never seen the failure outside kvm
<soren> heno: Interesting.
<heno> nor I believe has liw
<soren> Very, very interesting.
<soren> heno: Right, I asked him.
<slangasek> seb128: hrm, which notes are you looking at? I don't see anything about gvfs here
<cjwatson> slangasek: I have a fix for 218801 here
<cjwatson> slangasek: with the alternate CD, I *think* that you get one extra prompt rather than it just breaking, but I'm not certain
<slangasek> cjwatson: ok
<seb128> slangasek: the one I got when clicking in the url in the first ubiquity screen
<seb128> slangasek: they are similar to http://www.ubuntu.com/testing/hardy/beta
<pitti> \sh: done
<\sh> pitti, thx :)
<seb128> slangasek: I rebooted since and didn't note the url though
<slangasek> seb128: oh, well, those are old and don't apply anymore anyway :)
<cjwatson> seb128: probably identical to that, it's a central redirect
<cjwatson> it gets updated around the same time as the images are released
 * \sh heads home now...
<cjwatson> soren: upstream recommends 32-bit. at one point there was an attempt to build 64-bit grub on amd64, but it broke (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=244498)
<ubotu> Debian bug 244498 in binutils "absolute objcopy not working on amd64?" [Normal,Open]
<pitti> lool, StevenK: http://people.ubuntu.com/~ubuntu-archive/testing/hardy_probs.html has some remaining mobile stuff; any idea?
<cjwatson> soren: plus, y'know, it's been working this way for years
<soren> cjwatson: Sure.
<soren> *shrug*
<pitti> lool, StevenK: h-control-panel is FTBS on amd64, and hildon-desktop is certainly a consequence of that
<lamont> why is it that shortly after I iconify firefox, it uniconifies itself?
<mdz> lamont: because it has a modal dialog open somewhere
<mdz> lamont: click on it on the window list a couple of times
<ogra> lamont, or you have horizontal scrolling enabled for your touchpad
<lamont> had just done a text search in the window before I iconified it...
<lool> pitti: marquee-plugins is uninstallable because of hildon-desktop packages which aren't installable because of pending promotions
<ogra> (happens to me all teh time if my mouse is over the tasklist)
<pitti> lool: oh, what is it blocking on?
<lamont> then again, more and more crap is deciding that it should steal focus... about to the point to have me hack over X to deny all comers
<lool> pitti: I think only mobile-basic-flash is missing; it needed to move to xulrunner 1.9
<lool> pitti: asac and StevenK were working on it
<pitti> lool: ah, cool; merci!
<ogra> lamont, devilspie ftw
<StevenK> It's uploaded
<lamont> and I still need to find where compiz does it's focus-follows-mouse and teach it about 'strict'
<ogra> (i dont think that works with compiz though)
<lamont> compiz has it's own rules
<StevenK> mobile-basic-flash with xulrunner 1.9 should be in the archive
<slangasek> cody-somerville: ping
<pitti> ScottK, Hobbsee: ok to sync http://packages.qa.debian.org/p/python-omniorb.html and remove python-omniorb2? the latter is uninstallable and FTBFS in hardy
<cody-somerville> sladen, pong
<cody-somerville> erm
<cody-somerville> slangasek, pong
<slangasek> cody-somerville: hi, is there any sort of Xubuntu release announcement in the making?  Something I should link to from my mail?
<cody-somerville> slangasek, Yes there is.
<cody-somerville> slangasek, Jim Campbell has the details
<Hobbsee> pitti: i trust your judgement
<Hobbsee> pitti: so yes
<pitti> Hobbsee: well, it can hardly become more broken, but I want to keep to the protocol :)
<Hobbsee> pitti: hehe
<Hobbsee> eyah
<slangasek> cody-somerville: is Jim around?  He doesn't appear to be on-channel
<cody-somerville> He doesn't appear on at the moment. When do you plan to send the e-mail?
<slangasek> cody-somerville: within the half-hour
<cody-somerville> slangasek, https://wiki.ubuntu.com/HardyHeron/RC/Xubuntu
<Adri2000> pitti: is there a langpack upload planned before final release?
<pitti> Adri2000: yes, I have one built and ready for upload
<pitti> Adri2000: I'll upload it as soon as slangasek asks me to pull the trigger
<slangasek> cody-somerville: ouch, this content looks almost exactly like the Ubuntu one?
<slangasek> ... and images are missing
<cody-somerville> slangasek, I have someone working on that.
<Adri2000> pitti: :( I hoped I had enough time to fix tasks (generate pot file) and ask someone to approve the translations waiting in the review queue, but well, that'll wait for a post-release update then
<pitti> Adri2000: there is always -updates :)
<pitti> slangasek: actually, what's the chance of re-rolling the images now? if it's 0, I could just as well start the langpack flood?
<slangasek> pitti: 0
<seb128> pitti: any opinion on bug #214905?
<ubotu> Launchpad bug 214905 in swfdec0.6 "update swfdec to 0.6.4 version (local file access via remote flash file)" [Undecided,Confirmed] https://launchpad.net/bugs/214905
<mvo> Riddell: I fixed the data-extractor now and it extracts now both kde3 and kde4 desktop files, if we choose which to include (or just include both)
<Adri2000> pitti: for the langpacks sure, but I'll try to get the fixed tasks uploaded before release, to avoid all the sru process
<mvo> Riddell: let me know what you prefer, the extraction is not finished yet, but it looks good so far
<pitti> slangasek: ok, I'll start it then; it will take some hours to get them all uploaded and accepted from the queue anyway
<Riddell> mvo: can KDE 4 ones be marked in some way?  adding "(KDE 4)" to the end of the Name= ?
<seb128> pitti: any objection if I just sync it and swfdec-gnome from debian?
<mvo> Riddell: yeah, that should be possible
<Riddell> mvo: that would be good to have both but KDE 4 ones marked like that
<mvo> Riddell: ok, I check that out when the extraction is finished, it should be straightforward
<pitti> seb128: looks fine to me, but that needs ~motu-release approval -> Hobbsee, ScottK, sistpoty
<seb128> pitti: swfdec-gnome is part of GNOME so it has technically a standing exception and I'll claim that's a depends and sync it too I think
<Hobbsee> seb128: pitti, fine by me
<seb128> Hobbsee: thanks!
<Hobbsee> seb128: y/w
<Pici> Has the RC been released or are things still pending?
<slangasek> it's in the process of being released
<Pici> Okay, I'll just tell people 'soon'
<pitti> seb128: shall I sync or are you?
<seb128> pitti: I'll, just checking it builds fine etc on hardy before
<pitti> seb128: thanks
 * seb128 hugs pitti
<_MMA_> Riddell: Did xdg-user-dirs get moved around again? It's getting pulled in as a result of Studio using Rosegarden which pulls QT/KDE/whatever libs. I thought you moved that around? I remember there was some KDE bug involved also.
<Riddell> _MMA_: kdelibs4c2a depends on it
<_MMA_> Riddell: nm. I think I just tracked it to something else.
* slangasek changed the topic of #ubuntu-devel to: Archive: frozen like a penguin paradise | Ubuntu 8.04 LTS RC released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<LaserJock> \o/
 * mvo hugs slangasek
<laga> yay
<james_w> thanks slangasek
<MRutter> yay
<psyke83> asac, is bug 192888 considered fixed, or are you still considering nspluginwrapper for all archs? The bug is now marked fix released and no longer on the milestone list
<ubotu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents" [High,Confirmed] https://launchpad.net/bugs/192888
<asac> psyke83: no that was a typo. i ment intrepid. that bug is only fixed for flashplugin-nonfree task
<psyke83> asac, ah ok... that's unfortunate
<seb128> slangasek: good work ;-)
<slangasek> seb128: you too!
<wasabi> There a macro for a debian/control file to refer to the current package versioN/
<wasabi> So I can have one binary package depend on another in the same source file exactly?
<pitti> lamont: your postfix upload does not have bug#s; where should I look for the approval stuff, etc.?
<lamont> pitti: diff of HISTORY, I expect.  let me go dig it up for you
<pitti> lamont: I meant LP bug numbers
<lamont> not sure any were filed... it started as mdz mail from the u-d mailing list, iirc
<pitti> seb128: gtk+2.0 upload does not have a LP#?
<pitti> lamont: did you get slangasek's ok for that?
<lamont> I ran the HISTORY diff past him and such, yes/
<pitti> ok
<lamont> and he at least did the hand-wavy thing
<seb128> pitti: is that required?
<pitti> thanks
<seb128> pitti: I can file bugs and add numbers to changelog if you want
 * lamont is also highly interested in knowing when update-manager is published
<pitti> seb128: well, it's better to have it in the changelog for me to find the RM acks
<pitti> seb128: I'm fine with getting pointed to them via other means, of course
<seb128> pitti: there is no ack?
<pitti> seb128: how should I know, without bug numbers? :-)
<seb128> pitti: I though uploading fix was still allowed and than you guys were reviweing things in the queue
<seb128> pitti: well, there is a changelog? ;-)
<ogra> mvo, i have a bunch of reports from some people that suddenly tftpd-hpa doesnt add itself to inetd.conf anymore, could that be caused by your changes ? (essentially the ones that install ltsp-server-standalone)
<seb128> pitti: I didn't ask for any approval before uploading this one, just fixed some issues and uploaded as usual
<mvo> ogra: did I touch that package? let me look
<seb128> pitti: the current -dbg is not working and one svn change was backported wrongly some time ago, the upload fixes those issues
<ogra> the last two changelog entries are yours
<ogra> i cant reproduce it though
<ogra> but heard it wice now
<ogra> *twice
 * mvo checks
<mvo> ogra: is there a bugnumber?
<ogra> mvo, i dont think so
<mvo> ogra: it asks a debconf question if it should add itself to inetd or not: db_get tftpd-hpa/use_inetd  - strange, it defaults to true (and is asked with medium priority)
<ogra> yeah, it shouldnt ask and just go to inetd
<ogra> i dont really understand whats wrong there, but will investigate further
<mvo> ogra: could you ask him to run the postinst with "sh -ex /v/l/d/i/tftpd-hpa.postinst configure" ?
<mvo> maybe that gives us a clue
<ogra> mvo, he's gone from #ltsp, but i wil do if he comes back
<seb128> pitti: sorry if that's not clear from the changelog upload, I'm not sure if I included the previous debian one in the .changes, they fixed the -dbg to have the correct symbols (it was built using the udeb) and a patch backported incorrectly, I just used the new revision and reapplied ubuntu changes
<pitti> seb128: (previous changelog -> no)
<mvo> ogra: ok, let me know if I can help further
<pitti> seb128: I'll have a look; thanks
<ogra> mvo, will do
<seb128> pitti: there is no ubuntu bugs about those issues, I've just been following the debian discussion and though those would be nice to get for hardy
 * pitti accepts {gtk,gnome}-sharp to finall get this 'crash on exit' issue fixed
<seb128> pitti: you are welcome
<pitti> seb128: are you running that version on your box?
<seb128> pitti: yes
 * pitti accepts the new langpacks, too
<seb128> pitti: the patch change is a 1 liner and the dbg fix is just a dh_strip calls change in the debian rules, that should cause no issues
<pitti> seb128: right, looks trivial; accepting
<seb128> thanks
<pitti> lamont: ok if I ditch your bzr 1.3.1-1build1 upload and sync from Debian instead?
 * pitti just does
<evand> Now that the RC is out, can someone approve partman-base 114ubuntu5?
<W8TAH> good afternoon - a quick question if i may, is the 8.04LTS release candidate suitable for use in production?
<realist> Depends what kind of shop you're running.
<W8TAH> laptop and a couple samba severs
<W8TAH> school
<W8TAH> the sambas will be new builds
<W8TAH> laptop has been running beta for several weeks
<W8TAH> and keepign up to date on the updates to beta
<W8TAH> ??
<james_w> W8TAH: if you are running the beta then the release candidate should be better than what you have
<W8TAH> sweet
<james_w> if you've been keeping up to date though then you will have something close to the release candidate
<james_w> if you update again now you will have it.
<W8TAH> ok - cool
<W8TAH> ok
<W8TAH> no need for an iso / re-install?
<james_w> W8TAH: you shouldn't need to re-install
<slytherin> Hi, does anyone have any idea if it is worth upgrading bluez-utils to latest version (3.30)?
<W8TAH> thanks james_w
<W8TAH> i'll pull the iso for my servers but thats cuz they are new builds
<Keybuk> cjwatson: around?
<xhaker> mvo: on hardy's update-manager, release upgrade is set to show only new LTS releases. is it the right setting?
<seb128> Keybuk: he's away for the weekend
<W8TAH> james_w, ok - ive got a dist-upgrade running on my laptop and im downloading the iso for the servers -- easy jump to final when the time comes?
<mvo> xhaker: I think it is, we had a similar policy for dapper
<seb128> Keybuk: that's from what he wrote one hour ago
<mvo> (explicit opt-in for edgy)
<Keybuk> seb128: ah, thanks
<seb128> Keybuk: you are welcome
<xhaker> mvo: ok, asked just to be sure. I agree.
<mvo> ok, thanks xhaker
 * Keybuk goes back to attacking D-Bus with an axe (and valgrind)
<ion_> keybuk: Are you sure you donât need the BFG?
<W8TAH> BFG = Big friendly Gun?
<ion_> Yeah
<W8TAH> grin
<Keybuk> ion_: maybe, twelve "invalid read of size N" (overflow), six "read of freed block", and about twenty "still reachable"
<ion_> keybuk: The dbus devs didnât feel like valgrinding in the first place? :-)
<Keybuk> ion_: certainly not the bits I seem to touch ;P
<slytherin> Considering that we are in final freeze, any idea if the latest bluez-utils is worth the upgrade?
<xhaker> slytherin: my guess would no. the things entering the main repositories now would be patches, no new versions
<Whoopie> seb128: hi, I fixed the hibernate issue in the gdm menu. could you have a look at my patch at launchpad bug 208136 ? thanks in advance.
<ubotu> Launchpad bug 208136 in gdm "system cannot hibernate with GDM" [Undecided,New] https://launchpad.net/bugs/208136
<seb128> Whoopie: I'm not sure to understand the greeter_item.c changes
<seb128> -        strcmp (info->show_type, "timed") == 0))
<seb128> +        strcmp (info->show_type, "suspend") == 0))
<seb128> why this one?
<seb128> +   if (info->show_type != NULL &&
<seb128> +       sscanf (info->show_type, "custom_cmd%d", &i) == 1 &&
<seb128> and that?
<seb128> otherwise the other changes seems good
<seb128> also the changelog entry is not verbose enough, you should mention the patch changed and the bug number
<Whoopie> seb128: looking at the suspend part in greeter_item.c, I just adapted it to the hibernate part. it's just a "cleanup". re changelog, ok, I'll change.
<soren> I thought seahorse-agent was all that was needed to get the pop-up-asking-for-passphrase-for-ssh-keys thing when you tried ssh'ing for the first time after logging in? I just tried it under Xubuntu, and it prompts me on the command line.
<ogra> seb128, i lied yesterday, when i tried gtk-demo there was a tracker running for root already, when i shot that down gtk-.demo showed the same behavior
<ogra> so its definately the filechoser
<slytherin> soren: I think you need ssh-askpass-gnome
<slytherin> soren: No, wait, seahorse asks me for ssh password.
<slytherin> damn I am confused.
<seb128> Whoopie: ok, thanks for the work on it
<seb128> ogra: ok, makes sense
<seb128> Whoopie: did you try and verify it's fixing the issue?
<Whoopie> seb128: yes, as I'm not experienced enough in coding, I had to test. :)
<Whoopie> seb128: is that changelog ok?
<Whoopie> +  * changed debian/patches/11_powermanagement.patch to fix hibernate
<Whoopie> +    button in the GDM menu (lp: #208136).
<munckfish> cjwatson: got a sec?
<crimsun> asac: I don't understand your "rationale" question.  The point is to prevent breakage upon dist-upgrades for people who have manually configured ALSA settings in non-GStreamer apps.
<soren> munckfish: cjwatson's not around.
<munckfish> soren: ok thx
<munckfish> do you know when he will be?
<ogra> munckfish, and is unlikely to return before monday
<munckfish> aha ok
<Whoopie> seb128: btw, the fix is the same as for suspend which was fixed some time ago upstream. gnome bug 500362
<ubotu> Gnome bug 500362 in general "Suspend button does not work" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=500362
<crimsun> asac: while shipping Hardy's current PA package won't cause hellfire, it will present interesting (more) usability problems for people expecting to use Flash in $web_browser and play their favourite audio app (regardless what audio backend said app uses).
<munckfish> If I try do-release-upgrade on gutsy powerpc is it going to do the 'right thing' just now to get me to the hardy port? Taking into account the new apt source url for these sort of ports?
<ogra> munckfish, probably mvo could answer that (he doesnt do ppc but the release upgrader)
<munckfish> ogra: thx
<munckfish> mvo: got a sec?
<soren> update-manager (1:0.66) gutsy; urgency=low
<soren> * DistUpgrade/DistUpgradeControler.py:
<soren>     - transition powerpc users to ports.ubuntu.com
<soren> munckfish: ^^
<soren>  -- Michael Vogt <michael.vogt@ubuntu.com>  Tue, 10 Jul 2007 10:57:02 +0100
<munckfish> aha soren thx
<soren> np :)
<munckfish> I should have checked that, sorry I'm being pedestrian :(
<munckfish> tgif
<seb128> Whoopie: yes, the new changelog description is better, thanks
<seb128> Whoopie: right, those are the part which made sense to me, I'll have to check again the cleanup part and whether it's required or not
<mvo> munckfish: hello! please let me know if it works as expected :)
<munckfish> mvo: hi, actually I'm living slightly more dangerously than just powerpc, I'm working PS3
<munckfish> I just can't debug properly with live CD so looking to find the best way to upgrade my system so I can debug
<munckfish> did you make any PS3 specific changes too?
<mvo> munckfish: there is currently nothing ps3 specific in the upgrader, a ppc bug got fixed in 1:0.87.21, let me check if that one is build/published yet
<munckfish> ok thx
<mvo> munckfish: nevermind, the bugfix only affected dapper->hardy
<munckfish> mvo: ok thx
<munckfish> the only issue I'm aware of at the moment is no
<ion_> Will apport be disabled for the release?
<munckfish> transition package from ps3-cell kernel to straight powerpc kernel which will be used in hardy
<munckfish> I'm hoping that's the only real obstacle I'll meet
<Whoopie> seb128: the cleanup part doesn't hurt as the hibernate part is now the same as the suspend part. -> from the patched greeter_item.c: http://pastebin.com/d2925bd32
<mvo> munckfish: if you tell me the name of the old kernel package and the name of the new one, I can fix that
<munckfish> ah ok
<norsetto> is there a way to rebuild about 100 packages in a go?
<munckfish> mvo: I'll get back to you on that
<mvo> munckfish: great, thanks
<emgent> heya people
<blueyed> pitti: if I understand correctly, picking up crash files should be enabled in adept, so that it "just works", when apport gets enabled, correct? (your changelog entry assumes that adept is picking crashes up by default, which it is not)
<DB42> https://bugs.launchpad.net/ubuntu/+bug/219268
<ubotu> Launchpad bug 219268 in ubuntu "iwl3945 doesn't work with my wifi card (ipw3945 did)" [Undecided,New]
<beuno> DB42, there is a known bug with wifi card on upgrading
<DB42> is it that one ?
<beuno> DB42, nope, let me find it for you
<DB42> is it related at all ?
<beuno> DB42, I believe one of them is bug 185470
<ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] https://launchpad.net/bugs/185470
<beuno> which propose a few workarounds
<blueyed> pitti: just found your comment about it in the adept bug. so, it's fine. We'll enable picking up crashes in adept.
<DB42> beuno: thanks, reading
<DB42> beuno: i'll try it soon enough and report back
<beuno> DB42, right, thanks, but, please, in a different channel, as this one isn't for support  :)
<DB42> ok :) altough this is a bug not support :)
<beuno> isn't everything a bug?  :p
<Keybuk> pitti: around?
<seb128> Keybuk: he left for the weekend some hours ago
<Keybuk> bah
<Skiessi> libsamplerate could be updated to 0.1.3
<Skiessi> at least in ibex
<rutter> hey, is the  alt RC CD meant to make the ext3 parition a logical parition? I always thought the primary was meant to be a well primary parition
<rutter> nm
<LaserJock> does Network Manager use wpa_supplicant?
<slangasek> if you're doing things that require supplicating, yes
<LaserJock> k
<laga> slangasek: since you're off-duty: please ignore my request to merge r1300 from http://bazaar.launchpad.net/~mythbuntu/debian-cd/mythbuntu-debiancd till tomorrow ;)
<mroth> what is the proper component to file a bug related to the standard file open dialog?
<macogw> is it a bug that there is no linux-ubuntu-modules virtual package?  i have to manually install l-u-m after each kernel update in hardy, and that seems like a bug.
<macogw> it could also be some design decision that i dont understand, so i figured i'd ask
<laga> macogw: do you have linux-image-generic installed?
<macogw> i just went to look and it's no longer installed for some reason
<laga> it should be installed :)
<macogw> maybe when packages were being held back some time it went poof.... *shrug* sorry
<laga> it'd be interesting to know why it went missing
<macogw> perhaps removing l-r-m did it?
<macogw> its not a direct dependency though
<laga> yeah, not right now at least
#ubuntu-devel 2008-04-19
<kees> mvo: say, I was just doing a gutsy->hardy upgrade (in kvm) and didn't have enough disk space.  each time I made enough room, the next run of update-manager claimed to need more space than before.  I've since started tracking the log output, and I'll file a bug report for it, but was curious if you'd seen anything like that before?
<mvo> kees: no, suprisingly little bugreport from the space calculator (I guess everybody has 750gb hdds there days :P) - how much do you free? is that a complicated setup with lots of partions?
<kees> mvo: nope, just 1 partition for everything.  I think the issue is that it aborts immediately, rather than finishing all the calculations?
<mvo> kees: that sounds plausible
<kees> mvo: yeah, that seems to be it.  in the fail-cases, it would examine /var/cache/... then /usr and fail with an ever-growing "need" value.  in the final success case checks /var/cache/..., /usr, /usr again (?), /boot, and /
<mvo> kees: right, makes sense. please file a bug and tag it later, I will try to attack it early. or do you think we should fix it for hardy?
<mvo> kees: it checks /usr twice for simplicity reasons (once for real, once with some safety buffer)
<kees> mvo: it's not a show-stopper, but it was a bit of a head-scratcher.  "what? you need MORE space now?" after I cleaned up how much it wanted.  ;)
<kees> I'll tag it later.  :)
<mvo> kees: ok, I'm too tired to look into it now, but if its a one-liner patch, we can try to sneak it past
<kees> mvo: sure, no problem.  I wasn't actually expecting you to answer right now.  :)
<mvo> kees: still some loose ends that needs attention here and there, but I should go to bed soonish
<crimsun> asac: I believe https://bugs.launchpad.net/ubuntu/hardy/+source/libflashsupport/+bug/192888/comments/75 addresses your rationale question.
<Caesar> Umm, so it seems that update-manager-core is at 1:0.87.21 but update-manager is at 1:0.87.18
<Caesar> How does that even happen?
 * Caesar pokes at Launchpad
<slangasek> Caesar: 1) upload 500 arch: all langpacks for rebuild, swamping the i386 buildd; 2) upload update-manager, which builds arch: any and arch: all packages; 3) run amd64
<Caesar> That'll do it
<Caesar> slangasek: packages will go in with unmet dependencies post-build though?
<slangasek> yes
<slangasek> there's no check for installability at binary accept time
<Caesar> slangasek: that seems like a bug to me
<slangasek> well, enforcing installability at binary accept time would be a good way to deadlock development
<Fujitsu> It'd make transitions completely impossible.
<slangasek> it's annoying that we have langpacks ahead of update-manager in the build queue, and that's certainly a bug
<slangasek> (doubly annoying that it's been done right after RC, so people are going to see partial-upgrade issues until it clears)
<Caesar> We were just questioning the whole point of a RC that then subsequently gets upgraded
<Caesar> It makes all milestones very ephemeral
<Fujitsu> Aren't langpacks meant to be built on PPAs.
<Fujitsu> *?
<Fujitsu> Caesar: You haven't seen an RC that isn't an RC until you've seen MPlayer RCs.
<slangasek> Fujitsu: langpacks are part of the archive, so no?
<Fujitsu> slangasek: They're built in PPAs and binary-copied for every other release - why not Hardy?
<slangasek> they are?
<Fujitsu> They are.
<Fujitsu> Or we'd be utterly screwed.
<Caesar> Fujitsu: but a RC for a single piece of software is versioned and static, whereas a milestone for Ubuntu is only current until someone makes an upload, or you don't point it at an external repository
<slangasek> Fujitsu: well, this must be a fairly new innovation, seeing how PPAs have only been around for about a release cycle
<Fujitsu> slangasek: Correct.
<Caesar> slangasek: could the building of arch: all packages be load-balanced across all architecture buildds?
<Fujitsu> I think you just gave cprov a heart attack.
<slangasek> Caesar: in theory it could; you would basically have to set up a whole set of secondary queues though, to tell the buildds whether or not they're expected to build with -B or -b
<slangasek> Caesar: and then you have the fun of finding out at random which arch: all packages are only buildable on i386
<Caesar> slangasek: that'd help flush out some bugs wouldn't it?
<slangasek> nah, it would just cause more build failures of the sort plaguing openhackware; there are packages that need to build as arch: all, but simply require a toolchain for one particular arch to do their building
<slangasek> and up to now, it's been safe to assume that this will work when that "one particular arch" is i386
<slangasek> anyway - it wouldn't be impossible to load balance them better, but giving langpacks a lower build priority would seem to address the issue more directly
<slangasek> since it's the only thing we have that causes a batch of arch: all packages to flood the buildds and cause vastly disparate times-to-build between different archs
<Fujitsu> Except for the initial autosync, but only a few people use it in the first couple of weeks of the cycle.
<slangasek> sure
<nxvl> bdmurray: around?
<TheMuso> crimsun: I thought pulseaudio_dmix == bad;
<TheMuso> s/pulseaudio_dmix/pulseaudio + dmix/
<bdmurray> nxvl: I am now
<crimsun> TheMuso: well, yes, it certainly isn't optimal.  However, is having it grab the raw hardware worth the regressions?
<TheMuso> crimsun: Thats what I've started thinking lately myself.
<lamont> interestingly, hardy does _OK_ on a P2-233 with 192MB of RAMand a 6GB HDD
<jdong> lamont: not too surprised
<jdong> I'm playing FreeBSD BDSM right now
<jdong> with a 48MiB RAM VM
<lamont> it's the print server for the house
<tuntun> Why on earth do I have do a search for file 'foo' before I get the chance to configure the search?!?!
<tuntun> Main-menu > Accessories > Tracker-Search-Tool   ...Who the hell thought that It would be a good idea to only let the user configure the search after having done a first search?!?!
<beuno> why am I seing double?
<tuntun> Main-menu > Accessories > Tracker-Search-Tool   ...Oh great... And it it only searches within the home dir...without even telling you!!! This is turning into a farce...
 * lamont looks around for someone who loves hacking on compiz
 * lamont is reminded of just how thoroughly he hates quilt and all of its ilk
<salty-horse> bryce, here?
* elmo changed the topic of #ubuntu-devel to: Reduced buildd service till 3pm UTC due to power outage || Archive: frozen like a penguin paradise | Ubuntu 8.04 LTS RC released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/H
<jpatrick> elmo: I think a bit got cut off at the end
<elmo> jpatrick: it did, but my bit is at the front ;-)
<elmo> jpatrick: I'll restore the end when I take it out
<Idan> Hey all, God a question about version numbers... If I recall correctly older version of Ubuntu (5.04, 5.10) wouldn't change the version numbers of software after release, I noticed that in 7.10 (can't remember other ones), the version numbers did change, for example Firefox 2.0.x
<Idan> God=Got
<Idan> Anyone here?
<jpatrick> elmo: yes, yours is far more important ;)
<Fujitsu> Idan: In very few circumstances will new versions be uploaded.
<Fujitsu> Firefox is one of those.
<asac> crimsun: so if i understand this correct, this pulseaudio change should have been done right from the beginning?
<asac> TheMuso: could you please look at the latest patch in bug 192888?
<ubotu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents" [High,Confirmed] https://launchpad.net/bugs/192888
<ogra> asac, i'm running it like that since last night (when i saw crimsuns ping)
<asac> ogra: where is that config file? i don't have that ;)
<ogra> sound seems to be good here but it will likely not work on all non dmix capable cards
<ogra> and somehow fullscreen mode for flash movies flips immediately back to win mode now (might not be related)
<asac> ogra: "Applying it makes pulseaudio use the 'default' ALSA virtual device, which is dmixed and dsnooped for nearly all audio cards"
<ogra> aa/etc/pulse/default.pa
<ogra> oops
<ogra>  /etc/pulse/default.pa
<asac> ogra: i see that path, but i don't have it ;)
<ogra> but you have pulse installed ?
<asac> i only have client.conf in there
<ogra> th epulse server package creates it iirc
<ogra> ogra@osiris:~$ dpkg -S /etc/pulse/default.pa
<ogra> pulseaudio: /etc/pulse/default.pa
<ogra> the fulscreen thing is worrying
<asac> oh i think on this machine really removed it at some point ;)
<asac> ogra: so why would a virtual also device break anywhere?
<ogra> ??
<ogra> why should it ?
<ogra> you mean dmix
<ogra> i think
<asac> ogra: what does dmix do?
<ogra> err, why doesnt FF allow me to put search termes into the url field ??
<asac> isn't that a software layer?
<ogra> XML-Verarbeitungsfehler: Fehler beim Verarbeiten einer Referenz auf eine externe EntitÃ¤t
<ogra> Adresse: jar:file:///usr/lib/xulrunner-1.9b5/chrome/toolkit.jar!/content/global/netError.xhtml
<ogra> Zeile Nr. 10, Spalte 3:  %netErrorDTD;
<ogra> --^
<ogra> meh
<ogra> grr
<asac> ogra: yeah langpack bustage
<ogra> ah
<asac> error page is currently broken
<ogra> afaik older cards (typically sb driver) dont support it
<asac> so dmix does hardware mixing?
<ogra> http://alsa.opensrc.org/index.php/FAQ#What.27s_all_this_dmix.2Fdshare.2Fdsnoop.2Fasym_stuff.3F_How_does_it_work.3F
<ogra> no
<ogra> but afaik you need a certain amount of channels to plug dmix on top
<asac> crimsun: ^^ could you comment on this?
<ogra> and things like esd apps will be able to hog the device directly
<ogra> or libesd
<ogra> i know pitti did some deep research some releases ago
<asac> yeah, but maybe thats outdated now
<asac> at least the tiny details :)
<ogra> well, we're discussing principles and processes, not details atm :)
<asac> ogra: NOTE: For ALSA 1.0.9rc2 and higher you don't need to setup dmix. Dmix is enabled as default for soundcards which don't support hw mixing.
<asac>  * requires creation of a virtual slave device
<asac> http://alsa.opensrc.org/index.php/Dmix
 * ogra reads
<asac> for me this sounds like dmix was created for devices that are dump :)
<asac> dumb
<ogra> right
<asac> yeah ... so why would this "new" virtual alsa device break for some cards?
<ogra> so you want to default to asoundrc for that ?
<ogra> as i understood it in the past you need a certain amount of channels to have a dmix capable card which isnt the case for very old HW
<ogra> (soundblaster 16capable cards)
<ogra> but that might be outdated info
<asac> ogra: yes right, but i don't see that anywhere on that dmix page :(
<ogra> i'm probably behind wih my knowledge
<ogra> but even then that looks quite horrible to get right in the asoundrc
<asac> ogra: i don't want users to be required to edit their own asoundrc ... thats for sure
<ogra> especully tha "KDE - Still Hearing Stuttering? " part
<ogra> i'm a bit scared
<ogra> there are o many options and it doesnt look like there is a common reciepe that works with all aps and in all cases
<ogra> *apps
<ogra> we only have until wednesday
<laga> what was the situation regarding dmix before pulseaudio?
<laga> eg in 7.10
<asac> i don't know ... actually i don't think that its a regression that sound is not working :)
<ogra> its enabled by default in the modules, i think that wasnt different in gutsy
<ogra> the configuration is the prob
<asac> i never could play multiple streams from multiple apps out of the box here at least
<ogra> sound is working everywhere
<laga> asac: oh, that's sad. that has always worked for me
<ogra> apart from flash under certain circumstances
<asac> well, in the past i had to disable ESD because soudn wasn't working properly.
<ogra> asac, upgraded or plain hardy install ?
<laga> sound servers are evil anyways. (imho)
<ogra> my laptop has a two week old install and worked just fine from the beginning
<asac> ogra: read above ... i talked about regressions ;)
<ogra> (apart from teh flash issue)
<asac> before hardy it was always not really working here
<ogra> well, pulse is classes better indeed
<asac> right, but we need to care for apps that don't use pulse as well
<ogra> but imho we should revert to gutsy setup
<ogra> the puse setup we have atm wasnt really deeply looked at
<ogra> *nobody* during this cycle did *any* sound research
<ogra> we just blindly dumped in pulse as replacemet for esd
<asac> yeah ... and we got plenty of changed software
<ogra> gutsy is known to work ....
<ogra> or at least has *known* bugs
<asac> ogra: known to work for whom? for me it didn't work well ... but thats what i say, if really dumb cards stop working that didn't work in gutsy, then its not a regression IMO
<asac> but making flash have no sound for setups that previously had sound is pretty bad :/
<ogra> well, for me it always worked, ,i never had sound probs on any HW with an ubuntu over here ... but then i only use default apps
<ogra> *any Ubuntu
<ogra> (and pulse on my ltsp terminals)
<ogra> (since edgy)
<ogra> with a virtual asla device on top
<ogra> *alsa
<ogra> which i would suggest for us here as well, but that brings libflashsupport back into the loop
<asac> ogra: but isn't that exactly what crimsun suggests?
<ogra> which we dont want
<ogra> no
<asac> no we cannot use libflashsupport, please scratch that
<ogra> my setup is the other way round (and pulse isnt running in the user session)
<ogra> pulse is just providin the network port on my clients, in the session there is an asoundrc that defines a virtual alsa device connecting to the network port pulse offers on the client
<ogra> asac, everything wil work fie without any soundserver .... apart fro login and logout sounds
<ogra> and gnome event sounds (which we dont enable at all)
<ogra> pitti had a hack to gnome_sound_play in the past that made it use alsa in the back
<ogra> which worked fine for only login/out sounds but started to stutter if other sounds are played
<asac> ogra: yeah so lets kick pulse :)
<ogra> and lose login/out sounds ?
<asac> use gnome_sound_play hack?
<ogra> ask pitti about it how sane it is
<jeromeg> asac: that would be funny as pulseaudio has been advertised as one of the major new feautres of hardy
<ogra> in any case we need a spec for intrepid
<ogra> jeromeg, and ?
<ogra> we can change that
<laga> change it 5 days before release?
<ogra> laga, vs releasing with boken sound and no flash sound support ?
<jeromeg> ogra: I personally don't care, but changing things that have been planned for 6 monthes 5 days before the release looks weird to me
<ogra> jeromeg, the pro is that it wasnt planned
<ogra> we blindly followed upstream
<jeromeg> upstream ?
<asac> gnome
<ogra> relying on the fact that they know what they do and that it just works
<jeromeg> ok
<ogra> which it doesnt
<asac> ogra: so whats bad about crimsums suggestion? that it breaks old cards? whatelse? is there stuttering?
<ogra> no here, no
<ogra> i dont know where that fullscreen issue comes from
<ogra> i discovered it before going to bed last night, need to check that more
<ogra> s*not here
<ogra> it might break ltsp if we go with a per user asoundrc
<ogra> so that must be a global setup
<ogra> asac, given that crimsun is the most knowledgeable person here i tend to trus his expertise
<ogra> especially with the coments about the upgrade scenarios
<asac> ogra: fulll screen issue?
<ogra> i cant switch flash videos to fullscreen
<ogra> they snap back after a second
<asac> ogra: i am currently testing that setup and what i see is that videos dont run as swift as they should when i play flash in the background
<laga> i wonder why a change in sound setup would break fullscreen mode of adobe's crapware. ogra, steps to reproduce?
<asac> i doubt it does
<ogra> laga, apply the pulse change (i rebooted then to make sure to have a clean system) swithca flesh movie in youtube to fullscreen while playing
<ogra> asac, well, it started to show up after i made the pulse change to test it
<asac> ogra: works here :)
<asac> and i have a huge screen here ;)
<ogra> weird
<ogra> works here as well now
<asac> good :)
<ogra> i wonder wat that was
<ogra> it flipped back immediately after the "perss esc to leave fullscreen" mgs disapeared
<ogra> *press
<ogra> asac, upload it then
 * ogra is hoping for a fixed libflashsupport for 8.04.1 anyway .... 
<ogra> ltsp doesnt leave me a big choice here
<laga> why does http://www.ubuntu.com/community/ubuntustory/components say that main contains non-free components? does that make sense when they could just be shoved into restricted?
<ogra> laga, firmware
<laga> ogra: isn't that usually in l-r-m?
<ogra> The licences for software applications in main must be free, but main may also may contain binary firmware and selected fonts that cannot be modified without permission from their authors. In all cases redistribution is unencumbered.
<ogra> intel drivers are 100% free but the firmware still eeds to be a binary blob
<ogra> for example
<laga> ogra: i've always thought of main as a set of software i can modify the way i want and redistribute them freely, w/o having to be careful with the license. i guess i was wrong
<laga> oh well, i'm not going to do modify firmware anyways
<ogra> laga, thats gobuntu :)
<laga> heh
<ogra> ubuntu has the commitment to make HW work where possible ....
<laga> ogra: yes, and l-r-m plays an important role there. looking at l-r-m, it also contains a lot of firmware for DVB devices (where the drivers are free), so i don't see why some firmware gets the special 'main' treatment. are there some substantial differences in the license of those blobs?
<ogra> i'd guess so
<ogra> i'm by no means a licensing expert :) i trust our archive admins here
<laga> neither am i.
<laga> i talked to the gobuntu guys once  and they even removed init routines in some dvb drivers which upload a few bytes of binary stuff
<ogra> yeah
<ogra> asac, oh, btw did you test sound recording and input methods with the change ? would be odd if microphones stopped working
<ogra> (hardy is teh first time i had a working mic out of teh box right after install on any of my ubuntu machines)
<asac> ogra: i am completely the wrong person to deal with this i guess :) .. i don't even have a microphone ;)
<ogra> you have a laptop
<asac> hmm ... the old one i had never had working sound (except with debian etch)
<ogra> perfect
<asac> the new one ... no idea if it has a mic ;)
<asac> ogra: ?
<ogra> test the old one :)
<asac> well i tested it recently ... hardy still doesn't help
<ogra> if that works the fix *must* be safe :P
<asac> hehe
<asac> yeah, but i guess sound is still not working
<ogra> sound recorder seems to work for me
<asac> ogra: i am now tuning alsamixer tMic channel ... where can i see if i get any signal?
<ogra> asac, oh, btw if ou find a chance to test the last classmate image before release that would be very appreciated (especially suspend/resume)
<asac> ah sound recorder
<ogra> you probably need to unmute the mic input
<asac> yeah did that in alsamixer
<ogra> in volume control
<ogra> and select the right input source in sound recorder
<ogra> the default often doesnt work i found
<asac> ok
<asac> no luck ;)
<asac> tried all suggested inputs
<asac> and have microphone unmuted and boosted
<asac> but thats without the changed pulseaudio thing
<ogra> check the setup in your volume control
<ogra> it often has recording sources disable you need to swithc or unmute
<asac> well. i unmuted the mic there and boosted it ... no other device offers microphone so it should be right
<ogra> i have about 10 different input devices i can enable in the voume control settings
<ogra> and i need to unmute aux alongside the mic on this machine
<asac> uaa ... i got "rueckkopplung" :)
<ogra> yay
<ogra> turn it down a bit :)
<asac> i better leave that alone :(
<laga> 'feedback loop'?
<ogra> yeah
<ogra> that means its working :)
<ogra> just to sensitive
<laga> ah, just 'feedback'
<ogra> getting that configured right will be a challenge in next ltsp release  :)
<ogra> localapps and sound capture are on my list of desired things to have for intrepid
<Hobbsee> yay, power outage.
<laga> yay, no backup generators (?)
<Hobbsee> jcastro: got time for a chat, at some point?  (not overly time critical - after release is fine)
<Hobbsee> laga: fairly safe to say that some of the machines are on
<stgraber> laga: 1/3 of the builders are still up
<laga> okay, s/no/&t enough/ ;)
<crimsun> asac: the default pulseaudio config (that grabs raw hardware directly) is preferable with the intent of having libflashsupport pulled in directly with flashplugin-nonfree
<crimsun> asac: in light of that latter change to flashplugin-nonfree, not changing the pulseaudio config to match does break existing setups
<crimsun> asac: so, no, the pulseaudio change I mentioned earlier should not have been implemented right from the start
<crimsun> asac: it is only a stop-gap measure to prevent further regressions from dapper(, edgy, feisty,) and gutsy
<Whoopie> mjg59: Hi, I have a question with ejecting the bay on my thinkpad. your implementation is now used with ata_piix and not the bay kernel module. How can I call a script to unmount the drive (hdd/cd) before ejecting?
<asac> crimsun: i tested this setup and now i have problems like the second application that uses sound stutters. do we need to tune anything else to make this behave better?
<asac> like buffers or something?
<crimsun> asac: what are the first and second applications?
<asac> crimsun: doesn't matter.. i tried 1st RB and 2nd flash ... and vice-versa
<asac> also tried totem + flash
<asac> and flash + totem :)
<crimsun> asac: well, that symptom can be worked around by manually creating an asoundrc, and it's one reason the default for PA was not to use dmix/dsnoop
<crimsun> asac: the problem is that we can't create an asoundrc for all users that will work for all audio cards
<asac> so its not buffer related?
<crimsun> asac: not necessarily buffer-related, no.
<crimsun> asac: so now that you've established that, on your setup, native ALSA and native PulseAudio stutter, can you establish that concurrent native ALSA and/or concurrent native PulseAudio also stutter?
<crimsun> (e.g., multiple instances of `aplay /usr/share/sounds/*up.wav' for the former, multiple instances of `paplay /usr/share/sounds/*up.wav' for the latter)
<asac> crimsun: can't i set alsa as output in gstreamer-properties?
<asac> and start multiple totems?
<crimsun> asac: sure, although I was attempting to eliminate the GSt layer directly for that test
<asac> ok
<asac> crimsun: multiple aplay worked fine
<asac> crimsun: actually i am not sure that the sound stuttered ... it was rather that the video got stuck
<asac> except for flash which halted completely temporarily
<asac> multiple paplay and aplay appear to work properly
<crimsun> ok, so the next step would be to use multiple gst-launch-0.10es with alsasink and pulsesink
<asac> crimsun: for pulsesink i get bad pipeline error
<asac> gst-launch-0.10 audiotestsrc ! audioconvert ! audioresample ! pulsesink
<asac> strange that it worked at all ... gstreamer pulse wasn't installed
<highvoltage> http://www.zoitz.com/archives/35
<bigon> infinity: are you around? bug 217432 has been approuved by motu-release, will you build the pkg?
<bigon> bug #217432
<ubotu> Launchpad bug 217432 in openhackware "Please sync openhackware 0.4.1-3 from debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/217432
<crimsun> asac: looks like we need to pass device explicitly for module-alsa-{sink,source} in /etc/pulse/default.pa
<asac> crimsun: which device?
<ScottK> If there are any buildd admins about ...  clamav in dapper backports just failed with "ntpdate[4480]: no server suitable for synchronization found" for powerpc, ia64, sparc, and hppa.
<ScottK> I'd appreciate a giveback or fixing the problem + a giveback as needed.
<ScottK> Looks like the same problem for Hardy too, which makes it a little more urgent ...
<laga> maybe related to the buildd outdate?
<laga> outagE*
<james_w> ScottK: it seems to be many packages then.
<ScottK> Yes.  Same 4 archs.
<ScottK> laga: What buildd outage?
<laga> Reduced buildd service till 3pm UTC due to power outage
<laga>  /topic
<ScottK> OK, except that would have been over 3 hours ago.
<laga> yeah, but i wonder why nobody reset the topic
* elmo changed the topic of #ubuntu-devel to: Archive: frozen like a penguin paradise | Ubuntu 8.04 LTS RC released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/H
<laga> ok, ok.
<elmo> ScottK: link to the failed build?
<ScottK> elmo: here's one; http://launchpadlibrarian.net/13579444/buildlog_ubuntu-dapper-hppa.clamav_0.92.1%7Edfsg2-1.1%7Edapper1_CHROOTWAIT.txt.gz
<elmo> ScottK: at the LP level, if you have it
* elmo changed the topic of #ubuntu-devel to: Archive: frozen like a penguin paradise | Ubuntu 8.04 LTS RC released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ScottK> elmo: How about https://launchpad.net/ubuntu/+source/clamav/0.92.1~dfsg2-1.1/+build/566097
<ScottK> elmo: I can give you 8 if you want it (same package on hardy and dapper-backports for 4 archs each release.
<elmo> it's fine, I'll go through the buildd history
<elmo> right, I think I've reset them all
<elmo> but I'm trying to do it through the web ui and that's pretty painful
<elmo> if I missed anything, feel free to yell
<ScottK> Thanks.
<ScottK> elmo: kde-guidance on powerpc looks to have the same problem.
<james_w> elmo: does that include other packages?
<elmo> all == all packages on all buildds
<elmo> that got bitten by the ntpdate thing
<james_w> great, thanks.
<ScottK> elmo: Great.  I'll wait a bit then and see if anything looks to be left hanging.
<ScottK> lamont: Would you have a moment to look at an hppa specific build failure?
<lamont> sure
<ScottK> It's devscripts.
<ScottK> I'm getting the build log link.
<lamont> np
<ScottK> lamont: https://launchpad.net/ubuntu/+source/devscripts/2.10.11ubuntu5/+build/564980
<lamont> ScottK: either ntp yanked time forward 2.5ish hours (doubtful), or the kernel is being pissy (quite possible), or there's a bug (not so likely)
 * lamont gives it back to see how well it does in the chompers this tiem
<ScottK> lamont: Sounds good.  The area where it failed wasn't changed in this revision.
<ScottK> Thanksd.
<ScottK> Thanks even
<lamont> and I gave it a high score, so it should be next up
<ScottK> Cool.
<lamont> if it dies again, pls tell me?
<ScottK> Will do.
<lamont> dear launchpad, why is the number of waiting builds not a link?  everything else seems to be.  kthx.
<lamont> ScottK: btw, have you run across anything that could generate realtime-ish numbers of the number of queuefiles, recipients, successes and failures on a running postfix instance?
<ScottK> lamont: No, but I haven't looked either.
<lamont> me neither
<lamont> nao I wantses one.
<mjg59> Whoopie: There'll still be an ACPI event
<mjg59> Uh. Or possibly just a uevent
<ScottK> lamont: devscripts built this time.  Thanks.
<lamont> ScottK: it may have just been ntp-pain then
<crimsun> asac: device=default
<crimsun> asac: I attached a newer patch to that bug
<infinity> bigon: Get it synced, and I'll build it on Monday.
<bigon> infinity: ok thx
<ScottK> elmo: kde-guidance 0.8.0svn20080103-0ubuntu16 in hardy on powerpc and clamav 0.92.1~dfsg2-1.1 in hardy on powerpc and ia64 are still saying chroot problem.  I don't think they got retried.
<infinity> ScottK: Given bank...
<infinity> ScottK: back, too.
<ScottK> infinity: Thanks.
<lamont> ScottK: from the "hrm... these bear looking beyond one-liners" department:
<lamont> % apt-cache search postfix| grep stat
<lamont> mailgraph - Mail statistics RRDtool frontend for Postfix
<lamont> queuegraph - a RRDtool frontend for Postfix queue-statistics
<lamont> both of which claim to do "daily, weekly, monthly, and yearly"  but I want 5 minute samples and hourly graphs as well
<lamont> SMOP
<ScottK> ? SMOP
<lamont> simple matter of programming
<infinity> Simple Matter of ...
<infinity> Yeah.
<ScottK> Yeah.
<ScottK> infinity: That got it.  They all built.  Thanks again.
<kommander> hi all :-)
<sistpoty> infinity: if you've got time for some buildd fiddling, haskell-haskell-src would need the same timout adjustments on sparc like ghc6 (it's basically the same source)... however it's imo low priority
<kommander> got a silly question ... I want to make a custom initramfs with a boot script mounting root partition as read only, then creating an union with a tmpfs and these partition which will be /
<kommander> but ... to mount a partition, I need a / which is writable ?
<kommander> this is like chicken and eggs problem
<laga> kommander: mount -n?
<kommander> hum ... interesting !
<kommander> :-)
<madmetal_spyros> hello
<madmetal_spyros> anybody to talk about hardy upgrade problems?
<ScottK> madmetal_spyros: Try #ubuntu+1
<madmetal_spyros> oke thanks ScottK !
<james_w> those with buildd powers: lvm2 on powerpc was hit by the ntpdate problem and is still in chroot wait state, could someone poke it please? https://edge.launchpad.net/ubuntu/+source/lvm2/2.02.26-1ubuntu9/+build/566009
#ubuntu-devel 2008-04-20
<Fujitsu> Will apport's upgrade failure stuff also be disabled post release?
<Fujitsu> Or just crashes?
<TheMuso_> asac: According to that bug, it doesn't work for a user.
<crimsun> TheMuso_: just asked for follow-up, thanks
<crimsun> TheMuso_: more than likely, the stale gconf config is loading the detect module that attempts hw:0 after default is opened, and that will fail.
<crimsun> s/loading/loaded by/
<TheMuso_> Right.
<emgent> heya
<crimsun> TheMuso: it appears to be a race in the load order of suspend-on-idle and alsa-sink modules
<crimsun> s/sink/source/
<TheMuso> Fun.
<Hobbsee> i'm really hating the fact that if i plug the power in when it gives me the warning about critical power, laptop will shut down if you dont' put the power in, that it just shuts down a few mins later anyway.
<Hobbsee> bah.  that sentence failed the "making sense" idea.
<Hobbsee> i hate the fact that the power manager says "plug in now to avoid a shutdown", then shuts down in a few minutes anyway, even if you do plug in.
<Fujitsu> Hobbsee: Hm, doesn't do that for me.
<Fujitsu> And I often get that warning.
<Hobbsee> lucky
<Fujitsu> TheMuso: As a Canonical person, can you poke somebody to unbreak LP?
<TheMuso> Fujitsu: Whats up with it?
 * TheMuso is about to head out.
<Hobbsee> TheMuso: it's broken.
<Fujitsu> It's hanging, returning OOPSes with the ID `None', and some of the appservers seem to just not be working.
<Hobbsee> Fujitsu: they'll be asleep, it's a weekend.
<Fujitsu> Exactly.
<Fujitsu> And my usual sysadmin-waking contact is also asleep.
<TheMuso> sorry guys, heading out with family and kinda gotta go now...
<Fujitsu> OK, see you.
<Hobbsee> oy!  someone broke sudoku!
<Hobbsee> we can't release with that!
<Fujitsu> Hobbsee: WFM. What's borked about it?
<Hobbsee> Fujitsu: can't launch it
<Hobbsee>   File "/var/lib/python-support/python2.5/gnome_sudoku/game_selector.py", line 151, in make_saved_game_model
<Hobbsee>     sudoku.sudoku_grid_from_string(g['game'].split('\n')[1].replace(' ','')).grid,
<Hobbsee>   File "/var/lib/python-support/python2.5/gnome_sudoku/sudoku.py", line 232, in sudoku_grid_from_string
<Hobbsee>     assert(len(s)<=GROUP_SIZE**2)
<Hobbsee> AssertionError
<Fujitsu> Nice.
<Fujitsu> Remove the saved game?
<Hobbsee> Fujitsu: where is it?
<Hobbsee> works on a new profile.  must be a config issue
<Hobbsee> i just can't find the saved game
<Hobbsee> ah ha.  .sudoku
<Fujitsu> It'll be in ~/.gnome2/gnome-sudoku.
<Fujitsu> Or there, maybe.
 * Hobbsee didn't check for the obvious place
<Hobbsee> yeah, that fixed it
<Fujitsu> Yeah, ~/.sudoku is right.
<Fujitsu> ~/.gnome2/gnome-sudoku is the generated ones.
<Fujitsu> I can't see how a game could have violated that assertion.
<Hobbsee> no idea....
<Hobbsee> Fujitsu: i like the winning screen now.  it reminds me of my myspace page.
<Fujitsu> Heheh.
<realist> Hobbsee: I'm not sure if that's a good thing?
<Hobbsee> realist: of course it is!
<Fujitsu> Oh yes. It's a very good thing indeed.
<Hobbsee> it was a *lovely* page.
<Fujitsu> I was disappointed to find it missing several months ago :(
 * Hobbsee shakes her fist at the evil myspace page for deleting it
<Hobbsee> er, people
<Fujitsu> Aw... why did they delete it?
<Hobbsee> dunno
<realist> I've never seen one that doesn't look like a dog's breakfast
<Hobbsee> i'm assuming they did, as it's not there now
<Hobbsee> realist: oh, you never saw it?
<Fujitsu> It was a work of art.
<Hobbsee> Fujitsu: the comments were the best
<Fujitsu> I wonder if archive.org caught it.
<realist> Hobbsee: Nope, but it sounds like it was amazing.
<Fujitsu> Argh, no.
<Hobbsee> damn.
<Hobbsee> realist: similar to http://www.klickibunti.org/buntibunti.php
<Hobbsee> realist: with added bits about people cursing me for burning their eyes out.
<Fujitsu> Yeah. And the pony.
<Hobbsee> and "it bothers you less the longer you look at it.  SERIOUSLY!"
<Hobbsee> yeah
<Hobbsee> forgot about the pony for a bit there
<Mithrandir> mm, ponies.
<Mithrandir> almost as good as brains.
<Hobbsee> Mithrandir!
<Fujitsu> Not even close.
 * Hobbsee hugs Mithrandir
<Mithrandir> Hobbsee!
<Mithrandir> why do you run around with your at on?
<Fujitsu> Look, a Mithrandir! Haven't seen one of them around these parts in a while.
<Mithrandir> Fujitsu: I've been around
<Hobbsee> Mithrandir: it makes good armour.
<Mithrandir> new job and such takes most of my time, though.
<realist> I've never understood the pony references...
 * Hobbsee uses the @ as a shield against Mithrandir
 * Fujitsu steals Hobbsee's donut.
 * Hobbsee steals Fujitsu's computer, but happily lets Fujitsu have the donut.
<realist> That doughnut looks more like a snail!
<Fujitsu> Damn.
<Fujitsu> realist: But it's no good stealing snails.
<Hobbsee> realist: http://i-want-a-pony.com/
 * Mithrandir ruffles Hobbsee back
<Fujitsu> You can never beat the April Fools Slashdot theme.
<Hobbsee> heya ogra
<Hobbsee> Fujitsu: now, if slashdot put in that background....
<realist> Hobbsee: ahhh
<Fujitsu> I'm glad to see it's valid XHTML 1.1, too.
<Fujitsu> It just needs the scrolly rainbow background now.
<Hobbsee> indeed.
 * Hobbsee heads out for a while
<Hobbsee> enjoy the rainbows.
<realist> I just discovered a new pet peeve today
<realist> Using proprietary software, you have more reliance on the vendor for support
<realist> Whereas, help for F/LOSS is a mere google search
<Hobbsee> realist: this was a surprise to you?
<Whoopie> mjg59: yes, there's a uevent BAY_EVENT=3, but the drives are "deleted" automatically, so that I don't know if a script has the time to unmount the drives successfully.
<laga> oh my god. mjg59. *cries*
<laga> mjg59: i stayed up until 2am to read your blog. you rock.
<realist> Hobbsee: it'd never occurred to me before today.
<Hobbsee> realist: ah.
<mdke> need a bit of help with sed. Is there a way to replace all instances of X in a file, but only where they appear in a line containing the string Y?
<Hobbsee> mdke: i'm sure there's a more elegant solution, but why not grep for Y, pipe the output thru the sed command, then save to a file?
<realist> mdke: use awk?
<laga> Hobbsee: because anything not Y will be missing?
<Hobbsee> laga: good point
<mdke> realist: I'm not familiar with awk, is it easy to learn?
<afflux> mdke: sed '/Y/s/X/Z/g' -- where Z is the "new" pattern
<afflux> err, new string that is
<mdke> afflux: ok, thanks - I'll try that. is it ok just to escape "/" in the pattern with a period or do I need something else?
<highvoltage> Hobbsee: hmm, the problem with your solution would be that you lose the lines that doesn't contain the string
<afflux> mdke: not sure, try it :P
<Hobbsee> highvoltage: yeah, you'd need a if else thing.
<afflux> mdke: ah, according to the manpage Y is a regex
<highvoltage> it works here
<highvoltage> replace foo with bar in every line that contains STRING:
<highvoltage> sed /STRING/s/foo/bar/g filename > newfile
<mdke> doesn't seem to work with backslashes in the foo and bar strings
<mdke> I tried to escape them with a period each time
<afflux> mdke: hm? Can we see the command?
<highvoltage> could you give an example?
<laga> escaping with a period with in a regex?
<laga> -with ;)
<mdke> the command I tried was sed '/Xinclude/s/./C.//./hu.//g' index-hu.xml > index-hu.xml
<mdke> string X being "/C/" and string Z being "/hu/"
<mdke> lemme try escaping with a \
 * highvoltage was thinking the same thing
<laga> no
<mdke> nope, that doesn't work either, results in an empty file
<laga> mdke: try using "," instead of / for the sed command. eg s,foo,bar, instead of s/foo/bar/
<laga> or did you try to do that with the periods?
<mdke> laga: so I tried sed '/Xinclude,s,\/C\/,\/hu\/,g' index-hu.xml > index-hu.xml - that didn't work either
<afflux> mdke: the following should work: sed '/Xinclude/s/\/C\//\/hu\//'
<afflux> at least it works on a local test file I just made up
<mdke> afflux: it works except for the "> index-hu.xml" bit, that seems to cause an empty file
<laga> yeah
<Fujitsu> mdke: That's because the shell overwrites it first.
<laga> use sed -i index-hu.xml
<Fujitsu> Use -i on the sed, rather than shell piping.
<highvoltage> ok, you can put the /C/ part in brackets, that will make it find the string correctly
<realist> Much more elegant than my awk solution, at least
<mdke> Fujitsu: ah, I see - thanks everyone
<mdke> that works alright :)
<realist> cat file |awk '{match(Y) print gensub(X,Z) else print $0}' > outfile - or some such
<realist> if(match(Y,$0)!=0) rather
<realist> needs a semicolon too - absolutely not tested
<mdke> gah, there is one more thing
<mdke> if I need to use a "for y in x ; do" type script, and I need ${y} for one of the strings, how can I do that? It seems just to be putting ${y} in the file
<mdke> sed, I mean
<mdke> the command I tried was:
<mdke> for i in *.po ; do y=$(basename ${i} .po) ; echo ${y} ; sed -i '/XInclude/s/\/C\//\/${y}\//' ../../index-${y}.xml ; done
<mdke> but sed takes ${y} literally
<mdke> not sure if I'm explaining myself :)
<afflux> thats because of the ', try using " instead
<afflux> (IIRC)
<realist> ' would prevent shell expansion, yes
<realist> s/expansion/evaluation
<mdke> yay
<mdke> thanks afflux
<afflux> yw
<highvoltage> mdke: try using " instead of '
<highvoltage> oh sorry, didn't see that being mentioned already.
<hermanr> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311188#272 <-- Is this worthy of discussion with the APT developers?
<ubotu> Debian bug 311188 in debian-edu-config "debian-edu-config: Messes "programmatically" with conffiles of other packages" [Important,Open]
<hermanr> My comment was a spin-off: Apt repository interoperability
<hermanr> I suggested extending APT with metadata for declaring compatiblity between repositories.
<james_w> we discussed either removing debian-edu, or ripping out all of the parts that do bad things like this on Ubuntu to protect users
<hermanr> That's the manual short term fix.  I was concerned about the wear and tear on users, helpers and developers caused by the frequent bad surprises mixing of Apt repositories lead to.
<highvoltage> mdke: fwiw, sed '/include/s#/C/#/hu/#g' filename works for me
<hermanr> james_w: IMO, mixing of Apt sources should not be as dangerous as it is.  It's powerful.  Sometimes it's even necessary.
<hermanr> However, improving matters is not low hanging fruit. :-/
<hermanr> james_w: Has Ubuntu included Debian-edu in their proposed sources?
<james_w> hermanr: yes, it's in universe
<hermanr> james_w: That's implicitly endorsing Debian-edu, for better and for worse.
<james_w> yes
<hermanr> And evidently, Debian-edu will not accept any responsibility for that.
<hermanr> james_w: Have you approached Debian-edu and asked them if they are willing to support cross-installations like that?
<hermanr> james_w: Or, vice versa, has Debian-edu approached you?
 * hermanr is only loosely involved in debian-edu now
<james_w> not me personally, no.
<hermanr> s/you/y'all/
<james_w> I'm not sure what would be required for cross installations.
<hermanr> I just resent situations where pointing fingers lead to people washing their hands.
<james_w> if you want to look at the viability of making debian-edu work on Ubuntu, that would be appreciated
<james_w> otherwise I think that just neutering the package so that user's can't harm their installations is the best approach.
<hermanr> I'm not into the tech side of it, so I'm afraid not. :-(
<james_w> I have a suspicion that most people are just interested in the meta-packages, rather than the configuration stuff.
<hermanr> mhm
<hermanr> So there should be a derivative that isn't "real" Debian-edu, just a dry run with all the packages?
<hermanr> Alas, it won't work for a full Debian-edu setup.  And that has to be made clear!
<jdong> anyone know the timeline for vmware server in Hardy partner?
<hermanr> Adaptive configuration that will never mess things up, irrespective of the environment, is hard!  That's why custom distros is such a common workaround.
<hermanr> james_w: Yes, I think you need to neuter the Debian-edu packages before adding them to Universe.  They make assumptions based on stock Debian.  Ubuntu isn't stock Debian, so the assumptions fail.
<james_w> yup
<soc> did someone get pulseaudio working on 8.04?
<soc> is there maybe a bugreport already?
<emgent> heya people
<crimsun> soc: do you have a specific issue?  If so, please inform in #ubuntu+1.
<soc> ok
<Darklock> is tkamppeter ever around?
<johanbr> Darklock: SeenServ- I last saw tkamppeter (n=till@p54BEEFAC.dip.t-dialin.net) 1d 13h 11m 59s ago
<Darklock> d'oh
<mjg59> Whoopie: On a Thinkpad? There should be a separate event when you flick the eject lever, which doesn't cause the deletion
<mjg59> Though on most devices, all we get is the eject
<laga> slangasek: can you merge r1300 from http://bazaar.launchpad.net/~mythbuntu/debian-cd/mythbuntu-debiancd ?
<Whoopie> mjg59: there isn't with my thinkpad R52.
<mjg59> Whoopie: Did you get one with the bay driver?
<mjg59> Whoopie: Ok. event=2 shouldn't destroy the device.
<mjg59> Whoopie: The hotplug code is only called if event is 0 or 1
<Whoopie> mjg59: with the bay driver, I got a BAY_EVENT=3 on eject and 1 on insert
<Whoopie> mjg59: and now, I only get 3
<mjg59> Whoopie: Ok, 3 certainly shouldn't be causing the device deletion
<mjg59> Take a look at line 128 of drivers/ata/libata-acpi.c
<Whoopie> mjg59: and now? ;)
<mjg59> Whoopie: The hotplug call is only made if the event is 0 or 1 - the 3 should just go to userspace, and the device only be destroyed when you actually pull it out
<Whoopie> mjg59: what i see in drivers/ata/libata-acpi.c in 2.6.25 is different from this: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=237d8440cb2b104a3b97fc971a9bce67960bb616
<mjg59> Whoopie: Are you using 2.6.25 or 2.6.24?
<Whoopie> mjg59: 2.6.25
<mjg59> Someone's broken it
<crimsun> TheMuso_: / asac: ok, I think I have a middle-of-the-road solution that addresses all the regressions from previous Ubuntu releases and allows hal-aware hot(un)plug.  I've been testing it for the past hour, and it seems reasonable.  I've added comments on the bug.
<asac> crimsun: interesting
<asac> crimsun: any idea why my pulseaudio might not start with device hw:0 being busy?
<crimsun> asac: which pulseaudio config are you using, the default one in the current pulseaudio package or one patched?
<asac> crimsun: i think it should now match the one from your patch
<asac> i manually changed it that way
<asac> oh wait
<asac> crimsun: thumbs up from me :)
<asac> rock
<asac> ogra: ^^
<asac> can you test that as well?
<asac> ogra: its bug 192888
<ubotu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents" [High,Confirmed] https://launchpad.net/bugs/192888
<asac> \sh: ^^
<slangasek> laga: done
<laga> slangasek: yay.
<superm1> slangasek, did you talk to tjaalton already about fglrx 8.04?
<slangasek> superm1: I think so, I think I declined it for final
<slangasek> and recommended making it an SRU for 8.04.1
<superm1> ah
<superm1> even though it fixed a few of the pending issue w/ regard to the proprietary aticonfig tool?
<slangasek> yes; there are always pending issues to be fixed, but I don't want to be accepting black-box upgrades between RC and final
<slangasek> it should go through the SRU process at this point so we can take our time with it and make sure it's done right
<superm1> alright :)
<Adri2000> slangasek: the debdiff for the tasks upload sitting in the queue is http://adrishost.net/~adri2000/ubuntu/toupload/tasks_0.13-1ubuntu1.debdiff, it will allow the package to be translatable in rosetta and its translations to be available in the langpacks
<Whoopie> mjg59: I can't find the commit where they changed your patch.
<popey> is it possible to specify the video driver for x to use when the live cd boots? to force (for example) to use intel over i810?
<popey> (specifically for hardy)
<jojo4u> hi! upgrade xubuntu 7.10 to 8.10 using update-manager -d fails on my sources.list. default sources.list works fine. should I file a bug?
<fta> crimsun, i've tested your pulseaudio patch, looks fine for everything except wine. I used to run an app with padsp wine foo.exe, now it freeze during startup. and wine foo.exe has no sound at all.
<crimsun> fta: you shouldn't be using padsp to wrap wine, since pulseaudio no longer grabs hw:0 but plug:d{mix,snoop}
<fta> crimsun, so, what should I use instead ?
<crimsun> fta: what results do you get with aoss -- wine foo.exe ?
<fta> crimsun, no sound
<fta> hm, wait
<fta> "--" :)
<fta> crimsun, ok, thanks
<superm1> crimsun, having pulseaudio grab dmix : doesn't that unintended latency?
<superm1> *introduce unintended latency
<TheMuso_> crimsun: Thanks will likely see it in my bug mail this morning.
<asac> TheMuso_: bug 192888 ... good feedback so far
<ubotu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents" [High,Confirmed] https://launchpad.net/bugs/192888
<beasty_> morning
<beasty_> anyone here in .deb building
<TheMuso_> asac: Ok will take a closer look when I get to it in my morning email run.
<ScottK> beasty_: #ubuntu-motu is a better channel for basic packaging questions.
<beasty_> ok thanks
<TheMuso_> ...and not so good feedback also.
<calc> can someone who has access to look at this bug #218793 tell me if it is marked for OOo?
<ubotu> Bug 218793 on http://launchpad.net/bugs/218793 is private
<calc> someone claimed this bug was related to OOo but i can't see it
<Fujitsu> calc: That's nice and private. Maybe poke a security person.
<calc> kees: ping
<calc> jdstrand: ping
<julie> hi
<calc> i normally have access to security marked bugs if they are for OOo
<calc> so that bug must be mismarked somehow
<calc> or the user typoed
<Fujitsu> calc: By default only the reporter and ubuntu-security have access to security bugs...
<Fujitsu> Unless you're talking about the OOo project, in which case that might be true.
<calc> Fujitsu: hmm maybe i am specifically added on OOo bugs then
<calc> Fujitsu: because i can see bugs marked as security in lp for OOo usually
<Fujitsu> Right, you are explicitly added by a member of the security team.
<calc> Fujitsu: ah ok
<calc> i don't have any marked that way currently to check on, i can see private bugs but that is different
<julie> the problem is I changed my system lang to persian then tried to change it back to english but now its stuck on persian, kde menu is stuck on persian
<kees> calc: that bug isn't security -- I don't have access.
<calc> kees: ok
#ubuntu-devel 2009-04-13
<verb3k> There is a bug in Jaunty with unclear title, can someome help find a better one?  https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359818
<ubottu> Ubuntu bug 359818 in xserver-xorg-video-intel "[i945] Unusable with Intel 945GM/GMS, 943/940GML [8086:27a2] (rev 03)" [High,Confirmed]
<wnorrix> i keep getting a connection refused on ppa.launchpad.net when i try to upload my package
<dtchen> 220 0.0.0.0 Canonical FTP server ready.
<dtchen> seems fine from my route
<NCommander> DO we have hardening wrapper installed by default on any architecture, or have all of its changes been merged into GCC spec files?
<pwnguin> luisbg
<pwnguin> doh
<kees> slangasek: do you want me to upload the fix for linux86 (bug 360096)?
<ubottu> Launchpad bug 360096 in linux86 "FTBFS (fortify failure during compile)" [Undecided,New] https://launchpad.net/bugs/360096
<slangasek> kees: yes, please
<poseidon> I found what I think might be a bug (could be handy in some situations).  When I have a browser open and it's playing music my music player (banshee, rythmbox etc) doesn't work.  I've tested this with opera, firefox, banshee, amarok, and rythmbox.  So I think that the problem is independent of the applications.
<pwnguin> this is almost certainly flash's fault
<poseidon> Well I am using the adobe version so I guess there isnt' anything we can do :(
<pwnguin> yes / no
<dtchen> it depends what audio backends are in use
<pwnguin> theres stuff out there to sorta shim between flash and the newer audio stack
<dtchen> as of intrepid, there is no need for flashplugin-nonfree-extrasound/libflashsupport
<poseidon> I believe I just installed the flashplugin-nonfree package.  I don't know what kind of dependencies it uses
<dtchen> if you're attempting to troubleshoot in jaunty, we should migrate to #ubuntu+1, otherwise (for a supported, stable Ubuntu release), #ubuntu
<poseidon> I don't need any help.  Just wanted to let you guys know.
<dtchen> we're aware (well, at least the audio team), and it's most likely a misconfiguration at the user end
<dtchen> as of intrepid, installing Flash through adobe-flashplugin or flashplugin-nonfree does the right thing WRT pulse
<dtchen> (obviously for Kubuntu, Xubuntu, Ubuntu Studio, etc., that don't seed PulseAudio, it's moot)
<poseidon> I'm using a pretty default ubuntu interpid.
<dtchen> default meaning with or without updates?
<poseidon> with latest updates
<dtchen> then it's already a resolved issue for jaunty
<poseidon> k, cool :)
<slangasek> asac: does ubufox need an update yet in order to point to the jaunty repo for plugins?  there's no pfs/db/sources.list.9.04, for instance
<seb128> hey slangasek
 * slangasek waves
<seb128> slangasek: when do you expect we will be frozen frozen frozen for jaunty?
<slangasek> seb128: next Monday, I hope
<seb128> ok good, so still time to fix some bugs and send some GNOME 2.26.1 update your way ;-)
<ogra> seb128, any idea why we have to use -O1 with the keyring daemon on ARM (thanks for including the fix though)
<seb128> ogra: no
<geser> doko: is there a common solution for FTBFS because the configure script sets the python script dir to "/usr/local/lib/python2.6/dist-packages"?
<slangasek> the solution is to revert the latest python2.6 change
<geser> this site-/dist-packages change seems to make much patching needed to get everything build correctly again
<slangasek> generally, yes; but the specific problem you mention is a regression in python that's due to be reverted
<slangasek> infinity: can you take care of a manual bootstrap of cup (bug #359743)?
<ubottu> Launchpad bug 359743 in cup "ftbfs, needs manual build for jaunty" [High,Triaged] https://launchpad.net/bugs/359743
<infinity> slangasek: When I'm "at work" on Tuesday.
<infinity> slangasek: Bonus points if you can remind me?
<slangasek> infinity: ok. :) also, do we have a solution for P-a-s in place? (bg #301445)
<infinity> slangasek: There's a branch that core-dev can commit to.
<infinity> slangasek: (ie: feel free)
<lamont> infinity: good to see  you're getting your sleep. :-p
<infinity> lamont: Was at my parents' place all night upgrading a woody machine to hardy.  Shh.
<infinity> "upgrading"... It was a rather violent affair.
<lamont> woody?  zomg
<slangasek> infinity: code.lp.net only lists one in cjwatson's namespace?
 * lamont stabs at udev.  I hate trying to write new rules
<slangasek> infinity: so where's the branch I can commit to? :/
<infinity> slangasek: Remind me how to make bzr tell me where it's pulling a bound branch from? :P
<slangasek> bzr info
<slangasek> 'Checkout of...' or somethin
<infinity>   checkout of branch: http://bazaar.launchpad.net/%7Eubuntu-core-dev/packages-arch-specific/ubuntu/
<slangasek> curious; code.lp.net doesn't list that at all
<infinity> slangasek: Anyhow, if you do commit changes that you expect to do anything useful, you'll want to poke cprov to run the queue-builder to pick up said changes.
<slangasek> ok
<infinity> slangasek: (Normally, I'd say any one of us could run queue-builder, but it's half-broken right now, and fails miserably without some handholding...)
<infinity> \o/
<maxb> Speaking of manual bootstrapping, cmucl (universe) is in more-or-less the same situation except it's been like that since warty or thereabouts. Is there some guideline on what should happen to packages like that?
<persia> maxb, Ideally, make them not need manual bootstrapping :)
<persia> Or find a way to bootstrap remotely through "limited" build, or similar.
<IntuitiveNipple> When debugging multi-threaded apps, using gdb, is it possible to deduce which thread a function pointer is in by comparing its address to the gdb "info threads" list and looking at the Linux thread systags (which show addresses as far as I can tell) ?
<maxb> and if no-one's got round to that since warty, who makes a call on when to kick the old binaries out of the archive?
<broonie> IntuitiveNipple: A function pointer isn't in a thread.
<persia> maxb, Anyone can file a removal bug, and any developer can approve it, although generally it's left for someone to fix later, especially if it's maintained in Debian.
<IntuitiveNipple> broonie: Indeed, but I'm dealing with a structure with a request_handler * and the thread that was running the request_handler seems to be closing prematurely, so I'm trying to figure out how to get gdb to confirm that
<broonie> IntuitiveNipple: Breakpoint in the function and step through it (or trace in the function)?
<IntuitiveNipple> broonie: Hmmm, not sure that'll work since I can't identify (whilst the suspect thread is still active) which one it is, since I can only check the reference to it *after* it has gone AWOL!
<IntuitiveNipple> broonie: It's a really convoluted AT-SPI >libORBit2 > atk-bridge  > java > eclipse issue
<IntuitiveNipple> broonie: What I was hoping to trust is the gdb 'info threads' lists. I take one whilst the thread is alive, tell the app (eclipse) to close, it gets stuck, I take another thread list and find several have shutdown and one is stuck in a loop that surrounds a g_cond_timed)wait(), drill down into the data structures and try to figure out what is expected to be on the other end of the libORBit2 connection - the suspicion being the closed th
<IntuitiveNipple> read that has yet to be finalized or GCed
<slangasek> calc: if you're now waiting for revu for ooo-thumbnailer, should I be rejecting the package that's currently in the new queue?
<IntuitiveNipple> broonie: If the thread systags represent the thread's base virtual address (which it appears to since each thread is a regular distance apart), I could maybe deduce which thread the request_handler was in
* You're now known as ubuntulog
<calc> slangasek: yea go ahead and reject it
<calc> slangasek: i have a better packaged version now but not sure if anyone is going to look at it :\
<calc> argh!
 * calc kicks ooo packaging hard
<calc> ooo-java-common managed to no longer pull in jre once we dropped the external saxon library :\
 * calc has to upload a new OOo package now :\
<gionnico> Someone stole me 80MB ! Help me finding him!
<gionnico> Let's start with a dev question: does free -m show , under "used", also the memory used by the kernel itself?
<directhex> calc, pfft, java casusing issues
<calc> gionnico: i think that the kernel steals it off the top
<gionnico> calc: ah, so ..
<gionnico> is this ubuntu peculiarity?
<gionnico> because in gentoo free -m and the sum of all processes matches exactly..
<calc> gionnico: no
<calc> gionnico: oh no i didn't explain properly
<calc> gionnico: it steals it from "total" mem
<gionnico> ah
<calc> so the numbers should add up more or less i think
<gionnico> ok so i still miss 80mb
<gionnico> because free -m used shows me "X" while the sum of all processes makes "X-80"
<calc> other thing steal from total also, like addressing on 32bit mode, etc
<calc> s/mode/arch/
<gionnico> well i don't really care if there's something i can't see
<gionnico> but there's something i can see is using memory but i can't know what it is
<gionnico> Can i?
<radix> mathiaz: hi mathias, thanks very much for taking over that package upload on thursday
<mathiaz> radix: you're welcome :)
<radix> mathiaz: unfortunately, I'm going to have to dig myself into an even bigger karma debt and point out bug #360510
<ubottu> Bug 360510 on http://launchpad.net/bugs/360510 is private
<radix> huh
<calc> crap i forgot to close the lp bug in my upload :\
<radix> one sec, lemme fix that
<radix> there's a core file in it, that's why it's private
<radix> mathiaz: ok, bug #360510
<ubottu> Launchpad bug 360510 in landscape-client "crash in landscape-broker" [Undecided,Confirmed] https://launchpad.net/bugs/360510
<calc> slangasek: can i get you to approve, ayaspell-dic, ifrench-gut, myspell-sv, and openoffice.org-dictionaries (I fixed all the remaining dictionaries)
<lamont`> anybody looked into why xvnc4viewer barfs with "rect too big" on startup (regularly, sadly)
<istaz_> maybe not the right place to ask this but anybody know if there is still a feisty mirror somewhere? I need it to install php5-gd on a server that I don't want to upgrade atm
<Laney> old-releases.ubuntu.com
<lamont`> istaz_: you do relize that feisty hasn't been getting security updates for a few months, yes?
<istaz_> wow thanks you very much Laney exactl I needed
<istaz_> lamont`: yes, I plan on upgrading it when Jaunty comes out
<ScottK> calc: ifrench-gut accepted (it was in Universe).
<calc> ScottK: thanks
<calc> also i just uploaded the much better packaging version of ooo-thumbnailer (0.1~alpha2-0ubuntu1) if someone can accept that into universe, it's NEW
<lamont`> istaz_: the transition from feisty->gutsy will be easier if you do it before gutsy gets EOLed over to old-releases.
<lamont`> and by easier, I mean that edgy->feisty really really really sucked when I did it recently
<istaz_> feisty -> gutsy then gutsy -> jaunty?
<calc> istaz_: f -> g -> h -> i -> j
<istaz_> wow this is going to take a long time ^^
<calc> istaz_: he mans gutsy is going to be end of lifed later this week as well
<calc> s/mans/means/
<calc> istaz_: so better to do the upgrade before the packages get moved :)
<istaz_> I don't really understand the point if I am going to upgrade right after upgrading to jaunty
<istaz_> *gutsy
<calc> istaz_: you can't skip releases for upgrades
<calc> istaz_: unless you want to just reinstall
<istaz_> ah I didn't know that
<calc> istaz_: meaning you can't go from f -> j directly, you have to upgrade to each state in between for it to reliably upgrade
<istaz_> ok
<calc> istaz_: between LTS it is supported but not between regular releases, eg you can go from Dapper -> Hardy
<jdstrand> ScottK: can you add the clamtk and klamav test case instructions to bug #360655, then subscribe ubuntu-sru when ready?
<ubottu> Launchpad bug 360655 in clamav "SRU for clamav on intrepid (freshclam apparmor profile updates)" [Undecided,New] https://launchpad.net/bugs/360655
<ScottK> jdstrand: Sure.
<jdstrand> ScottK: thanks
<directhex> if you were me, who would you file a bug against for a mouse sensitivity issue?
<ScottK> lool: mobile-meta accpeted.
<jcole> does mythbuntu jaunty have its own patched zenity that *does* steal focus? -> https://bugs.launchpad.net/ubuntu/+source/zenity/+bug/272083
<ubottu> Ubuntu bug 272083 in mythbuntu "Zenity windows appear underneath others" [High,Confirmed]
<ScottK> superm1: ^^
<superm1> jcole, no, but the ideal situation is to have zenity grab focus.  as of right now, mythtv-setup doesn't work right for several situations because the zenity window is not focusing
<superm1> and the application that spawned zenity is blocking, waiting on the user to answer the zenity question
<pochu> directhex: xserver, but I'm not you :)
<jcole> superm1: will mythbuntu have the proper glade config for zenity?
 * jcole doesnt understand the rationale of having zenity windows default to be behind all other windows o_O
<superm1> jcole, we're not going to change the zenity behavior for just mythbuntu, i'd prefer that we see it fixed in the distro
<superm1> jcole, it's best to ask the #ubuntu-desktop folks why this is the way it is
<superm1> I agree it sounds wrong right now
<directhex> pochu, which source package is that?
<NCommander> Can a buildd admin please kill the build on rhenium?
<superm1> jcole, but if it comes down to it that the desktop team isn't willing to change that behavior, i suppose mythbuntu can ship a glade file and divert the one in zenity, but that's definitely not what i want to do
<pochu> directhex: xorg
<pochu> directhex: package is xserver-xorg
<pochu> directhex: but I could be totally wrong. that's where I would fill it though :)
<directhex> i think i might file against gnome-control-center since it's the customer-facing end of my issue
<directhex> it can always be bounced around by a triager
<directhex> oh. #
<directhex> bug #28052
<ubottu> Launchpad bug 28052 in gnome-control-center "Improve mouse sensitivity and acceleration settings" [Unknown,Confirmed] https://launchpad.net/bugs/28052
<directhex> hm, no, not quite the issue i have
<jcole> superm1: the main purpose of zenity *is* to steal focus... it's been like that for years... doesnt make sense to break all zenity apps for the sake of (whatever the rationale may be)
<superm1> jcole, yeah i agree.  so tomorrow when everyone is back from holiday, it's a good idea to stir up this discussion
<slangasek> calc: I'll have a look at those, sure
<lool> ScottK: Thanks!
<calc> slangasek: thanks
<calc> slangasek: i also uploaded the better version of ooo-thumbnailer after going through REVU checks
 * slangasek nods
<LaserJock> bryce: regarding your email to -devel, I'm not sure what you mean by "performance problems". Do you mean "it'll make it go faster" or "it'll make it not crash as much"?
<superm1> LaserJock, it will run more fluidly (faster)
<LaserJock> hmm :/
<LaserJock> I was hoping for the later
<LaserJock> jaunty is certainly making me regret buying an Intel graphics card
<ajmitch> LaserJock: the drivers are that bad?
<calc> LaserJock: i think intel wanted to help prop up ati and nvidia a bit with their crappy drivers
<calc> LaserJock: aiui their drivers on windows have been equally bad in other areas
 * ajmitch might hold off on upgrading from hardy then
<LaserJock> ajmitch: I get a lock-up about every day. I have to hard reboot.
<ajmitch> that's pretty bad
<lifeless> LaserJock: its 'not crash as much' too
<calc> ajmitch: intrepid is probably fine, the main problem with intel drivers on jaunty are due to the 2.5/2.6 driver
<lifeless> LaserJock: because you can stop using UXA
<LaserJock> ajmitch: it's really spotty. you might be just fine, but this is the first Ubuntu release I've had problems
<calc> ajmitch: https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
<dtchen> there are reports in the streets that newer libdrm and xserver-xorg-driver-intel are much more stable
<dtchen> s/driver/video/
<calc> dtchen: newer than what we have?
<LaserJock> Intrepid was just fine for me
<dtchen> calc: yes
<calc> dtchen: ah
<calc> bryce: ^ see what dtchen said (if you aren't already aware of it)
<LaserJock> lifeless: does UXA currently fix problems?
<lifeless> its the new vm for intel drivers, but AIUI its a little fragile right now
<ScottK> LaserJock: UXA works great for me except when it falls over and dies.
<jdong> performance and glitchiness are fine for me in UXA
<jdong> just it frickin kills X on every resume
<jdong> s/every/90%/
<LaserJock> I don't care about like speed and stuff, I just want to be able to use FF without it having to hard-reboot every day
<jdong> and EXA for me just hardlocks on compiz start.
<LaserJock> s/it//
<ScottK> LaserJock: The 'greedy' option described in Bug #359600 works great for me.
<ubottu> Launchpad bug 359600 in xserver-xorg-video-intel "Solved slow 2D performances with EXA" [Undecided,Confirmed] https://launchpad.net/bugs/359600
<ScottK> Or in bryce's PPA....
<LaserJock> ok, I'll give it a go
<lifeless> LaserJock: disable compositing and UXA, use bryces deps, pretty sure it will be fine :)
<LaserJock> lifeless: I've never used UXA, and I've tried without compositing. I'll now try bryces packages
<ScottK> siretart was touting the newer Intel drivers yesterday or the day before.
#ubuntu-devel 2009-04-14
<LaserJock> well, bryce's package nicely fixes the problem by dumping me into vesa :-)
<LaserJock> I'm guessing that's not the intended fix
<jdong> LaserJock: is performance better? :D
<LaserJock> well, if I could get a better screen resolution I'd just stick with it
<LaserJock> but it sorta looks not-so-great
<jdong> ah yeah, how many people put nonstandard resolutions in their VESA modes anyway.
<jdong> I remember having this problem with my ATI card back when there were no drivers (more or less)
<tclineks> is there anyone working on a 9.04 jeos image?
<jdong> hmm it doesn't seem like vmmouse probing works in Jaunty anymore for vmware mouse acceleration... :(
<cody-somerville> mouse acceleration?
<jdong> yeah, the VMWare absolute position mouse driver
<jdong> for seamless host/guest mousing.
<jdong> there's some sort of HAL callout used to load the vmmouse input driver
<jdong> but in Jaunty only evdev/HID emulation is being used
<jdong> (Intrepid and below did it correctly)
<TheMuso> slangasek: what are we doing in relation to release freeze and GNOME 2.26.1 updates? There are a few a11y related GNOME 2.26.1 package updates available.
<tclineks> http://cdimage.ubuntu.com/jeos/releases/jaunty/ =(
<cjwatson> tclineks: the separate jeos image was retired in favour of just being an option in the Ubuntu server installer
<tclineks> oh really
<tclineks> available in alternate installer?
<tclineks> too bad as small iso footprint can be kind of nice, but ah well
<cjwatson> no, just server
<cjwatson> I'm sure you could do it with the netboot mini.iso ...
<tclineks> crap
<tclineks> 60% done with alternate iso
<tclineks> ok
<tclineks> thanks
<calc> tclineks: you can rsync that afterwards to server
<cjwatson> or jigdo
<calc> tclineks: probably would download less than a whole cd
<calc> tclineks: or what cjwatson just said :)
<tclineks> calc: alternate?
<tclineks> haven't dealt with jigdo
<calc> tclineks: yea you can rsync between different cd's or use jigdo to rebuild them
<calc> tclineks: you just need to rename it to the new name or however you want to do it
<tclineks> hm
<cjwatson> you should be able to boot the netboot mini.iso with the following arguments to achieve pretty much the same effect as jigdo:
<cjwatson> err, as jeos:
<cjwatson> tasksel/skip-tasks=standard pkgsel/language-pack-patterns= pkgsel/install-language-support=false clock-setup/utc-auto=true
<tclineks> nice
<cjwatson> actually, you might want to install the virtual kernel as well
<cjwatson> so add: base-installer/kernel/override-image=linux-virtual
<tclineks> i'll give that a go
<slangasek> TheMuso: I've given seb128 the green light for 2.26.1 updates, pre-RC; what updates do you have, maybe they're already on seb128's list?
<TheMuso> slangasek: gnome-orca and gnome-mag, which I am responsible for updating. Accerciser, which is universe.
<superm1> jdong, this is something i'm always getting on BIOS developer's cases about, if the mode is in the EDID, it should be in the VBIOS
<slangasek> TheMuso: will you be able to upload those today?
<slangasek> superm1: so, how's mythbuntu+mesa looking?
<TheMuso> slangasek: indeed.
<jdong> superm1: haha fat chance they'll listen
<jdong> superm1: not unlike fricking Apple with their ATA PIIX mode controllers in BIOS emulation mode
<tclineks> don't quite have the knowledge to do the mini.iso deal, just grabbing the full server iso
<tclineks> thanks for you rinput
<tclineks> your*
<cjwatson> np
<oobe> I installed juanty beta and was wondering when the release becomes final in a few days will i have to do a full dist upgrade or will i be prompted with updates as per usual as in a normal apt-get upgrade should suffice?
<cjwatson> oobe: You should read the documentation for what dist-upgrade vs. upgrade mean, and you should generally use dist-upgrade through development releases. However, System -> Applications -> Update Manager (or the automatic notification) is not equivalent to 'apt-get upgrade', and should work fine.
<cjwatson> (I mean System -> Administration -> Update Manager, obviously ...)
<oobe> i use kubuntu so im not used to those paths
<oobe> plus i usually do everything with apt
<cjwatson> if you're using apt-get directly, then use apt-get dist-upgrade
<oobe> ok
<oobe> thanks
<jdong> see the manpage on apt-get for the difference between the two
<jdong> (more or less the only time it matters is when apt-get reports held back packages)
<slangasek> calc: hunspell-vi, hunspell-hu still Conflict: myspell-da?
<directhex> oobe, incredibly short version: dist-upgrade will add/remove packages to reflect changed deps, upgrade will hold packages that would require adding.removing things
<calc> slangasek: yea, hmm let me see if i can see why
<oobe> directhex, thanks as cjwatson mentioned i really should read more docs on apt and dpkg but what you just said makes it very clear
<slangasek> calc: not a regression, I think it's a pre-existing packaging bug; accepted already
<calc> slangasek: ok thanks
<calc> slangasek: also working on a ooo update atm but still beating on it to make sure its working right
<slangasek> calc: why is that needed
<slangasek> ?
<calc> i managed to cause it to drop the jre dependency from ooo-java-common when i dropped the saxon package
<slangasek> ugh
<slangasek> can you upload now, and beat on it in parallel?
<calc> i fixed it up and built it and noticed the variable wasn't being substituted so fixed it up again and i think it will work correctly now
<calc> yea i can upload it now as i think it should work now
<slangasek> OOo needs to be in the build queue *ASAP* to avoid delaying CD builds
<calc> yes, it takes 36hr to build on armel :\
<calc> i just got a bug report today that made it clear what the issue still existed
<calc> so been working on it for a while when i saw it wasn't quite fixed yet, should be fine now though so i will upload it should be done uploading in ~ 1hr
<superm1> slangasek, 7.4 breaks vesa for us, i'm testing it with -nv later tonight
<superm1> slangasek, i've tried to bisect the tree, and i at least found when it started breaking, but it's not a matter of just revert this one commit and you're fixed
<slangasek> erk, breaks vesa?  that's not even the same bug I was thinking of, is it?
<superm1> no, the one you are thinking of is breaking -ati, and that exists on 7.3 too
<slangasek> bryce: followed up to your -intel call for testing; dunno if it needs moderation to reach ubuntu-x
<superm1> so it's two ugly bugs
<slangasek> superm1: :/
<calc> slangasek: started upload, should take somewhere between 30-45m i think
<slangasek> ack, thanks
 * jdong out of desperation foreports pulseaudio intrepid->jaunty.
<jdong> optimistically trying to bisect the flash/skype regressions.
<wgrant> jdong: What Flash regressions?
<jdong> wgrant: A-V loses sync on things like hulu or youtube, randomly.
<jdong> audio continues at normal speeds but video seems to just completely stop.
<wgrant> I've not seen that.
<jdong> might be an X/xv related problem though.
<jdong> just trying to whittle down the list of suspects
<dtchen> you need a crackton of fixes in the audio stack
<superm1> slangasek, if we wanted to block notification-daemon from getting installed in mythbuntu but just notify-osd, how would we (effectively) do that?  pitti did an upload the other day that stopped notify-osd from getting spawned on !gnome for kubuntu users, but we'd still like to use it on mythbuntu.  removing notification-daemon appears to be the most effective way of (easily) doing that
<dtchen> jdong: you need newer linux, alsa-lib, alsa-plugins, pulseaudio
<tclineks> oh maybe i will do the mini.iso after all, found some docs
<tclineks> it'd be nice to have some common recipies
<slangasek> superm1: I think I've gotten lost in the negatives in that question.  What is it you want installed?
<calc> slangasek: done uploading
<superm1> slangasek, haha.  we have notification-daemon and notify-osd installed side by side right now.  we notify-osd to be used, but to have it be used notification-daemon has to not be present it appears
<slangasek> calc: ta
<jdong> dtchen: ah, how new?
<superm1> i think it gets pulled in from earlier dependency resolution by things alphabetically before mythbuntu-desktop, like gnome-power-manager
<slangasek> superm1: so you want to keep notification-daemon from *ever* being installed on mythbuntu?
<jdong> dtchen: I noticed also annoyingly that skype ain't API-compatible with newer alsa-lib either. Groan stupid proprietary stuff.
<slangasek> superm1: or you just want to make sure only notify-osd is pulled in automatically?
<superm1> slangasek, no, just not by default
<slangasek> ok
<superm1> notify-osd is currently there (recommends on mythbuntu-desktop i believe)
<dtchen> jdong: at least what we have in current jaunty. you'll likely need to pull my linux tree and pulseaudio bzr branch, too.
<dtchen> jdong: that should be sufficient for Intel HDA but may be insufficient for Intel8x0 AC'97
<slangasek> superm1: I wonder if seeding notify-osd at the top of the seed would make a difference?
<jdong> dtchen: would you have any hints as to why skype's audio playback would cause 80% of one core to be in system time? strace wasn't very helpful; seems to mostly be select() time
<jdong> (it didn't happen in Intrepid)
<superm1> slangasek, well is it the seed resolution or normal dependency resolution that does it I wonder?
<slangasek> superm1: if not, then the only other thought I have is to change gnome-power-manager to depend on notify-osd | notification-daemon, and try to sort the knock-on effects
<dtchen> jdong: welcome to mainloop hell.
<dtchen> jdong: (known issue, the ARM guys are hateful about it, too)
<superm1> slangasek, i think there are some other apps that do it too though, so that would be a handful of apps just for this change
<jdong> dtchen: interesting; any literature you have on it off the top of your head?
<superm1> slangasek, i'll try moving it to the top of the seed and see how tomorrow's daily works out with that change
<slangasek> superm1: well, it shows up in the seed; http://people.ubuntu.com/~ubuntu-archive/germinate-output/mythbuntu.jaunty/all
<slangasek> we ought to see improvement in the seed after the next publisher run, if it's going to take
<dtchen> jdong: i don't know aside from pulseaudio chat.
<slangasek> currently, it's libnotify1 that pulls it in
<slangasek> (according to the seed)
<superm1> ooh very cool output.
<jdong> dtchen: would you suspect adobe flash AV desync to be video stack related or pulse related?
<dtchen> jdong: both
<jdong> dtchen: and I suppose it's also known that glitchfree seems to universally glitch more, huh?
<dtchen> jdong: on which kernel and using which pulseaudio?
<jdong> dtchen: jaunty stock on both counts
<dtchen> jdong: then you don't have the necessary base fixes to linux.
<dtchen> jdong: (they'll be SRUd from my conversation with rtg)
<superm1> slangasek, okay well i've committed that change.  when is the next publisher run for me to take a look at the output then?
<jdong> dtchen: ah. Would that have any impact on the mainloop behavior in your opinion?
<dtchen> jdong: the glitch-free portion isn't mainloop-related; that's pcm_lib and mid-layer (both linux)
<slangasek> superm1: once an hour at 3 after the hour, so you should see the difference in about 1:10 or so
<dtchen> jdong: i.e., http://kernel.ubuntu.com/~dtchen/README.asc
<superm1> slangasek, okay cool thanks, i'll check back after dinner then
<jdong> dtchen: mmmph. Perhaps I should just wait on Intrepid a bit longer for the dust to settle. Thanks for your infinite knowledgebase as always :)
<mrooney> bryce: happen to know if bug 312319 is a dupe of anything?
<ubottu> Launchpad bug 312319 in ubuntu ""Fatal server error: no screens found" w/dual nvidia Quadro 1700" [Undecided,Confirmed] https://launchpad.net/bugs/312319
<bddebian> lamont: You around by chance? (about xdelta)
<superm1> slangasek, here's an overview of the last high/critical bugs I know about after testing on -ati, -vesa, and -nvidia for mythbuntu: http://tinyurl.com/mythbuntu-bugs . there are some smaller ones left too, but i'm not getting to them until i make more progress on mesa stuff
<slangasek> superm1: thanks, I'll have a look through those later
<slangasek> TheMuso: the gnome-orca diff includes this change; does this wind up in the binary package?:
<slangasek> -localedir = os.path.join ("/usr", "share", "locale")
<slangasek> +localedir = os.path.join ("/export/home/wwalker/work/orca/branches/gnome-2-26/bld", "share", "locale")
 * TheMuso checks
<TheMuso> slangasek: appears it doesn't
<calc> slangasek: did OOo get processed yet? i haven't seen an email yet
<bryce> mrooney: check launchpad
<LaserJock> bryce: yo, you get my comments on bug #359600?
<ubottu> Launchpad bug 359600 in xserver-xorg-video-intel "Solved slow 2D performances with EXA" [Undecided,Confirmed] https://launchpad.net/bugs/359600
<bryce> LaserJock: yeah been looking at this
<ScottK> bryce: For me greedy was the difference between I can't possibly live with this, what will I install instead and hmm, not too bad.
<bryce> ScottK, no one reports bugs against X that go, "I can live with this, but..."
<bryce> ;-)
<ScottK> bryce: Between Intel video and some unrelated stuff I'm not thrilled about, I have a Debian ISO on my hard drive that I've decided to hold off on installing for a bit now.
<bryce> making threats is not very constructive
<ScottK> bryce: I'm not intending a threat.  Just trying to express how bad I thought it was before and how much better it is now.
<bryce> ScottK, sounds like you're making an ultimatum - "Make the change I want or I quit"
<ScottK> bryce: I doubt greedy is suitable for a default, be needs to be one of the options we give people (I don't envy anyone having to write the release note for this).
<ScottK> bryce: Not at all.  I changed it myself and my situation is OKish now.
<slangasek> calc: notchet
<slangasek> TheMuso: ack, thanks
<calc> ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) <- should that actually work?
<calc> it seems not to even though its in debian policy documented that way
<calc> erg i see what is wrong
<calc> its supposed to be whitespace delimited not comma delimited
<mathiaz> slangasek: what's your opinion on bug https://bugs.launchpad.net/landscape/+bug/360510?
<ubottu> Error: Could not parse data returned by Ubuntu: timed out (https://launchpad.net/bugs/360510/+text)
<mathiaz> slangasek: should this go in the release or in jaunty-updates?
<slangasek> mathiaz: what's the impact of the bug?
 * slangasek doesn't know what landscape-broker is
<slangasek> calc: how did your local testing turn out? should I go ahead and accept the OOo upload now?
<mathiaz> slangasek: it's one component of  landscape
<slangasek> that doesn't tell me anything I couldn't infer from the name :)
<mathiaz> slangasek: yeah - let me look into this a bit more.
<mathiaz> slangasek: the impact is outline in https://bugs.launchpad.net/landscape/+bug/360510/comments/5
<ubottu> Ubuntu bug 360510 in landscape-client "crash in landscape-broker" [Undecided,Confirmed]
<mathiaz> slangasek: if the broker crashes, landscape-client doesn't work.
<mathiaz> slangasek: the system won'
<mathiaz> slangasek: the system won't be manageable by landscape anymore.
<mathiaz> slangasek: so a system couldn't get its updates since landscape cannot send the package update request.
<radix> hi, I'm around to discuss it
<radix> but yes, what mathiaz is saying is true
<mathiaz> radix: ^^ is that a possibility (ie an upgrade to jaunty would block the system from upgrading anymore)?
<mathiaz> radix: *updating*
<radix> yes, at least updating through landscape
<mathiaz> radix: isn't that the case for most of systems managed by landscape?
<mathiaz> radix: ie are you supposed to use apt-get to manage packages on a landscape managed system?
<radix> right, the biggest point of using landscape is its centralized package management
<radix> I mean, rather, that that's its biggest feature
<radix> so it's pretty serious, as far as users of landscape and landscape itself goes
<slangasek> mathiaz, radix: if you can get the fix uploaded in the next few hours so it lands before RC, I'll take it
<radix> it's completely ready, as far as the packaging branch goes...
<mathiaz> slangasek: ok - I'll upload a new package today.
<slangasek> thanks
<radix> slangasek, mathiaz: thank you both again
<slangasek> calc: OOo accepted now; if there was anything broken in it per your testing, please bump the version when you upload
<radix> I am going to have to bake about fifteen cakes for you guys to regain my karma, I think
<slangasek> whooo cake
<radix> :-)
<mathiaz> radix: well I prefer thai food than cakes FWIW
<radix> mathiaz: noted ;-)
<slangasek> ooh thai cake
<radix> hah
<slangasek> wait
<lamont> bddebian: actually just running off for the evening
<lamont> will be back in about 7 hours or so
<bddebian> lamont: NP, thx
<mathiaz> slangasek: I've got a landscape-client package ready to be uploaded. Should I go ahead?
<slangasek> mathiaz: yes
<calc> slangasek: sorry it seemed to be fine
<geofft> if I'm running intrepid and have jaunty in my sources.list, but apt preferences pinning all but one package at intrepid, does do-release-upgrade figure out what to do?
<pwnguin> thats a lot of pinned packages
<geofft> That's how the preferences phrase it, no? Package: * Pin-Priority: -1
<pwnguin> maybe i should learn how to pin packages sometime ;)
<dholbach> good morning
 * bryce waves to dholbach
<dholbach> hiya bryce
<pitti> Good morning
<Hobbsee> heya pitti!
<Superdweeb> hey, most of you guys are asleep right?
 * pitti hugs Hobbsee
 * Hobbsee hugs pitti back :)
<Hobbsee> how goes it/
<pitti> Hobbsee: I enjoyed San Francisco last week (LF collab summit), and the Easter holiday
<pitti> time to get back to work :)
<Hobbsee> ahhh, nice
<Hobbsee> heh.  Get fixing!  :)
<elmo> doko: why isn't python-examples seeded as supported?
<doko> elmo: because nobody did note? really, should we support these? upstream currently considers removal of many of these
<elmo> doko: *shrug* just seems odd - the source is in main, seems like a no-brainer.  but I'm not bothered either way
<elmo> (by source, I mean python2.6, not python-defaults, obviously)
<doko> sure, we can add it
<cjwatson> it's already in the development seed
<elmo> cjwatson: oh?  nijaba's ubuntu-maintenance-check script was flagging it as unsupported to me
<elmo> maybe it or I am on crack
<cjwatson> elmo: it was in desktop in dapper (probably mistakenly), but is in development as of hardy; it may be that nijaba's script is confused about the status of development, since there's quite a bit of desktopy stuff in there
<slangasek> pitti: strange, why is /tmp only a ramdisk if / is low on space?  (On an upgraded system, I have it as a tmpfs in /etc/fstab)
<slangasek> having /tmp as tmpfs also makes it more straightforward to use read-only root...
<pitti> slangasek: in fstab? I'm fairly sure that this wasn't configured so by d-i
<cjwatson> d-i doesn't do that (yet), no
<nijaba> cjwatson: That is definitely a problem with Dapper.  Are the python-examples in development or supported-development in Jaunty?  IIRC only the ones in supported-development are marked as maintained.  but maybe that is a mistake
<slangasek> hmm, wonder where my tmpfs setting came from
<cjwatson> /etc/init.d/mountoverflowtmp mounts /tmp as tmpfs in emergencies
<cjwatson> nijaba: development
<slangasek> ohwell, I'll keep it there in any case
<cjwatson> nijaba: was looking at hardy, I don't imagine the distinction matters for jaunty
<nijaba> cjwatson: nope
<elmo> FWIW, I'm looking at jaunty
<pitti> bryce: I'm not sure about your own reply to the call for testing; are you still looking for feedback on 2.6.3-0ubuntu10~bug359600greedy1 ?
<nijaba> cjwatson: maybe there is a logical issue here.  So far, the script marks as maintained only those packages that are in some selected seeds directly or by inheritance.  When a package is not found there, it is not marked as maintained at all.  Shouldn't we change this so that any package in main should at least be considered as maintained for 18mo, then for a LTS mark it as maintained for 3y if in a DT seed and 5 for a server seed?
<bryce> pitti: no longer
<cjwatson> nijaba: for the 18-month releases, anything that's seeded at all should be supported, surely; the discrepancies would be a good way to find bugs in your scripts :-)
<pitti> bryce: okay
<bryce> pitti: my fears were confirmed, so we're back to square one
<cjwatson> nijaba: I don't think you should use main for this, but just the full set of seeds
<elmo> nijaba: so, one other thing I've noticed is that my (hardy) kernel always seems to be considered unsupported
<elmo> which is a little distressing if true ;-)
<nijaba> cjwatson: ok.  expect a new version shortly
<nijaba> elmo: that's a known issue, as kernels, apart from the orinal one, are generally not seeded.  if you know a way to solve this, I'll take it
<cjwatson> kernels so are seeded
<pitti> bryce: BTW, I watched Keith's talk about GEM, UXA, and KMS last week; pretty interesting, but the amount of changes that we'll see in karmic are also scary :)
<nijaba> cjwatson: really?  where?
<cjwatson> oh, well, I guess ABI changes will leave unseeded kernels. Is that what you mean?
<nijaba> cjwatson: yep
<bryce> pitti: oh dear
<cjwatson> yeah, only thing you can do there is special-case them
<bryce> pitti: I thought we were through the worst of that.....
<pitti> bryce: well, we don't really use UXA yet, so I don't count jaunty yet
<slangasek> pitti: do we need to rate-limit Keith?  Distract him with board games?
<pitti> well, the changes make a lot of sense, of couse
<pitti> I'm slightly worried about what will happen for nvidia systems
<bryce> pitti: it's already been affecting us even though we don't use UXA, but I was hoping it'd all be stable so we could switch to it in karmic
<bryce> pitti: yes I am definitely growing tired of users grousing at us and threatening to switch to some other distro
<nijaba> cjwatson: so any linux-[generic|server|image-*-[generic|server]] should me marked as maintained?
<pitti> bryce: would that actually help? I can't see how it can work significantly better in current FC11, for example?
<pitti> they are using nouveau by default there
<ogra> pitti, do you still maintain that table with languages used worldwide ?
<davmor2> slangasek: is that kieth have you heard about this d&d game.......
<pitti> ogra: well, there's not much to maintain :)
 * ogra fails to find the url
<pitti> ogra: http://bazaar.launchpad.net/%7Eubuntu-langpack/langpack-o-matic/main/annotate/head%3A/langpacksize
<bryce> pitti: of course not, that's the sadly ironic thing
<pitti> bryce: unless, with "other distro" they mean "lenny" or "hardy" :)
<slangasek> davmor2: more like "hey have you heard of this San Juan variant called Lima"
<cjwatson> switching distributions to avoid Intel driver bugs is a bit like switching cities to avoid divine retribution
<bryce> pitti: well I also hope we can rely more on -nouveau in karmic.  Dunno if it'll be viable for defaulting to, but that's definitely my hope
<cjwatson> it'll catch up with you in the end ...
<bryce> cjwatson: exactly
<davmor2> slangasek: give him a copy of the sims and tell him he can't code till he completes it :D
<ogra> pitti, hmm, i thought i remembered a table with an overview how many people speak what langs in relation to the total world population
<cjwatson> nijaba: right, something along those lines although I suspect there are a few more flavours to add there
<pitti> bryce: *nod*; I doubt that we'll get a GEM/KMS enabled nvidia driver very quickly anyway
<Hobbsee> davmor2: oh dear ;)
<pitti> ogra: that might be in some ancient email
<ogra> pitti, size doesnt matter so much on USB images ;)
<ogra> ah, thanks
<cjwatson> nijaba: an alternative would be to whitelist by source package for the kernels
 * ogra checks if evo still has it
<dholbach> Keybuk: does the patch in bug 343215 look good to you?
<ubottu> Launchpad bug 343215 in pybootchartgui "pybootchartgui crashed with ValueError in get_proc_state()" [Medium,Fix committed] https://launchpad.net/bugs/343215
<Keybuk> I've never really looked at the pybootchartgui code
<tjaalton> I've got a race condition on boot when using a remote server to collect syslogs. the boot hangs when trying to start klogd unless the network is up
<tjaalton> failsafe works, because while the menu is open the network manages to get up and running
<tjaalton> this is jaunty
<tjaalton> should I file a bug or blame the local configuration?
<Keybuk> tjaalton: it's not something we support I think
<tjaalton> Keybuk: hrm, ok
<slangasek> tjaalton: do you have the remote server configured by IP or by hostname?
<Keybuk> pitti: is there any way to get the actual core file for a crasher bug?
<tjaalton> slangasek: hostname
<pitti> Keybuk: if it was successfully retraced, it gets deleted
<Keybuk> pitti: :-(  but that means I can't actually examine the crash
<pitti> Keybuk: so, if you are looking at a bug like that, then "no", I'm afraid
<slangasek> tjaalton: I would advise not doing that, unless you want to also add the hostname to /etc/hosts.  syslog itself is udp and should behave itself if the host is unreachable, but if it can't resolve the hostname I think that's invariably going to be painful
<Keybuk> pitti: the bug has a trace which puts the line of code of the crash at the *entry* to a function
<Keybuk> which makes little-to-no sense
<slangasek> tjaalton: if you get the same hangs when pointing at an IP, I think that merits a bug
<tjaalton> slangasek: ok, I'll try that next
<Keybuk> so I need to examine the stack, but can't do that without the core file
<Keybuk> pitti: does apport delete the core files from the user's /var/crash directory when reported?
<ogra> Keybuk, why does apt-get install bootchart default to install pybootchartgui for me ?
<ogra> if we dont support it
<pitti> Keybuk: no, it remains for a week
<pitti> Keybuk: the cron job deletes old files
<Keybuk> ogra: I didn't way we didn't support it?
<ogra> oh, you were referring to the syslog qestion above, sorry
<ogra> still though, its in universe
<Keybuk> ogra: personally I dislike pybootchartgui strongly
<ogra> tjaalton, from my experience with remote syslogging in ltsp, syslog has hardcoded dns lookups builtin ...
<ogra> Keybuk, so why do we pull it in by default ?
<slangasek> because I haven't gotten to that one in component-mismatches yet
<ogra> we should offer it optionally but default to whats in main
<slangasek> I was going to drop the pybootchartgui recommends for jaunty
<ogra> oh, so its supposed to go to main ?
<Keybuk> ogra: there is no chart generation tool in main
<ogra> ah, good
<Keybuk> slangasek: but then people installing bootchart would have no charts
<Keybuk> and I'll reassign all the zillion bugs about that to you personally <g>
<ogra> Keybuk, the java one we used to use ?
<Keybuk> ogra: that's in bootchart-java
<ogra> right, that should be the default then
<slangasek> Keybuk: ...
<Keybuk> slangasek: the bootchart package contains only the collector, it generates .tgz files containing the data collected
<Keybuk> slangasek: you need either pybootchartgui or bootchart-java to turn that into a chart
<Keybuk> which bootchart will do if either one is installed
<Stskeeps> bootchart finally got seperated?
<slangasek> Keybuk: are you arguing pybootchartgui should be installed by default?
 * ogra wonders why it doesnt collect anythng for him on armel 
<Keybuk> slangasek: I'm saying that one of the charting tools should be installed *with* bootchart by default, yes
<slangasek> Keybuk: ok. would you like to write an MIR? :)
<Keybuk> ie. if you install bootchart, you should get one of the charting tools along with it
<Keybuk> personally I prefer the java one
<Keybuk> but that made people throw things at me for being written in java
<Keybuk> the python one is supposed to be "better", but I think it's output sucks
<directhex> nothing wrong with java
<Keybuk> and it generally doesn't work more
<directhex> if you have the disk space and RAM for it ;)
<Keybuk> slangasek: I could argue that the java one should be in main already, since it was only separated out of a source package that was in main before
<ogra> you have it installed by default anyway
<slangasek> Keybuk: great - let's recommend that one by preference and get it back into main, then. :)
<Keybuk> slangasek: can you file a bug to remind me?
<slangasek> Keybuk: if we're in agreement, how about if I just upload?
<Keybuk> sure
<ogra> hmm ... "cp cannot stat "/lib/libc.so.*"
<ogra> Keybuk, meh, i think the init-top script needs special casing for armel
<ogra> lool, ^^^
 * slangasek eyes the bootchart version numbers
<ogra> lool, do we use /lib-vfp in initramfs ?
<lool> If we do it's probably by accident
<lool> I think that's actually a bug if we do
<lool> Because we should create vfp initrd if the buildd is vfp
<lool> err should NOT
 * ogra looks for the runes to display initramfs contents
<lool> But the copy_exec stuff and other logic might be doing that   :-/
<ogra> yes
<ogra> so we would need to special case that or make a link or something like that
<slangasek> Keybuk: bootchart missing an .orig.tar.gz?
<Keybuk> slangasek: ?
<cjwatson> ogra,lool: should be a one-liner in copy_exec
<slangasek> Keybuk: 0.90.1-2 is a native package
<cjwatson>                 # Try to use non-optimised libraries where possible.
<cjwatson>                 # We assume that all HWCAP libraries will be in tls.
<cjwatson>                 nonoptlib=$(echo "${x}" | sed -e 's#/lib/\(tls\|i686\).*/\(lib.*\)#/lib/\2#')
<Keybuk> slangasek: bootchart is a package we wrote
<slangasek> Keybuk: <shrug> if there's no upstream tarball, why use non-native-format version strings
<slangasek> (debuild whines at this)
<Keybuk> because I prefer them
<Keybuk> point me at the line in debian-policy that says you can't use a revision format version string if you don't have an orig.tar.gz ;)
<slangasek> it doesn't say you can't
<slangasek> it's just annoying when you do :)
<ogra> wow
<ogra> pybootchartgui explodes massively on armel
<Keybuk> slangasek: I think information is lost if you don't use them
<cjwatson> policy does allow that, but I think the intention is for that to be for cases where an upstream has released something with a dash in its version
<Keybuk> I like to still use <code version>-<packaging version>
<Keybuk> cjwatson: I don't see that intent in -policy at all
<slangasek> cjwatson: evidently, that's what "upstream" is doing :-)
<cjwatson> TBH if I wanted to separate code and packaging I would create an .orig.tar.gz
<cjwatson> just because that would make the separation more explicit
<Keybuk> but that involves causing myself pain deliberately
<cjwatson> policy doesn't really specify the existence of an orig.tar.gz at all; it's left up to common sense
<cjwatson> perhaps we should change that ;-)
<lool> cjwatson: thanks; will patch the sed foo
<cjwatson> (except in C.3, which is less than obviously normative)
 * ogra wonders if bootchart-java behaves differently on armel
<lool> cjwatson: It's unfortunate that I can't force the hwcaps for ldd; I can force them only for ldconfig
<lool> slangasek: Pushing initramfs-tools; tested the change on my babbage and confirmed that it dropped /lib/vfp from the initramfs
<slangasek> I guess that's critical for RC on armel?
<ogra> well, it breaks things like bootchart :)
<slangasek> but not things like boot? :)
 * ogra didnt notice any breakage in the default setup yet ... though we're likely using the wrong libc then i assume
<ogra> hmm, bootchart-java doesnt seem to finish parsing
<ogra> pybootchartgui definately has the wrong code for CPU detection, i wonder if bootchart-java suffers the same thing :/
<ogra> ah, no ! i get a png now, its just very slow
<ogra> !!
<ogra> hmm, a 0 byte png yet ...
<slangasek> why does pybootchartgui need code for CPU detection?
<ogra> no idea, but the parser tries to compare system.cpu with something
<ogra> and fails at that step on my imx51 system
<ogra> the java parser is running since 7:30min already
<ogra> ah, and it finished
<ogra> nice !
<ogra> my babbage board takes 0:41 to boot
<ogra> thats not bad for booting from two Sd cards i think
<ogra> http://people.ubuntu.com/~ogra/babbage-jaunty-20090414-2.png in case anyone is intrested to see the boot of a babbage board
<amitk> ogra: two SD cards?
<ogra> amitk, one is my bootfloppy and the other sits in an USB SD reader and carries the rootfs
<ogra> initramfs comes from the first one
<amitk> aah
 * ogra wonders what that udevadm sleep is doing there between 6 and 11.5 sec 
<ogra> asac, is there any ETA for the NM fix on armel ? would be nice to have ir in the RD image
<ogra> *it
<ogra> *RC
 * ogra sighs about his typing
<asac> ogra: is there still time to get anythin on the RC CDs at all?
<ogra> slangasek, ^^^ ?
<slangasek> that depends entirely on what it is
<ogra> bug 356517
<slangasek> the NM fix - yes, I would like to get that in; is it ready for upload?
<ubottu> Launchpad bug 356517 in network-manager "NetworkManager does not detect eth0 on armel" [High,In progress] https://launchpad.net/bugs/356517
<slangasek> and even if it weren't in time for RC, better to have it in the queue if possible so we can take it opportunistically
<asac> ok. i will fast track right after what i am doing now
<pitti> slangasek: just for planning, is it okay for you if I upload apport after RC? (to disable itself by default)
 * ogra would prefer to not have to release note ifconfig calls :)
<slangasek> pitti: any chance that fix can get in /before/ RC?  That's where it's supposed to be according to the schedule
<pitti> slangasek: ok; I just thought we might want it on for the RC itself
<slangasek> asac: thanks.  btw, does ubufox still need updated to know to look at 9.04?  my cursory inspection of the source suggests it does
<asac> slangasek: the sources.list is "just" a backend thing for setting up the DB, but looking into this i found that the urls still have 8.04 as distributionID ... most likely was a typo
<nijaba> cjwatson: should the rt kernel flavor considered as maintained?
<slangasek> asac: does that mean there aren't changes that need to be made to ubufox to update it for a new release?  If so, I should take that out of te checklist
<asac> slangasek: anyway. what i am doing right now is finalizing fix for bug 353924 and bug 270303 (both committed)
<ubottu> Launchpad bug 353924 in ubufox "Offline home page always English (browser language hard-coded to en-US)" [High,In progress] https://launchpad.net/bugs/353924
<ubottu> Launchpad bug 270303 in ubufox "MASTER - firefox (intrepid): "your browser has been updated and needs to be restarted"" [High,In progress] https://launchpad.net/bugs/270303
<cjwatson> nijaba: no, you can tell because it's in universe/multiverse
<asac> slangasek: no we need to fix the distributionID url (also committed)
<slangasek> asac: okie
<nijaba> cjwatson: ah, right, I did not click on the link to check, sorry
<pitti> slangasek: okay; one-line change to disable apport by default is uploaded
<ogra> doko, i see that on armel doing an upgrade: http://paste.ubuntu.com/150705/ bug or not ?
<ogra> (it auto-opens the update-manager details window)
<slangasek> lool, ogra: I'm planning to defer initramfs-tools until post-RC, to not hold up all the respins much longer
<pitti> seb128: I can't say which of the two libproxy uploads is yours and which is mine; I just rejected one of them
<seb128> pitti: yeah, that's ok, those should be identic anyway ;-)
<slangasek> heh :)
<slangasek> pitti: stray 9_autotools.patch2 in this tracker upload; do you want to redo?
<pitti> slangasek: whoops; yes, I'll reupload
<pitti> slangasek: done; I also updated Vcs-Bzr:; thanks for pointing out
<asac> ogra: __ARMEL__ ?
<asac> ogra: can you please spin nm with this debdiff and give me an ack? http://paste.ubuntu.com/150727/
<ogra> asac, will do
<asac> ogra: cool. that would help us to not do another round ;)
<RicardoPerez> tkamppeter: Hi! I'd just posted a minor patch to fix a i18n issue in the system-config-printer applet. Could you take a look and apply the patch (if you think it looks ok)? I'm talking about bug #360621
<ubottu> Launchpad bug 360621 in system-config-printer "Applet menu options shows untranslated, albeit they're translated (patch supplied)" [Undecided,New] https://launchpad.net/bugs/360621
<tkamppeter> pitti, can we make a release freeze exception for the patch in bug 360621? It is a one-liner.
<ubottu> Launchpad bug 360621 in system-config-printer "Applet menu options shows untranslated, albeit they're translated (patch supplied)" [Undecided,New] https://launchpad.net/bugs/360621
<ogra> asac, hrm, that will take a while ... 115M build-deps ...
<pitti> tkamppeter: the patch makes sense; don't know about slangasek's plan for building CDs
<pitti> tkamppeter: please upload it anyway, so that it's in the queue; then it's quick to accept if we want it
<slangasek> probably post-RC
<pitti> slangasek: btw, did we ever consider renaming RC to "beta 2"? :-)
<slangasek> yuck
<slangasek> "probably post-RC" could also mean "probably SRU", if you prefer :)
<slangasek> pitti, didrocks: does the gtk2-engines change have any effect on our default theme?
<pitti> slangasek: no, we are using murrine by default; I switched to clearlooks for testing
<RicardoPerez> Thanks very much to everybody :)
<pitti> RicardoPerez: good job in chasing down i18n bugs
<didrocks> slangasek: it just contains others GNOME default themes (clearlooks, and so on.)
<RicardoPerez> pitti: I know I'm irritating about the i18n issues :) Sorry! :P
<pitti> RicardoPerez: no, you aren't; unfortunately it's just a bit late to get in changes
<didrocks> pitti: I switched to clearlooks too and didn't notice regression
<kwwii> pitti: I just noticed that the latest ubuntu-wallpaper package never made it into jaunty (it fixes a bug in the simple-ubuntu wallpaper in which the left pixels are transparent)...any chance of that making it into jaunty or at least an update right after?
<RicardoPerez> pitti: many thanks anyway :)
<slangasek> didrocks: well, pretty much by definition, "fixes" to the appearance of themes break the UI freeze ;)  So I want to be sure this doesn't cause changes to our default appearance
<pitti> kwwii: I saw the sponsoring bug today, but it's a bit late I'm afraid
<pitti> kwwii: I can upload it, but it might very well get rejected
<didrocks> pitti: I don't know if you notice but tracker has been rejected
<nijaba> cjwatson: does http://bazaar.launchpad.net/~nijaba/ubuntu-maintenance-check/trunk/revision/14 looks ok to you?
<pitti> didrocks: I know, I reuploaded it for the stray .patch2 and also added Vcs-Bzr
<tkamppeter> pitti, RicardoPerez, OK, will upload the fixed s-c-p
<didrocks> pitti: ok, thanks :)
<RicardoPerez> tkamppeter: thank you very much!
<cjwatson> nijaba: that grep syntax is bogus
<cjwatson> nijaba: I think you meant something like this: egrep -q "^linux-(headers|image|restricted)-"
<cjwatson> nijaba: (grep -> egrep, [] -> (), delete trailing * which is unnecessary here and anyway you meant .*)
<didrocks> slangasek: I didn't have noticeable regression, even with French strings. The new features seems to not add too much changes in UI itself
<cjwatson> nijaba: likewise, grep -q "\-[virtual|server]$"  ->  egrep -q "\-(virtual|server)$"
<nijaba> cjwatson: :/ right.  Passed my test, I do not know how
<asac> ogra: thought you have a big pipe ;)?
<cjwatson> nijaba: I think I would also use grep -q -- "-blah" rather than grep -q "\-blah"
<cjwatson> nijaba: other than that, looks ok
<cjwatson> nijaba: well, do you care about non-x86 architectures here?
<ogra> asac, nah, just an expensive one :P
<nijaba> cjwatson: hmm... do we have non x86 that are maintained?
<kwwii> pitti: right, it seems it wsa forgotten along the way
<cjwatson> nijaba: lpia, armel
<cjwatson> (maybe not in hardy, I forget the exact timeframes)
<kwwii> pitti: as the bug is only in the secondary wallpaper it should be fine if it gets included in an update after install
<cjwatson> nijaba: oh, also, why the two separate greps at the start, when the second is just a more specific case of the first?
<nijaba> cjwatson: well, would could be giving me details on this?  pgraner ?
<nijaba> cjwatson: no good reason, a left over
<cjwatson> nijaba: you could just say that lpia (flavour: "lpia") and armel (flavours: "imx51", "ixp4xx") kernels are supported and that won't fire if the kernels aren't present
<cjwatson> nijaba: but yes, pgraner
<asac> ogra: those build deps are good to have ;)
<ogra> yeah, its just that i have a freshly installed system here atm
<ogra> but i'm already in the middle of the build now
<cjwatson> ArneGoetje: could you merge lp:~cjwatson/langpack-o-matic/gnome-user-guide-recommends, please? It'll get rid of some entries on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt once the next batch of language packs are uploaded with it
<tkamppeter> pitti, s-c-p uploaded.
<asac> slangasek: i uploaded nm-applet togetgher with human-icon-theme for 358526
<asac> slangasek: waiting for ogra's confirm on the armel patch ... should happen soon too
<asac> (e.g. nm daemon upload)
<ogra> still building :/
<ogra> nijaba, armel is definately jaunty only yet, no hardy support back then
<nijaba> ogra: could you give me the output of 'dpkg -l | grep "$linux"' on an armel and lpia system if you have a sec?
<ogra> i dont have a lpia system around atm, but for armel i can
 * StevenK boots an lpia install
<nijaba> ogra: that would be great.
 * nijaba thanks StevenK
<ogra> nijaba, i assume you want the packages starting with linux-* ?
<nijaba> ogra: right
<ogra> (your grep logic above is a bit flawed :) )
<nijaba> ogra: I have not clue what the kernel packages look like on those system
<ogra> same as everywhere
<StevenK> Heh, yeah, '^linux'
<StevenK> ^ == start of line, $ == end of line
<ogra> http://paste.ubuntu.com/150756/
<nijaba> ogra: uh, right ^linux, not $ :(
<ogra> StevenK, wont work either :)
<ogra> the lines start with ii
<StevenK> Shhhh
<nijaba> ogra: dug
<nijaba> duh, even
<ogra> dpkg -l | cut -d' ' -f3 |grep "^linux"
<lool> slangasek: initramfs-tools is arch: all though
<slangasek> lool: it still has to get built, which would delay things another ~1h
<lool> Ok
<nijaba> ogra: thanks a lot.  so there is a bit of a mess, as -generic -> x86, -server -> x86, but -imx51 -> armel.  What will happen when we want an server flavor armel build?
<ogra> nijaba, in the above paste s/imx51/ixp4xx/ or s/imx51/versatile/ for the other two armel subarches
<ogra> i guess you would end up with something like: linux-image-2.6.28-11-server-$subarch
<ogra> not sure about the order, $subarch could come first
<lool> pitti: Hey
<lool> pitti: notify-osd 360989
<nijaba> ogra: ok, I'll worry about it later then...
<lool> pitti: I can't reproduce here, but perhaps you have an idea of what changed that makes $GDMSESSION be default.desktop for some installs and default for others
<slangasek> lool: is bug #349459 still a target for final?
<ubottu> Launchpad bug 349459 in cairo "Please provide a VFP-optimised build for cairo" [Medium,In progress] https://launchpad.net/bugs/349459
<StevenK> nijaba: http://paste.ubuntu.com/150762/
<lool> slangasek: I could upload it this week, otherwise either as a SRU or not at all, depending on importance of other issues
<nijaba> StevenK: great, thanks a lot.
<infinity> nijaba: The odds of having "-server" kernels on armel are pretty slim.  We don't have them on any !x86 arch because, in general, there's no real difference between, say, a sparc64 workstation and a sparc64 server, from the POV of what the kernel should support.
<pitti> lool: "default.desktop", really?
<infinity> nijaba: In the armel world, the very few armel "servers" out there (like the Marvell boards we're using as buildds) would be their own subarch anyway.
<ogra> well, you might want special generic server features enabled in the config
<ogra> stuff thats not actually arch related
<nijaba> infinity: what about NAS? I thought a lot of them were using arm?
<cjwatson> nijaba: I'm not aware of plans for such an image
<lool> pitti: That's for mdz
<cjwatson> oh, now that I press page down once more I see that others have already answered that
<lool> pitti: Mine uses default.desktop and has it in the gdm.conf as well
<cjwatson> nijaba: don't borrow trouble
<nijaba> cjwatson: I am not either, was just trying to deduce a global logic
<lool> pitti: Sorry mine says default
<lool> and has default.desktop in gdm.conf
<pitti> lool: right, that should be /usr/share/gdm/BuiltInSessions/default.desktop
<ogra> nijaba, i guess best is to grab the logic the kernel team uses for generating the names
<cjwatson> nijaba: don't try to invent a global logic in advance of the kernel team either - deciding on names for images is their prerogative
<cjwatson> ogra: there isn't anything set in stone
<ogra> sadly
 * cjwatson shrugs
<infinity> ogra: Most of the "server-related features" are enabled in x86 -generic kernels too. :)
<ogra> infinity, yeah, indeed
<infinity> ogra: The differences between -generic and -server aren't what most people expect, and are usually related to hardware support tradeoffs (like supporting massive amounts of RAM on -server, but fewer processor architectures, etc)
<nijaba> cjwatson: ok, for now any -(imx51|ixp4xx|versatile|generic)$ will be considered to be on the same maintenance cycle as Ubuntu.  will adapt if and when needed then
<infinity> ogra: Since in the armel world, subarches already cover those sorts of things, I doubt we'd ever need or want -server images.
<ogra> asac, works !
<nijaba> * -(imx51|ixp4xx|versatile|lpia|generic)$
<mdz> pitti: my only guess is desktop-switcher
<kwwii> wow, my jaunty system just fell apart...error 13 from grub, fsck problems, etc...how does one report a bug in this case?
<lool> mdz: Ah you used desktop-switcher?
<ogra> yeah i think so too, but i wasnt sure there might be things enabled you dont want on desktop but on server
<lool> mdz: it's know to cause breakage sadly
<ArneGoetje> cjwatson: will do
<slangasek> pitti: bug #352656 doesn't look critical enough to me to warrant a freeze exception; what do you think of pushing this to SRU?
<ubottu> Launchpad bug 352656 in compizconfig-backend-gconf "Ignores GNOME preferred terminal application setting" [Low,Fix committed] https://launchpad.net/bugs/352656
<slangasek> pitti: (is it regression-potential?  it's not marked as such)
<infinity> nijaba: To be honest, your better bet is probably just to find linux-image\* in Component: main on all arches, and there's your list.
<pitti> will always have the
<pitti>         <filename>$GDMSESSION</filename> set to the basename of the
<pitti>         session that the user chose to run without the
<pitti>         <filename>.desktop</filename> extension.
<pitti> slangasek: I don't know whether that worked in intrepid, I'm afraid
<nijaba> infinity: if I do so, we would be saying that we maintain -rt, -xen, etc for 3y, so it does not work
<pitti> lool: it seems it's meant to not have .desktop
<slangasek> pitti: ok; without a clearer justification, I'm inclined to reject
<cjwatson> nijaba: -rt and -xen are not in main
<infinity> nijaba: linux-image-xen is in universe.
<cjwatson> (though you should check Component: restricted too)
<infinity> (Not that I'd mind us supporting it...)
<pitti> slangasek: ok; I'll reopen the bug then
<nijaba> cjwatson: and security, and updates
<cjwatson> nijaba: those are not components, so no
<infinity> nijaba: security and updates are pockets, not components.
<lool> pitti: Ok, we should have written this in gdm.conf in the first place
<nijaba> cjwatson: but my problem is that if I search for a specific kenel version, that has been updated after initial release, I will not find it in main
<lool> pitti: If you look at daemon/slave.c:4644, gdm strip .desktop only for user session
<lool> pitti: Not for configured or fallback sessions
<nijaba> cjwatson: hence my current logic to go around this
<mdz> njpatel: do you have any ideas on bug 360989?
<ubottu> Launchpad bug 360989 in notify-osd "notification-daemon started instead of notify-osd in Netbook Remix" [Undecided,New] https://launchpad.net/bugs/360989
<slangasek> nijaba: well, those kernels by definition are also not "supported" for security, you have to instal the renamed one to get security support ;)
<lool> pitti: This is patched in debian/patches/35_gdm.conf.patch, but even the upstream default config file uses .desktop there
<ogra> lool, shouldnt it actually use the Exec= line from the .desktop file instead of the name ?
<lool> mdz: Could you attach your .dmrc?
<pitti> lool: I'm fine with updating the d-bus service test accordingly if you want
<mdz> lool: done
<lool> pitti: Yes, I think we should fix: gdm to strip .desktop, gdm to default to default and not default.desktop and notify-osd to asked default.desktop
<lool> mdz: dthanks
<mdz> (it's empty)
<pitti> lool: perhaps not all three, with the freeze being really close now?
<lool> mdz: Mine has [Desktop]\nSession=default
<lool> mdz: Which is why GDMSESSION is correct here
<ogra> it is only written if you manually selected a session
<ogra> similar to gconf behavior
<lool> pitti: Agreed, probably only notify-osd change for RC
<mdz> lool,pitti: just to confirm, I don't think this is an RC issue
<lool> pitti: I can do it if you like
<mdz> it's the sort of thing I expected from integrating notify-osd late
<lool> mdz: Could you explain what you ran though?  Did you run desktop-switcher?
<pitti> with slangasek just shutting the doors, we probably can't get it into RC, but we might get it post-RC or SRU
<lool> mdz: I wonder what changed your .dmrc or created mine differently
<mdz> lool: I don't remember, I haven't touched the machine in over a week
<ogra> usually its only a DM that writes .dmrc
<pitti> lool: sure, please go ahead, and coordinate with slangasek about rc/final/sru
<mdz> lool: my .dmrc is dated today
<mdz> around the time I rebooted the system after installing updates
<njpatel> mdz: desktop-switcher doesn't touch session files (just /gnome/session/required_components gconf list)
<lool> mdz: I think it's written my gdm when you chose a session on the login screen
<ogra> right, and only then
<mdz> lool: I've never even *seen* the login screen on this system
<mdz> it's always been autologin
<mdz> njpatel: thanks, I've copied that into the bug
<lool> mdz: It's probably written every time, I mentionned login screen to explain the use case
 * ogra wonders if asac noticed his success message
<koperton> hi i have made a simple bash script ; to work it shoul be in the /usr/bin . so now i have only to create my debian package . i have read this  http://ubuntuforums.org/showthread.php?t=852023
<koperton> and i have create
<koperton> d
<koperton> but ... it install nothing
<directhex> koperton, #ubuntu-motu
<koperton> ok
<koperton> sorry for that
<slangasek> asac: you saw ogra say that your NM patch fixed the problem?
<asac> slangasek: yes. uploaded
<slangasek> great
<asac> so now i am ready for RC
<asac> ogra: ^^
<ogra> yippie !
<asac> just verified that it really doesnt includew the code on non ARMEL ;)
<asac> s/doesnt includew/does run/
<ogra> heh
<seb128> slangasek: we will probably need an another apport update
<ogra> just wanted to say ...
<seb128> slangasek:
<seb128> $ ubuntu-bug --package gedit --pid $(pidof gedit)
<seb128> Usage: /usr/bin/ubuntu-bug <pid>|<packagename>|<program path>|<.crash file>
<seb128> slangasek: that breaks the launchpad integration menu entries in all desktop applications there
<slangasek> seb128: er, and when did that regress?
<asac> good. finally no new bugs ;)
<seb128> dunno, that was mentionned in this glchess email yesterday on the list
<seb128> and somebody else pointed on #ubuntu-desktop right now that it's broken in any applications
<seb128> and I can confirm that here
<seb128> "  * debian/local/ubuntu-bug: Drop generic passthrough of apport-{cli,gtk,kde}
<seb128>     options since this leads to too much confusion. Instead just support a
<seb128>     single argument and check whether it is a pid, a package name, a .crash
<seb128>     file, or a program path. This does the right thing when calling it with a
<seb128>     .crash file (LP: #347392) and fixes the help output (LP: #344923) Update
<seb128>     manpage accordingly."
<seb128> I guess
<seb128> 0.148
<seb128> which was 2 weeks ago
<slangasek> pitti: ^^
<slangasek> superm1: mythbuntu seed doesn't look any better wrt notif*
<asac> cdimage.u.c seems to be down from here :/
<slangasek> asac: 358526> human-icon-theme touches a lot more ISOs than I realized, due to ltsp; so I'm going to defer that one for the moment, possibly until post-RC
<OsamaK> Hello. I found some typos in the Arabic docs, is it possible to fix that? (the 'freeze' is in action).
<asac> slangasek: ok, i think its fine (with me) ... please consider it as a ride along if more ISOs need to be respun though.
<asac> i will let the dxteam know, so they dont bug me "RC images still have this bug" ;)
 * slangasek nods
<Ampelbein> seb128: i don't think this is a problem directly in apport but from how liblaunchpad-integration calls ubuntu-bug as the options were changed there. http://paste.ubuntu.com/150786/ should fix that in the liblaunchpad-integration.
<seb128> Ampelbein: not really
<seb128> $ ubuntu-bug gedit $(pidof gedit)
<seb128> Usage: /usr/bin/ubuntu-bug <pid>|<packagename>|<program path>|<.crash file>
<seb128> Ampelbein: we need both option because gnome-sudoku needs a --package gnome-games for example
<directhex> whoopsie. bug 361049 is the result of insufficient packager testing
<ubottu> Launchpad bug 361049 in monodoc "monodoc-base: missing NDesk.Options.dll" [Undecided,New] https://launchpad.net/bugs/361049
<Ampelbein> seb128: ah, ok.
<cjwatson> OsamaK: it might be possible to do it post-RC
<cjwatson> OsamaK: are the fixes committed somewhere?
<pitti> seb128, slangasek: re (sorry, was at lunch)
<seb128> pitti: wb
<pitti> seb128, slangasek: could we change lp-i to call s/ubuntu-bug/apport-gtk/ ?
<seb128> pitti: is lpi using out of GNOME? ie is -gtk always right?
<pitti> seb128: alternatively, we could just call ubuntu-bug <pid>
<slangasek> pitti: well, changing either package requires full respins; so whichever is most correct
<pitti> or I need to change ubuntu-bug to accept all options again, which is more intrusive, though
<slangasek> and I think this should be post-RC, at this point
<pitti> slangasek: post-RC> ack
<pitti> seb128: apt-cache rdepends liblaunchpad-integration1 is only gnomeish
<pitti> but still, using ubuntu-bug would be nicer
<pitti> phone, brb
<seb128> pitti: would <pid> work on the case where you need to specify a package? ie gnome-sudoku will match gnome-games?
<seb128> pitti: I think the reason why we have --package <package> --pid <pid> right not is those cases
<pitti> seb128: the major reason for supplying --package is that it's more efficient
<pitti> seb128: if you supply pid, it looks up the executable, and then the package with (the equivalent of) dpkg -S
<pitti> seb128: wouldn't that work for sudoku?
 * pitti tries
<seb128> pitti: that should, I'm just trying to figure why we have this extra api and call --package if not required
<pitti> seb128: as I said, it speeds it up a bit
<pitti> confirmed that ubuntu-bug <pid> DTRT for sudoku
<seb128> right, I tried here too
<seb128> so you recommend just not using --package or calling apport-gtk rather?
<seb128> is lpi called out of GNOME and would apport-gtk be still right in those cases?
<pitti> seb128: right now, lpi is only called for gnomeish things, but also for e. g. pidgin
<pitti> I prefer calling ubuntu-bug over apport-gtk, since that has built in DE detection
<seb128> which is a gtk application so apport-gtk is ok
<seb128> ok
<seb128> want to do the lpi change?
<pitti> right, it would just not work if you'd install pidgin under KDE and don't have apport-qt installed
<pitti> seb128: I think I'll go with changing the ubuntu-bug calling semantics
<pitti> s/semantics/arguments/
<pitti> this is a safe one-liner and keeps the semantics
<seb128> ok thanks
 * seb128 hugs pitti
<pitti> slangasek: I'll upload this, and we can accept it after RC, or before if we need to rebuild anyway; okay?
<slangasek> pitti: yes
<pitti> sorry for having screwed that up, I didn't think about checking lpi
<pitti> seb128: do you know if there's a bug for this?
<seb128> pitti: bug #360470 is that I think
<ubottu> Launchpad bug 360470 in gnome-games "glchess relies on bug-buddy to report bugs, as a result "Report a problem" does nothing" [Low,Incomplete] https://launchpad.net/bugs/360470
<Ampelbein> pitti: bug 353503 also
<seb128> pitti: the title is misleading, what it really means is that apport doesn't run where it should
<seb128> bug #353503
<ubottu> Launchpad bug 353503 in yelp "Report a Problem menu choice non functional" [Low,Incomplete] https://launchpad.net/bugs/353503
<pitti> Ampelbein: thanks
<pitti> I'll make the first a dup of the second
<Ampelbein> there are some more i have spotted.
<Ampelbein> which should become the master?
<Ampelbein> 353503?
<pitti> Ampelbein: yes, just made it the master
<pitti> Ampelbein: if you find more, marking them as dupes is appreciated
<Ampelbein> will do
<pitti> seb128: this WFM: http://paste.ubuntu.com/150805/
 * pitti restores tabs (which shouldn't be there in the first place, argh)
<seb128> pitti: the change looks good to me
<seb128> hum wait
<pitti> eww, the bzr branch is out of date
<seb128> pitti: will "launchpad-integration --package gedit" display the assertion in this case?
<pitti> launchpad-integration --package gedit -b
<pitti> works fine
<pitti> seb128: the assert is only for cleanliness
<pitti> $ launchpad-integration  -b
<pitti> AttributeError: 'NoneType' object has no attribute 'binarypackage'
<pitti> it fails way before that
<seb128> ok
<seb128> good
 * seb128 hugs pitti
 * pitti commits dokos' uploads to bzr first
<seb128> yeah, known issue, doko doesn't bother update bzrs when doing changes ;-)
<pitti> meh, it doesn't even build
<elmo> could someone seed openssl-blacklist in hardy, please?
<elmo> cjwatson: ^-- ?  (not sure, if there's a better way/place to report such low priority things; I realise this is not the best time to be asking)
<Ampelbein> pitti: talking about launchpad-integration? i'm not a developer, but wouldn't http://paste.ubuntu.com/150830/ do the trick?
<pitti> Ampelbein: not that part, the -dbg package gets files into /usr/local
<seb128> Ampelbein: <pitti> seb128: this WFM: http://paste.ubuntu.com/150805/
<pitti> and I need to fix that
<superm1> pitti, your change wrg to notify-osd only showing up in gnome stopped it showing up in xfce on mythbuntu too.  i was wondering if you had any ideas how to get it there now?  it seems if we remove notification-daemon it shows up, but it's going to be hard to remove notification-daemon since it gets pulled in via libnotify1 when building CDs
<pitti> superm1: depends on owhether you want it in xfce, I figure?
<pitti> superm1: you should be able to remove the package, though
<superm1> pitti, well in mythbuntu we do - i dont know if cody-somerville wants it in xubuntu too
<pitti> notify-osd satisfies Recommends: notification-daemon
<superm1> pitti, slangasek recommended moving notify-osd to the top of our seeds and seeing if the the publisher just doesn't pick notification-daemon, but it still got picked up i'm guessing by dependency resolution order
<pitti> superm1: if xfce wants to use notify-osd as well, we could also change the dbus service file accordingly
<slangasek> pitti: xubuntu doesn't
<superm1> oh :(
<cjwatson> elmo: done
<elmo> cjwatson: ta
<superm1> slangasek, well looking at livecd-rootfs, mythbuntu odesn't use the tasks for building the live disk, but uses the meta packages.  i think this was because w/ tasks, all of gnome got pulled in by dependency resolution.  so what if a conflicts is put on mythbuntu-live?  would that do the trick you think?
<slangasek> superm1: depends how accomodating apt wants to be at the time, I guess
<superm1> slangasek, okay i'll try to do some experiments emulating what livecd-rootfs does in a chroot then and see what apt thinks about it
<ogra> calc, around ?
<superm1> pitti, i just talked to cody-somerville and mr_pouit in #xubuntu-devel and they appear to be fine with bringing notify-osd into xfce now
 * pitti arghs and wonders why lpi suddenly installs files into /usr/local/lib/python
<pitti> superm1: ok; that needs a notify-osd upload, though
<pitti> or, we just use seeding everywhere for now
<superm1> pitti, it's already seeded at least for mythbuntu
<superm1> pitti, i think that .service file is what needed adjustments then?
<pitti> right
<seb128> pitti: python bug, didrocks had the same issue with gnome-applets apparently
<seb128> pitti: that might be fixed with the update from this morning, doko or slangasek knows about the details I guess
<pitti> probably, but I presume we can't get a fixed python in time, so I'll do a debian/rules workaround
<pitti> I'll try
<seb128> pitti: are you update with the version from today?
<pitti> probably not
<slangasek> python is already "fixed", AIUI
<Tonio_> jcastro: about the UDS, I confirmed to claire, as suggested, you weren't in copy
<Tonio_> jcastro: should I forward to you then ?
<jcastro> Tonio_: nope, that's fine, thanks for the heads up though
<Tonio_> jcastro: no pb... I was a bit late, but I needed confirmation from my company, since I just announced I was leaving ;)
<Tonio_> form the company I mean... ;)
<ogra> Tonio_, so i'll see you in barcelona ?
<Tonio_> ogra: yup, sponsored again ;)
<ogra> i wonder from where you take all that bribing money every time :P
<pitti> slangasek, seb128: thanks for the hint; now I get files in site-packages/, but at least not usr/local any more
<slangasek> site-packages, not dist-packages? :(
<Tonio_> ogra: hehe :)
<pitti> slangasek: right
<ogra> Tonio_, btw, i think i saw you on german TV recently
<ogra> in a report about FOSDEM
<pitti> there was a previous upload to correct this, but apparently it doesn't work any more
<Tonio_> ogra: hu ?? ah !
<Tonio_> with my broken foot ?
<ogra> what did you do with your leg ?:)
<ogra> ouch
<Tonio_> ogra: during FOSDEM, my left  foot was brone
<Tonio_> broken
<slangasek> pitti: does gnome-applets use the python.m4 from automake to detect python paths?
<ogra> yeah, i noticed something was wrong with it
<pitti> slangasek: I don't know, I'm working on launchpad-integration
<slangasek> oh
<slangasek> pitti: does lpi "" "" "" ? :)
<Tonio_> ogra: everything's fine now, hopefully
<pitti> there's no python.m4 in the code anyway
<ogra> great :)
<slangasek> pitti: are there python path checks in a configure script?
<pitti> and no hits with grep for python.m4
<slangasek> pitti: what I'm getting at is that aclocal had a buggy macro before which has only now been fixed, so re-autotools might fix this
<slangasek> and smell better than hard-coding a hack in debian/rules
<pitti> slangasek: ah, I'm still installing today's upgrades (I just started with python)
<pitti> there's a new automake etc. coming in
<pitti> slangasek: I'm doing full autoreconf anyway, bzr only has the .am/configure.in bits
<slangasek> ok
<calc> ogra: pong
<pitti> seems that was it; yet another example why I advocate debian/patches/99autotools.patch instead of doing it at build time
<ogra> calc, is see http://paste.ubuntu.com/150705/ on my systems ... while that doesnt make dpkg fail, it enforces update-manager to open the details window ...
<doko> pitti: the aclocal.m4 needs to be regenerated
<pitti> right, it's working now after dist-upgrade
<pitti> slangasek: launchpad-integration uploaded for bug 353503
<slangasek> pitti: ack; post-RC
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/353503/+text)
<pitti> *nod*
<calc> ogra: hmm thats very strange i didn't change anything regarding that between 9ubuntu2 and 9ubuntu3
<ogra> well, its a freshly installed system from before easter, geeting its first upgrade run today
<slangasek> calc: the espa-nol you had me sync had an unsatisfiable build-dep :(
<Keybuk> pitti: is the core file not in the .crash file?
<pitti> Keybuk: it is
<pitti> Keybuk: if you have a .crash file, you can use apport-unpack to get it
<Keybuk> oh there it is, encoded in an rfc822 header :p
<slangasek> content-type: ELF/multipart
<Keybuk> pitti: great, thanks
<tseliot> pitti: would this change in nvidia-common break jockey? http://launchpadlibrarian.net/25455321/nvidia-common_0.2.10.debdiff  (bug #303825)
<ubottu> Launchpad bug 303825 in nvidia-common "linux-image-2.6.27-9-generic failed to install/upgrade : run-parts: /etc/kernel/postinst.d/nvidia-common exited with return code 10" [High,In progress] https://launchpad.net/bugs/303825
<Keybuk> pitti: we should probably teach apport about upstart's strange core dump behaviour
<Keybuk> pitti: or does it know about it already?
<pitti> tseliot: from a first look, it shouldn't
<pitti> Keybuk: it doesn't special-case upstart in any way right now; what should it do?
<Keybuk> pitti: Upstart will always crash in a syscall to sigprocmask() in the crash_handler() function
<Keybuk> it basically catches the SEGV, and lets a child process crash on its behalf
<Keybuk> so the real cause of the crash is whatever was happening when the SEGV signal handler ran
<pitti> Keybuk: so you want it to unwind the stack trace until that point for dup detection?
<Keybuk> yeah
<pitti> Keybuk: apport already does stack unwinding for some situations
<tseliot> pitti: ok, thanks, I'll make an SRU then
<Keybuk> if you look at bug #358915 it looks like it picked on the top-level function called from the main loop
<Keybuk> rather than the real function
<ubottu> Launchpad bug 358915 in upstart "init crashed with SIGSEGV in event_poll()" [Medium,Incomplete] https://launchpad.net/bugs/358915
<calc> slangasek: ah crap :( will look at it after i get my report written (~ 10m)
<slangasek> calc: I've already uploaded what should be a fix
<slangasek> just waiting for another release teamer to review it
<Keybuk> admittedly, I can find no reason *WHY* this crashed from this core file
<Keybuk> but it's always worth making back traces nicer :p
<slangasek> (actually, probably waiting until after RC)
<calc> slangasek: ok sorry for the problem :(
<ogra> ogra@osiris:~/Devel$ free
<ogra>              total       used       free     shared    buffers     cached
<ogra> Mem:       3087916    2993664      94252          0      34624    1902964
<ogra> -/+ buffers/cache:    1056076    2031840
<ogra> Swap:      4803392    4803384          8
 * ogra screatches head what the hell uses all that swap on his system
<pitti> Keybuk: so where in http://launchpadlibrarian.net/25186204/Stacktrace.txt should it unwind to, for StacktraceTop?
<ogra> i dont run anything special ... evo, ff, four terminals and xchat
 * slangasek giggles
<Keybuk> #3  job_change_goal (job=0x7f70bacdb1e0, goal=JOB_STOP,
<Keybuk>     emission=0x7f70bacd8ff0) at job.c:703
<Keybuk> 	__FUNCTION__ = "job_change_goal"
<Keybuk> pitti: that's the "crashing" function
<slangasek> ogra: I think it's probably evo, ff, and xchat
<Keybuk> the one immediately below the "<signal handler called>" thing
<pitti> I think in the past I considered unwinding to <signal handler called>
<ogra> slangasek, well, top reports X and ff with around 400M VIRT usage each ... the rest of the processes looks relatively calm
<pitti> but I didn't do it, since with that we'd miss crashes in signal handlers
<pitti> (although that's much less likely)
<ogra> nothing in the three digit area
<Keybuk> pitti: makes sense; this is somewhat upstart-magic since it *catches* SIGSEGV <g>
<Keybuk> very few programs do that
<slangasek> ogra: tmpfs?  sysv shm?
<pitti> Keybuk: what I'd like to see is package hooks being able to specify further unwinding; that keeps the facility general
<pitti> Keybuk: perhaps you can open a bug against apport with this example, and how the StacktraceTop should look like?
<Keybuk> pitti: sure
<ogra> ogra@osiris:~/Devel$ df -h|grep tmp
<ogra> tmpfs                 1,5G     0  1,5G   0% /lib/init/rw
<ogra> tmpfs                 1,5G  8,2M  1,5G   1% /dev/shm
<ogra> looks calm as well
<ogra> killing evo got me 34M back from my swap
<ogra> killing FF only got me 1M more free space
<ogra> hrm
<Keybuk> how much video memory do you have?
<ogra> its my lappie with intel card ... so none actually ... in BIOS 128M (maximum) shared videoram are set
<ogra> ok, closing everything but one gnome-terminal and xchat still only gets me 42M free
<ogra> i start to suspect the intel driver leaks somewhere
<ogra> that would also explain why i see system lockups after several days without any trace in any logs
<ogra> simply because i hit OOM
<Keybuk> so 128M of X's memory will be that
<ogra> yes, but what is eating 4G of swap
<ogra> on a system only having xchat and a terminal open
<ogra> opening and closing evo doesnt really show a change in that footprint ... same goes for FF
<ogra> Mem:   3087916k total,  2969868k used,   118048k free,    70652k buffers
<ogra> Swap:  4803392k total,  4774848k used,    28544k free,  2373076k cached
<ogra> oh !
 * ogra just notices he is running metacity while he ran compiz earlier today
<ogra> looks like it switched
<ogra> Mem:   3087916k total,  1409668k used,  1678248k free,    75592k buffers
<ogra> Swap:  4803392k total,     9972k used,  4793420k free,  1073884k cached
<ogra> hmm
<ogra> switching compiz back on crashed X immediately ... now my swap is freed up
<slangasek> superm1: are you adding a conflicts to mythbuntu?  I think that's the only thing blocking a reroll of mythbuntu images at the moment (assuming the X bugs aren't getting more love before RC...)
 * cjwatson successfully installs to a virtio device. Nice ...
<superm1> slangasek, if i add it, it will be right after RC.  i need to make sure it actually works in a chroot yet, but that won't be until later today
<ogra> mumble
<slangasek> superm1: ok, so I should go ahead with mythbuntu RC rolling?
<superm1> slangasek, but otherwise wubi bug has been fixed, so rerolls are fine
<superm1> yeah
<cody-somerville> How is Ubuntu handling X's poor auto-detection of DPI?
<seb128> it forces 96 dpi
<cody-somerville> Okay, thanks.
<cjwatson> ah, yes, if Xubuntu isn't doing that then that would explain the installer difference
 * cody-somerville nods.
<cody-somerville> superm1, ^^ You might be interested in doing the same.
<superm1> cody-somerville, yeah we are forcing 100dpi actually (since the most common case for us is TVs)
<cody-somerville> Okay.
<superm1> we're doing it via our gdm-cdd.conf.
<superm1> we did however get a complaint about doing it this way, that on displays that are supposed to have rectangular pixels, they are square
<superm1> bug 151310 i believe
<ubottu> Launchpad bug 151310 in mythbuntu "-dpi 100 forces square pixels even on 16:9 display with 4:3 pixel resolution" [High,New] https://launchpad.net/bugs/151310
<slangasek> Keybuk: hmm, but bootchart-java has other deps that aren't (and never have been) in main; is pybootchartgui really that bad?
<Keybuk> slangasek: I prefer the -java output
<Keybuk> slangasek: though if those deps were not in main, how was bootchart in main previously?
<slangasek> I don't know
<Keybuk> or has somebody promoted bootchart to main without an MIR?
<slangasek> the intrepid version didn't dep on them
<Keybuk> what are the deps?
<Keybuk> java build system changes perhaps?
<slangasek> libcommons-cli-java, libcommons-compress-java
<slangasek> maybe
<calc> StevenK: stick it in a large bag of rice ;-)
 * calc would probably completely disassemble it and manually dry and then stick it in rice like the other poster mentioned :)
<Keybuk> slangasek: it's honestly a surprise to me that bootchart is in main ;)
<slangasek> Keybuk: been there since dapper or earlier; but if you think that's /wrong/, demoting it is a real easy fix for the component-mismatches pain. :)
<Keybuk> looks like Tollef did an initial MIR for it way back in the day
<Keybuk> I think that it's ok to be in universe, it's not something we install by default
 * Keybuk is not a subscriber to main-or-bust
<ogra> but please make -java the default dep
<rgreening> bug 361185 requires ack
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/361185/+text)
<cody-somerville> What can cause SIGUSR2?
<geser> kill -s USR2
<cody-somerville> Thats odd because I'm seeing a crash in the Live CD when clicking the logout button with SIGUSR2 in Xubuntu
<geser> I don't know if any other reason exist that such a signal might get send
<cjwatson> Seeker`: what does it take to get the logs at http://www.novarata.net/mootbot/ updated? Is it just a manual rsync or something? If so, could you please do one (if you're still the right contact for mootbot maintenance)?
<cjwatson> Seeker`: I've been waiting for logs from a meeting on 4 April to appear there so that I can write up minutes with reference to them
<Seeker`> cjwatson: will give the relvant person a prod
<superm1> slangasek, if a solution isn't identified for the intel freezes and mythtv segfaults, will reverting to mesa 7.3 be out of the question before jaunty at this point?
<slangasek> superm1: a full revert would not be my first choice, but if necessary we could look at it
<superm1> slangasek, okay.  i'm going to attempt a second bisection then at least to identify a second round of commits that are bad (i've got one set so far)
<cjwatson> Seeker`: thanks. For future reference, whom should I talk to?
<jpds> cjwatson: nalioth runs the server.
<cjwatson> aha, thanks
<cjwatson> TheMuso: do you understand bug 360530? dm-raid45 does seem to be added to the initramfs
<ubottu> Launchpad bug 360530 in dmraid "On first boot "Gave up waiting for root device"" [Undecided,New] https://launchpad.net/bugs/360530
<_2eXtreme> hey guys, with regards to risk management, can anyone give me a few examples of risks that would arise in a development project that you are working on by yourself? im writing a report for a personal project, and i need to get some examples of what risks are so that i can get an idea of what a risk is, and then identify the ones i have encountered. please help, i dont know anything about risk management, but i ne
<directhex> _2eXtreme, risk: getting sued by microsoft for patent violation
<_2eXtreme> directhex, am i right in thinking that risk management is one of things where you just write a load of b***s**t, like one of the boring business sides of software dev that no one really cares about?
<directhex> _2eXtreme, bingo!
<directhex> _2eXtreme, and bill the client for Â£180 an hour, that's an important step
<_2eXtreme> directhex, can i say taht a change in requirements could be one?
<directhex> _2eXtreme, yes, especially late in development
<_2eXtreme> directhex, cool, so, are there any websites that sort of...tell you about example risks?
<ebroder> How do the Ubuntu buildds get at the .ddeb before the build chroot is thrown away, if it doesn't get added to the .changes file?
<cjwatson> ebroder: I believe it's just copied out by hand at the end of the build; it would need to be added to the .changes file if .ddebs were processed by Soyuz, but they aren't
 * ebroder nods
<infinity> ebroder: It's a violent and hideous hack best not described.
<infinity> ebroder: But, yes, the ultimate goal is to make soyuz accept them as part of the upload, and then they'll be added to .changes.
<martinw> christel: you said quite a few times in public that you are quite happy that you know young, male lawyers who are falling for you. you said your mom told you it would be smart to be a little bit flirty with them
<martinw> christel: and i think its quite obviousy why that is quite smart, when you and your staffy friends dont stick to your own policy.
<martinw> christel: you make Freenode be your own little dating site
<martinw> its a shame
<hyperair> martinw: /me doesn't see anything said by christel.
<martinw> sabdfl: i hope you are proud to invest money in form of donations to a hobby like Freenode. Rob Levin wanted this network to be different than other IRC networks and dedicated to Free Software
<martinw> but what current staffers made of this is a shame, really
<hyperair> martinw: exactly what are you talking about?
<martinw> sabdfl: maybe we get a live interview some day that show what unethical behaviour you supported
<martinw> and what you have in mind to justify it
<hyperair> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<martinw> i am very curious
<bizkut> where2
<ebroder> Anyone from the security team who could look at bug #356861? These vulnerabilities have been in the wild for over a week now
<ubottu> Launchpad bug 356861 in openafs "OpenAFS Security Advisories 2009-001 and 2009-002" [Undecided,Confirmed] https://launchpad.net/bugs/356861
<kees> ebroder: yup, know about.  if anyone is prepared to do the patching and testing, we'd be happy to publish updates.
<ebroder> kees: We have patches for Hardy, Intrepid, and Jaunty
<ebroder> Although Anders and I would both prefer to see 1.4.10 synced in for Jaunty, if that's possible
<ebroder> Hmm...did Anders post an actual patch for Intrepid? I can generate one if he didn't
<ebroder> I guess not. I'll do that now
<kees> ebroder: it's very late in the release cycle, you'll need to get a freeze exception.  https://wiki.ubuntu.com/FinalFreeze
<kees> ebroder: as for the others, please see https://wiki.ubuntu.com/SecurityUpdateProcedures (once patches exist, marking it as "In Progress")
<ebroder> kees: Ok, thanks
<ebroder> kees: If we just take 1.4.9 in Jaunty instead of 1.4.10, do you still need the debdiff or can that be done as a sync from Debian?
<ebroder> Oh, hmm...1.4.9 seems to have been booted out by 1.4.10. Never mind
<kees> ebroder: if you want to fix it in jaunty with a patch (like done for intrepid, hardy, dapper), that's fine.  if you want 1.4.10, you'll need to go through feature freeze and final freeze exceptions with approval from the motu-release team.
<andersk> How likely is such an exception to be approved?  I assumed not very likely, which is why I posted a minimal 1.4.9 package.
<RicardoPerez> slangasek: Hi! Too late for a very simple patch to fix an i18n issue?
<slangasek> RicardoPerez: too late for RC; for final, it will depend on how simple
<RicardoPerez> slangasek: it's a oneliner. the bug is #361312
<RicardoPerez> (sorry, bug #361312)
<ubottu> Launchpad bug 361312 in computer-janitor "Some strings shows untranslated, albeit they're translated (patch supplied)" [Undecided,New] https://launchpad.net/bugs/361312
<RicardoPerez> very very simple, as you can see
<slangasek> yes, that looks appropriate, either for post-RC or for an SRU
<RicardoPerez> slangasek: great news :)
<RicardoPerez> I don't know if I need to assign a developer & status
<NCommander> slangasek, we're doing a minor seed change in Xubuntu to close #278763 and I'd like to run the seed diff by you just to make sure its alright so we don't need to worry about breaking Xubuntu so close to release: http://paste.ubuntu.com/151041/
<slangasek> RicardoPerez: if you need an uploader for it, then you need to subscribe ubuntu-main-sponsors
<RicardoPerez> slangasek: Ok, I'll do that just now
<RicardoPerez> slangasek: thanks a lot, cheers
<slangasek> NCommander: given that these transitional packages all exist and are usable, I don't see that this change is really warranted this late
<NCommander> slangasek, fair enough, I'll slate the change for karmic
<slangasek> NCommander: it would be good if when karmic opens, we can get a solution to the fact that core-dev don't have commit access to the xubuntu seeds, so that we can get changes merged over in a timely fashion
<NCommander> slangasek, xubuntu seeds are managed by the xubuntu-devel team
<slangasek> yes, they are
<NCommander> They were changed mid-intrepid to lp:~xubuntu-dev/ubuntu-seeds/xubuntu.jaunty
<slangasek> and they're not tracking the changes in the ubuntu seed, where this change was made months ago
<slangasek> those are changes I would push out with my RM hat on, if I could commit to the seed
 * NCommander just realized I read what you originally said backward
<NCommander> *sigh*
<ebroder> Anyone from motu-release around? How likely are we to get a freeze exception to sync in 1.4.10 of openafs from Debian? (for bug #356861)
<ubottu> Launchpad bug 356861 in openafs "OpenAFS Security Advisories 2009-001 and 2009-002" [Undecided,In progress] https://launchpad.net/bugs/356861
<jpds> ebroder: You might want to subscribe motu-release to the bug.
<kees> ebroder: and check with #ubuntu-motu
<ebroder> Sure - I'm just trying to get a sense of which way I should push the bug. I'll ask #ubuntu-motu
<philsf> I have some spare time now, if any devel wants to test something for Jaunty
<siretart> bryce: have you considered downgrading the intel driver to the 2.4 branch for jaunty?
<siretart> bryce: I've compiled it locally for me, and I feel it behaves much better than 2.6 branch in jaunty. and even in fact better than the 2.7 one.
<bryce> siretart: have you read the IntelPerformance page I wrote?
<siretart> bryce: no, where can I read about it?
<bryce> siretart: also did you know we're in FinalFreeze, so even if we wanted to do that, it couldn't be done?
<bryce> see the Ubuntu-X wiki, it's linked from the Troubleshooting section
<siretart> bryce: I'm imagining a new package 'xserver-intel-xorg-intel-2.4' that conflicts/replaces the intel driver in some PPA
<bryce> siretart: feel free to set something up
<siretart> https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance
<siretart> bryce: I think I have such a package ready..
<bryce> please add a link to your ppa from that wiki page, in a new section on reverting to 2.4
<siretart> hm. I haven't tried this in intrepid, so I cannot say if it's a regression, but...
<siretart> ... when enabling compositing in metacity, moving a gnome-terminal window (and only gnome-terminal) is unbelievably slow
<siretart> is that known/expected?
<bryce> you could check launchpad but it's not an issue I've heard before
<bryce> although I think not so many people use metacity+compositing yet
<walters> siretart: do you have the transparent background enabled?
<bryce> in general composite on intel seems to have a performance regression, so perhaps that's it
<siretart> walters: no
<siretart> I know it was fine with compiz
<siretart> but for some reason, compiz doesn't love me anymore in jaunty :( - still investigating that
<bryce> siretart: most tricks and tips and workarounds we know of are listed on that wiki page fwiw
<siretart> reading that page now...
<siretart> bryce: okay, I've just uploaded my xserver-xorg-video-intel-2.4_2.4.1-1ubuntu11~ppa1_source.changes package to my ppa - pending publishing
<siretart> I'll head of to bed right now, I'll do some more testing tomorrow
<bryce> ok cool
<bryce> siretart: don't forget to update the wiki page with info on your package, so others can make use of it
<bryce> I pretty much point everyone that complains about intel performance issues to that page, so that way they'll find your packages easily
<bryce> siretart: thanks for putting that backport together
<siretart> that's rather a forward port than a backport, no? ;-)
<siretart> bryce: btw, I had to add 2 patches to get that beast built against libdrm 2.4.5...
<bryce> true, forward port ;-)
<bryce> siretart: not surprising
<siretart> wow
<siretart> I managed to get compiz started
<siretart> and moving gnome-terminal is as expected. only metacity's compositing manager breaks it
<siretart> s/breaks/makes it unusable/
<siretart> HA! same performance as in intrepid again. yay
<siretart> even planetpenguin is playable, though it's better without compiz
<siretart> anyway, I can sleep now tightly. cu tomorrow!
<TheMuso> cjwatson: that doesn't appear to be a dmraid bug to me, it looks like its something to do with mdadm.
<cjwatson> TheMuso: I initially made it mdadm, but the nvidia_blah stuff in the error message looks like dmraid, and mdadm doesn't seem to do anything with raid45 (only raid456)
<TheMuso> cjwatson: hrm ok, will take another look. I find it kinda hard to work with screenshots.
<TheMuso> cjwatson: in the modules screenshot I don't see raid45, and if it were for dmraid it would be dm-raid4-5
<neruda> any plans for a vmware image?  I tried to virtualize 8.0.4 (64bit) with vmware server and found out the hard way that vmware cripples all of its free products?
<neruda> ?=!
<cjwatson> TheMuso: it's not in the modules screenshot, but the "CRW_1325.jpg" attachment shows a screenful of these two errors repeated:
<cjwatson> TheMuso: device-mapper: table: 252:0: raid45: unknown target type
<cjwatson> TheMuso: device-mapper: ioctl: error adding target to table
<cjwatson> TheMuso: and then at the end: device-mapper: ioctl: unable to remove open device nvidia_ddbfdieb
<cjwatson> TheMuso: so that seems to be the most immediate problem
<cjwatson> TheMuso: "raid45" does show up in dmraid's source ...
<TheMuso> hrm ok, I need to find out whether he chose to use a dmraid array at install time and some info about the array.
<TheMuso> cjwatson: thanks for that
#ubuntu-devel 2009-04-15
<DrCheese> Linux and Ubuntu is cancer that attaches itself in an intellectual property sense to everything it touches.
<DrCheese> Linux and Ubuntu is cancer that attaches itself in an intellectual property sense to everything it touches.
<ScottK> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<Hobbsee> damn lag.
<ScottK> Thanks.
<Hobbsee> \o/ win!
<ajmitch> wasn't even a very creative troll
<cjwatson> beat me to it
 * Hobbsee ^5 cjwatson
<jdong> is today official troll day?
<Hobbsee> seems so
<ScottK> He could of at least claimed we were insecure or something.
<Hobbsee> well, now he's claiming that i can't see him, so...
 * TheMuso wonders whether DrCheese created #windows, however I can't seem to see the topic or names without going in there.
<jdong> why does that IP look familiar.
<Hobbsee> TheMuso: highly unlikely.  People who create large channels are usually too busy to petty troll.
<Hobbsee> @btlogin
<infinity> Hobbsee: It's not a large channel, he's in ##windows, not #windows.
<infinity> Hobbsee: Although, even that's moderately large, actually.
<Hobbsee> infinity: ah, i didn't do a whois to check.
<jdong> Hobbsee: part of the big MA Comcast DHCP pool; identifying him is probably hopeless.
<Hobbsee> jdong: ah yes, you should recognise that IP.  check the BT.
<jdong> Hobbsee: I don't have access to it, do I?
<jdong> ah I see it.
<jdong> yeah I should've recognized that indeed.
<Snova> ?
<jdong> frequent customer.
<Snova> Heh.
<jdong> Snova: ubuntu-ops log 4/13 and 4/08
<emgent> hallo
<Hobbsee> and under the other aliases.  Here's a cross-channel hammer
<ScottK> Comcast generally gives you the same IP for each lease renewal, so unless he knows how to ask for a new one, it should ~work.
<jturek> has anybody found that the ATI Mobilitiy cards (X2300) doesn't detect in restricted drivers in jaunty
<jturek> i seem to not be able to get ubuntu to use the restricted driver manager for teh ati x2300
<jturek> clear
<dholbach> good morning
<Amaranth> dholbach: wow you're up early
<dholbach> hiya Amaranth - it's 7:34 - and I was out running already! :-)
<Amaranth> ah, right, dang daylight savings
<siretart> bryce_: wiki edited
<bryce> siretart: great
<superm1> slangasek, i've got a resolution for bug 355242 that involves only a 2 line diff
<ubottu> Launchpad bug 355242 in mesa "mythfrontend.real crashed with SIGSEGV in QGLWidget::resizeEvent()" [High,Fix committed] https://launchpad.net/bugs/355242
<superm1> mythbuntu rc disks will need a re-roll with it
<slangasek> superm1: it's a patch to mesa?  That implies invalidating all the ISOs
<superm1> slangasek, perhaps can you just reroll mythbuntu after the others have been verified then?
<slangasek> we can consider that.  it does effectively mean we don't get jigdo support for the RC, but if we time it fairly close then we can at least get some jigdo benefit
<tjaalton> slangasek: there's also a candidate for the wacom crashes, but it's still untested so not meant for RC
<slangasek> ok
<pitti> Good morning
 * slangasek waves
 * siretart bounces happily through the channel - finally working intel driver..  :-)
<pitti> siretart: oh, what did you change?
<siretart> pitti: see my latest post to ubuntu-devel. I've reverted to the 2.4 branch
<pitti> siretart: interesting; that still works with current X then?
<siretart> pitti: you need to compile it against jaunty's X and libdrm, which works with some patching.. :-)
<siretart> working packages can be found in my ppa
<siretart> well, at least WFM
<Mirv> cody-somerville: hi, do you have plans to fetch xubuntu-docs translations from rosetta and upload a new xubuntu-docs with those included?
<wgrant> Is there a non-historical reason for USNs to list Xubuntu but not other unofficial flavours as affected?
<RAOF> Has anyone else recently seen dbus-daemon go crazy, consume a core, and all available memory (it's up to 1.6GiB, and still rising)?
<Keybuk> RAOF: something sending it a lot of timing out messages?
<Keybuk> dbus-monitor is your friend
<RAOF> Hello, tracker!
<RAOF> Hm.  Apparently tracker would like to tell me that my index is corrupted.
<liw> does tracker work for anyone else? it's never done anything useful for me :(
<lifeless> liw: using all your cpu is useful
<Keybuk> we don't even install it by default now
<lifeless> liw: it tests your cpu
<Keybuk> and I'm pretty sure it's removed by update-manager on upgrade
<directhex> ta dholbach
<siretart`> Keybuk: I can confirm that update-manager didn't remove it on my amd64 desktop last week when I upgraded from intrepid->jaunty
<mvo> I can ensure that it gets removed if thats what we want
<siretart`> +1
<mvo> (sorry, I have not followed the state of tracker)
<seb128> mvo: we decided again doing that in a systematic way because some users are using it
<liw> Keybuk, it didn't get removed from my laptop, actually
<mvo> ok
<RAOF_> Keybuk: Thanks; looks like the bug is tracker spamming "OMGINDEXCORRUPTED" messages into the void.
<liw> I'd love to have something like tracker, if it didn't hog my computer and actually found things when I search
<seb128> tracker will probably be better next cycle
<liw> good to hear
<seb128> the jaunty version is basically a rewrite, it still has some issue but gets lot of work
<siretart`> RAOF_: where does it spam to?
<seb128> nokia is paying to get it working fine on their device apparently
<Keybuk> seb128: is there going to be a rewrite to use fsnotify instead of inotify?
<liw> fsnotify?
<liw> ah, some new kind of implementation, good
<Keybuk> liw: lwn.net/Articles/311350
<seb128> Keybuk: that I don't know, but now it's possible to have applications pushing datas rather than the indexer going through the disk all the time
<seb128> Keybuk: ie your mailed can send datas to tracker when receiving emails rather than relying on inotify to go through the disk emails
<seb128> mailed -> mailer
<RAOF_> seb128: Do we actually have the evolution side of that system in jaunty?
<seb128> no ;-)
<seb128> the new version is still new, I expect it to work better
<seb128> I would not bother too much with the jaunty version
<seb128> there is frequent db corruptions and still issues
<Keybuk> ah
<cody-somerville> wgrant, Xubuntu *is* an official flavour :)
<cody-somerville> Mirv, I'd like to, yes.
<liw> evolution db corruptions? never :)
<Keybuk> one of the neat features of fsnotify/fanotify is that a watching application gets a file descriptor to the data just written/read
<Keybuk> so you don't need to stat(), open(), etc. massively saving on overhead
<seb128> liw: no, tracker db corruptions ;-)
<wgrant> cody-somerville: It's no more official ('supported', I suppose the correct term is) than Mythbuntu or UbuntuStudio, is it?
<liw> Keybuk, can fsnotify do things like "show me everything that ever changes in this filesystem" or "...inside this directory tree"?
<seb128> liw: btw have you seen this bug about computer-janitor using update-manager as translation domain?
<Keybuk> liw: in theory, yes
<liw> seb128, I have; I haven't investigated yet, I'll have to discuss the gettext domain issue with mvo
<Mirv> wgrant: not supported by Canonical, but official (like Mythbuntu, Ubuntu Studio)... it's good to refer to those as official as there are also unofficial Ubuntu variants like Eeebuntu, Ubuntu ME etc..
<Keybuk> liw: fanotify is by-filesystem rather than by-file/directory
<seb128> ok
<liw> Keybuk, Ã¼bercool!
<wgrant> Mirv: True. But my point is that it's odd to single out Xubuntu.
<liw> I'm going to have to add support for that in my backup program
<Mirv> wgrant: yes, regarding your actual point, it's probably just historical, there have been other such cases as well
<Keybuk> liw: inside-this-directory-tree is harder, in that you'd have to read the filename and strncmp or something ;)
<liw> Keybuk, that'd be one way; I'd have to benchmark whether it'd be faster to scan the directory tree and remember all inodes and then compare with indoes that change
<Keybuk> liw: I can't imagine that it wouldn't be faster ;)
<Keybuk> though the overhead for a smaller directory of processing and discarding unwanted events could be high, I guess
<cody-somerville> wgrant, I'm not sure what their status is
<liw> Keybuk, depends on size of tree and number of changes, but I'm too stupid to know which is faster without benchmarking
<pitti> lool: you'll upload the fix for bug 339466 to the queue?
<ubottu> Launchpad bug 339466 in python-debian "cron.weekly script produces a warning since the Python 2.6 transition" [Medium,Triaged] https://launchpad.net/bugs/339466
<slangasek> pitti: bug #361543 for you :(
<ubottu> Launchpad bug 361543 in apport "/etc/default/apport mistakenly installed as /etc/default/apport.default" [Undecided,New] https://launchpad.net/bugs/361543
<pitti> owch
<slangasek> cody-somerville: is there a technical-overview-esque page for Xubuntu to link from https://wiki.ubuntu.com/JauntyJackalope/TechnicalOverview for RC?
<slangasek> Riddell: will there be an RC technical overview for Kubuntu as well?
<tseliot> mvo: are you around?
<mvo> tseliot: yes
<tseliot> mvo: any ideas on this? https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/351394
<ubottu> Launchpad bug 351394 in nvidia-common "nvidia -177 needs to be transitioned to -180 on upgrade" [High,Triaged]
<mvo> tseliot: let me have a look
<tseliot> mvo: also, what driver version do you migrate to "nv" in Jaunty?
<tseliot> s/version/versions/
<lool> pitti: I was waiting for some ubuntu-release ack
<lool> pitti: (I sub-ed the team yesterday)
<pitti> lool: you got it
<pitti> cjwatson, evand: yay, thanks for fixing the default grub target; in the beta I still had to change it from (hd0) to my USB stick (sdc), now it automatically DTRT
<lool> pitti: Yup, uploaded
<cody-somerville> slangasek, There shall be.
<slangasek> Riddell: https://wiki.ubuntu.com/JauntyJackalope/RCAnnouncement is up for consideration, pulling in the same kubuntu text from the beta; please let me know if changes are needed
<Riddell> slangasek: good with me
<pitti> seb128: did you have any problems with the retracers last week? they seem surprisingly stable now
<pitti> seb128: I remember some weird HTTP errors, but no real crashes any more
 * pitti -> offline, CD testing
<AstralJava>  /join #ubuntustudio
<AstralJava> bah
<sabdfl> gosh, reading scrollback for martinw
<sabdfl> how is everyone here today?
<ogra> busy testing ;)
<slangasek> up at strange hours, right on schedule :)
<ogra> slangasek, i see no 14.2 respin for armel desktop, did you forget us ?
<slangasek> sabdfl: martinw == Patrick Frank, fwiw; he has Issues with Authority :/
<slangasek> ogra: didn't forget, just got caught up getting other things squared away - I'll do the ports run now
<sabdfl> me too! i'll try and chat privately with him when he comes online
<ogra> thanks, i'll test it ;)
<seb128> pitti: no, good work ;-)
<lool> cjwatson: What would be the right seed to list redboot-imx51-babbage
<lool> cjwatson: We use it to build the official images, but it's not pulled by any package and the package itself is not included in any media, only its contents
<cjwatson> lool: I'd say platform.jaunty/supported-installer-common then
<lool> Ok, thanks
<ScottK> siretart: I gather your adventure in Intel bleeding edge stuff did not have a happy ending?
<siretart`> ScottK: for my laptop, yes, I'm happy with the 2.4 branch on my laptop
<ScottK> siretart: Weren't you also testing the latest 2.6?
<siretart`> ScottK: jaunty ships some later revision of the 2.6 branch. I've tried the 2.6 HEAD, 2.7 HEAD and 2.4 HEAD
<siretart`> ScottK: I got the best results from the 2.4.1 package with bryce's patches as found in intrepid
<siretart`> ScottK: having said this, I'd suggest to include my package in universe for people like me.
<ScottK> I see.  Some Gentoo guy was recently telling me that his had recently gotten better with the bleeding edge stuff.
<ScottK> siretart: As long as you're willing to support it for the life of Jaunty, I think it's a great idea.  Otherwise a PPA might be better.  What do you think?
<siretart`> yes, 2.7 is a big improvment on my laptop compared to 2.6. but still hasn't acceptable performance
<seb128> siretart: where do you notice those slowness issues?
<siretart`> ScottK: I'm willing to integrate updates from intrepid-updates to the package, yes.
<siretart`> ScottK: I'm not familiar with the code to actually start hacking on
<siretart`> seb128: compiz and planet-pengiun-racer are not usable at all.
<ScottK> siretart: OK.  The only issue then would be any -security issues that come up after Intrepid eol
<seb128> what in compiz?
<seb128> normal actions, ie alt-tab switch
<siretart`> seb128: resizing windows, the expose effect, alt-tab switch, etc.
<seb128> hum ok
<seb128> I guess it's not that slow on my card
<siretart`> seb128: alt-tab switch was unnaceptable in metacity with compositing as well
<seb128> I was just wondering if people were using extra features which showed the issue
<ScottK> siretart: Did you try Option "MigrationHeuristic" "greedy"?  While it's still not up to Intrepid, I find it usable.
<siretart`> ScottK: err - I'm not suggesting to put it in main but universe. and for universe we don't promise security (or other) updates at all
<ScottK> siretart: True.
<siretart`> ScottK: no, I haven't tried that option
<ScottK> siretart: You might.  I understand it makes some people have crashes so is not suitable for a default, but it made a huge difference for me.
<ScottK> For me it's like uxa without crashes.
<siretart`> is that option for the 2.4 branch or 2.6 branch?
<ScottK> Either as I understand it.
<siretart`> hm
<ScottK> siretart: Bug #359600 has some information
<ubottu> Launchpad bug 359600 in xserver-xorg-video-intel "Solved slow 2D performances with EXA" [Wishlist,In progress] https://launchpad.net/bugs/359600
<siretart`> I've been testing the 2.6 and 2.7 branches both with UXA
<ScottK> We had it for default for a while in Intrepid, but didn't keep it, so it must be for both.
<siretart`> so I cannot really comment on EXA. EXA was more than unacceptable for me in 2.6, and I didn't even bother trying it in 2.7
<ScottK> I see.  It made a huge difference for me with exa.
<ScottK> siretart: For a new package you'll need two motu-release acks.  You have mine to get you started.
<siretart`> ScottK: okay. who else from motu-release is around here? :-)
<slangasek> ScottK: I don't know of any reports of crashes due to greedy migration being enabled, but the patch to xserver-xorg-video-intel to /try/ to enable it by default for those chips causes crashes
<slangasek> the only issue I've found with greedy migration here is pixmap lossage
<slangasek> (firefox in particular likes to go black in patches)
<Lure> slangasek: I have also noticed some black areas with greedy (but not to the level that I would go back to non-greedy ;-))
<pochu> to which package should I reassign a bug in the nvidia binary driver?
<directhex> which version?
<tseliot> pochu: nvidia-graphics-drivers-$VERSION (where VERSION is 180, 173 or 71)
<directhex> tseliot, there are only three nvidia-graphics-drivers now?
<tseliot> directhex: I forgot 96
<directhex> that's better ;)
<directhex> tseliot, so, anything worth having in the 185 betas, that you know of?
<pochu> tseliot: ty
<tseliot> np
<pitti> Keybuk: nice, the current c't (famous German computer magazine) has a 3-page article about upstart
<tseliot> directhex: mainly fixes for VDPAU and support for new cards: http://www.nvnews.net/vbulletin/showthread.php?p=1976912
<directhex> tseliot, neat
<tseliot> directhex: only for Karmic and/or backports to Jaunty though
<directhex> tseliot, my main issue currently is trying to get actual audio out the hdmi port on an nvidia 9300 motherboard. it appears non-trivial
<tseliot> directhex: isn't that something that alsa/pulseaudio should deal with?
 * tseliot > lunch
<directhex> tseliot, oh, yeah, sure. but i can't get a bloody thing via speaker-test. and it's hell trying to get sound out of assorted command-line alsa utils which all use totally different device naming syntax
<Keybuk> pitti: got a url/translation?
<pitti> Keybuk: it's not online, just in the paper magazine
<pitti> Keybuk: http://www.heise.de/ct/inhalt/2009/09/176/
<dholbach> soren: ever used kvm for testing images and ran into "kvm: 27711: cpu0 unhandled wrmsr 0xc0010117 data 0"?
<dholbach>  amd64 dvd ubiquity install hanging at 78% "System locale is being configured" (or something like that)
<soren> dholbach: That could very well be unrelated.
<soren> dholbach: I consider those messages debug messages more than anything.
<dholbach> soren: ok, I'll re-test and see what happens
<soren> dholbach: The guest kernel sometimes pokes at various MSR's to see if there's something there, and that gets logged by the host kernel. Most of the time, it's benign.
<soren> Most of the time.
<slangasek> ScottK, Riddell: does the Kubuntu KDE4 remix warning on https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes still apply in the case of upgrades to 9.04?
<ogra> hmm, so 24h later i see my system starting to eat my swapspace again ... it went from 0M to 264M within the last 30min, without me doing anything special or additional to what i did 1h before
<ogra> (i have htop running constantly since i ran out of swap yesterday )
<ogra> heh, and between me starting to type the above and now it went to 379M swap usage
 * ogra closes evo and firefox
<ogra> (only xchat and two terminals are open now, system is at 429M swap usage)
<slangasek> ogra: how's the armel candidate ISO looking, BTW?
<ogra> livesession is fine, install is at 57%
<ogra> no unknown bugs seen yet
<ogra> sabdfl, good push for the new TZ map, it looks a lot better now
<Riddell> slangasek: I think that can go
<sabdfl> ogra: thanks to kwwii and evand's work, i agree
<Riddell> evand: know anything about this?  http://pastebin.ubuntu.com:80/151367/  when running OEM mode
<evand> Riddell: not until now.
 * evand digs
<evand> thanks sabdfl
<Riddell> evand: davmor2 says that didn't happen yesterday
<Riddell> has anything changed since then?
<evand> it happened in 1.12.5
<evand> fix incoming
<Riddell> evand: does this affect kubuntu only?  or ubuntu desktop too?
<evand> kubuntu only
<davmor2> Riddell: I just done ubuntu oems
<slangasek> Riddell: it can go because 8.04->9.04 is only a supported path for kde, not kde4 remix?
<Riddell> slangasek: right
<slangasek> ok
<Riddell> slangasek: OEM broken on Kubuntu desktop CDs ^^
<slangasek> waah
<Riddell> evand: also reboot didn't seem to be working at the end of a Kubuntu install
<evand> Riddell: where did it break?  Did pressing the button not do anything, or did the computer fail to restart after shutting down?
<Riddell> evand: ubiquity quit, desktop sits there being itself
<evand> hrm, ok.  I'll pull down the latest Kubuntu daily-live and see if I can reproduce it.
<cjwatson> sorry about the OEM breakage, apparently my fault way back in 1.12.0
<cjwatson> I have the Kubuntu image here, I can have a look ...
<evand> ah great
<evand> should I go ahead and upload this change and we'll deal with the reboot issue as another upload?
<cjwatson> my instinct is to batch it up for post-RC, since we have some other changes for then anyway
<cjwatson> Riddell,slangasek: what do you think?
<davmor2> slangasek: get it in now before there are many tests on it :)
<Riddell> I'm tempted to upload the OEM fix and respin that for RC
<cjwatson> I'd kind of like to fix the colours on the Kubuntu partition bars too
<davmor2> cjwatson: I though that got fixed
<cjwatson> not to my knowledge
<slangasek> I don't like shipping the RC with broken OEM mode, but doing a respin now cuts into our testing time and our image prepublishing time
<cjwatson> Riddell: is #133d80 a plausible Kubuntu-blue colour to use for the partition bars?
<Riddell> kwwii's area really ^^
<kwwii> erm, where?
<davmor2> slangasek: there aren't that many test on kubuntu are there
<kwwii> cjwatson: that is a pretty kubuntu-ish color, but it might be too dark bepending on where/how it is used
<slangasek> davmor2: rerolling kubuntu includes rerolling DVDs, which takes > 1.5h just for the livefs rebuild
<Riddell> slangasek: toss a coin :)
<slangasek> Riddell: is it acceptable to you to ship the RC without a usable OEM mode?
<Riddell> yes, it's not the end of the world
<slangasek> ok, then that's my preference
<Riddell> I'm just mindful that it's not well tested so if there's further problems (and davmor2 had issues yesterday) they won't be picked up
<slangasek> we can make images available immediately post-RC for testing, then?
<Riddell> we can indeed
<Riddell> and we have alternate OEM to test
<cjwatson> kwwii: bug 348461, though I don't have a screenshot to hand unfortunately
<ubottu> Launchpad bug 348461 in ubiquity "Jaunty: Kubuntu shouldn't use grey for the installed system bar in ubiquity" [Undecided,New] https://launchpad.net/bugs/348461
<Riddell> evand: bug 361668
<ubottu> Launchpad bug 361668 in ubiquity "kubuntu OEM mode broken" [Undecided,New] https://launchpad.net/bugs/361668
<cjwatson> I can explicitly test Kubuntu OEM immediately post-RC, since we need to update the oem-config timezone map anyway
<cjwatson> or, indeed, I can test it now with evand's fix
<kwwii> cjwatson: ouch, without seeing the problem it is pretty hard for me to just suggest a color :(
<cjwatson> let me see if I can produce a screenshot
<kwwii> cjwatson: the blue you suggested fits well with kubuntu colors so testing it can't hurt
<kwwii> I could download a CD and test it myself but that would take a bit
<cjwatson> nggh, partition bars are still invisible in Kubuntu?
<kwwii> I have to take my son to the dentist, bbiab...I'll read the log when i return
<robbiew> doko: do you think we can fix bug 353704?
<ubottu> Launchpad bug 353704 in ia32-libs "Wrong path for lib plugins in amd64 build" [High,Triaged] https://launchpad.net/bugs/353704
<robbiew> doko:   it breaks Skype on amd64, is it feasible to fix in an SRU of 9.04
<doko> robbiew: I think Bo is fixing this
<davmor2> Riddell, slangasek: right so the out come is we can carry on testing the images that are up, and you'll do a respin friday (or something) for us to nail all the oem issues is that correct?
<ogra> argh
<slangasek> davmor2: yes
<ogra> slangasek, gdm sudeenly crashes on babbage/imx51
<davmor2> slangasek: Cool :)  Cause I just finishe ubuntu desktop :)
<ogra> install went flawless
 * ogra checks what seb128_ changed between beta and now in gdm :/
<seb128_> no
<slangasek> looks like Robert's the one who changed it
<ogra> no ?
<seb128> what changed?
<ogra> ah
<slangasek> though it could be a library regression, rather than the gdm change
<ogra> seb128, i get the "greeter is crashing, trying with another greeter" message in gdm suddenly
<seb128> slangasek: the change he did was a one line boolean logic for the hours format combo
<ogra> yeah, that doesnt really look like it could cause anything
<seb128> ogra: that means the greater is crashing, could be any library gdm is using or xorg
<slangasek> that patch doesn't touch the greeter, so probably not
<seb128> do you get apport triggering? anything in the logs about a crash?
<ogra> noting in Xorg.0.log ... inspecting the rest atm
<ogra> i see 7usr/bin/gdm in the processlist
<pitti> slangasek, bryce: I updated the "known issues" bits on https://wiki.ubuntu.com/JauntyJackalope/TechnicalOverview#Known%20issues with the workarounds known to me (we have a few more crashers, but they involve patching the driver, which is a bit out of scope for release notes); does that look okay to you, or is it too technical?
<ogra> gdm log only has xkbcomp messages ...
<ogra> nothing in /var/crash
<slangasek> pitti: it's the wrong place for it; bugs that aren't fixed for final should be documented at https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes
<slangasek> pitti: I can take care of porting that over, though
<pitti> slangasek: ah, I'll move it over
<pitti> slangasek: I guess it doesn't hurt to also keep it on TechOverview, for the RC?
<slangasek> if the tech overview will go up on the ubuntu.com website again, then we should have it ready for final, i.e., eliminate duplication w/ the release notes
<pitti> slangasek: your lock on ReleaseNotes timed out, are you still working on it?
<slangasek> pitti: no
<lool> I am suspicious that this gdm issue might be cause by the gtk+2.0 issue
<lool> we'll confirm soon
<pitti> slangasek, bryce: okay, put on https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes now
<slangasek> thanks
<slangasek> lool: right, I wondered...
<ogra> what irritates me here is that i indeed get a gtk window telling me the greeter cant start
<dholbach> soren: can you join #ubuntu-testing?
<ogra> lool, slangasek same thing with new gtk
<lool> ogra: Could you try moving away your /usr/lib/vfp?
<dholbach> soren: I'm having the same issue again (amd64 jaunty host, jaunty guest): freeze during the installation - how best to debug it?
<lool> ogra: sudo mv /usr/lib/vfp /usr/lib/vfp.bak
<ogra> same thing
<lool> ogra: Does dbus run?
<lool> On my install it doesn't
<ogra> yes
<lool> Can't start Hardware abstraction layer - please ensure dbus is running
<seb128> if you log in, can you run gdmthemetester?
 * ogra tries startx
<seb128> or gdmflexiserver
<ogra> one sec, just installing sshd
<ogra> btw, i cant stop gdm with the initscript
<dholbach> kirkland: hiya - can you join #ubuntu-testing so we can chat a bit about kvm on amd64 jaunty? I'm having hangs during test installations
<kirkland> dholbach: during language pack en ?
<ogra> hmm, startx does nothing now
<ogra> ah, its just slow
<ogra> ~/.xsession-errors has nothing special
<ogra> no panel though
<seb128> your install seems to be busted
<ogra> my live session runs flawless
<ogra> and my install i did from beta was upgraded yesterday
<ogra> and worked flawless as well
<seb128> so what is not working?
<ogra> my desktop doesnt come up with startx
<ogra> gdm pops up the "greeter is dying, trying another one" msg
<ogra> hmm, and avahi doesnt seem to work, i cant ssh into the .local address ...
<seb128> you say it waorsk flawless and that it crashes and doesn't run at normal speed
<seb128> I'm confused now
<ogra> i just did an install from a fully working livesession
<ogra> after reboot i hang at the greeter message
<ogra> killing gdm and running startx only gets me a wallpaper
<ogra> the testinstall i did with the beta image was upgraded yesterday and didnt show any issues
<seb128> ok, so maybe that new install is busted in some way
<ogra> i see nothing in the gdm or xorg logs
<ogra> the .xsession-errors file looks fine as well
<seb128> that's not gdm specific apparently if you get only the desktop and no normal session
<ogra> yes
<seb128> is your lo interface working correctly?
<seb128> ping localhost
<bigon> slangasek: hi, could you please accept my new telepathy-mission-control upload? (I've rerun libtoolize to fix FTBFS)
<seb128> ping 127.0.0.1
<ogra> works fine
<seb128> ok so that's not that
<ogra> nope
<slangasek> bigon: a bit occupied at the moment
<seb128> if you run a non GNOME session and try running nautilus or something there, what happens?
<ogra> whats that, startx --xterm ?
 * ogra totally forgot how to do that manually
<ogra> ah, well ... i'll create an .xsession file
<ogra> aha, running nautilus from the xterm segfaults
 * ogra tries gnome-session
<ogra> hmm
<seb128> can you get a nautilus stacktrace?
<ogra> x-session-manager[7681]: WARNING: Application 'gnome-wm.desktop' failed to register before timeout
<ogra> x-session-manager[7681]: WARNING: Application 'gnome-panel.desktop' failed to register before timeout
<ogra> doe that look ok ? ^^^
<seb128> those are only warnings but that's nor normal
<seb128> can you get the nautilus stracktrace?
<ScottK> slangasek: The release not on does not boot with Intel D945 is still relevant, but needs rewording as the problem is much more widespread than we knew at Intrepid release time.  It needs to be generalized, but I'm not at all certain how to word it.
<ogra> will try to
<ScottK> not/note
<ogra> i dont get a metacity either though
<slangasek> ScottK: right, I remembered that was why the release-notes bug was open; I don't know how to word it, either
<ScottK> slangasek: My recommendation would be: "It's a kernel bug, give it to the kernel team to figure out how to word it".
<ScottK> After all, an action passed is an action completed. ;-)
<slangasek> heh
<pitti> slangasek, ScottK: is universe frozen as well? I'm currently sponsoring bug 340085 (fatal issue), and I'd like to shepherd it through the queue
<ubottu> Launchpad bug 340085 in pymol "Pymol Doesn't Initialize after Upgrading to Python 2.6" [High,New] https://launchpad.net/bugs/340085
<ScottK> pitti: motu-release is reviewing stuff.  If you're happy, I'll give it an advance ack and go for it.
<jussi01> hrm, Ive found a bug in usb-creator, can someone tell me which package is missing from the deps? http://paste.ubuntu.com/151418/
<ScottK> siretart: Are you still around?
<siretart`> ScottK: yes
<ebroder> ScottK (or other motu-release types) - if I ask for an FFE to sync openafs 1.4.10 from Debian (bug #356861), am I likely to get it?
<ubottu> Launchpad bug 356861 in openafs "OpenAFS Security Advisories 2009-001 and 2009-002" [Undecided,In progress] https://launchpad.net/bugs/356861
<ScottK> siretart`: One other issue I thought of for Intel 2.4 is the Fedora compiz hack will be an issue for KDE users of your package.
<ScottK> siretart`: http://www.kitterman.org/ScottK/2009/01/bug_254468_momentary_video_gar.html for details.
 * siretart` looks
<ScottK> siretart`: Do you think it might be possible to provide two binaries (one with/one without) in your package?
<ScottK> ebroder: Assuming the title of the bug is accurate, yes.
<pitti> ScottK: motu-release sub'ed
<ebroder> ScottK - Version 1.4.9 was released to fix the security vulnerabilities. We're asking for 1.4.10 because it has other bugfixes in addition to the security patch
<ScottK> ebroder: Is it just bugfix and have you tested it?
<ebroder> ScottK: I haven't tested it personally; I believe Anders has. I can check with him
<siretart`> ScottK: according to your blog, the patch is in xorg-server. I'm touching the intel driver only, not the xserver
<ScottK> siretart: Right.  Nevermind then.  I got confused.
<ScottK> Sorry for the distraction.
<ebroder> ScottK: I can do testing before asking for the FFE; I just wanted some sense of if it was likely to be granted before I put the work in
<ScottK> ebroder: My sense it that if you move quickly a favorable response is likely.
<ScottK> it/is
<ebroder> ScottK: Ok. I'll do that then. Thanks
<siretart`> ScottK: aah, but thanks for the pointer. I've encountered it in intrepid when unlocking gnome-screensaver as well, but couldn't really describe the issue.
<ScottK> pitti: He's a motu, so I've ack'ed it and he can upload it.  Thanks for pointing it out.
<siretart`> now things are more clear
<ScottK> The good news it the patch it dropped in Jaunty, so case closed.
<ogra> lool, you bumped the version numbers in the arm p3a ?
 * ogra tries to get back to the original gtk libs before giving seb128 qa stacktrace
 * ogra doesnt get why the livesession works fine 
<lool> ogra: i should have
<lool> ogra: But if you moved /usr/lib/vfp away it doesn't make any difference
<ogra> hmm
<ogra> still, why does the livesession run flawless ?
<pitti> ScottK: oh, great
<ogra> lool, its also weird that avahi doesnt seem to function even though i see it in the processlist
<lool> ogra: You mean on your network?
<ogra> yes
<lool> ogra: I think it relies on multicast, and I don't trust that too much with our current network drivers
<ogra> ssh babbage.local doesnt work
<ogra> it worked before
<ogra> i *only* use it
<ogra> and never had any probs
<ogra> in this install i can only ssh in by IP
<ogra> seb128, here is an strace output for you ... http://people.ubuntu.com/~ogra/nautilus-stacktrace.txt
<seb128> ogra: I meant gdb backtrace
<ogra> yes, i know
<ogra> coming next
<cjwatson> kwwii: http://people.ubuntu.com/~cjwatson/tmp/kde-partitioner.png
<kwwii> cjwatson: that is easy, let me pick the color from the current kde4 theme
<ogra> seb128, http://people.ubuntu.com/~ogra/gdb-nautilus.txt not really nuch
<seb128> #0  0x40bed6e8 in memcpy () from /lib/vfp/libc.so.6
<seb128> #1  0x40f9c1c8 in ?? () from /usr/lib/libpng12.so.0
<seb128> ogra: seems to be a libpng issue
<seb128> lool: ^
<seb128> ogra: you might want to install the corresponding -dbg and get a valgrind log
<kwwii> cjwatson: #509de8
<lool> ogra: Could you move /lib/vfp out of the way to be sure?
<ogra> it is moved
<kwwii> Riddell: I took that from the Oxygen theme, it should fit fine, or?
<lool> ogra: /lib, not /usr/lib
<rgreening> cjwatson: ping
<cjwatson> rgreening: yes?
<lool> ogra: Cause the backtrace shows /lib/vfp above and I want to exclude it
<ogra> oh, ok
<cjwatson> kwwii: ok, thanks
<rgreening> cjwatson: it appears that during the alt install (using daily cd) that the lpia image fails to detect dhcp during install
<cjwatson> rgreening: can I see logs please?
<kwwii> cjwatson: I added that to the bug as well, for clarity
<rgreening> cjwatson: any suggestions?
<cjwatson> rgreening: go back to the installer main menu and select "save debug logs"; you'll be able to extract it to a USB stick
<rgreening> cjwatson: ah. ok.,
<ogra> lool, ergh ... moving /lib/vfp now tells me "nautilus command not found"
<cjwatson> syslog is the one I need
<lool> ogra: run ldconfig as root, ubt I don't see why it would matter
<lool> ogra: Perhaps you have some I/O issues
<ogra> lool, using the full path gets me the segfault again though
<ogra> i indeed did run ldconfig first
<seb128> install the libpng dbg and get a valgrind log?
<lool> It shouldn't matter too much, it's just a cache
<rgreening> cjwatson: ok, I don't have my lpia system here.. I have to run home to get. But I have another user with same issue... jussi01.
<ogra> why the heck does it run in the livesession
<ogra> with identical libs and apps
<rgreening> jussi01: are you able to help get the logs from the lpia during install?
<cjwatson> my guess is a missing network module
<seb128> ogra: your install might be corrupted somewhere, disk issue, ram issue, install glitch
<rgreening> cjwatson: ok, I may have to run home... so I can check back in an hour or so if thats the case.
<ogra> well, it worked flawless, no errors
 * ogra checks installer logs
<ogra> nothing there ...
<lool> ogra: So without /lib/vfp and /usr/lib/vfp it still segfaults?
<ogra> yes
 * lool is relieved that it's not late breakage by these changes
<ogra> i wonder if it has to do with langpacks
<lool> German?
<seb128> I doubt of it
<ogra> its the actual only difference between a live session and the installed one i can think of
<seb128> why would the locale trigger a crash in libpng?
<ogra> the avahi think is also very very strange
<ogra> *thing
<seb128> I would rather think local corruption
<ogra> ok, i'll try a reinstall to a clean device ... its 1h max that i lose by it
<ogra> i would expect some error in the installer logs with corruption though
<ogra> the last libpng upload i see on -changes predates beta
<ogra> md5 of the image is correct ...
<seb128> did you get a valgrind log?
<ogra> no
<ogra> but i have both SD cards still here
<ogra> just want to make sure its not a worn out SD or something
<ogra> logging out in the live session properly gets me to a gdm screen btw
 * ogra runs the installer and leaves it in english
<lool> ogra: I just ran nautilus in a ssh -X session on my babbage, just fine
<lool> Using gtk+2.0 2.16.1-0ubuntu2 though
<ogra> lool, an installed one from today =
<ogra> ?
<lool> ogra: No, an up-to-date dev environment
<ogra> my upgraded system didnt show any issues
<ogra> its only this install
<lool> Ok; I need to try an install then
<ogra> the fun thing is that i just overwrote the upgraded system
<ogra> which makes seb128's theory of a corruption a weird idea
<ogra> since the target device is known to work reliable
<seb128> ok, so get a valgrind log ...
<ogra> let me finish the install first
<seb128> stop talking until then ;-)
<ogra> heh
<ogra> doko, you dont know which exact image you tested on your babbage, do you ?
<directhex> bah. just for pitti, i'll go hunting in intrepid-proposed
<doko> ogra: it was the daily, the day I tested
<doko> and sent the email
<mdz> is it known/intended that the Examples icon changed on the desktop CD?
<ogra> doko, so saturdays build then i guess
<philwyett> pitti, You just commented on https://bugs.launchpad.net/bugs/344710
<ubottu> Launchpad bug 344710 in mesa "Mesa under Hardy in an RC state - Request SRU to full release" [Undecided,Fix released]
<dholbach> mdz: it's a .desktop file now which can be translated as opposed to a symlink it was before
<ogra> doko, do you remember anything from the SD related messages you mentioned in your mail ?
<DnaX> slangasek: hi, I'm the boy that working on irda-utils package
<DnaX> ogra: ping, read up
<ogra> doko, and do you have by chance your installation logs ?
<ogra> hi DnaX
<DnaX> MAKEDEV script is deprecated?
<pitti> philwyett: yes, I did
<ogra> yes, since a while already
<philwyett> pitti, I have previously done what you commented https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/283175 and it has sat wishlisted for a long time now.
<ubottu> Launchpad bug 283175 in mesa "Intel i915 cannot swizzle TEX arguments" [Wishlist,Confirmed]
<liw> mvo, I need to talk to you about translations
<mvo> liw: ok
<DnaX> instead of using it (and deactivate udev) i can insert on modprobe config file the modules ircomm-tty, irlpt and irnet
<DnaX> ogra: ok?
<liw> mvo, it's my understanding that the computer-janitor code located in update-manager/Janitor should use "update-manager" as the gettext domain; is this correct?
<mvo> liw: yes, we have it in the update-manager.pot
<mvo> liw: isn't that the case already? I was sure it was using gettext with the right args/setup
<DnaX> ogra: I've made a patch for postrm (#340873)
<liw> mvo, it should be the case, yes; I was just checking to make sure I know what the situation is supposed to be
<ebroder> mvo: Oh - I finally got a chance to test your third-party sources.list config option. It works perfectly. Thanks again for putting that together
<mvo> ebroder: execllent, thanks for testing it!
<ogra> DnaX, just attach it, i'm way to busy with RC issues atm
<DnaX> ogra: ok
<mdz> davidm,lool: I see there are no test results yet for the UNR candidate; is everything OK?  do you need help?
<davmor2> mdz: I can look at it after the cds, when I pick up tests that are left :)
<liw> many years ago there used to be /etc/locale.gen, but it seems no more; has that been replaced by something else?
<ogra> liw, /etc/default/locale ?
<ogra> and/or /etc/environment
<liw> ogra, that sets the locale to use, I am talking about what locales the system generates (or is that even a current concept?)
<pitti> philwyett: right, we should probably just be honest and close it as wontfix; it's really not worth breaking existing installs for this
<ogra> well, locale-gen but with the name of the locale as arg
<liw> ogra, that would generate locales, but I want to know where the list of locales to generate is stored
<ogra> well, i think thats read from one of the above files
<liw> ogra, I don't think it is...
<lool> mdz: I've reminded everybody that we need to test all flavours we care about, but didn't come to test it myself yet, I've been fighting issues with various other flavours so far
<lool> mdz: Happy if you can test UNR though :)
<lool> mdz: Before reinstalling the AA1 please test notify-osd though
<pitti> ScottK: do you think the testing in bug 306889 was correct? should you still get bounces from invalid filenames?
<ubottu> Launchpad bug 306889 in amavisd-new "Default Ubuntu configuration is backscatter source" [High,Fix committed] https://launchpad.net/bugs/306889
<mdz> lool: I don't have access to that AA1 today, it's in the office.  I don't have a netbook at home yet unfortunately
<ScottK> pitti: I think the testing was correct.  I just uploaded a fix for post-RC in Jaunty and once that's accepted I'll update the SRU.
<lool> mdz: (Also the mobile QA folks are on in central and west coast, so they come up a bit later)
<pitti> ScottK: so it makes it better, but not perfect yet?
<mdz> lool: ok, just checking if you needed help
<ScottK> pitti: Yes.  Definitely.
<cjwatson> liw: /var/lib/locales/supported.d/
<philwyett> pitti, You can close it if you wish as won't fix. Kind of sad and makes me wonder a little why I bother. Thanks for your time.
<pitti> ScottK: so then we should perhaps move it to -updates, but keep the bug open for the remaining issue?
<mdz> lool: I'll wait for the QA folks to come around first
<ebroder> DktrKranz: I just found one that I hadn't seen before. Let me try to extract the relevant bits
<ScottK> pitti: I'd say close that bug and I'll open a task in Bug #360689 for Intrepid.
<ubottu> Launchpad bug 360689 in amavisd-new "Default Ubuntu configuration is backscatter source in Jaunty" [Medium,Fix committed] https://launchpad.net/bugs/360689
<pitti> ScottK: ah, WFM; thanks
<liw> cjwatson, thanks; so my system seems to be supporting the locale, but gtk says it's not... I guess gtk is being silly
<ScottK> pitti: Did you get to the fakeroot SRU yet?
<cjwatson> liw: the actual generated locales are in /usr/lib/locale/
<ogra> bah
<ogra> my babbage install worked flawless this time
<ogra> lool, ^^^
<ogra> did it in english though
<ogra> and to a new SD card i hadnt used yet
<ogra> lool, i'll try another one in german to the same card now ...
<pitti> ScottK: I will, I'll fully process all SRU bits today (just in the middle of catching up with teh SRU bug mail)
<ScottK> pitti: OK.
<ebroder> DktrKranz: Just posted the full list of CVS deltas to the bug
<ogra> seb128, dont wait for the valgrind log ...
<seb128> ogra: don't worry, I've enough bugs backlog to keep busy, I'm not waiting on your issue ;-)
<ogra> heh
<ogra> i did an english install to a new SD card ... works now
<asac> awe: Meru VCell :) ... wonder how  a per-station setup is special? e.g. different BSSIDs for the same ESSID, sounds normal.
<ogra> i'll try the same in german hoping its not caused by any langpacks
<DktrKranz> ebroder: commented
<ogra> slangasek, i dont see the babbage image on the isotracker
<ebroder> DktrKranz: Ok. I'll rework the bug for just the security fixes, then. Thanks for the input
<DktrKranz> ebroder: thanks you :)
<DktrKranz> s/s//
<lfaraone> If I were to incorperate some of Canonical's GPL code into my project where would the apropreate place to give attribution be?
<cody-somerville> Was console-common in ubuntu-standard in dapper?
<cjwatson> cody-somerville: it was in ubuntu-minimal
<cjwatson> (transitively, anyway)
<cody-somerville> cjwatson, What was the reason that changed?
<cjwatson> cody-somerville: it was replaced by console-setup in edgy, which unified X and console keymap configuration
<cjwatson> http://wiki.ubuntu.com/SaneInstallerKeyboard
<cody-somerville> Awesome
<cjwatson> cody-somerville: Debian will be doing the same; there are a few things to fix that were more critical to Debian than to us
<cody-somerville> cjwatson, What is Debian doing now?
<cjwatson> hopefully we'll get those resolved this year
<cjwatson> Debian's still on the old system
<cjwatson> console-setup was actually mostly written in Debian, although we contributed quite a lot to it
<cjwatson> but it isn't the default there yet
<cody-somerville> Okay.
<cody-somerville> Thanks :)
<cjwatson> why the question?
<DnaX> ogra: now all work perfectly in irda-utils package, fill patches on bug report, in time for rc?
<ogra> no, thats post RC stuff
<ogra> images are already rolled and in testing
<cody-somerville> cjwatson, I didn't know it changed and noticed the lack of console-common when looking at mobile-netbook-remix's manifest file for today's build
<cjwatson> cody-somerville: ok; just to check, though, it does have console-setup?
<cody-somerville> cjwatson, sure does
<seb128> does the bbc plugin list only 1 item for other people too?
<awe> asac: ping
<asac> awe: yes. i am still here ;)
<awe> asac: the per-station bssid.  yikes.  ;)
<awe> asac: i think it's something to do with the key exchange
<asac> awe: hehe. just curious how that is different to a "normal" shared essid setup
<asac> wasnt obvious from what you pasted/wrote
<mvo> seb128: bbc-plugin> I have a lot more, my totem is 2.26.1-0ubuntu2
<awe> asac: whenever the mainframe ( or  whatever you want to call it ), sees a new station send a Probe, it responds with a new BSSID
<mvo> seb128: let me upgrade
<awe> so every station gets a unique BSSID for the same ESSID
<awe> I don't understand how this messes up the key exchange, but this setup seems to work fine for Open and WEP configurations
<asac> awe: are those BSSIDs kind of volatile? e.g. does the main frame hand out new ones regularly or something?
<awe> I spent about 4 hours onsite to narrow it done to what I described.  I'll probably need to go back onsite again to get further details.
<awe> asac: it hands out a new BSSID for each unique station
<awe> I don't know whether they can be re-used or not
<DnaX> ogra: all done (bug #340873)
<awe> Anyways, smagoun asked me to file an upstream bug, but I realize you can't do much without more info
<ubottu> Launchpad bug 340873 in sane-backends "[Jaunty] modprobe requires .conf filenames now" [Medium,Fix released] https://launchpad.net/bugs/340873
<DnaX> ogra: what about this? https://bugs.launchpad.net/ubuntu/+source/irda-utils/+bug/361431
<ubottu> Launchpad bug 361431 in irda-utils "USB-IrDA udev hotplug support" [Undecided,New]
<awe> asac: I need to get back to another fire I'm fighting right now, and am also supposed to leave for a few days of vacation tonite.  Perhaps we can chat more about this next week, and maybe I'll go onsite again to get more details
<asac> awe: yeah. i think that info isn't really enough. we need kind of output of wpasupplicant and maybe even driver and so on
<directhex> hm. interesting.........
<asac> awe: enjoy your holiday. i guess its not that urgent ;)
<directhex> well i never!
<awe> asac: thanks!
<ogra> DnaX, thats nothing for jaunty anymore ... its not even triaged
<liw> mvo, I have just prepared a new computer-janitor upload and requested a freeze exception; if it gets accepted, could I entice you to do the upload?
<mvo> liw: sure
<liw> mvo, excellent, thank you
<ogra> slangasek, so since there are no babbage images on the isotracker i'll report directly to you :P i did two successful english and one gernam install of the imx51 image today (one broken one due to HW issues), its fine to go out as RC
<ogra> *german
<robbiew> Keybuk: two minutes for FC11?  wow
<Keybuk> yeah, they're really laying down the gauntlet
<ogra_babbage> wohoo
<Keybuk> normally I'd be a lot nicer about my open source colleagues work, but I'm really enjoying the muppetfreude
 * ogra googles muppetfreude
<Keybuk> ogra: it's a word that elmo invented
<ogra> hehe
<Keybuk> you know how schadenfreude is delight in the suffering of others?
<Keybuk> muppetfreude is delight at the incompetence of others
<ogra> yeah
<ogra> its an ingenious word
<ogra> kudos elmo
<kees> james_w: can you quickly patch bug 236305 to have s-t-b just block the creation of the "admin" user as a quick work-around?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/236305/+text)
<james_w> kees: probably. It was jpds that was looking at that
<kees> james_w: ah, okay.
<kees> james_w: I wasn't sure if a fix was pending.
<james_w> jpds: what do you think of that solution for Jaunty?
<ebroder> kees: Got a second to look at bug 356861? We have a patch now for all 4 releases
<ubottu> Launchpad bug 356861 in openafs "OpenAFS Security Advisories 2009-001 and 2009-002" [Undecided,In progress] https://launchpad.net/bugs/356861
<jpds> kees, james_w: I _think_ that there's a patch available at: http://mail.gnome.org/archives/system-tools-list/2008-May/msg00006.html
<kees> ebroder: later on today, most likely.  I have a bunch of publication work to do today.
<ebroder> Ok, cool
<james_w> jpds: I don't see that diff fixing the issue
 * hyperair pokes dtchen
<hyperair> dtchen: #202089 worth an upload? it seems that pitti would like it fixed for good
 * pitti waves with the "Jaunty is in deep freeze" banner
<calc> is it possible to get a copy of the LSB spec anymore?
<calc> it seems to have vanished over the years
<hyperair> use the source, calc.
<Keybuk> calc: linuxbase.org?
<calc> Keybuk: couldn't find it on there but found it on freestandards.org finally
<jpds> james_w: I'll take another look at the source later.
<james_w> jpds: cool, thanks
<doctormo> Does anyone know much about python/gtk/glade and how to get them to use po translations? None of the tutorials I try seem to work for this project and I could do with some assistance.
<jpds> doctormo: Standard gettext module doesn't work?
<doctormo> jpds: not the way I'm using it
 * calc is somewhat surprised bo is arguing that ia64 is supposed to be installed into /usr/lib64 also as LSB essentially contradicts that without actually coming out and saying it (afaict)
<mdz> bryce: is bug 358574 a duplicate of bug 359392?
<ubottu> Launchpad bug 358574 in linux "[drm:i915_gem_idle] *ERROR* hardware wedged" [Medium,Triaged] https://launchpad.net/bugs/358574
<ubottu> Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Critical,Triaged] https://launchpad.net/bugs/359392
<liw> I need to change a patch to the kernel; what's the best process to do that in Ubuntu? get the kernel source package, apply patch, dch -i, debuild?
<directhex> hm. are there any new headline items that people want to include in karmic which are going to cause the usual crunch for CD space?
<calc> directhex: java :)
<directhex> blimey
<directhex> openjdk?
<calc> there has been some talk of getting openjdk and the java bits for OOo onto the cd, not sure if the OOo bits will make it though
<superm1> liw, that would take a long time to build. i'd use the info from the wiki (https://help.ubuntu.com/community/Kernel/Compile) instead
<superm1> liw, it's got advice on how to just build one of the x86 kernels rather than the 4 or so that it normally would
<directhex> calc, i think magicking 100 meg for openjdk is already a major challenge
<liw> superm1, thanks; I'd be happy to wait for it to compile, as long as the result is correct, though
<directhex> calc, my current chain of thought is only offering to free up ~4 meg
<superm1> liw, well you will have just as accurate a result, just far quicker if you follow the directions on that page
<directhex> calc, this chain of thought may also result in lynchings
<bryce> mdz, sounds like it
<bryce> mdz, although I'd not seen that particular error message before..  But the timing and symptoms match up
<calc> directhex: i think there are some plans to free up more space, but i don't know how
<directhex> calc, i'm sure details will be forthcoming at UDS
<directhex> calc, if it were to receive some fixing of slightly over-eager Recommends:, then replacing Rhythmbox with Banshee would save megs & add features
<directhex> calc, this is not the case today, but certainly when using --without-recommends the numbers speak for themselves
<bddebian> lamont: Hey, I almost forgot about you. :)  Do you have any plans for xdelta?
<calc> directhex: ok
<directhex> calc, however, i suspect some areas of the internest would start a riot if this were to take place
<lamont> bddebian: meh
<lamont> what does it want? besides firey death?
<jdong> kees: what level of local access is necessary to compromise udev as per USN-758?
<Mirv> directhex: has there been any talk lately about using lzma on squashfs?
<directhex> Mirv, i don't know. would that be good?
<bddebian> lamont: That's fine with me to, I just want libglib1.2 gone. :)
<calc> Mirv: i believe cjwatson thinks that is a bad idea
<bddebian> Of course debdelta and pristine-tar are still r(b)deps afaik
<calc> Mirv: would both increase memory requirements and slow it down more afaik
<Mirv> directhex: not as good as with packages, but sladen (or someone) estimated 15% gain could be done
<Mirv> calc: I know
<directhex> Mirv, 15% of 700 meg is almost java
<kees> jdong: any local user.
<maxb> ooi, has anyone looked into lzma-compressed .debs ?
<Mirv> directhex: I know :) it could be something to play with, even if it would be too slow / memory-hog on low-end computers. it's soon time for play-time anyway.
<jdong> kees: lovely :) whee
<Mirv> maxb: they are in use already selectively, for example openoffice
<calc> maxb: i implemented it back in 7.10
<kees> jdong: i.e. the ability to run a C program
<jdong> kees: is there a PoC anywhere?
<calc> maxb: er 8.04 actually
<jdong> kees: I presume most udev-using distros are vulnerable?
<directhex> maxb, depends on whether you want debian compatibility
<kees> jdong: I am unaware of a public exploit, but it probably won't take long to be developed
<maxb> I mean, how much CD space would be saved by using them across the board.
<calc> maxb: maybe 150MB more than current maybe, but it would increase unpack requirements by 30MB for all packages
<kees> jdong: yes, any distro running udev is vulnerable.  I'm not aware of any work-arounds either.  it's a pretty serious issue.
<calc> er 30MB memory
<lamont> bddebian: ah, that.  yeah - let me get a debian upload to close the debian bug and then I'll request a sync,  because hey, why it's not like we're frozen or anything :-D
<jdong> kees: yeah if that's understatement of the day. Ouch.
<kees> jdong: note that it requires a reboot as well.
<calc> maxb: see wiki.ubuntu.com/dpkg-lzma
<jdong> kees: noted
<ebroder> kees: Restarting udev isn't good enough?
<ebroder> I missed that in the notice. Bleh
<kees> ebroder: you can stop/start it, but you'll likely lose ptys, etc.  i.e. ssh broke for me when I tried a stop/start
<jdong> ebroder: is it yet another fun day for linerva? :)
<bddebian> lamont: Well I meant for Debian :)
<ebroder> jdong: It very well might be
<lamont> ah, ok
<Mirv> maxb: on live CD the packages aren't available as such, since the whole CD is a squashhfs image. therefore for live-cd lzma usage squashfs-lzma should be used.
<ebroder> jdong: And we were just finally starting to build up some uptime!
<jdong> ebroder: haha, always something to ruin it :)
<jdong> *attempts a udev stop-and-start on a test box*
<Mirv> maxb: so on live cd it doesn't matter even if all packages used lzma
<Mirv> and someone correct me if I'm wrong etc :)
<Keybuk> jdong: don't do that
<jdong> Keybuk: hehe alright then, jdong will reboot instead :)
<maxb> I was going to say "there are some loose packages on the livecd", but only 32 and they come to <10MB
<Keybuk> jdong: you can use /etc/init.d/udev restart
<Keybuk> but then the upgrade should do that for you
<jdong> Keybuk: so does applying the update without restarting effect the security update?
<Keybuk> you must restart the running udevd
<Keybuk> it us udevd that is exploitable
<Keybuk> kees: interesting point, jaunty will restart the running udevd - but pre-jaunty won't
<ebroder> kees: Are you in touch with the Debian security team yet? Do you know if we should expect an update today? This week?
<kees> ebroder: they are aware of it; I'm not sure when it is planned for.  I know RH said they won't be publishing today.  I expect SUSE to publish shortly.  (1700 UTC was their idea)
<Keybuk> jdong: it's pretty safe to just kill udevd and run udevd --daemon again
<Keybuk> if you plug a USB device in at *that exact moment* it won't work, OBVIOUSLY :p
<kees> Keybuk: I put notes in the USN to reboot.  That's not uncommon.
<jdong> Keybuk: ah, thanks :)
<geofft> hm. on a server where you don't expect new hardware after boot, can you just kill udevd?
<Keybuk> geofft: probably not recommended
<Keybuk> various things stop working
<Keybuk> (if you don't restart it again)
<Aleksey_S> hi all
<Aleksey_S> guys, is here someone experienced in audio?
<Aleksey_S> especeally, i am interested in bug 354522
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/354522/+text)
<ashmew2> hi
<ashmew2> i need to ask something
<ashmew2> where do i start as a ubuntu deve ?
<ashmew2> developer*
<ashmew2> i dont know where to begin , which language to learn.
<ashmew2> What to do
<liw> ashmew2, have you read https://wiki.ubuntu.com/UbuntuDevelopment ?
<Aleksey_S> I am not member of ubuntu-devel team, just user of ubuntu. but as programmer i can say, that no mean what language do you know
<ashmew2> liw: I tried that site
<ashmew2> Aleksey_s: Which language is most suitable ?
<ashmew2> C or python or C++
<Aleksey_S> unfortunately, there isn't simple answer on this sort of questions
<geofft> ashmew2, find things you're interested in making better for yourself personally
<ashmew2> hmm..ok..so i start by learning one language from scratch , like hello world
<geofft> and learn whatever language that code is in. That's the most effective way
<liw> ashmew2, Ubuntu consists of tens of thousands of programs, written in hundreds of languages
<Aleksey_S> yes.
<ashmew2> If i am an absolute beginner at programming ,will C++ be a good start ?
<liw> ashmew2, Python is probably the easiest to learn; C, C++ and perl are also very common
<geofft> The best way to be a better coder is to read and understand and hack existing code.
<Aleksey_S> if you want to be experienced programmer don't start with python etc
<Aleksey_S> interpreted languages, i mean
<ashmew2> Start with C++ then ?
<ashmew2> yeah i get that
<Aleksey_S> yes
<Aleksey_S> then java python etc, will be very simple to learn for you
<ashmew2> So..you learn gradually from tutorials on the internet how to develop applications ? I mean you start from Hello World..
<liw> I think it's perfectly fine to start with Python or other interpreted languages even if you want to become an experienced programmer (he says, having been a programmer for 25 years now, and started with an interpreted language )
<ashmew2> wow..
<liw> ashmew2, if you don't know how to program, may I suggest: http://www.htdp.org/
<dtchen> Aleksey_S: what are the audio codecs in use for the two computers?
<ashmew2> 25 years is a LONG time
<ashmew2> liw:Thanks for the link :D
<Aleksey_S> dtchen: i don't follow
<ashmew2> Thanks guys! Cya around (hopefully) :D
<Aleksey_S> i think it is very hard to understand pointer arifmetics etc when you started with high level language
<dtchen> Aleksey_S: for the bug report you quoted, what are the audio codecs in use?  see /proc/asound/card*/*codec*{,/*}
<ashmew2> yeah
<ashmew2> i tried doing pointers
<ashmew2> and cant understand it in C++
<ashmew2> arrays is ok
<Aleksey_S> are this info missing in my reports attached?
<ashmew2> simple programs is ok
<ashmew2> well i g2g..Cya
<Aleksey_S> dtchen: i thought i attached all required info. if it isn't so, i will reboot to ubuntu and gather that info. unfortunately, it will be not easy, because my espeak sounds terrible
<Aleksey_S> and i am visually impaired, i can't work without speech support
<dtchen> Aleksey_S: ah, yours is present. (too many people commenting in that bug report without attaching necessary info)
<dtchen> Aleksey_S: one thing you could try is using a kernel with ALSA fixes
<dtchen> Aleksey_S: i've posted a test at http://kernel.ubuntu.com/~dtchen
<Aleksey_S> do you think it is alsa bug?
<Aleksey_S> all apps, which aren't using portaudio work correctly
<dtchen> Aleksey_S: it's not clear whether it's only portaudio or some other component in the stack
<Aleksey_S> ok then
<Aleksey_S> how i can test your kernel?
<Aleksey_S> e.g. what i need to do to install it
<dtchen> Aleksey_S: do you use proprietary drivers according to Hardware Drivers?
<Aleksey_S> mmm
<Aleksey_S> i have intel video
<Aleksey_S> and atheros wifi card. but i think it uses freevare driver
<Aleksey_S> i think no, i am not using proprietary drivers
<Aleksey_S> can you gather that info from my attachments?
<dtchen> well, apport reports that you aren't using any, but that's only at the time of post
<Aleksey_S> sure then
<dtchen> so, we'll assume you only need to install http://kernel.ubuntu.com/~dtchen/linux-image-2.6.28-12-generic_2.6.28-12.42~crimsun2lp345627_amd64.deb
<Aleksey_S> how about headers etc?
<dtchen> sha256sum == 5ab3db6eaf636a5aaa348eefa876bea7f4079da4e95db73b25d697aa8e8250ab
<Aleksey_S> *what about
<dtchen> Aleksey_S: let's migrate to #ubuntu+1 so we don't clutter this channel
<Aleksey_S> that checksum doesn't mean anything to me. i don't know how to check it under linux
<Aleksey_S> #ubuntu+1? is + sign allowed in channel names?
<dtchen> yes
<ubuntuman> hi
<ubuntuman> !seen amitk
<ubottu> I have no seen command
<ubuntuman> anybody here involved in the arm port who can explain to me why the orion5x support has been dropped?
<ubuntuman> i use a linkstation from buffalo and was going to install the beta right now in it, seeing the installer image and kernel have been removed :(
<mdz> Keybuk: can you tell me how to extract the UUID from a swap device?
<mdz> Keybuk: ah, never mind, vol_id does it
<liw> pitti, slangasek: about #361792 (freeze exception for computer-janitor): I don't want to push the release managers, but I need to know whether I should stay up and wait for the verdict or whether I can go sleep
<pitti> liw: if in doubt, just upload it, and be prepared for it to get rejected
<pitti> liw: it won't go into RC anyway
<pitti> so no need to stay up
<liw> pitti, ah, that's what I needed to know, thank you
<mdz> pitti: did you already upload apport -0ubuntu5?
<pitti> mdz: yes, it's sitting in the unapproved queue
<mdz> pitti: is it safe to commit a trivial change to the ubuntu branch?
<pitti> mdz: you can always commit it, but I can't guarantee that it will land in jaunty proper
<mdz> pitti: it's not urgent for jaunty, I just want to get it off of my HDD
<mdz> pitti: it's a one-liner in a hook, if for some reason you did need to do another upload it would be safe
<pitti> mdz: sure; and if not, it'll just land in karmic
<jpds> kees: Patch added to bug #236305.
<mdz> pitti: thanks, done
<ubottu> Launchpad bug 236305 in gnome-system-tools "Creating user with username 'admin' hoses admin group, sudo config" [Critical,Confirmed] https://launchpad.net/bugs/236305
<kees> jpds: cool, thanks.
<mdz> ogasawara: the change I just committed in apport r1390 will attach the missing info from https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume#Hibernate specific information
<ogasawara> mdz: awesome, thanks
<mdz> ogasawara: if there are any other places where you're still asking for users to collect info manually, I am happy to help add those to the hook as well, just point me to them
<ogasawara> mdz: will do
<mdz> ogasawara: it's very easy, this one was a two-line change:
<mdz> +	attach_file_if_exists(report, "/etc/initramfs-tools/conf.d/resume",
<mdz> +                          key="HibernationDevice")
<ogasawara> mdz: so it should be easy for us to whip up any future patches
<mdz> ogasawara: yes, I've added a lot of convenience functions to make common things into one-liners
<mdz> ogasawara: "attach the output of this command", "attach this file", and so on
<mdz> ogasawara: "pydoc apport.hookutils" shows everything that is available
<pitti> mdz: ah, I rejected the ubuntu5 upload from the queue, since I messed up (apport.default still in the orig.tar.gz)
<pitti> mdz: oh, did you already upload 0ubuntu6? it says "jaunty", not "UNRELEASED"
<mdz> pitti: that's my mistake, it should be UNRELEASED
<mdz> you can merge it into ubuntu5 if you want
<pitti> mdz: done, and pushed
<mdz> pitti: apport-collect didn't do quite what I'd hoped on bug 361852 (no hook info).  is that a bug?
<ubottu> Launchpad bug 361852 in linux "[Jaunty] Resume from hibernate doesn't work on a Dell XPS M1330" [Undecided,Incomplete] https://launchpad.net/bugs/361852
<pitti> mdz: ah, it's the old source vs binary package confusion
<pitti> there is no "linux" package (at least not the one you mean)
<pitti> mdz: workaround: apport-collect -p linux-image-2.6.28-11-generic 12345
<pitti> but it shoudl be clever enough to at least run the source package hooks
<pitti> so that's also a bug
<dtchen> mdz: is there a way to filter output from a command using apport.hookutils's command_output()?
<dtchen> mdz: use case is: pactl stat|grep ^Default
<YokoZar> Anyone know when mvo will be back?
<YokoZar> he seems to have disappeared on vacation or something
<ScottK> He was back today
<kees> cjwatson: I want to answer the question "what source packages have binary packages in the seed supported-server?"  Due to moving of binaries "up" when germinate runs, is there no output that can answer that question short of walking the STRUCTURE file myself and expanding each seed?
<ubuntuman> anybody here involved in the arm port who can explain to me why the orion5x support has been dropped?
<kees> bryce, kirkland, soren: do any of you know what the magic is that causes my mouse to track in a guest X session in virt-viewer _without_ having had to click into the viewer?  This works for me on hardy, but not jaunty.
<kirkland> kees: i'd guess that this is a vnc option
<kees> kirkland: but it works in my hardy guests...
<kirkland> kees: oh, hmmf
<tjaalton> kees: hardy probably uses -input-vmware
<kees> tjaalton: ah-ha.  is that still available in later releases?  (and if so, how do I enable it?)
<tjaalton> sorry, -vmmouse
<tjaalton> it is, but you'd need to disable evdev
<tjaalton> on the guest
<kees> cjwatson: nm, nijaba says you're busy.  :)
<kees> tjaalton: isn't that a not-good thing to do?
<tjaalton> copy the hardy xorg.conf and then add 'Option "AutoAddDevices" "false"' to ServerFlags
<tjaalton> kees: probably isn't that worrying on a virtual guest
<kees> okay
<tjaalton> -vmmouse could ship an fdi file to override evdev
<tjaalton> oh, it does
<tjaalton> so check that it's used, 'lshal' and look for the mouse
<tjaalton> and the value of input.x11_driver
 * kees switches to #u-x
<jdong> tjaalton: wow creepy I just posted about that on the forums.
<jdong> http://ubuntuforums.org/showthread.php?p=7079221#post7079221
<jdong> the vmware planets have aligned.
<tjaalton> jdong: heh, ok then.. the fdi file should just be fixed
<jdong>   input.x11_driver = 'evdev'  (string)
<jdong> what info is helpful for fixing it?
<tjaalton> so filing a bug against -vmmouse with ubuntu-bug from a VM should gather enough information to fix it
<tjaalton> running ubuntu-bug should include everything
<tjaalton> but at least the lshal output from the VM is needed
<tjaalton> hal-probe-vmmouse doesn't seem to do it's business
<jdong> yeah that seems to be the issue
<jdong> haha ubuntu-bug OOM.
<jdong> obviously I trimmed back this VM a bit too much.
<jdong> do you feel the lshal alone is sufficient info?
<tjaalton> should be enough
<tjaalton> do you have mdetect installed?
<jdong> no; should I?
<tjaalton> because hal-probe-vmmouse uses vmmouse_detect from mdetect
<tjaalton> no wonder it doesn't work
<jdong> wow.
<jdong> you're kidding :D
<tjaalton> try installing it
<tjaalton> the newer upstream version of -vmmouse includes it
<tjaalton> ..which seems to be four months old, oops
<jdong> tjaalton: works
<jdong> do you think we can get this through freeze?
<tjaalton> file a bug and we'll see :)
<jdong> roger
<slangasek> ogra: great, thanks for the update
* spm changed the topic of #ubuntu-devel to: LP Emergency Down @2300UTC | Archive: release freeze | Ubuntu 9.04 Beta released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> liw: as pitti says, when in doubt, upload to the frozen queue :)
<kees> kirkland: okay, usplash inits the screen and then quits immediately (without drawing anything) on my jaunty VM...
<kirkland> kees: what's your kvm command line?
<kees> /usr/bin/kvm -S -M pc -m 512 -smp 1 -name 64bit-Ubuntu-9.04-desktop -uuid ea8cfb3a-cd8f-d588-14bd-a809b2ce6ac1 -monitor pty -pidfile /var/run/libvirt/qemu//64bit-Ubuntu-9.04-desktop.pid -boot c -drive file=/vmware/64bit-Ubuntu-9.04-desktop.qcow2,if=ide,index=0,boot=on -net nic,macaddr=00:0c:29:5f:50:a9,vlan=0,model=virtio -net tap,fd=21,script=,vlan=0,ifname=vnet2 -serial none -parallel none -usb -vnc 127.0.0.1:2
<kirkland> kees: let me try with those options
<kees> kirkland: actually, this might be simpler than that....
<kees> kirkland: ran it on the cmd line, got "no usable theme found for 1024x768"
<kirkland> kees: oh, hmm, yeah, that would do it
<kirkland> kees: we should add higher res themes to usplash-themes
<kees> kirkland: gimme a second to investigate... I think I hadn't been noticing it due to the X crasher.  I assumed it was all related
<kees> hrm, no luck.
<kees> kirkland: all my own fault.  I think i've got it sorted
<kirkland> kees: yeah, i was able to launch my vm with your command (mostly)
<kirkland> kees: what was your problem?
<kees> kirkland: I'd written a custom usplash package and didn't correctly unregister its alternative when removed.
<kirkland> kees: :-)
<jdong> hahaha :)
#ubuntu-devel 2009-04-16
* spm changed the topic of #ubuntu-devel to: Archive: release freeze | Ubuntu 9.04 Beta released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<dmg> Hey, it appears the latest mplayer svn makes dash segfault during ./configure.  Can anyone else reproduce this?
<dmg> My version of dash is the latest in jaunty, 0.5.4-12ubuntu2.  mplayer svn is at svn://svn.mplayerhq.hu/mplayer/trunk .
<dmg> I'd give a backtrace, but dash is stripped.  Should I build one by hand with -g?
<cjwatson> http://wiki.ubuntu.com/DebuggingProgramCrash has instructions for acquiring debugging symbols and getting backtraces
<dmg> cjwatson: thanks
<cjwatson> (i.e. yes, it's stripped, but we save the debug symbols in packages on ddebs.ubuntu.com)
<dmg> cjwatson: looks like dash and mplayer's configure script are both wrong.
<dmg> the configure script has a bug -- they replaced all the `` with $(...) instances, but there's a place where they had
<dmg> `(echo foo | grep ...)`
<dmg> that turned into $((echo ...) ...
<cjwatson> hah
<cjwatson> arithmetic expansion
<dmg> and dash slurped in the entire file while parsing looking for the closing ))
<cjwatson> I don't entirely blame dash for getting confused, although obviously it's still a bug
<dmg> it segfaulted because parser builds stuff using alloca(), and it ran out of room.
<ebroder> Good for them for quoting things properly, though!
<ebroder> ...or something
<cjwatson> indeed, the problem is obvious from http://bazaar.launchpad.net/~vcs-imports/mplayer/trunk/revision/29144
<cjwatson> interestingly, bash manages to parse it as the author intended, although I have no idea how
<cjwatson> it must be doing some serious lookahead to manage that
<dmg> cjwatson: probably once it sees something that's not an arithmetic token, it gives prunes that branch of the parse tree and figures it must just be a normal command line replacement?
<dmg> (i.e, 'echo' isn't numeric ...)
<dmg> I'd need to go back and look at bash's grammar..
<dmg> cjwatson: my two-line patch has been sent to the mplayer mailing list.  I suppose that's good enough.
<dmg> Thanks for your help.
<jdong> kees: I'm getting multiple user feedback that the udev update doesn't trigger a reboot notification. Is this intended?
<mrooney> kirkland: just thought you might like to know that I got my sheeva plug (http://www.linuxdevices.com/news/NS9634061300.html) today and it is running jaunty server, in a 150mb footprint no less!
<mrooney> I will hopefully be putting up a blog post soon about it, I imagine not too many people are shipping jaunty already, let alone the ARM port
<kees> jdong: lacking it is not intended, no.  It was mentioned in the USN, though.
<jdong> kees: ah, okay. I suppose it doesn't make much sense to spam another update to pop up a pretty bubble.
<kees> jdong: but it's possible the packaging lacked it originally
<jdong> yeah about 5 users told me it on separate accounts, so I'm assuming the packaging lacked it.
<jdong> I don't think we had to replace udev very often (the binary itself) :)
<kees> jdong: it's actually never happened before for -security.  :P
<jdong> :)
<jdong> I'm kind of shocked that of all the other major distros that I subscribe security notifications to, none have mentioned this yet.
<jdong> when was this vulnerability discovered?
<kees> jdong: last week
<jdong> yikes
<kees> jdong: 1700 UTC today was the coordinated release time... *shrug*
<jdong> ah, I see
<jdong> I suppose it looks like a one-man show for now, huh? :)
<kees> but yeah, I'm a bit surprised, this is a pretty serious issue.  :P
<jdong> yeah, painfully serious.
<kees> 1700 was SUSE's recommendation, too.
<ebroder> I'm still trying to figure out if I care enough to patch my high-use Debian machine myself while I wait for them to get their act together
<jdong> and it's not like the SELinux profiles in RHEL do anything to stop it either. udevd_t is shockingly unconfined_domain()
<kees> yup.  the Xen-guest SELinux-escape route is possible with this vuln too.
<jdong> ouch, xen guests can exploit the host you mean?
<ebroder> Wait..what?
 * ebroder may really care now
<kees> it was a paper that was written about a specific Xen guest-to-host vulnerability.
<jdong> haha ebroder is gonna have a sleepless night :D
<kees> ebroder: the Xen issue was fixed a long while ago.
<ebroder> Oh, ok
<jdong> ah, dan walsh wrote a reflection on that, I recall
<jdong> i.e. it being a mistake RH didn't confine VM's in the host.
<kees> jdong, ebroder: http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf
<kees> jdong: no, it was confined, but allowed block device access.
<kees> anyway, same principles could be used to escape SELinux with the udev vuln.  I think, I'm not much of an selinux-escape-artist
<jdong> mmm I see.
<dholbach> good morning
<jdong> currently what I see in refpolicy is that the "user_u, sysadm_u, staff_u" users do not have the ability to use netlink_socket
<jdong> I assume that means users confined under these domains would not have then ecessary access to pull this off.
<jdong> however, the default config is to place users in unconfined_u so this is moot.
<bryce_> slangasek: so, evidence is piling up that switching "greedy" on is a very good thing.  There is only one data point to the negative - your firefox case
<bryce_> slangasek: so I'm wondering how to reproduce that issue, and if we can definitively tie it to greedy, or if it might be an unrelated issue
<slangasek> bryce_: which was informally confirmed by others on IRC last night; so we'd be trading performance for correctness...
<slangasek> the only thing that changed to trigger the behavior was turning on greedy
<slangasek> reproducing> i965, switch/scroll windows rapidly
<bryce_> slangasek: was it?  I missed that discussion.
<bryce_> slangasek: I'm on i965 and not reproducing it
<slangasek> er, sorry - 945
<slangasek> you'd think I'd know by now what I'm running
<bryce_> heh
<bryce_> what were other people on?  who else reported seeing the issue?
<bryce_> if it's only appearing on !i965 or only i945 or whatever, maybe we can conditionalize those cases
<slangasek> I'll check my logs
<slangasek> bryce_: it was Lure this morning
<slangasek> <Lure> slangasek: I have also noticed some black areas with greedy (but not to the level that I would go back to non-greedy ;-))
<jdong> kees: *WOW*, the Xen dude is quite an escape artist. Quite an amazing read.
<slangasek> bryce_: did you get a fixed patch that doesn't cause insta-segv?
<jdong> kees: by far the biggest mistake was xend_t being allowed *ALL* block devices.
<bryce_> slangasek: no, but based on the good perf numbers we're getting I'm considering taking a shot at making one
 * slangasek nods
<bryce_> slangasek: I mean, if it's worth giving it a shot
<bryce_> ideally, I'd like to have the black firefox problem out of the way though
<maco> slangasek: wait, is it scroll in firefox quickly *or* switch between various windows, or is it switch between firefox windows? i'm confused
<maco> ive got a 945 at home i can play with in the morning and a 965 here
<bryce_> I also have a 945 I can upgrade and play with tomorrow I guess
<slangasek> maco: a lot of all of the above
<maco> slangasek: ok
<tjaalton> sigh, this klogd hang is driving me nuts
<tjaalton> it's not doing any remote logging, so that's not it
<tjaalton> Keybuk: shouldn't init wait for the network to be up before it proceeds to rc2?
<liw> tjaalton, I don't think init sets up networking, and anyway, it shouldn't wait, since it can take indefinitely long (e.g., if the dhcp server is down during boot)
<liw> tjaalton, where does klogd hang for you?
<tjaalton> liw: it hangs on boot if the network is not up yet (normal dhcp setup, network-manager isn't used)
<liw> tjaalton, hmm... weird
<tjaalton> because the dhcp server is on another network, so it might take a while to get a lease
<tjaalton> I'll try to strace it..
<tjaalton> ldap is used, and it tries to run it as 'klog' user.. maybe that's why it fails
<maxb> window level all
<tjaalton> hm, now that I messed up the klogd initscript (it didn't try to start it at all), it fails in the next initscript which is dbus
<tjaalton> so klogd is not at fault here, that's for sure
<tjaalton> liw: it's the mountnfs-scripts that are failing.. looks like mountnfs.sh is run even though the network is not up, and that hangs the boot
<liw> tjaalton, that'd be a bug, yes
<liw> the fix would be to switch to using upstart events, I'm sure :)
<pitti> Good morning
<seb128> hello pitti
<slangasek> TheMuso: we're slipping in one kernel upload post-RC; one change is specific to lpia, but the other applies to anyone running ext4.  Can you sync up linux-rt and linux-ports and get them into the upload queue, so we can push that through ASAP after RC is done?
<liw> slangasek, any chance you'd accept a further change to fix my SATA/SEMB problems? http://bugzilla.kernel.org/show_bug.cgi?id=11579 (but I haven't verified the patch yet)
<ubottu> bugzilla.kernel.org bug 11579 in Serial ATA "Libata SATA hard drive detection" [Normal,Resolved: code_fix]
<slangasek> liw: is that a blocker for installability?
<slangasek> oh, if the patch isn't verified yet, then the timeline probably doesn't work
<liw> slangasek, it prevents installing on a bunch of WD SATA hard disks -- the kernel doesn't recognize them as hard disks
<slangasek> the kernel in question is already uploaded, and needs to be accepted for building by tomorrow in order to make this work out time-wise
<liw> ah, too bad
<liw> I'll test the patch RSN anyway, it'd be nice to get this fixed in an SRU
<TheMuso> slangasek: ok I'm on it, I have one bug I need to kill thats powerpc-specific as well, so this is good news, thanks.
<liw> (although it probably requires an updated ISO image, too, hmm)
<slangasek> liw: yeah, which would have made it useful to have in for final :/
<TheMuso> slangasek: ...or I could if the git commits were pushed to kernel.ubuntu.com.
<slangasek> smb_tp: ^^ linux-ports folks need those kernel commits :)
<smb_tp> slangasek, TheMuso The patches itself are there. Just a sec I forward Tims mail with the ids
<smb_tp> I am currently locally building that kernel to get the abi files for the merge back
<TheMuso> smb_tp: Not really useful, as I list the exact changelog bits from mainline in the ports upload'
<TheMuso> I could generate it however, so I'll see what I can come up with.
<smb_tp> TheMuso, would the exported patches be ok? You could apply them with git am
<TheMuso> smb_tp: that would be fine, means I rebase by hand, i.e no script, but thats ok.
<TheMuso> seems the RSS for gitweb is not updating which is why I thought some of the patches weren't there.
<pitti> smb_tp: I just updated bug 321474 to remove the v-failed/regression tags
<ubottu> Launchpad bug 321474 in linux "[Intrepid] Update kernel to Linux 2.6.27.13" [Medium,Fix committed] https://launchpad.net/bugs/321474
<pitti> smb_tp: is there a plan when to release the intrepid kernel to -updates?
<smb_tp> pitti, Yes, I definitely wanted to go over the open stuff to see where we stand and have Intrepid and Hardy moved to updates soon
<smb_tp> TheMuso, I created a local topic branch for that upload and have to merge it back as soon as I got the abi files. Then I'll push everything
<smb_tp> TheMuso, Mail is away
<TheMuso> smb_tp: thanks
<TheMuso> smb_tp: re your email regarding intrepid ports, I'll read it again on the weekend and look into it then.
<smb_tp> pitti, The when: is early next week ok for you or would it be better this week?
<smb_tp> TheMuso, NP, it has been behind quite some time now. So a little longer won't hurt
<pitti> smb_tp: I don't mind, the actual copying is trivial
<pitti> smb_tp: I see two regression-proposed bugs: bug 337929 and bug 311716
<ubottu> Launchpad bug 337929 in linux-backports-modules-2.6.28 "ieee80211_regdom=EU now causes oops after latest update" [Medium,Fix released] https://launchpad.net/bugs/337929
<ubottu> Launchpad bug 311716 in linux "The slider brightness Applet has value inverted after the last update (2.6.27-11)" [Medium,Confirmed] https://launchpad.net/bugs/311716
<pitti> smb_tp: no v-failed any more
<pitti> if we could clarify those two, then we'd be good to go
<pitti> smb_tp: oh, and no regressions reported against the hardy update
<smb_tp> pitti, The regdom thingy should be somewhere. But it might be in the patches queued up. I have to check. With brightness problems I fight a bit. Trying to get info about the specific issue as all are mixed up. But from the general feeling that is not worse than the version in updates now, just not better.
<smb_tp> pitti, Oh, right the regdom bug is for lbm. I see andy asked for feedback which seems to have arrived now. But it is not yet uploaded to proposed
<pitti> smb_tp: ah, so it needs another lbm upload first?
<smb_tp> pitti, yes
<smb_tp> pitti, I put it onto my list to get done soonish.
<smb_tp> pitti, About the inverted brightness: as it is that way on 2.6.27-11 and (maybe as I have not clear feedback) the same in proposed. Would it be ok to move proposed to upadates anyway? I even think the inversion issue should be fixed in the proposed.
<lool> The linux-backports-modules-intrepid-generic in ship-live seems to be bogus; anybody minds if I drop it?
<smb_tp> lool, What means bogus?
<lool> It's not in jaunty anymore
<lool> smb_tp: The fact that's a package not existing in jaunty is listed there seems wrong, I'm not saying tehre are bugs in the package  though :)
<smb_tp> lool, Oh, is that the meta-package
<lool> eagle-usb-utils isn't in jaunty either
<lool> smb_tp: Not really, it's a task listing additional packages to install in the live CD I think
<lool> eagle-usb-utils isn't in jaunty anymore either; looks like I could cleanup this seed
<smb_tp> lool, I pretty much think so. The nameing with the release in it looks like that
<smb_tp> It would then be linux-backports-modules-jaunty-generic
<TheMuso> smb_tp: hrm ok, since you haven't also uploaded other patches that are in the jaunty tree, theres no point rebasing. I'll just use that ext4 patch fix, and do another bug fix I need to do, and that will be it.
<lool> stgraber: Hey, we really need the ARM images added to the tracker
<pitti> mvo: hm, should I remove the current intrepid-proposed update-manager due to lack of feedback, or do you want to test it yourself? (bug 292179)
<ubottu> Launchpad bug 292179 in update-manager "Intrepid upgrade removed EVMS but should not have allowed upgrade" [Medium,Fix committed] https://launchpad.net/bugs/292179
<smb_tp> TheMuso, that new kernel only consists of that config change in lpia and the ext4 fix (compared to the last release)
<TheMuso> smb_tp: from there on in, any SRUs that are likely to be useful for ports can just be pulled as patches directly, no tree rebasing.
<TheMuso> smb_tp: yes I know
<lool> stgraber: Could you please add an entry in Ubuntu for desktop armel imx51 babbage (that's a live) and split the netboot ones with one per flavor (versatile, ixp4x, iop32x)
<lool> stgraber: Also, UMPC needs dropping and UNR should be its own toplevel project (and server as well BTW)
<pitti> mvo: (I'd prefer the latter, of course)
<TheMuso> smb_tp: what I'm saying is that there are other commits in the jaunty tree that haven't been uploaded, so I don't need to rebase, and for SRUs, commits will only need to be pulled where they are applicable to ports
<slangasek> lool: why is there any need to reorganize the products?
<lool> slangasek: Well the current situation is inconsistent, the MID and UNR images are listed in different ways, but they are built in the same way
<lool> slangasek: But I can understand if you prefer avoiding any reorg at this point
<lool> stgraber: ^
<slangasek> lool: ah, well; UNR is built from main, which also sets it apart from MID presently?
<lool> slangasek: UNR is built from universe as well; it includes cheese for instance
<smb_tp> TheMuso, A complete rebase would pull things not yet uploaded, yes. So it is not useful here. When we are doing sru's I guess both approaches are ok. With rebasing you get all things, but if you prefer you can cherry pick what you find applicable/useful
<slangasek> lool: oh
<TheMuso> smb_tp: yeah the cherry-picking will likely be what I'll do.
<lool> slangasek: This might be a bug though, not one I expect to be fixed before release though, there are ~24 binaries from universe or so
<smb_tp> slangasek, I just had the full test-compiles done for that proposed kernel and just saw lpia ftbs due to a missing module. I look into that and get back to you. Maybe the package I uploaded should get dropped
<slangasek> smb_tp: ack, let me knwo
<smb_tp> slangasek, Yeah, the problem was the change for CONFIG_PACKET from m to y. Which needs a little tweaking with the modules list
<mvo> pitti: I can do it myself if, but probably not today
<pitti> mvo: doesn't need to happen today, I was just wondering if it makes sense to keep it in -proposed
<slangasek> smb_tp: rejecting this upload, please reupload at your discretion
<smb_tp> slangasek, ok, thanks
<pitti> mvo: especially because I assume we'll need more u-m SRUs soon
<smb_tp> TheMuso, If you are not picking the config change for lpia, you will be ok
<TheMuso> slangasek: mind having a quick look at bug 355344? Since another ports upload is forthcoming, I'd like to get this fixed now, rather than have to do an SRU.
<ubottu> Launchpad bug 355344 in linux-ports "crtsavres.o is required for kernel module builds" [Undecided,Confirmed] https://launchpad.net/bugs/355344
<TheMuso> smb_tp: I'm not, since lpia is not built from ports at all
<slangasek> TheMuso: sorry, can't do it right now
<TheMuso> slangasek: ok I subscribed ubuntu-release to it anyway
<pitti> mvo: ubuntu-vm-builder is in a similarly sad state :(
<mvo> pitti: ok, I put that on my list as wel
 * pitti hugs mvo
<pitti> I'm currently doing a cleanup round for -proposed
<lool> mdke_: Around?
<lool> mdke_: We'd need some help in getting the installation instructions in shape for UNR
<lool> mdke_: We have some bits in the middle of https://wiki.ubuntu.com/UNR and some reqs on https://help.ubuntu.com/community/Installation/SystemRequirements
<pitti> slangasek: there's a new tzdata update (http://launchpadlibrarian.net/25523792/2009e-2009f.diff) with a trivial, but urgent diff; would you rather have this as an SRU, or can I upload it to jaunty?
<slangasek> pitti: jaunty
<pitti> ok, thanks
<pitti> slangasek: oh, doko uploaded a tzdata as well, I'll look at it and integrate
<pitti> ah, installs a missing file; seems safe enough
<pitti> doko: I reject your tzdata upload, I'll integrate it into the 2009f one
<YokoZar> mvo: poke
<doko> pitti: ok, thanks
<superm1> pitti, TheMuso should have hardware that will be able to reproduce and test the package from -proposed for bug 297245
<ubottu> Launchpad bug 297245 in xserver-xorg-video-intel "[i965] Dell Studio 15 White Screen on X startup" [High,Fix committed] https://launchpad.net/bugs/297245
<superm1> he's got the one system I had that could do it
<TheMuso> superm1: I'll isntall intrepid on it tomorrow and test that.
<superm1> TheMuso, it's actually a hardy proposed package i think in question
<TheMuso> superm1: oh
<TheMuso> well it will be hardy then
<superm1> TheMuso, you don't need to install to test it, it will fail off a hardy live disk, and you can install the deb in the live mode to verify X comes back to life
<slangasek> superm1: morning
<TheMuso> superm1: good enough, thanks
<TheMuso> I'll do that tomorrow and report back
<slangasek> superm1: mesa has just been accepted; it's a .5h build, then a 1.5h wait for the publisher, then I'll reroll mythbuntu
<superm1> slangasek, g'morning.  dog kept waking me up all night, so i figured i might as well stay up :)
<pitti> Keybuk: for bug 283316, is "sudo udevadm monitor --udev" really the correct thing to debug the udev rules? I only get some "change" event on the USB host, not the actual rules processing (the tracks/vol_id detection is probably the part which causes this)
<ubottu> Launchpad bug 283316 in udev "CD-ROM tray closes automatically after eject" [High,Fix released] https://launchpad.net/bugs/283316
<slangasek> superm1: heh
<superm1> slangasek, sounds good.
<superm1> TheMuso, thanks
<slangasek> superm1: testing resources will be available around then?
<superm1> slangasek, i'll be able to, not so sure anyone else is up yet though
<slangasek> superm1: well, that gives them another 3h to wake up :)
<slangasek> superm1: you and fader seem to have been the main testers, anyway
<superm1> slangasek, yeah at least for those that report it.  there's a handful of people that we've been getting testing dailies and reporting whether things are broke for their situations, but can't seem to get them reporting to the iso tracker yet
<slangasek> heh, ok
<TheMuso> slangasek: BTW I won't be able to get linux-rt sorted until a new linux-source package is in the archive, since that doesn't currently use a git repo, and build deps on the linux-source-2.6.28 package to build
<slangasek> ok
<wubbbi> Any Packagebuild or bugfixes needed here?
<mvo> YokoZar: /poke
<YokoZar> hi
<pitti> Keybuk: nevermind, --environment was missing
<YokoZar> So I've seen quite a few changes for the kernel set as "fix committed" - is a new kernel gonna roll out for the release candidate?
<slangasek> no
<ogra> slangasek, so one time back to the ltsp change ... formerly the amd64 server + i386 client installations didnt have to touch dhcpd.conf, while they had to rebuild their chroots for i386 the conffile was preconfigured for i386 and didnt have to be touched ...
<ogra> slangasek, as i understand conffiles the change in the package will quietly replace the existing dhcpd.conf for these users
<ogra> (on upgrades)
<ogra> which means their clients will silently stop booting
<slangasek> ogra: conffiles> correct; the flipside seems to be that amd64-on-amd64 is the only thing you can actually configure out-of-the-box right now, and that common case fails?
<slangasek> dholbach: could you elaborate on why you consider bug #361765 a bug?  AFAICS, the task still exists
<ubottu> Launchpad bug 361765 in tasksel "DVD alternate install still offers "Edubuntu Desktop"" [Undecided,New] https://launchpad.net/bugs/361765
<ogra> right, but doe sthat justify to break all existing amd64->i386 setups (which is a huge amount imho)
<slangasek> ogra: discuss that with stgraber?
<ogra> i did, i just wanted a second opinion
<ogra> the problem is known since breezy and since we didnt have a proper solution we kept it the way it was until tonight
<slangasek> ah
<dholbach> slangasek: I think it's just the term
<ogra> i'd rather perfer to work out a proper solution than breaking it for many people on RC day
<davmor2> ogra: I don't think the fix has gone in yet has it slangasek?
<slangasek> ogra: then that's a good argument for rejecting it, but I would like you to come to an agreement with stgraber instead of me being a mediator for that
<slangasek> dholbach: i.e., "edubuntu" vs. "Ubuntu Education Edition"?
<ogra> yes, he will come here once he is online again (he is commuting atm)
<dholbach> slangasek: yes
<ogra> davmor2, nope
<ogra> davmor2, its waiting for the freeze to fall, thats why i brought it up
<davmor2> ogra: Okay.
<ogra> dholbach, the dvd installs edubuntu-desktop
<slangasek> dholbach: ok, makes sense
<ogra> as a package/task
<ogra> and by the definition RichEd set up "Ubuntu Education Edition" != edubuntu
<ogra> (though dont ask me what "Ubuntu Education Edition" is actually after his definition :) )
<ogra> but the two are very distinct on all websites so you need to update these as well
<slangasek> hrm?
<slangasek> I have no idea what definition that is.  As far as I was ever told, Ubuntu Education Edition was a new name for edubuntu.
<ogra> http://www.ubuntu.com/education was referring to edubuntu as a distro ... www.edubuntu.org was referring to ubuntu in education as something different from edubuntu
 * ogra checks if that was fixed/changed already
<ogra> edubuntu is still in the menu on ubuntu.com but apparently the text referring to it was removed now
<ogra> there is still http://www.ubuntu.com/products/WhatIsUbuntu/edubuntu though
<ogra> that should point to http://www.ubuntu.com/education
<dholbach> ogra: https://bugs.launchpad.net/ubuntu-website/+filebug :)
<ogra> slangasek, the prob is that the actual strategy was never made clear to anyone by rich so there is a lot confusion
<ogra> dholbach, i'm not doing edu stuff and am busy up to my ears in arm, can you file it ?
<dholbach> ogra: I don't know much about the edubuntu situation, just noticed it during the installation
<ogra> (that should really be discussed with LaserJock rather)
<ogra> dholbach, the transition rich had to do is only half way done, i have no idea who has taken over his role but if we change it on the DVD it should be changed everywhere for a professional look
<dholbach> ogra: I'm not sure we'll find the right answer here in #ubuntu-devel
<ogra> no idea
<ogra> i dont mind if it stays as is, just pointing out the overall inconsistency
<liw> is the queue with uploaded packages that aren't entering the archive due to the freeze visible somewhere?
<slangasek> https://launchpad.net/ubuntu/jaunty/+queue?queue_state=1
<soren> liw: http://launchpad.net/ubuntu/jaunty/+queue
<soren> ...and choose "Unapproved"
<liw> thanks
<soren> Or save slangasek's link if you're the bookmarking sort of person.
<soren> :)
<liw> I'd like to save the bookmark where I can easily find out such things :)
<soren> It's called #ubuntu-devel :)
<soren> You may have heard of it.
<soren> :p
<slangasek> irc://chat.freenode.net/%23ubuntu-devel
<geser> it's part of the secret knowledge passed on from one developer generation to the next one :)
<liw> I'm not sure oral history is the best way to document things
<liw> but I'll ask more things again :)
<geser> I don't know how well google has indexed http://irclogs.ubuntu.com/
<ScottK> wget and grep work though.
<directhex> wgrep!
<vlada_> hi
<vlada_> can someone help me set up development environment the easiest way?
<vlada_> I need boost package. Is it called libboost in ubuntu?
<Pici> apt-cache search boost
<vlada_> ah, thanks
<vlada_> I've found one package with version number attached after libboost.
<vlada_> Is it advised to call that one, or should I proceed with libboost-dev only?
<ScottK> vlada_: It depends on what version you want.
<directhex> vlada_, generally, version numbers in package names refer to ABI versions, versionless -dev packages pull in the most recent headers corresponding to the most recent API/ABI in the archive
<ScottK> directhex: Generally, yes, but not in the case of boost
<ScottK> vlada_: ^^
<mdz> lool: regarding bug 362071, are we actually using lpia for any alternate ISOs?
<ubottu> Launchpad bug 362071 in linux "CONFIG_PACKET should be "y" on lpia; breaks DHCP in alternate installer?" [Medium,In progress] https://launchpad.net/bugs/362071
<cjwatson> mdz: I filed it after getting a bug report from a user who was doing so.
<cjwatson> mdz: actually, I think they were using a netboot image
<cjwatson> nevertheless, http://cdimage.ubuntu.com/ports/daily/current/jaunty-alternate-lpia.iso exists
<mdz> cjwatson: is it being considered RC?
<lool> mdz: A bunch of people seem to be trying to install Ubuntu flavours with the lpia arch via the alternate images
<lool> mdz: I guess they think lpia is best for their atom or whatever
<cjwatson> mdz: not quite, but there was an ext4 bug that we wanted to fix anyway
<cjwatson> mdz: (Medium bugs aren't RC)
<cjwatson> I discussed it with slangasek last night
<slangasek> not publishing the alternate is also an option, if the kernel update is considered untenable; but the ext4 issues are fairly high-profile as well, and the delta is very manageable here
<pitti> meh, svn.debian.org/wsvn is just about the worst svn browser I've ever seen
<pitti> I just want to look at a file...
<azeem> pitti: heh, I feel your pain
<directhex> they updated wsvn to a version which can't browse source
<directhex> use viewvc
<slangasek> superm1, fader_: mythbuntu build going now
<fader_> slangasek: Thanks
<cheleo> is the rc to be released today?
<vlada_> thank you all
<vlada_> I have another strange problem
<vlada_> cmake generates this message:
<vlada_> -- The CXX compiler identification is unknown
<vlada_> CMake Error: your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found.   Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
<vlada_> every other pagkage seems to recoganized
<dholbach> slangasek: do you think bug 334657 is release-critical?
<ubottu> Launchpad bug 334657 in qt4-x11 "Subpixel/Lcd mode with VRGB/VBGR makes qt4 applications on Jaunty unreadable" [Medium,Confirmed] https://launchpad.net/bugs/334657
<slangasek> dholbach: is it really only VBGR/VRGB that are affected?  That seems like a blatant configuration error, then?
<dholbach> slangasek: I have no idea - ccm (in #ubuntu-bugs) told me about it and asked how to get more attention to it
<slangasek> (you don't use the vertical subpixel settings unless your pixels are laid out vertically; which for most people they aren't0
<dholbach> seb128, Riddell: any idea about bug 334657?
<ubottu> Launchpad bug 334657 in qt4-x11 "Subpixel/Lcd mode with VRGB/VBGR makes qt4 applications on Jaunty unreadable" [Medium,Confirmed] https://launchpad.net/bugs/334657
<seb128> dholbach: why would I have any idea about qt?
<seb128> no
<seb128> I've no clue about fontconfig, fonts or qt
<ccm> hi there
<dholbach> ccm: slangasek asked: "is it really only VBGR/VRGB that are affected?  That seems like a blatant configuration error, then?"
<ccm> dholbach: in my tests it is and all users seemed to report so
<ccm> dholbach: it happened directly after an upgrade to jaunty for me
<slangasek> ccm: why did you have VRGB set?
<slangasek> that's not a default, and it's not the subpixel orientation that most users have
<ccm> slangasek: actually that was a result of lcd (laptop) display tuning for getting better font results - as it is quite easy to reach this menu in ubuntu and you dont even need admin rights for it, i think a bunch people tested it
<ccm> slangasek: and might still have turned it on as it had no negative side effect
<slangasek> well, it's still a misconfiguration if you click a setting that doesn't actually match your subpixel layout, and if it looked good at all that was an unintended side-effect in the first place
<slangasek> so I don't see that this is a critical bug
<slangasek> superm1, fader_: mythbuntu 20090416 up
<fader_> slangasek: Thanks, I'll start grabbing it
<slangasek> superm1, fader_: can you give an estimate of how long it'll take to get the tests covered?
<fader_> slangasek: I think I can get the i386 ones done in 1-1.5h once I have it downloaded
<slangasek> fader_: how long's the download take? :)
<fader_> slangasek: I'll let you know in just a moment :)
<slangasek> ok
<fader_> slangasek: rsync says about 15 minutes for the download
<slangasek> cool
<ccm> slangasek: well actually vrgb is broken now. that means at least it will hit users who intentionally configured it for rotated displays and those who turned it on by chance. so the question seems more if it might have impact to a remarkable amount of users after release - be it by misconfiguration or intention, in fact both will be presented unusuble qt applications and might have no clue at all on how to fix it
<Keybuk> fbond: what would you like to know?
<slangasek> ccm: can you give me a simple test case with which to reproduce the bug, given that I'm running Ubuntu with no Qt apps currently installed?
<fbond> Keybuk: Can you point me to docs in the wiki?
<Keybuk> fbond: what are you trying to do?
<fbond> I want to force r8168 to be loaded before r8169.
<Keybuk> fbond: there is no r8168 driver
<fbond> Oh, crap, that's right.  This system is actually Debian.  Sorry.
<Keybuk> fbond: off to #debian with you then ;)
<ccm> slangasek: I assume no
<fbond> Keybuk: sorry about that.  I forgot that I sometimes am on machines that *aren't* running Ubuntu.
<slangasek> ccm: hmm?
<cody-somerville> Its okay fbond. I make that mistake *all* the time.
<ccm> slangasek: at least "qtconfig" is enough as a test application
<cody-somerville> :P
<tjaalton> Keybuk: network is started up both by udev and init, but why?
<Keybuk> fbond: though in general, first check whether your device is supported by the other driver (modinfo r8168)
<slangasek> ccm: ok, grabbing
<pitti> fbond: curiously, I sometimes forget that there are machines out there which aren't running Linux.. :)
<Keybuk> tjaalton: physical devices are started by udev, logical devices by init
<slangasek> ccm: in any case, even if the conclusion is that Qt is Really Broken, this is likely to be a matter for an SRU rather than an emergency pre-release fix
<fbond> Keybuk: I'm bugging people in #debian now, but in this case r8168 and r8169 both support the chip in question, but r8169 is buggy on it while r8168 works fine.
<fbond> Keybuk: Meanwhile, the *other* chip on the system requires r8169.
<ccm> slangasek: then go you to you display settings and enale "lcd" mode and "vrgb" (while no qt app is running)
<ccm> slangasek: then start qtconfig
<tjaalton> Keybuk: well, ifup -a is run twice here, since /e/n/interfaces has eth0
<slangasek> augh, just turning on VRGB hurts my eyes
<Keybuk> fbond: ah, then you need both 8168 and 8169 loaded
<tjaalton> at least the services in if-up.d are run twice
<Keybuk> tjaalton: ifup -a should only be run once
<Keybuk> tjaalton: udev does not run it, it will run ifup eth0
<Keybuk> fbond: in that case, you're going to have to poke things in /sys/bus/pci/drivers/r8169 and 8168
<tjaalton> Keybuk: right, true.. but the services are restarted
<Keybuk> tjaalton: shouldn't be
<Keybuk> tjaalton: if the device is up, it won't be run again
<slangasek> ccm: I cannot say with certainty that what qt is doing there is actually wrong for true VRGB
<tjaalton> nfs-common is run three times here (obviously a bug, it shouldn't do that in rc2/S20)
<slangasek> wait, yes I can, I can rotate my output :)
<Keybuk> tjaalton: are you sure they're not just getting run again because you don't actually check multiple devices?
<Keybuk> tjaalton: they'll be run for "ifup lo" *and* "ifup eth0" remember
<ccm> slangasek: well qtconfig looks unusable, right? in all display directions
<fbond> Keybuk: That seems ... unreasonable.
<Keybuk> fbond: why?
<fbond> Keybuk: Well, I just can't help but feel that I have to know an awful lot of implementation details to do something that seems pretty simple.
<fbond> Keybuk: Between udev/modprobe/sysfs ...
<Keybuk> fbond: changing drivers is not supposed to be "simple"
<Keybuk> you're not supposed to need to worry about it at all
<fbond> Keybuk: Oh, well that's true.
<fbond> Keybuk: Any docs on the particular pokings that need to occur?
<slangasek> ccm: ah, yes, it's still unusable when I rotate my monitor (and not just because it makes my neck hurt)
<tjaalton> Keybuk: ah, excellent..
<Keybuk> fbond: there's lots of documentation, e.g. in the kernel source
<Keybuk> tjaalton: there's a reason we don't start services in that directory ;)
<slangasek> ccm: so it's certainly a valid bug, but we certainly can't commit to fixing this before release when there's no known fix yet
<tjaalton> Keybuk: hmm, you mean the ones in if-up.d shouldn't be run?
<fbond> Keybuk: Would it be unreasonable to, e.g., blacklist both r8168 and r8169 and then put both in /etc/modules?
<ccm> slangasek: okay then. If that does not fit into release critical thats fine for me. I just wanted to bring this up to somebody who can say so as it did not get any attention so far and I wanted to prevent that it just got overseeing.
<Keybuk> fbond: wouldn't make any difference
<ccm> slangasek: thank you for the taking the time
<Keybuk> fbond: both would load, and the existing rules for binding would still take place
<slangasek> ccm: no problem :)
<ccm> dholbach: and thank you for getting me in contact :)
<Keybuk> tjaalton: they're not services usually, they're tasks
<dholbach>  ccmno worries
<dholbach> ccm: no worries :)
<Keybuk> tjaalton: ie. they poke or prod or do something when a network device comes up
<Keybuk> tjaalton: we don't start/stop services based on the presence or not of network devices
<Keybuk> fbond: the kernel makes the decision which driver gets which device
<fbond> Keybuk: Things currently work if I rmmod both, modprobe r8168, and then modprobe r8169.  I was under the impression that drivers "claim" devices.
<Keybuk> fbond: ah, that's more interesting then - yes you can force that
<Keybuk> though that should be forceable with a tweak to modules.order
<fbond> Keybuk: Ah, perfect.  Let me read about that.
<Keybuk> ie. edit /lib/modules/$(uname -r)/modules.order and make sure r8168 is before r8169
<Keybuk> (assuming both claim your device, that will make 8168 "win")
<fbond> Keybuk: If depmod gets run will my changes be overwritten?
<Keybuk> fbond: no, only a kernel upgrade would overwrite your changes
<Keybuk> use dpkg-divert to prevent that
<fbond> Keybuk: Great, thanks for your help.
<fbond> I'm still hoping that one day I will understand udev, modprobe, and kernel interactions.  But I think it would take a few days of reading.
<Keybuk> fbond: there's good books on it which are only slightly out of date <g>
<fbond> Keybuk: You're pulling my leg, right?  Does such a book truly exist?
<Keybuk> fbond: "Linux Device Drivers" by Greg Kroah-Hartman
<fbond> Keybuk: Oh, I have an old old copy of that, I think.
<tjaalton> Keybuk: yes, figured as much. maybe I just need to hack around the mountnfs issues for now, and make sure this works properly when sysv-initscripts are replaced by upstart events ;)
<Keybuk> tjaalton: karmic, hopefully
<tjaalton> Keybuk: yeah, looking at the specs
<Keybuk> fbond: http://lwn.net/Kernel/LDD3/ is the current edition
<Keybuk> fbond: ch.14 is the relevant one, though there are improvements there that the book misses
<fbond> Keybuk: I think I bought my copy about 5 years ago.  I'll have a look at the recent edition.
<Keybuk> fbond: LWN is an excellent resource for catching up on the changes since
<fbond> Keybuk: Okay, thanks again.
<Keybuk> (in summary, rather than all the _PRODUCT, _ID, etc. nonsense, the kernel now exports a single MODALIAS string that describes the device uniquely
<Keybuk>  and modules have aliases that wild-card match these strings
<Keybuk>  so if we do 'modprobe $MODALIAS' we get whatever module(s) think they can support that card)
<slangasek> superm1: ping?
<tkamppeter> pitti, hi
<slangasek> fader_: hmm, I forgot that I'd already neutered the sync-mirror script - you don't actually have mythbuntu 20090416 yet
<slangasek> (because I failed to fully publish it)
<fader_> Ah, heh... okay, I'll stop testing :)
<slangasek> publishing now
<fader_> Should I just grab it from cdimages via http?
<slangasek> fader_: whichever way you'd like to grab it - just make sure you're grabbing the 20090416 serial
<fader_> slangasek: roger that... I'll just grab it via http
<pitti> hey tkamppeter, how are you? had a good travel back?
<tkamppeter> Yes, and I have a new SRU, for Jaunty and for Intrepid, bug 357732
<ubottu> Launchpad bug 357732 in ghostscript "cups always prints with the default page size" [Undecided,New] https://launchpad.net/bugs/357732
<tkamppeter> The patch is small, perhaps the Jaunty version can directly get in after the RC.
<azeem> W31
<azeem> bah, sorry
<pitti> tkamppeter: should rather become an SRU
<tkamppeter> pitti, uploaded to Debian BZR of CUPS
<pitti> tkamppeter: ok, thanks
<tkamppeter> pitti, how to proceed for the Jaunty SRU?
<pitti> tkamppeter: we should create a jaunty branch anyway
<tkamppeter> pitti, also uploaded upstrream now.
<pitti> tkamppeter: "uploaded"?
<tkamppeter> Upstream is http://www.openprinting.org/download/printing/pdf-printing/
<pitti> ah, that part :)
<tkamppeter> pitti, you thought that upstream is Debian?
<pitti> tkamppeter: no, I thought that you got cups upstream commit rights now
<vlada_> can somebody tell me how can I get c++ executable
<vlada_> gcc is already installed?
<directhex> gcc is a C compiler
<vlada_> -? +!
<directhex> g++ is for c++
<directhex> install build-essential.
<vlada_> didrocks: thanks
<vlada_> I've never thought these could be separate packages
<superm1> slangasek, pong
<slangasek> superm1: hi, mythbuntu images are up and waiting :)
<superm1> okay cool thanks
<fader_> superm1: I'm testing the i386 ones atm
<fader_> (Just FYI)
<superm1> fader_, cool, i'll grab amd64 then
<superm1> i've got amd64 hardware that failed that open luckily enough
<fader_> Works out well then :)
<tkamppeter> pitti, bug 357732 is prepared for a Jaunty SRU. An Intrepid SRU is not needed (here the bug does not occur).
<pitti> tkamppeter: thanks, this will be a good reminder
<tkamppeter> bug 357732
<evand2> seb128: Do you have any suggestions for a workaround for bug 361112?  I'm convinced it's a GTK/metacity bug as we definitely call set_transient_for.
<seb128> evand2: better to ask mvo about wm issues
<evand2> sure thing.  mvo ^
<mvo> evand: looking now
<evand> thanks!
 * jtholmes is away: for about 3 hours
<mvo> evand: could you please try http://paste.ubuntu.com/152178/ ?
<evand> will do
<mvo> evand: I will be away for a bit for dinner but I will read backlog
<evand> ok
<evand> mvo: no such luck
<Keybuk> liw: Matrix Keysigning Party?
<Keybuk> we all wear PVC, Bondage Gear, Sunglasses and come with large guns?
<jdong> now THAT'S a keysigning party :)
<jdong> WHOOO I GOT video-intel TO HANG AGAIN!!
<jdong> compiz's fade-in animation for the Firefox awesomebar did it in this time.
<Keybuk> jdong: there's no prize for that, you know? :)
<jdong> Keybuk: so that's why I'm not filthy rich yet :)
<Keybuk> getting video-intel to not hang is where the prize is at
<jdong> now that's no fun.
<ogra> jdong, well, at least it hangs for you ... for me it does that:
<ogra> Swap:      4803392    4352308     451084
<jdong> awesome
<jdong> does it put itself out of misery soon thereafter?
<ogra> until i hit OOM at some point and the whole machine hangs
<jdong> aww.
<ogra> though i'm adventurous and use UXA
<jdong> apart from hanging after 30 minutes of use, 90% probability of crash-after-resume is my other problem.
<jdong> this is under UXA
<jdong> EXA has completely stopped working for me in Jaunty
<jdong> (when compiz attempts to launch I get a GPU lockup)
<ogra> works here just not fast
<Keybuk> UXA is full of lock-up bugs
<Keybuk> really no prizes there
<ogra> yeah
<ogra> but i somehow got used to see xchat through my terminal windows while working
<ogra> no UXA no compiz for me
<slangasek> superm1: how's it looking for you?
<fader_> slangasek: Sticking my $0.02 in, i386 looked great
<superm1> slangasek, not sure yet.  my download took awhile, so i'm just testing now
<slangasek> ok
<superm1> fader_, what graphics hardware did you test with?
<superm1> fader_, not sure if you saw with your disconnect; what graphics hardware did you test with?
<fader_> I tested in virtualbox... not sure what it emulates
<superm1> vesa
<superm1> and mythtv-setup was fine for the last step correct?
<fader_> superm1: Correct... I didn't see any problems in any of the setup screens
<superm1> fader_, okay cool; good
<pitti> tkamppeter: I thought bug 357732 wasn't needed for intrepid? You requested an intrepid task; also, the jaunty task is needsinfo, is it still waiting on something?
<ubottu> Launchpad bug 357732 in ghostscript "cups always prints with the default page size" [Undecided,Invalid] https://launchpad.net/bugs/357732
<fbond> Keybuk: FWIW, blacklist r8168, blacklist r8169, and putting r8168, r8169 in /etc/modules does do the trick.  initramfs needs to be regenerated, of course, and your root fs can't be on a network filesystem.
<fbond> Keybuk: modules.order doesn't seem to be used/present on any systems I have available here, BTW.
<fbond> Keybuk: (but I didn't look that hard)
<superm1> slangasek, i'm having a hard time authenticating with iso tracker for some reason (getting 403 errors), but the test turned out mostly right.  the bug we were trying to fix is fixed, but it uncovered another (in ubiquity) that is lower priority.  so i'd say push rc, and i'll have the ubiquity bug fixed for final
<Keybuk> fbond: ok
<slangasek> superm1: ok, thanks
<pitti> lool: notify-osd bzr branch has two uploads which aren't in jaunty; and the second is unreleased
<pitti> lool: the second one has major changes, I hope you didn't intend them to go into jaunty?
<lool> pitti: The first is in the queue
<lool> pitti: the second is just in progress stuff not worth an upload
<pitti> lool: ok, that's for karmic then; I'll branch off a jaunty branch and commit the stuff DX asked for for jaunty
<lool> pitti: The changes are trivial, but they might show a big diff; happy to defer to karmic
<tkamppeter> pitti, I have updated bug 357732 now. I have requested the Jaunty and Intrepid tasks before I found out that the bug is not present in Intrepid. The Intrepid task I have set Invalid now. I have also set the CUPS/Jaunty task to "In progress" now as the reporter has done the requested tests and the fix is uploaded upstream and commited to Debian.
<ubottu> Launchpad bug 357732 in ghostscript "cups always prints with the default page size" [Undecided,Invalid] https://launchpad.net/bugs/357732
<kees> pitti: hi, I have a friend experiencing the volume-notification part of bug 338837, but he's running notify-osd past 0.9.5 which supposedly fixed it
<ubottu> Launchpad bug 338837 in notify-osd "New notification does not work if icon theme is changed from Human" [High,Fix released] https://launchpad.net/bugs/338837
<kees> does anyone have a T60 that can reproduce this: 362463 ?
<Pici> bug 362463
<ubottu> Launchpad bug 362463 in notify-osd "Volume change notifications no longer displayed in Jaunty" [Undecided,New] https://launchpad.net/bugs/362463
<bryce> pitti, slangasek:  https://wiki.debian.org/XStrikeForce/InputHotplugGuide
<Pici> kees: I can reproduce that here.
<chrisccoulson> Pici - you see anything on the session bus?
<Pici> chrisccoulson: dbus-monitor? No. I get activity for changing the brightness, but not from volume changes/mutes.
<chrisccoulson> i'd be tempted to reassign that to gnome-settings-daemon then
<chrisccoulson> it's not a notify-osd bug if there is no messages being sent to it
<kees> chrisccoulson: what's the method for debugging this?
<kees> Pici, chrisccoulson: dmandell is the filer of 362463
<kees> dmandell: can you run "dbus-monitor" and see if you get messages for volume changes?
<kees> dmandell: Pici was not seeing dbus notifications, so it seems like this is a lower regression than just notify-osd
<pitti> kees: can you please follow up in the bug and talk to MacSlow about it?
<dmandell> Sure
<kees> pitti: sure, though I'd like to have more specific details.
<pitti> bryce: want me to do anything with that guide? (ECONTEXT)
<dmandell> No messages when I change my volume.
<kees> dmandell: okay, cool.  can you add that detail to the bug report?
<dmandell> Yup.
<kees> chrisccoulson, pitti: what is actually responsible for sending those dbus messages?
<bryce> pitti: nope, just reference
<pitti> kees: that's done by libnotify1
<pitti> kees: programs usually link to that, and this converts the libnotify API calls to d-bus messages, which notification-daemon or notify-osd pick up
<pitti> kees: but I doubt that there's a problem with the dbus side
<pitti> I guess it just fails to draw the bubbles
 * pitti -> dinner
<kees> the drawing works, but the app linked to libnotify1 isn't sending... but I don't know what app that is on a T60.  :)
<pitti> kees: oh, I see; that's an app problem then, and dbus-monitor should show whether it's actually sending the calls
<kees> pitti: right, I just don't know how the button-press maps all the way into dbus.
<kees> pitti: and it's clearly HW specific.  2 T60 people see it, and I don't.
<kees> pitti: and their volume buttons actually function.
<ebroder> kees: Should I add openafs-client.NEWS entries to all of the debdiffs for bug 356861?
<ubottu> Launchpad bug 356861 in openafs "OpenAFS Security Advisories 2009-001 and 2009-002" [Undecided,In progress] https://launchpad.net/bugs/356861
<kees> ebroder: we tend not to, but you can if you want.  :)
<kees> tedg: ah-ha, there you are.  trying to track down the root cause of bug 362463
<ubottu> Launchpad bug 362463 in notify-osd "Volume change notifications no longer displayed in Jaunty" [Undecided,New] https://launchpad.net/bugs/362463
<ebroder> kees: *nods* Ok. Since the intrepid one is the only one that needs changing, I'll pull it from there for consistency :)
<ebroder> Hmm...actually, I take that back. I think I do want them in there so people know you need to upgrade the kernel modules
<tedg> kees: My guess would be gsd would be the next place to look.
<tedg> kees: The person to ask about that is davidbarth, who doesn't seem to be in this channel.
<tedg> kees: #ayatana
<kees> tedg: what can dmandell do to diagnose that?
<kees> tedg: he's not in #ayatana either :(
<tedg> kees: Hmph.  There goes passing it off :)
<kees> tedg: any ideas on how to diagnose gnome-settings-daemon ?
<hyperair> add some fprintf hooks in it
<hyperair> =p
<tedg> bratsche: The bug we're talking about is bug 362463
<ubottu> Launchpad bug 362463 in notify-osd "Volume change notifications no longer displayed in Jaunty" [Undecided,New] https://launchpad.net/bugs/362463
<tedg> kees: No, not really :(  I'm hoping that bratsche does :)
<kees> tedg: could debian/patches/16_use_synchronous_notifications.patch have done it?
<bratsche> I'll take a look.
<kees> tedg: that's the only thing that seems to touch notifications recently.
<kees> bratsche: cool, thanks
<tedg> kees: Well, that should make them work at all.  So it should have to be there.
<kees> heh
<tedg> kees: It may have changed though, and that might be the issue.
<bratsche> kees: You know, I think this may have been removed deliberately because some people (including myself and dobey) were complaining that it's annoying to hit the "volume up" button and then see a notification that basically says "you just hit the volume up button, as you thought you did."
<kees> bratsche: but this still happens for me on my machine.
<kees> bratsche: i.e. it's specific to the T60 or something.  also, I thought that was the point of those notifications?
<kees> bratsche: it gives you an indication of where you are on the spectrum of volume, min, max, etc
<kees> bratsche: I would imagine mpt would freak out if volume-change-notifications were _removed_.  :P
<bratsche> I just tested, and when I do volume up key.. I get the volume progress bar kind of notification.. but I no longer get the one that just says "you hit the volume up button" or whatever.
<bratsche> Let me go test on my Thinkpad.
<kees> bratsche: right, we're debugging a total lack of the progress bar notification.
<bratsche> Ah, I see.
<bratsche> Okay hang on.
<bratsche> I misunderstood.
<kees> np :)
<bratsche> I'm getting the progressbar notification on my T61
<bratsche> Let me update and make sure I'm on the latest package.
<kees> bratsche: dmandell (and Pici) are seeing the problem, so anything you can have them do to help diagnose would rock (if you can reproduce it yourself).
<a|wen-> pitti: ping
<bratsche> I'm updating now.
<dmandell> top
<bratsche> kees: I just did an update and restarted my T61 and the volume progress notification is still working for me.
<kees> bratsche: okay, please work with dmandell, he's the one seeing the issue.  :)
<kees> heya mneptok
<mneptok> kees: ahoyhoy!
<mneptok> kees: you going to be in town around the middle of June?
<mneptok> (PDX)
<dmandell> bratsche: Anything I should do to debug?
<kees> mneptok: I think so, yes, drop me a line.  :)
<bratsche> dmandell: I'm not familiar with this code yet.  Let me take a look in it.
<dmandell> Ok.
<bratsche> dbarth did the gsd patches I think, but he's not around right now.
<bratsche> dmandell: You're up-to-date right?  And you reset after your last update?
<mneptok> kees: roger roger
<dmandell> bratsche: I updated yesterday to see if the problem had been fixed, rebooted after the update.
<bratsche> Okay, just checking.
<dmandell> I can do it today to rule that out as a problem.
<bratsche> I'm looking through the code, but I'm not really sure what to be looking for yet.  I should talk to dbarth probably since he's more familiar with it.
<pitti> kees: oh, it's about the volume buttons?
<pitti> kees: the path is roughly like this:
<pitti> kees: keypress -> kernel -> evdev event KEY_VOLUMEUP -> X.org -> X.org key Event XF86VolumeUp -> gnome-settings-daemon -> call libnotify to produce volume up notification -> dbus -> notify-osd picks it up and draws bubble
<pitti> a|wen-: hi
<sbeattie> pitti: where does the actual sound volume adjustment occur in that pipeline?
<pitti> sbeattie: that's also g-s-d, triggering the mixer when it receives the keypress
<sbeattie> pitti: cool, thanks.
<a|wen-> pitti: i was just in a longer discussion in #ubuntu-modu about the sru policy https://wiki.ubuntu.com/StableReleaseUpdates ... motu-sru would like to give the ack before upload, and afaik for main uploading before ack is ok?
<pitti> sbeattie, kees: if you strace -p `pidof gnome-settings-daemon` and press the button, you should see some open("/dev/snd/controlC0", O_RDWR) fiddling
<pitti> and in dbus-monitor there should be something like http://paste.ubuntu.com/152308/
<pitti> i. e. g-s-d sending to dest=org.freedesktop.Notifications the notification-audio-volume-high message
<pitti> a|wen-: right; it's much easier (and rare) to reject something from the queue than to have the uploader wait for another round of bug ping pong
<pitti> a|wen-: however, that's standard practice for main; if motu-sru wants ack-before-upload, that's totally fine for me
<pitti> a|wen-: just let me know what you decide, so that I stick to it
<pitti> a|wen-: right now, my practice is that when I see an universe upload in the queue, I look at the bug and check if it's ack'ed; if not, I sub motu-sru and ask for ack
<chrisccoulson> dmandell - for the volume notification issue, it might be useful to do "killall gnome-settings-daemon; gnome-settings-daemon --debug --no-daemon" and attach the output to the bug report when you hit the volume key
<chrisccoulson> g-s-d is quite verbose in debug mode
<a|wen-> pitti: all started with the process description not being clear about ack before upload or not necessary ... you might get a ping from jdong at some point about updating the description to reflect their decision (nobody fills compelled with changing wordings in processes too much)
<dmandell> chrisccoulson: No output at all from hitting volume key
<chrisccoulson> very strange
<chrisccoulson> if you completely kill gnome-settings-daemon and then hit the volume key, then does the volume change?
<chrisccoulson> it shouldn't, but i just wonder if you've got something else that grabs the key (very unlikely)
<chrisccoulson> i should check to see if i get debug output on volume change actually;)
<chrisccoulson> i get this output each time i hit the volume key:
<chrisccoulson> ** (gnome-settings-daemon:28950): DEBUG: Using volume step of 6
<chrisccoulson> you don't see that no?
<liw> Keybuk, I keep forgetting that movie exists, ever since the sequels
<ion_> liw: http://xkcd.org/566/ (the bottom one)
<seb128> dmandell: there?
<dmandell> seb123: I'm back
<dmandell> seb123: Went to lunch.
<seb128> dmandell: I was not there before but I read the bug, what hardware do you have? do you event for those keys in xev?
<dmandell> chrisccoulson: The volume buttons on my T60 stlil work with gnome-settings-daemon disabled.
<chrisccoulson> right#something else has to be grabbing the volume button
<chrisccoulson> wierd
<dmandell> seb123:  I'm just a normal user, I don't think I'm doing anything weird, how would I check xev?
<dmandell> chrisccoulson: Per the bug, this worked in Jaunty until fairly recently, I haven't made any config changes in that time, just apt-get updates.
<seb128> dmandell: open a command line and type "xev"
<chrisccoulson> dmandell - my volume doesn't change when i kill gnome-settings-daemon
<seb128> chrisccoulson: hi, you get the bug too?
<chrisccoulson> no, it works fine for me
<dmandell> when I start gnome-settings-daemon --debug --no-daemon, I see the following:
<dmandell> ** (gnome-settings-daemon:25566): DEBUG: Unable to parse: 'XF86AudioMedia'
<dmandell> Not sure if it has anything to do with anything, but it's audio related so I thought I'd bring it up.
<chrisccoulson> dmandell - what does xev show when you press the key with no gnome-settings-daemon running?
<seb128> dmandell: should not, could you run xev and see what events you get for those keys?
<seb128> chrisccoulson: could be bug #357673 but it doesn't have lot of details, still good to debug it
<dmandell> nothing in xev
<ubottu> Launchpad bug 357673 in gnome-settings-daemon "No notification when sliding audio volume on X31" [Low,Incomplete] https://launchpad.net/bugs/357673
<seb128> dmandell: is g-s-d running?
<seb128> does stopping it makes a difference?
<dmandell> seb128: yes
<dmandell> (running)
<chrisccoulson> you should kill it first
<seb128> chrisccoulson: you think that g-s-d grab events and do nothing with those?
<dmandell> no, killing it doesn't make a difference.
<chrisccoulson> seb128 - i think there is something else on the system grabbing the key
<LaserJock> hmm, did Gnome switch to git today?
<seb128> ok, so sounds similar to #357673
<chrisccoulson> dmandell says that the volume still changes with no g-s-d running at all
<seb128> LaserJock: they are in the middle of it not sure if it's done yet
<seb128> chrisccoulson: his laptop might have those cabled, ie acting on an hardware level
<LaserJock> seb128: does that mean any bzr mirrors or bzr-svn branches are going to not work now?
<seb128> LaserJock: that would be a question for #launchpad rather I guess
<chrisccoulson> seb128 - quite possible, but they worked at some point before
<LaserJock> seb128: right, just thought you might know
<seb128> chrisccoulson: before today or before a linux or xorg update? ;-)
<seb128> LaserJock: no, I don't use bzr imports, I use svn directly usually
<seb128> it's faster and less buggy (no outdated imports)
 * chrisccoulson finds it very confusing to understand how keypresses get from the hardware to an application
<LaserJock> seb128: ah, but I guess you'll have to switch to git or find a bzr <-> git method
<seb128> LaserJock: I'm not using bzr to work on GNOME so I've nothing to switch really
<seb128> LaserJock: we only have the debian directory in bzr for desktop packages and we use tarballs
<dmandell> seb128: the timeframe of bug 357673 approximately matches my own.  I think I lost volume notifications at around the same time.
<ubottu> Launchpad bug 357673 in gnome-settings-daemon "No notification when sliding audio volume on X31" [Low,Incomplete] https://launchpad.net/bugs/357673
<chrisccoulson> dmandell - could you switch to a terminal (CTRL+ALT+F1), and run "sudo showkey -k" and press the volume button
<chrisccoulson> do you see any keycodes when you do that?
<LaserJock> seb128: ah, I thought you were doing more upstream stuff so that you'd often want VCS checkouts
<LaserJock> seb128: anyway, I'll ask #launchpad
<seb128> chrisccoulson: https://wiki.ubuntu.com/Hotkeys/Troubleshooting is quite detailed
<chrisccoulson> thanks seb128 - i'll have a read of that
<seb128> dmandell: you might want to follow instructions on https://wiki.ubuntu.com/Hotkeys/Troubleshooting too
<ion_> I didnât read the bug report, but i think some package changed something so that the volume control keys donât control software volume *at all*, since they canât be prevented from controlling the hardware volume. Thatâs probably why thereâs no indicator.
<dmandell> chrisccoulson: nothing happens
<dmandell> no keycodes
<chrisccoulson> dmandell - that's wierd, so the kernel is not producing any keypress event at all
<seb128> dmandell: do you still have old linux versions installed you can boot?
<ion_> chrisccoulson: Thatâs probably an intentional workaround.
<dmandell> seb128:  I may, hold on.
<chrisccoulson> thanks ion_ - is there a reference to that somewhere? do you know what changed?
<ion_> hotkey-setup (0.1-23ubuntu10): * Drop the override of the hotkey mask for ThinkPads.  This is currently used for brightness keys, volume keys, and the ThinkVantage button: - overriding the volume keys causes double-stepping of the volume, because the volume was also being adjusted in the hardware mixer, which we can't disable - so we don't want these keys exposed for now. LP: #355300.
<chrisccoulson> ion_ - thanks
<chrisccoulson> dmandell^^^
<chrisccoulson> looks a likely suspect for your issue
<seb128> and that was uploaded around the time where it broke
<seb128> bug #357673 is on 2009-04-08
<ubottu> Launchpad bug 357673 in gnome-settings-daemon "No notification when sliding audio volume on X31" [Low,Incomplete] https://launchpad.net/bugs/357673
<kees> ion_: what's the correct fix for this?
<ion_> kees: I havenât investigated the issue, but probably either finding a way to disable the hardware mixer control, or making the keys control the indicator but *not* software volume.
<ion_> The latter one would probably be a bit of a kluge.
 * kees 's head spins
<kees> ion_: so prior to that fix, pressing volume keys on that hardware would double-step?
<ion_> Yes
<ion_> The behavior used to be such that like 80% of the volume indicator would be equivalent to total silence and the last 20% would suddenly raise the volume.
<kees> icky.  :)
<dtchen> can you try deselecting the relevant tracks using system> preferences> sound> devices> default mixer tracks ?
<dtchen> s/relevant tracks/relevant mixer elements/
<ion_> Which makes sense if you plot [0:1] x*x
* slangasek changed the topic of #ubuntu-devel to: Archive: release freeze | Ubuntu 9.04 RC candidate released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<cjwatson> slangasek: "RC candidate"? :-)
<calc> heh
<ebroder> Courtesy of the Department of Redundancy Department :)
 * jdong starts seeding the .torrent torrent
<ebroder> Oh, do torrents need seeds? I have bandwidth I can throw at the problem, too
<sladen> ebroder: throw it, and see if there are catchers
<DnaX> ogra: about status of irda-utils bugs?
<ericdc> I am remastering a Ubuntu Server 8.04 LTS CD with a preseed file. I would like to include some packages on the CD to avoid grabbing them from the internet. Can anyone help me or tell me when I can get help?
<ebroder> ericdc: You want to look at https://help.ubuntu.com/community/InstallCDCustomization
<ericdc> ebroder: thats where I started
<akgraner> mdz: What happened to the animal theme for the desktop background?
<directhex> akgraner, good question. i kept the default wallpaper for hardy & intrepid, but jaunty has pushed me towards nabbing something else
<akgraner> directhex: I was waiting for it, just downloaded the updates and was notified that the RC was done...Was hoping the last update would have the artwork.
<akgraner> well the animal artwork I mean...
<rickspencer3> akgraner: hi
<rickspencer3>  I hear you were asking about default artwork?
<BUGabundo> akgraner: hi
<akgraner> rickspencer3: hi
<akgraner> rickspencer3: yes...I was asking about the artwork
<rickspencer3> sorry I missed it
<rickspencer3> I hear through the irc grapevine you're looking for a bunny with antlers?
<rickspencer3> :)
<mdz> akgraner: I wouldn't go so far as to say there is a theme...the wallpaper has changed in different ways for each release.  these days, the design team develops it and we just drop it in
<akgraner> rickspencer3: yes...I was hoping with last updates I installed, when I did the reboot a Jackalope would appear...I was a little disappointed...
<rickspencer3> too bad
<rickspencer3> I'm sorry you're dissapointed
<akgraner> I liked the charm of that..was an announcement I missed.
<rickspencer3> kwwii: is there not a different background that would suit with one of the alternate themes?
<rickspencer3> akgraner: I don't think you missed an announcement
<rickspencer3> like mdz says, we just help out the art team by dropping in their great work
<mdz> akgraner: why did you expect to see a jackalope on your wallpaper?
<LaserJock> extrapolation from a data set of 2?
<akgraner> rickspencer3: maybe I'm just to new...well there was ipex and a heron...
<rickspencer3> yeah
<akgraner> so I guess I just expected a jackalope
<rickspencer3> akgraner: you're right, the totally abstract background is a break from tradition
<rickspencer3> but I think there are some good jackalope backgrounds out there
 * ScottK would have enjoyed Bassalope, but is many releases too late for that.
<ikus060> join #launchpad
 * ScottK hands ikus060 a '/'
<rickspencer3> I personally like how the new background has elements that are picked up elsewhere, like the default search page and such
<rickspencer3> I think kwwii, our resident artist is in Germany, so it's late there, but he'll be able to connect you with some of the community submitted themes that have the jackalopes
<akgraner> rickspencer3: I thought something that would break a tradition would have been discussed, that's why I asked if I missed something....
<LaserJock> akgraner: well, the animal theme was new for Hardy
<rickspencer3> akgraner: honestly, I don't know where it was discussed, I know the current background has been in the product for quite a while, since the week before visual freeze
<rickspencer3> I wish I tracked this more, but I think there's a way for community members to submit themes and such, so I know it's a totally public deciscion
<akgraner> rickspencer3: yes the current one as been there I just thought the final *pop* would be the animal showing up...that's all...
<calc> is it possible to have comments in the control file?
<rickspencer3> hehe
<mdz> akgraner: 8.04 was, I believe, the first release to have animal-themed wallpaper.  if there was a tradition, the people making the wallpaper didn't know about it :-)
<akgraner> rickspencer3: I'll go on a virtual hunt for the jackalope...just wish I had known it wasn't going to be there..I was *really* waiting to see it...
<ScottK> calc: yes.  leading '#'
<akgraner> mdz: see I blame on being the newbie..:)
<akgraner> blame it I mean
<ScottK> rickspencer3 and akgraner: There is a package called community-themes
<rickspencer3> akgraner: I invite you to come back tomorrow in (what is your) morning
<rickspencer3> ScottK - thanks
<akgraner> cool thanks!
<akgraner> rickspencer3: ok..
<akgraner> rickspencer3: what time and for what?
<rickspencer3> kwwii: will be here, he's a really good guy and is generally in charge of our artwork, perhaps you will meet in Barcelona
<calc> ScottK: ok cool :)
<ScottK> calc: I use it all the time to stub out misbehaving binaries.
<pwnguin> did i miss something? is there going to be a 9.06?
<calc> ScottK: cool :)
<cjwatson> pwnguin: ...
<calc> ScottK: i'm working on repackaging OOo and using it for better documenting
<akgraner> rickspencer3: ok  thank you, I'm afraid I won't be able to make Spain...:(
<rickspencer3> oh bummer
<rickspencer3> you know me and Pete work together right?
<rickspencer3> my wife couldn't make Barcelona either
<akgraner> rickspencer3: I do now
<pwnguin> cjwatson: someone posted to -devel about a problem with 9.06 installing netbook-remix
<rickspencer3> akgraner: let me know how the background works out for you
<rickspencer3> ttyl
<akgraner> rickspencer3: I will, Thanks..:)
<calc> akgraner: maybe you can make it to 10.04 UDS :)
<calc> akgraner: it should be somewhere in the US
<akgraner> calc: I hope one day...:)
<cjwatson> pwnguin: typo
<cjwatson> or possibly abject confusion
<akgraner> calc: if not I've already been talking to Outback steak houses for release parties..:)
<mdke_> lool: I know that Dougie Richardson was interested in helping out with UNR documentation, I'm unlikely to be able to help until the end of Sunday but if you post to ubuntu-doc I'm pretty sure you'll get a bite
<cjwatson> pwnguin: the mail is very confusing and suggests that perhaps they were getting an image from somewhere entirely different, not us
<pwnguin> probably
<akgraner> thanks ya'll for info...be back tomorrow..:)
<BUGabundo> akgraner: what theme colour would you like for KK? not sure if we are going Green (that would be too much openSUSE)
<robbiew> akgraner: http://kiriyard.com/2009/03/sarusaslu-jaunty-jackalope/
<akgraner> robbiew: me goes to look
<lool> mdke_: We posted, but are held for moderation I think
<lool> mdke_: Thanks
<akgraner> BUGabundo: I need to think about that question...
<akgraner> robbiew: Thanks!  Great site...:)
<BUGabundo> humm we are going out of raibow colours lol
<StevenK> akgraner: Outback Steak House for a release party? Oh, there has to be something better ... :-)
<BUGabundo> already used most of the brownish
<robbiew> akgraner: no problem
<BUGabundo> suse is grean, redhat is redish
<BUGabundo> and KDE uses all it can from blue and black
<akgraner> StevenK: there are but the Koala theme...seemed to go with it...and the bar areas are cool....:)
<BUGabundo> akgraner: are you imagining kk yellow? LOL
<mdke_> lool: did you post with an Ubuntu or Canonical address?
<StevenK> Argh, yellow is bad.
<StevenK> Yellow would require developers to wear sunglasses to use the release
<lool> mdke_: ubuntu
<mdke_> lool: nothing in the moderation queue
<mdke_> lool: those addresses should be whitelisted anyhow
<lool> mdke_: Might have gone through then -- I'm not sub-ed
<lool> mdke_: Right
<BUGabundo> StevenK: ehehe
<mdke_> lool: I don't see anything
<lool> mdke_: http://article.gmane.org/gmane.linux.ubuntu.doc/12370
<lool> largish thread already
<lool> mdke_: It's in the middle of it, sorry
<cjwatson> lool: FYI, pi-makelist-vfat seems to have broken with the partitioned armel images
<mdke_> lool: ok, I see that, but it doesn't look lik a request for help. Better to start a new thread and clearly request assistance :)
<lool> cjwatson: I think you had fixed that; it borke again?
<cjwatson> lool: if I remove the 2>/dev/null | sed from the end, I get http://paste.ubuntu.com/152384/
<cjwatson> definitely broke, we're seeing zero-sized .list files
<lool> cjwatson: That's bad; that's when a tool doesn't want LBA but only CHS addresses for partitions or verifies that they match both
<ogra> erm
<cjwatson> can I leave it with you?
<ogra> did you add a ~/.mtoolsrc ?
<cjwatson> yes
<lool> cjwatson: Yeah except I don't know what to do
<cjwatson> see debian-cd/tools/pi-makelist-vfat
<cjwatson> lool: you say that as if I do ;-)
<lool> I guess I have to compute CHS and LBA compliant addresses; but I don't know how parted picks them
<lool> The thing is that parted seems to change the disks' CHS depending on the partitions you create
<lool> That is if you "parted mkpart" twice, you see different CHS values for the disk
<cjwatson> if you can't figure it out, I can have a look tomorrow, maybe
<cjwatson> I know where to look for parted's CHS handling, at least roughly, but I don't know offhand how it behaves or how to control it
<lool> I'll try to fix it; I was hoping never to have to do that but it seems I was lucky until now
 * ogra doesnt see the mtools_skip_check=1 in the MTOOLSRC ...
<ogra> i think mtools need that for all image operations
<ogra> if you dont use actual devices
<lool> mdke_: Point taken; will write a new email asking explicitely
<mdke_> lool: roger. If nothing happens by the weekend, I'll lend a hand
<lool> ogra: That looks like a good setting to avoid touching this stuff altogether  :-)
<ogra> heh
<lool> mdke_: I'll wait til Tobin tries out various image writing tool and include his description in the list of things to help with; thanks
<mdke_> lool: ok
<ebroder> Looking at bug #356861, is the security team not going to handle the Jaunty upload? So I should find a sponsor?
<ubottu> Launchpad bug 356861 in openafs "OpenAFS Security Advisories 2009-001 and 2009-002" [Undecided,In progress] https://launchpad.net/bugs/356861
<kees> ebroder: for jaunty, you need to clear it with motu-release since jaunty is frozen.
<blfgomes> could anybody help me setup bzr to work with a proxy that requires authentication? =/
<cjwatson> blfgomes: #bzr is probably a better place to ask
<ebroder> Any motu-release types around to OK?
<lool> cjwatson: Sorry which image borke for armel?  live or alternate?
<blfgomes> cjwatson: it was down a while ago, but I guess it's up now... thanks!
<cjwatson> lool: I was looking at desktop, but both seem to have the problem
<cjwatson> blfgomes: that could only have been the server; individual channels on the same IRC server can't really be down independently
<blfgomes> cjwatson: whatever it was, it wasn't connecting :)
<dtchen> ebroder: i've pinged a -release member in -motu
<lool> ogra: What was the syntax to use skip_check in mtoolsrc?
<ogra> lool, well, whats said in the error message ;)
<ogra> mtools_skip_check=1
<lool> ogra: I should learn to read really
<ericdc> I do I prevent ppp-udeb to be loaded by the ubuntu installer OR how do I skip the detection with a preseed?
<ericdc> How do I prevent ppp-udeb to be loaded by the ubuntu installer OR how do I skip the detection with a preseed?
<lool> ogra, cjwatson: No, the skip_check isn't enough
<lool> damn
<cody-somerville> ericdc, What image are you using?
<ogra> but its definately needed if you work with images
<ogra> so keep it
<lool> ogra: Why?
<ogra> no idea, but i cant work with images with mcopy or mdir if i dont have it set ... i think it was explained in the manpage somewhere
<ogra> All the Mtools commands perform a few sanity checks before going ahead, to make sure that the disk is indeed an MS-DOS disk (as opposed  to,  say  an  ext2  or  minix
<ogra>        disk). These checks may reject partially corrupted disks, which might otherwise still be readable. To avoid these checks, set the MTOOLS_SKIP_CHECK environmental variable or the corresponding configuration file variable (see section  global variables)
<lool> Yes it wasn't needed so far
<lool> So I'd better keep the safety checks if disabling them isn't enough and they used to pass
<ericdc> cody-somerville>Ubuntu 8.04 LTS Server
<ogra> i never managed to work with mtools on images without them
<ogra> i remember i used to set MTOOLS_SKIP_CHECK in former scripts i did, nowadays i just have it in mtoolsrc
<ericdc> cody-somerville: I remastered the CD image with some extra packages and now it's failing detection pppoe concentrators. Which is BAD because I want the process to be fully automated.
<cody-somerville> ericdc, Did it try to detect PPPOE before?
<ericdc> cody-somerville: the worst part is I don't use pppoe
<ericdc> cody-somerville: no never
<ericdc> cody-somerville: only since I added extra packages
<cody-somerville> ericdc, I think you can preseed the the error messages so they don't show. I couldn't figure out how to make it not try and detect except by removing the udeb and regenerating the archive indices.
<ericdc> cody-somerville: I can't seem to find what d-i directive to use to skip it
<cody-somerville> ericdc, There is none
<ericdc> cody-somerville: I wish there was a list
<ericdc> really
<ericdc> crap ok
 * calc is beginning to think that the only reason multiple OOo can't be installed at the same time is due to buggy packaging (nothing in upstream itself)
<jdong> calc: is there ever a better reason for why you can't install the same package to two prefixes?
<calc> jdong: well its already essentially doing that by default, the debian packaging just changes it to be in a non-versioned prefix
<calc> at least afaict so far
<calc> OOo doesn't exactly follow the FHS
<calc> which makes it fairly easy to do the multiple install
<jdong> meh the FHS is a "recommendation"
 * jdong watches the pitchforks come
<calc> jdong: sticking arch indep data into /usr/lib isn't exactly a good idea
<jdong> ok that's a bit painful.
<calc> jdong: and as far as debian is concerned FHS isn't just a recommendation its required
<calc> of course some debian packages are thus buggy when it is too painful to try to fix them
<calc> there are 6 noted exceptions to FHS in policy
<jdong> right.
<jdong> I see the merit, but it does make packaging a lot hairier
<jdong> how do you put up with OOo packaging anyway? isn't there a good 6-8 hours of pipeline latency when you build a package? :)
<kees> pitti: I seem to have both /etc/default/apport and /etc/default/apport.default :(
<chrisccoulson> kees - there's a bug report for that already isn't there?
<calc> jdong: for a cached build it takes ~ 1-2hr
<kees> chrisccoulson: oh, dunno
<calc> jdong: for the buildds it takes ~ 36hr before they are all done (armel is really slow)
<jdong> ah I see
<jdong> at least caching makes it bearable then
<chrisccoulson> kees - bug 361543
<ubottu> Launchpad bug 361543 in apport "/etc/default/apport mistakenly installed as /etc/default/apport.default" [Medium,Fix committed] https://launchpad.net/bugs/361543
<kees> chrisccoulson: thanks
<calc> jdong: yea
<calc> jdong: aiui there is a better c++ linker that might help as well in binutils but it is still experimental
<kwwii> lol, I put mascots in the wallpapers and kinda felt the heat for it, and now we don't use them and people miss them, funny that
<kwwii> if it makes anyone feel better there is already a bunch of work going on in the ubuntu-artwork team creating koala pics ;)
<kwwii> personaly, I prefer my desktop without a mascot
<calc> kwwii: yes... no matter what you do it is wrong ;-)
<ebroder> I thought the Ibex was really well done. I swear I looked at the background for at least 2 months before even realizing it was supposed to be an Ibex
<jdong> kwwii: I'm thinking animated wallpapers
<jdong> like maybe with a jackalope and if you click it it runs across and shatters some desktop icons
<jdong> courtesy of compiz?
 * ebroder twitches
<askand> Anyone here familiar with the new notify-osd?
<askand> I am thinking of bug 338695 where lowresimages appears in the bubbles, in the case with pidgin it appears that they do not actually have a highresversion of the icon in question and therefore we see a lowresicon, would the way to go in this case be to file a bug against pidgin for not providing scalable images, or at least highresversions?
<ubottu> Launchpad bug 338695 in rhythmbox "low res icons for notifications" [Undecided,New] https://launchpad.net/bugs/338695
<cjwatson> ericdc: your remastering has probably set incorrect Priority fields; compare the Priority fields in your Packages files against those in the archive
<cjwatson> ericdc: also look through the installer's syslog to see which udebs it's loading; it generally includes a brief explanation of why
<cody-somerville> cjwatson, Does d-i load all the udebs on the cd or just those of a certain priority or what?
<cjwatson> cody-somerville: http://lists.debian.org/debian-boot/2004/07/msg01207.html
<cjwatson> in brief, by default it loads Priority: standard and above, and anything installed explicitly using an anna-install command (and the dependencies of both of those, of course)
<cjwatson> or the Enhances thing I mention; I forget whether I ever looked into how that really behaves
#ubuntu-devel 2009-04-17
<cody-somerville> Is there a udeb include and exclude file? I remember reading something about that.
<cjwatson> yes, there's one on the standard CD images. It contains netcfg, ethdetect, pcmcia-cs-udeb, and wireless-tools-udeb.
<cjwatson> anyway, I could debug ericdc's problem if I could see the syslog.
<cody-somerville> cjwatson, What takes precedence? The heuristics listed in your e-mail or the exclude list?
<cjwatson> cody-somerville: (they're rules not heuristics.) excludes seem to be dropped after everything else, apart from dependency resolution
<cjwatson> TBH it's easiest to look at anna.c:choose_modules() in the anna source package if you want details; it's not that hard to read
<cody-somerville> ok
<cjwatson> I've had trouble tracking down why people were seeing pppoe questions on customised images in the past and would actually quite like to sort it out with a syslog
<cjwatson> but now, bed
<StevenK> mv planet-ubuntu Danny-Piccirillo-planet
<directhex> StevenK, blogspot rss shat itself, then
<StevenK> directhex: Looks like
<lool> FIS partition ends at 16777215B and doesn't leave enough room for FIS 16777216B
 * lool sighs
* slangasek changed the topic of #ubuntu-devel to: Archive: release freeze | Ubuntu 9.04 release candidate released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> cjwatson: ...long day. :)
<jdong> now it's release candidate released :)
<lifeless> cjwatson: bug 12230
<ubottu> Launchpad bug 12230 in cvs "cvs checkout is racy, it wasn't in the past" [Medium,Incomplete] https://launchpad.net/bugs/12230
 * jdong thought it was better when it was release candidate candidate released
<jdong> for those people who read topics right to left
<lifeless> cjwatson: I find the repeated 'is it really still a bug' questions converge on 100% noise. Do you?
<jdong> O_O a 5 digit bug
<lifeless> jdong: yes, but its just an example of the make-work pattern in the 'bug team' that I have grown to loathe
<lifeless> its been triaged; its been analysed, the root cause is known.
<jdong> If I may appoint as a quote of the day:
<jdong> "Not a high priority, but should be fixed for Hoary so that Robert can remove the
<lifeless> all it needs is to be fixed.
<jdong> workaround and get better throughput"
<lifeless> and indeed, the cscvs test suite *still* works around this bug
 * lool sighs
<lool> Another 3 hours of sleep wasted, solution was trivial
<LaserJock> lifeless: do you actually want the status changed to Confirmed on that bug? it's still set at Incomplete
<lifeless> LaserJock: I replied via mail, the mail processor should andle it
<lifeless> oh, frell I forgot to indent
<lifeless> *so* annoying.
<LaserJock> just thought I'd check ;-)
<lifeless> thanks, appreciated
<alex-weej> does anyone semi-officially maintain linux 2.6.29?
<alex-weej> (an ubuntu package that is)
<TheMuso> alex-weej: there are mainline builds
<TheMuso> alex-weej: let me get an URL for you
<TheMuso> alex-weej: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.29.1/
<alex-weej> mainline = vanilla?
<TheMuso> dtchen: I've created a jaunty pulseaudio branch to allow for handling of SRUs etc, while the ubuntu branch will remain trunk/karmic development branch.
<slangasek> TheMuso: this linux-ports upload includes renames of the powerpc kernel packages; not mentioned in the changelog at all, and not acceptable post-RC
<slangasek> TheMuso: so I'm rejecting this out - can you fix that and reupload?
 * hyperair groans
<hyperair> shit. nautilus-share segfault huh
<hyperair> now if only i had the time to go digging for bugs right now
<TheMuso> Can I assume the linux-ports rejection was due to no bug task for the ext4 bugfix?
<StevenK> [11:59] < slangasek> TheMuso: this linux-ports upload includes renames of the powerpc kernel packages; not mentioned in the changelog at all, and not acceptable post-RC
<StevenK> [11:59] < slangasek> TheMuso: so I'm rejecting this out - can you fix that and reupload?
<TheMuso> StevenK: thanks must have missed that.
 * TheMuso ponders how that could have happened, and looks
<StevenK> TheMuso: The next line was you disconnecting :-P
<TheMuso> heh right
 * TheMuso finds the problem... Damn auto-generated control files. :S
<ebroder> Not cool: marking a public bug a duplicate of a private bug so I can't see the discussion
<cody-somerville> ebroder, I'm sure they didn't do it on purpose.
<cody-somerville> ebroder, Whats the bug number?
<ebroder> bug #273283. bug #349987 was marked as its duplicate
<ubottu> Bug 273283 on http://launchpad.net/bugs/273283 is private
<ubottu> Bug 349987 on http://launchpad.net/bugs/349987 is private
<ebroder> What?
<ebroder> Weird. I'm pretty sure I don't have any special bits that would let me see 349987
<cody-somerville> ebroder, fixed
<ebroder> :-D
<ebroder> Thanks
<ebroder> Oh, do apport bugs with proc maps/tracebacks/etc attached get marked private automatically?
<wgrant> Apport crashes do, yes.
<wgrant> For non-Python things they have coredumps.
 * ebroder nods. Makes sense
<wgrant> And publicising coredumps or tracebacks with variables expanded is a bad idea.
<ebroder> Hmm...re: bug #362691, it seems like a no-change rebuild will probably change the deps to use Python 2.6 instead of 2.5, but that also seems incredibly risky to do this late in final freeze. Is there any way to just change the dependencies of the package without actually doing a full rebuild?
<ubottu> Launchpad bug 362691 in xen-3.3 "XEN depends on Python 2.5" [Undecided,New] https://launchpad.net/bugs/362691
<ebroder> I guess the package could possibly be hacked to force it to use Python 2.5, but that seems kind of poor
<ebroder> I guess this may actually be better fixed as an SRU
<ScottK> ebroder: I'd rather fix it now and SRU if needed than release it known broken.
<ebroder> Fix it as in do a full rebuild?
<ScottK> Assuming that works, yes.  I didn't check if more was needed.
<ebroder> I have no idea if more's needed - I'm really theorizing here. I just wanted to get a second opinion before I went source diving
<ebroder> ScottK: It looks like the Makefile just uses `python setup.py` (with some environment vars and such), so I /think/ a rebuild might just fix it
<ajmitch> it may need the --install-layout change as well
<ScottK> Yep.
<ebroder> Oh, good point
<ScottK> ebroder: As ajmitch said, it may also need --install-layout=deb
<ebroder> I just add that to the setup.py install invoke, right?
<ScottK> I'd say give it a shot.
<ScottK> Yes.
<ajmitch> and if it has --prefix there, they are mutually exclusive now (iirc)
 * ajmitch may be wrong about that now
<ebroder> Wow...what a weird way of calling setup.py: `python setup.py install --home="$(DESTDIR)/usr" --prefix="" --force --install-lib="$(DESTDIR)$(LIBPATH)/python"`
<calc> hey what happened to karma?
<calc> i lost like 80K in the past couple days
<ScottK> calc: See planet.  Translation credits got adjusted.
<calc> ah ok
<ScottK> Personally, I think everyone who had to put up with those mails deserved the karma.  I know one guy got 14,000 before we got the job manually killed.
<Hobbsee> ++
<Hobbsee> or at least, if the karma was actually useful for something - like, redeemable at the canonical store or something.
<ajmitch> if it could be used like that, you can bet there'd be many more people doing less-than-helpful bug triage
<ScottK> And we have enough of that already.
<ScottK> Personally I try to keep my karma below a certain level and use it as a guage of "You've been spending too much time on Ubuntu lately".
 * cody-somerville makes a note to have Launchpad OSA's regularly cut ScottK's karma in half.
<ajmitch> now that karma's been adjusted, you can spend a whole lot more time on ubuntu for the same value
<ScottK> Well last time I looked it was ~15K and now it's 60K, so I've messed something up.
<cody-somerville> uploads now get you loads of karma
<superm1> do main uploads get you more than universe uploads or anything crazy like that?
<ScottK> Yeah.  I just looked and without the soyuz karma about about at ~10K, which has been my goal.
<ScottK> There should be negative karma for uploada that FTBFS.
<ScottK> uploada/uploads
<ebroder> Ugh. I hate when the clean target doesn't work in a package "W: xen-3.3 source: patch-system-but-direct-changes-in-diff .hgignore and 110 more"
<superm1> ScottK, at least that FTBFS from supported architectures maybe.
<ScottK> Sure.
 * ScottK heads off to bed.  Good night all.
<ebroder> Night
<ebroder> Hmm...how long until main stops taking uploads?
<StevenK> It's very very slushy right now. Critical bug fixes only
<wgrant> And probably then only for a couple more days.
<ebroder> Oh! I was getting my Gutsy EOL date and my Jaunty release date confused
<ebroder> I guess I'm not /quite/ so rushed to get a patch for bug 362691 together
<ubottu> Launchpad bug 362691 in xen-3.3 "XEN depends on Python 2.5" [Undecided,New] https://launchpad.net/bugs/362691
<wgrant> You should be...
<ebroder> I'm rushing, I just don't have to get it ACKed and uploaded /tonight/
<ebroder> And I don't think my change is likely to affect the one binary package in main; if anything it'll break one of the universe packages
<persia> even universe is slushy
<wgrant> Ah.
<ebroder> *nods* I won't be heartbroken if this has to get fixed as an SRU instead of fixing it now, but I want to try anyway
<slangasek> ebroder: how does that patch address the stated bug ("needs python 2.5 but is missing a dependency")?
<ebroder> The makefile just uses "python", so rebuilding will use python2.6
<slangasek> then the package will still be wrong
<slangasek> if it currently depends on python 2.5 but misses a dependency, your patch would appear to make it depend on python 2.6 without an explicit dependency
<ebroder> Good poitn
<ebroder> *point
<slangasek> the package probably needs some ${python:Depends} in the debian/control or something
<TheMuso> slangasek: linux-ports re-uploaded, sorted out control changes so they aren't in the diff. Just waiting for linux-source-2.6.28 from mainline to be available so I can upload linux-rt.
<ebroder> slangasek: I think you're right, although that still doesn't solve the fact taht we'll be upgrading it to 2.6 in the last week of the release cycle
<slangasek> TheMuso: saw, thanks
 * TheMuso looks forward to using git for linux-rt in karmic and beyond.
<slangasek> ebroder: indeed - though there's little risk of regression if the package is already broken, I think this is probably better suited to an SRU anyway
<ebroder> So..don't rush to get the fix in place now?
<slangasek> ebroder: right
<slangasek> TheMuso: linux/i386 is in ACCEPTED right now, so you should be able to grab for linux-rt in a couple of hours
<TheMuso> slangasek: Got a better idea. I'll build arch indep packages locally, and use that as a base. By the time I upload and its accepted thigns will be fine at the DC end of things.
<TheMuso> Doing it that way will mean I have to wait much less time.
<TheMuso> just need linux-source-2.6.28 to be present for the buildds.
<slangasek> ah, well, if you're in that much of a hurry you could also just download the .deb from launchpad
<TheMuso> slangasek: I would if I hadn't gone over my quota for this month and thus connectino has been slowed somewhat. :S
<TheMuso> connection
<slangasek> heh
<jdong> heh. How does e-mail subject / header unicode work / not work?
<jdong> i.e. https://lists.ubuntu.com/archives/jaunty-changes/2009-April/009498.html
<jdong> the transliteration seems to have exploded
<ebroder> Haha
 * slangasek blinks
<superm1> okay everyone hide, when slangasek opens his eyes, he'll be really confused!
<jdong> it was reproduced fine in the body of the e-mail
<slangasek> everyone's gone!  I guess I can reject this mesa upload then, no one needs it
<slangasek> jdong: yes, clearly a case of overly-enthusiastic mail software
<superm1> haha
<jdong> slangasek: interestingly. Definitely the upload sticks out in the jaunty-changes list :)
<TheMuso> slangasek: uploading linux-rt. Strictly a rebase, so since the package only contains metadata, the only changes are changeloge entries, and an update to debian/control to explicitly depend on the latest linux-source-2.6.28 package. SRUs will not be rebased, but have the SRU patches added to the package proper.
<slangasek> TheMuso: ok
<StevenK> slangasek: livecd-rootfs will get pushed through today?
<slangasek> yes
<liw> slangasek, kiitos
<dholbach> good morning
<slangasek> liw: n/p
<pitti> Good morning
<pitti> kees: known bug, and fix waiting in unapproved queue
<slangasek> StevenK: ping
<slangasek> StevenK: the latest livecd-rootfs upload includes a full load of .bzr cruft; could you clean that up and re-upload?
<StevenK> slangasek: Oh, damn it. Sorry about that.
<dholbach> bzr bd for the win!
<slangasek> except when it fails :)
<StevenK> slangasek: Fixed and re-uploaded.
<slangasek> StevenK: thanks
<mvo> doko: what is your opinion on https://bugs.edge.launchpad.net/ubuntu/+source/python2.6/+bug/353251/comments/13 ?
<ubottu> Ubuntu bug 353251 in python3.0 "rtinstall scripts (to provide new 2.6 symlinks) are not run on intrepid->jaunty upgrade" [High,Fix released]
<dholbach> slangasek: fails?
<pitti> StevenK: DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I.bzr -I.svn -I.shelf"
<pitti> StevenK: FTW :)
<slangasek> dholbach: sure, bzr bd has been broken at various points this cycle
<slangasek> pitti: isn't "-i" alone supposed to be sufficient?
<pitti> slangasek: -i only works on the diff.gz according to documentation
<pitti> -I filters from built tar.gz
<pitti> (native packages)
<slangasek> -i -I, then? :)
<pitti> but maybe they fixed that
<liw> very few things are great when they fail
<liw> but awesome is awesome even in failure, I'm sure
<StevenK> pitti: Yeah, I used -i, not -I :-(
<pitti> slangasek: nice, indeed
<pitti> wasn't there yet years ago when I added that
 * pitti simplifies his ~/.devscripts
<dholbach> what's wrong about "bzr bd --native -- -S"? :)
<slangasek> nothing when it's working
<dholbach> ok
<dholbach> you guys make it sound like it's always broken :)
<dholbach> I use it all the time and I'm happy
<Amaranth> whee, 15 second boot and 2-5 second warm cache login time
 * Amaranth just did a fresh install
<pitti> Keybuk: hm, bootchart-java pulls in libcommons-compress-java and libcommons-cli-java; before the package split they weren't in main; why did it grow those deps?
<pitti> Riddell: do you want kgrubeditor back in main (see concerns in bug 262309) or unseed it?
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/262309/+text)
<slangasek> pitti: kgrubeditor seems to have so far failed its MIR?
<pitti> slangasek: it's been in main before, but only preliminarily promoted
<slangasek> ah
<Keybuk> pitti: they were probably just missing Depends before?
<Keybuk> some weird java build system change madness maybe?
<Keybuk> I just looked at the intrepid deb, and they're inside the .jar there
<pitti> Keybuk: ah, so bundled vs. split out
<Keybuk> where the whole change to java-* seems to have made them depends instead
<madduck> is it deliberate that i cannot install openssh-server with 'add/remove software' (but it works with synaptic) on 9.04rc?
<BUGabundo> madduck: was it ever there?
<madduck> no idea
<madduck> but it's *openssh-server*
<madduck> i would think that that's part of the core system, no?
<mvo> madduck: hello! add/remove is designed to show stuff for end-users (basicly what comes with a desktop file). we bend the rules a bit for some stuff like codecs. its a really good question if openssh-server should be in or not
<madduck> fair enough
<madduck> i was assuming something like that
<madduck> and it's a worthwhile consideration
<madduck> it just startled me a bit...
<madduck> btw, i liked the 9.04rc install, folks.
<madduck> and so far, it's all working
 * madduck replaced the old etch kde install of his ex-girlfriend with 9.04rc
<StevenK> slangasek: Oh, are dailies enabled again, or are they manual only from here on out?
<slangasek> StevenK: I may end up enabling dailies to save myself the effort of rolling things by hand over the weekend, but perhaps not until the installer is where we want it
<liw> madduck, hi
<madduck> hello. funny, this channel is like #d-d five years ago. :)
<slangasek> /invite Overfiend
<mvo> haha - I was just thinking that
<StevenK> Bwaha
 * mvo remembers some words starting with f* that he learned in this channel at this time
<pitti> lool: hm, /usr/lib/sendmail? Shouldn't that be /usr/bin/sendmail?
<slangasek> heh
<StevenK> mvo: Like the fire brigade?
<mvo> it was suprising how rich the english language can be
<mvo> StevenK: exactly :P
<BUGabundo> mvo: so where is the list of apps to show in GAI at?
<mvo> BUGabundo: ls /usr/share/app-install/desktop/*.desktop
<madduck> thanks folks, i'll be back if there are problems with 9.04rc
<cjwatson> lifeless: absolutely noise. That was the very first thing I objected to in my blog post about bug triage (http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2009-02-27-bug-triage-rants.html) and I've been complaining about it for years, on and off
<cjwatson> jdong: can you file a bug on Soyuz about that bogus From line if you haven't already? (It used to mangle the body of the mail as well; at least that's been fixed ...)
<liw> cjwatson, lifeless: perhaps it'd be helpful to have a tag for the handful of bug reports that have an automated test case, at least
<cjwatson> TBH I think that's a red herring; bug triagers should have the skill to read and understand a bug before commenting on it
<liw> fair enough
<liw> (I updated the description)
<liw> (otoh, automated test cases for bugs are a good thing anyway, more bug submitters should provide them :)
<bryce_> cjwatson: optimist.
<cjwatson> bryce_: beats editing every bug to say in different ways "hey guys, this is a real bug, please leave it alone" (which IME a certain set of bug triagers ignore anyway, so you end up in an arms race)
<liw> dammit, can we stop improving boot time: I didn't even notice my desktop booted
<slangasek> radix: hmm, was this landscape-client upload meant to go to jaunty release, or was it supposed to go to a PPA?
<liw> (I was trying to halt it, and wondered why the heck it was taking so long -- it had rebooted instead)
 * slangasek laughs
<slangasek> zul: looks like you sponsored this landscape-client upload to jaunty-release?  can you clarify what the intent is here?
<BUGabundo> liw: lucky ! mine still take 35 secs to gdm, and a lot more into it until I can use it
<BUGabundo> liw: http://fileland.bugabundo.net/fotos/Linux/bootchart
<Riddell> pitti: yes I'd like kgrubeditor in main
<ogra> slangasek, i know i'm a bit hasty, but i'd like to report that the NSLU2 RC install finished successfully
<slangasek> hasty? :)
<ogra> :)
<slangasek> which image is NSLU2, again?
<ogra> ixp4xx
<pitti> Riddell: that means people can wedge their grub configuration with it and get ucf questions, you are aware of that?
<ogra> netinstall
<Riddell> pitti: ucf?
<pitti> Riddell: /boot/grub/menu.lst is managed with ucf nowadays (or somethign that looks very much like it), AFAIK
<slangasek> ogra: thanks, published to the netboot rc page
<slangasek> pitti: it is ucf, yes
<ogra> thanks
<Riddell> pitti: they can also fix their grub configuration when something goes wrong or needs changed
<cjwatson> Riddell: does it round-trip cleanly - that is, if you load a grub configuration in it and then save it without making any changes, does it produce an identical file? likewise if you make just one change, it should make only that change and not also make trivial changes elsewhere
<Riddell> cjwatson: no, doesn't seem to
<cjwatson> that's going to result in a good few bugs filed on grub then :(
<pitti> that was the primary concern why the MIR hasn't been approved yet
<ogra> the first is easily solved by greying out the save button until a change has been made though
<liw> yay, upstream fixed the problem with the kernel not recognizing my disks (LP: #257790)
<Riddell> ok, I'll remove it from the seeds
<liw> how difficult is it to create one's own version of the ISOs, with a custom kernel?
<BUGabundo> liw: not hard! just takes a bit
<hyperair> more difficult than just installing the kernel manually
<BUGabundo> there's a wiki with the steps
<BUGabundo> hyperair: that's true
<hyperair> =p
<BUGabundo> we need a tool to make costum images!
<BUGabundo> like suse studio
<hyperair> for one, the kernels will get superseded
<liw> hyperair, installing the kernel manually ... to a system that hasn't been installed?
<hyperair> liw: install, then install the kernel on top of it
<hyperair> liw: if your kernel won't boot, then chroot comes to mind
<liw> hyperair, no can install when installer does not see disks
<hyperair> oh wait O_o
<hyperair> ah
<hyperair> that sounds painful X_X
<hyperair> guess the ISO's the only way for you
<BUGabundo> netboot maybe?
<hyperair> actually...
<hyperair> no
<hyperair> if you use a USB startup disk..
<hyperair> it would be pretty easy
<hyperair> just crack open the squashfs..
<hyperair> then install the kernel
<hyperair> and remove the old kernel
<hyperair> i think
<cjwatson> parts of the kernel are also, rather necessarily, outside the squashfs
<BUGabundo> hyperair: that's the manual way
<BUGabundo> and still requires a bit of work
<hyperair> ah crap
<hyperair> lol
<BUGabundo> let me find the wiki page
<hyperair> the ISO structure is something i still know next to nothing about
<BUGabundo> and now I can't find the wiki
<hyperair> hehe
<hyperair> it always eludes you when you need it doesn't it? =p
<BUGabundo> LiveCDCustomization
<BUGabundo> luckly I save all wikis to disk....
<BUGabundo> makes it easy to have on hand when google fails
<BUGabundo> https://help.ubuntu.com/community/LiveCD?highlight=((LiveCDCustomization))
<BUGabundo> there you go https://help.ubuntu.com/community/LiveCDCustomization
<liw> BUGabundo, thanks, I'll give that a try
<BUGabundo> all the trouble to extract squashfs and redo the FS is too much
<BUGabundo> aint anyone working on a tool to do that for us?
<lool> pitti: You mean /sbin
<lool> pitti: /lastlog sendmail on #ubuntu-release :)
<pitti> lool: ah, saw it; thanks
<hyperair> BUGabundo: is there a guide for customizing what gets installed?
<liw> note to self: copying initrd to vmzlinuz is not conducive to getting a working installer
<BUGabundo> hyperair: humm start with minimal and base metapackages?
<hyperair> BUGabundo: ?
<hyperair> BUGabundo: how does a desktop cd get generated generally?
<hyperair> BUGabundo: i mean without cracking it open blah blah
<Hobbsee> hyperair: seeds, and germinate
<BUGabundo> don't know! ask the images admins
<hyperair> hehehe
<BUGabundo> there you go
<Hobbsee> hrm, which doesn't seem to be in this guide
<hyperair> yeah
<hyperair> they don't
<BUGabundo> there's a wiki on how to do your own germinate
<hyperair> hmm there is?
<BUGabundo> I read part of it once
<hyperair> considering that germinate does ring a bell, i think i might have as well
<hyperair> on an unrelated note, i'm curious as to how many people agree with the new update-notifier behaviour
<cjwatson> hyperair: livecd-rootfs does the work of generating the live filesystem
<BUGabundo> hyperair: -1
<hyperair> cjwatson: ah cool, i'll look into that too =p
<hyperair> BUGabundo: hahah. personally, i view the new behaviour as a security hole.
<BUGabundo> we will ppl just closing and not updating
<hyperair> not just that
<hyperair> i'm talking about using the new behaviour to trick people into giving the password to gksudo
<BUGabundo> I'm tired of this. I was among those that discussed this in +1, and opened the bug
<hyperair> heh yeah
<BUGabundo> Mark as closed it *twice* with won't fix
<BUGabundo> so either we discuss for kk, or forget it
<hyperair> they seem pretty stubborn regarding this
<hyperair> so.
<Hobbsee> Please take this discussion elsewhere, guys.
<BUGabundo> I won't even comment anymore on the bug
<hyperair> right
<pitti> Riddell: ok, please tell me when you uploaded k-meta, I'll wave it through the queue
<Hobbsee> like you say, the bug has been marked twice as won'tfix, and there's no point disturbing this channel withit
<pitti> directhex: at the expense of bringing mono out of sync again, would you agree to droping the Recommends: libgluezilla from libmono-webbrowser0.5-cil? or should it get a MIR?
<directhex> hm, what do we need libmono-webbrowser0.5-cil for?
<pitti> directhex: mono-tools build-dep and reverse dep of libmono-winforms2.0-cil
<pitti> OTOH gluezilla looks harmless enough
<pitti> and the recommends: seems to be justified, WDYT?
<directhex> it's harmless enough, yes
<directhex> oh. oh ARSES
 * directhex files a big nasty bug against ubuntu-dev-tools
<pitti> directhex: so, MIR then?
<ogra> can someone let usb-imagewriter out of binary NEW ?
<liw> hm, I did something wrong. my ISO doesn't boot (at least not under kvm)
<liw> or, the live system doesn't boot
<directhex> pitti, yeah. golly gee, i love MIR paperwork \o/
<taavikko>  any change for "ubuntu-bug -p pkg" tool to have it uploading it's contents to an existing bug?
<pitti> directhex: we just need to sort out http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt RSN
<taavikko> as of now, it seems to be missing that functionality?
<pitti> taavikko: to do that, use apport-collect
<taavikko> pitti: thanks :)
<directhex> pitti, Bug #362845 is my excuse for why this wasn't spotted sooner
<ubottu> Launchpad bug 362845 in ubuntu-dev-tools "reverse-build-depends: Ignores Build-Depends-Indep" [Undecided,New] https://launchpad.net/bugs/362845
<pitti> directhex: hah
<pitti> ogra: done
<ogra> Pici, thanks :)
<ogra> err pitti
<pitti> Keybuk: uh, bootchart-java uses gcj, not default-jdk
<Keybuk> does it?
<Keybuk> see, shows how much I know ;P
<Keybuk> Java confuses me
<pitti> +export JAVA_HOME=/usr/lib/jvm/java-gcj
<pitti> the build deps are correct, though
<pitti> Keybuk: not just you :)
<Keybuk> it doesn't help that our Java policy doesn't actually appear to be written down anywhere
<Keybuk> like the wiki
<ogra> hmm, works for me without exporting JAVA_HOME
<ogra> even on armel
<directhex> ...........................
<directhex> i need to start using Tomboy.
<pitti> Keybuk: I collect stuff in bug 362849
<ubottu> Launchpad bug 362849 in bootchart-java "promote to main" [Undecided,Incomplete] https://launchpad.net/bugs/362849
<directhex> https://wiki.ubuntu.com/MainInclusionReportgluezilla
<directhex> check the date/time it was written
<ogra> oh, i thought the decision was to demote bootchart to universe instead
<Laney> directhex: that bug looks fixed already
<Laney> are you using the latest u-d-t?
<pitti> directhex: oh, nice! ah, it's not linked to a MIR bug, thus it escaped our attention
<pitti> directhex: thanks, I'll deal with it
<directhex> Laney, i think so. this machine is on jaunty
<Keybuk> pitti: I thought we decided to just demote bootchart to universe anyway?
<ogra> yeah
<Laney> directhex: well it is fixced for me
<pitti> Keybuk: WFM; I don't know where it should  live
<ogra> Keybuk, i bet someone forgot to close the bug :)
<Keybuk> slangasek: ?
<pitti> Keybuk: (having it in universe makes sense to me, though)
<pitti> Keybuk: slangasek is sleeping
<directhex> pitti, perhaps i never got around to filing the bug, and it sorta slipped my mind
<pitti> no reverse dependencies, so I guess it's just seeded in supported
<Keybuk> he'll be up later ;)
<ogra> so your ping was really informative :P
<directhex> pitti, of course, i would only have written an MIR on request, so you can feel better about having spotted the issue back in November ;)
<cjwatson> installer and supported-development
<pitti> cjwatson: bootchart is in the installer seed?
<cjwatson> it is, but it's no longer used
<cjwatson> feel free to rip it out
<pitti> okay
<ogra> we had a udeb for it
<ogra> ages ago
<Riddell> pitti: kgrubeditor isn't in kubuntu-meta
<pitti>  o kgrubeditor: kgrubeditor
<pitti>    [Reverse-Depends: Kubuntu.Jaunty desktop seed]
<pitti> hmm
<pitti> Riddell: oh, of course
<pitti> Riddell: -meta ignores apckages in universe, so it's just the seed change
<pitti> so much the better
<pitti> cjwatson: ok, committed; thanks
<pitti> Riddell: ok, thanks
<pitti> Riddell: what's the rationale for the kde-l10n-* uploads? there's no bug # associated with them
<lifeless> cjwatson: yes me too; was seeking confirmation we really are on the same page; we are :)
<lifeless> liw: the problem isn't metadata, its makework/quantity not quality
<zul> slangasek: it was suppose to be going to a ppa
<Riddell> pitti: the futile hope of having complete translations.  bug 362229
<ubottu> Launchpad bug 362229 in language-pack-kde-fr "Kubuntu language packs miss .desktop translations" [Undecided,Fix committed] https://launchpad.net/bugs/362229
<pitti> Riddell: ah, thanks
<kwwii> pitti, slangasek: I've made the png a jpg and now it is almost 1MB, the package also includes a fix for another bug
<directhex> kwwii, is 1mb better or worse?
<pitti> kwwii: how come that it grew so much? it's currently an PNG as well
<pitti> directhex: current size is 1.6 MB
<directhex> pitti, how bad's the crunch for space this release?
<pitti> directhex: CDs are nicely at the limit, so any package size increases are a no-go at this point
<kwwii> pitti: I have no idea, the problem was the transparent pixels and the fix came with a file which is much larger
<kwwii> pitti: I tried to reduce it but couldn't get much more than a couple hundred KBs
<kwwii> directhex: -1MB is always good just before release :)
<pitti> (-0.6 MB, but that's still good, of course)
<kwwii> pitti: hehe, right :)
<kwwii> how many command line tools is that?
<liw> the desktop ISO can't set up a RAID to install to, can it? but the alternate can?
<hyperair> that's right.
<pitti> liw: yes, d-i partitioner allows you to set up lvm, raid, crypto, etc.
<directhex> liw, mdadm softraid? yes
<liw> then I need to switch my attempts at creating a custom ISO to that, thanks
<directhex> pitti, and these rumblings over openjdk in a future release. how is freeing up the ~100 meg required even possible?
<pitti> directhex: sure, we could throw out OO.o
<pitti> (just kidding)
<ion_> Replace it with LyX and Gnumeric! :-P
<directhex> pitti, great! now who was it who wanted OpenJDK? oh, right, calc...
<pitti> directhex: frankly, I have no idea, and my personal opinion is that we shouldn't sacrifice 1/6 of the CD for a single programming language
<pitti> but I think that remains to be discussed
<pitti> once we have the space, we can argue about how to use it
<directhex> pitti, i could save you >4 meg today with some teeny bits of package substitution!
<pitti> directhex: sounds great for karmic!
<pitti> we can also free some more space by ripping out GNOME help translations and moving them to language packs
<pitti> that shoudl be in the order of 50 MBs
<pitti> but we need some soyuz support for that (bug filed)
<directhex> oh, yes please. tomboy is 95% translated images
<directhex> in docs
<directhex> jms@osc-bigmac:~$ du -hs /usr/lib/tomboy/
<directhex> 520K	/usr/lib/tomboy/
<directhex> jms@osc-bigmac:~$ du -hs /usr/share/gnome/help/tomboy/
<directhex> 4.4M	/usr/share/gnome/help/tomboy/
<liw> hm, this is weird: in gnome-terminal, if I open a new tab, it tries to use the same working directory as the previous tab; if I am running man, the new tabs open in /usr/share/man
<directhex> liw, oh, that's right! well spotted
<liw> #362880
<cjwatson> mvo: how are upgrade tests looking, from your POV?
<mvo> cjwatson: pretty good now, there were bug #357884 and bug #361194 that were pretty anoying but those are fixed now
<ubottu> Launchpad bug 357884 in python-central ""pycentral rtinstall" script does not add symlinks for python2.6 on upgrade" [High,Fix released] https://launchpad.net/bugs/357884
<ubottu> Launchpad bug 361194 in update-manager "Intrepid -> Jaunty RC upgrade test fails" [High,Fix released] https://launchpad.net/bugs/361194
<mvo> cjwatson: but I will do a re-run with the current archive today (now that some new stuff entered)
<vlada_> hi guys
<vlada_> I want to install kde3 libs in order to build older version of rosegarden
<vlada_> is there any howto?
<ScottK> vlada_: sudo apt-get install kdelibs4-dev
<vlada_> ScottK: 4?
<vlada_> i NEED 3
<vlada_> stivky caps lock, sorry
<Riddell> vlada_: that is KDE 3
<vlada_> just a strange naming scheme, I guess. Thanks
<vlada_> Riddell: any idea why's that?
<vlada_> except to confuse users...
<wgrant> It's probably the ABI version.
<Riddell> as wgrant says
<vlada_> I still find it confusing. But hay, nobody's perfect :)
<]NeRoNexX[> hi
<]NeRoNexX[> :)
<liw> I finally have a working custom alternate ISO, which passed the integrity check; trying to install under kvm results in a complaint that PPPoE doesn't work
<cjwatson> liw: can I see the syslog please?
<cjwatson> you're not the first person to report this with customised images, and I'd like to track it down
<liw> cjwatson, un moment
<liw> (need to convert image to raw, mount it with the help of kpartx before I can extract)
<liw> in the meanwhile, the vanilla alternate ISO (from which my custom one is made) does work
<cjwatson> uhh - I would expect you to need to extract syslog from the running installer
<cjwatson> i.e. scp it out or similar
<liw> cjwatson, without network?
<elmo> cjwatson: I suspect liw means the KVM image?
<liw> oh, but it doesn't write the syslog to disk of course
<liw> yeah, kvm image
<cjwatson> liw: you should be able to configure it manually
<persia> liw, Pass kvm another disk image (not using kpartx), and copy it into there.
<cjwatson> you have dhclient
<cjwatson> elmo: sure, but as liw says the syslog is only in RAM
 * liw goes back to reproduce
<cjwatson> liw: if you could add DEBCONF_DEBUG=developer to the boot arguments while you're at it, that would be helpful
<pitti> kirkland: FYI, you can now use report.pid in apport hooks instead of grepping it out of ProcStatus
<liw> hm, scp is not installed
<liw> cjwatson, I can do that, too, for the next run
<cjwatson> scp: 'anna-install openssh-client-udeb'
<kirkland> pitti: i ended up dropping that all together
<kirkland> pitti: and just using:     report['KvmCmdLine'] = command_output(['ps', '-C', 'kvm', '-F'])
<kirkland> which might grab more than one kvm command line
<pitti> kirkland: I know, just FYI
 * liw curses Linus for giving in and not keeping Finnish as the default kernel keymap
<kirkland> pitti: what's the usage syntax?  report['Pid'] ?
<pitti> kirkland: report.pid
<pitti> (integer)
<kirkland> pitti: oh, strange
<kirkland> pitti: why is it not a key/value pair?
<pitti> it's not a field we want to put into bug reports
<kirkland> pitti: okay
<pitti> at that point it would just clutter
<kirkland> gotcha
<liw> cjwatson, do you care about the one without DEBCONF_DEBUG=developer?
<kirkland> pitti: how do i get rid of stock fields that I consider clutter for my package?
<seb128> evand1: is usb-creator displaying a "Unable to determine the partition number." error a known issue?
<pitti> kirkland: you can del report['Field']
<pitti> kirkland: but please test it
<cjwatson> liw: yes
<pitti> kirkland: and just for safety, wrap it in a try: except KeyError: pass
<cjwatson> liw: I may turn out not to need the debconf debugging; we'll see
<liw> cjwatson, sent; fwiw, running dhclient brings up networking without a problem
<kirkland> pitti: thanks
<seb128> evand1: I've filed bug #362917 let me know if you need details
<ubottu> Launchpad bug 362917 in usb-creator "Unable to determine the partition number." [Undecided,New] https://launchpad.net/bugs/362917
<liw> cjwatson, shall I save the ISO I have, to make further debugging for you? or would you like a copy of it?
<cjwatson> liw: can you save it just for the moment? I'll look at your log today
<cjwatson> (once I get it ...)
<liw> cjwatson, I can save it for a long while, if you need me to :)
<liw> mv sembfix.iso custom-jaunty-rc-iso-that-cannot-get-networking-up-automatically-saved-for-cjwatson.iso # there
<liw> now, the next logical step for me would be to try my custom ISO on real hardware, hopefully without breaking anything... (me, touch hardware and not break anything? bwahaha)
<cjwatson> superm1: bug 352572: which, specifically, are the patent-encumbered files in the mythtv source package, and why is there no mention of the encumbrance in debian/copyright?
<ubottu> Launchpad bug 352572 in mythtv-status "Please move libmyth-perl and libmyth-python to universe" [Undecided,Invalid] https://launchpad.net/bugs/352572
<cjwatson> liw: actually, could you dump it on rookery or something? that would be no slower for you and would save me download times, since I just need to look at a couple of files in it
<superm1> cjwatson, the bits that are included from ffmpeg.  i suspect that the original author of the package, on debian-multimedia didn't mention them in detail
<liw> cjwatson, sure
<cjwatson> superm1: ah. please document this for a future upload?
<superm1> cjwatson, sure will do
<liw> hm, usb-creator no longer offers to format a stick
<pitti> MacSlow: did you see my question in bug 331369?
<ubottu> Launchpad bug 331369 in notify-osd "regression vs. notification-daemon: positioning when multiple screens are available" [Medium,Fix committed] https://launchpad.net/bugs/331369
<MacSlow> pitti, rechecking
<MacSlow> pitti, oh ja klar ... sorry :)
<MacSlow> pitti, but you should just grab rev 293 (or tag 0.9.12)
<MacSlow> pitti, that has only that one-line patch from david
<pitti> MacSlow: 0.9.12 has other unrelated changes
<MacSlow> pitti, well commit 293 is what you're after then
<pitti> MacSlow: ok, thanks; can you please say so in the bug report, so that I won't forget?
<MacSlow> pitti, done
<pitti> mvo: could you upload the update-manager fix for bug 351394 ?
<ubottu> Launchpad bug 351394 in xserver-xorg-video-nv "nvidia -177 needs to be transitioned to -180 on upgrade" [Undecided,New] https://launchpad.net/bugs/351394
<liw> bah, it seems I failed to put in my custom kernel onto the custom cd
<mvo> pitti: the fix is to comment out the nvidia driver to let xorg work its magic to detetct what driver to use. in this case it would not help (because -nv is buggy). I'm a bit heasitant to upload it to jaunty
<pitti> mvo: oh, ok; I thought it was related to restricted temporarily not being available
<mvo> pitti: i.e. it will not fix this particular problem but may introduce regressions (also the risk is relatively low)
<mvo> pitti: sorry, the comment in the bug is a bit short, I will make it better
<pitti> mvo: so -180 doesn't support that model any more? shouldn't it transition to -173 then?
<pitti> tseliot: ^
<pitti> this bug is pretty confusing
<pitti> -nv shouldn't have a role here at all
<superm1> cjwatson, in looking for a good set of text to describe the ffmpeg bits, i was hoping debian/copyright in ffmpeg-debian would have it, but it's missing the same type of information
<mvo> pitti: the user has -177 installed but restricted is disabled for some reason
<pitti> an nvidia -> nv switch is a regression
<pitti> mvo: ah, he disabled restricted himself?
<mvo> pitti: probably, mmight be a mistake on his part of course
<pitti> ok, that's relieving, though
<mvo> pitti: its not clear to me what u-m should do, probably warn
<tseliot> pitti: yep, nvidia->nv doesn't work in his case
<mvo> and the additional bug is that nv claims to support the card but it does not
<tseliot> right
<pitti> ok, I updated the bug
<liw> oh, silly me: I only put the new kernel .deb on the cd, I didn't modify the installer to actually use it
 * liw decides to give in to the angry wolf in his stomach and go out for groceries
<ogra> oh, that was the noise all day ?
<liw> cjwatson, the ISO is now in my home directory on rookery
<liw> cjwatson, I'll delete it after you tell me you're done with it, to save disk space
<jcastro> Keybuk: fyi: http://www.harald-hoyer.de/linux/boot-time-distro-comparison
<Keybuk> jcastro: I just posted that to you on #distro
<jcastro> always a day late and a dollar short
 * ogra sends jcastro a dollar
<Keybuk> jcastro: harald is on the cabal channel, so I knew waayyyy ahead of you <g>
<Keybuk> I even told him to use the german mirror to get the iso since the usual one was slow for him :p
<jcastro> Keybuk: I am just the catch-all for things just in case.
<jcastro> Keybuk: I am down to 7 seconds on my X200 with the intel SSD
<jcastro> 7.00
<Keybuk> see, I don't get these fancy Intel SSDs :'(
<robbiew> heh
<pitti> mdz: for your freezes, https://edge.launchpad.net/~bryceharrington/+archive/purple is worth testing (mesa with 965 fix)
<mdz> pitti: bryce already said on the bug that it didn't fix things for him, so I wasn't going to bother
<Mirv> ^ helped me on a GMA X3100
<pitti> ah, ok
<Mirv> and helped tjaalton as well
<pitti> mdz: greedy, or Option "EXAOptimizeMigration" "off" don't help either?
<siretart`> wow
<Mirv> I'd suggest mdz to try it since it helped us already. it'd be worthwhile to know if it fixes problems for many/most i965 users.
<siretart`> linux 2.6.30-rc2 + libdrm 2.4.9 + intel 2.7.0 == win
<cjwatson> mvo: I'm trying to puzzle out whether the python2.4 part of bug 353251 is release-critical. Can it be fixed in an SRU, since the default python won't be 2.4 and will therefore work?
<ubottu> Launchpad bug 353251 in python3.0 "rtinstall scripts (to provide new 2.6 symlinks) are not run on intrepid->jaunty upgrade" [High,Fix released] https://launchpad.net/bugs/353251
<siretart`> 3d performance wise
<mdz> pitti: I haven't tried it.  I had to turn off desktop effects in order to be able to work, and that was enough of a workaround
<pitti> siretart`: that's what I heard, too; not quite jauntyable though, I'm afraid
<pitti> mdz: ah, ok; that's one of the workarounds documented in the release notes
<pitti> to get people through the first few weeks until we have an SRU
<siretart`> pitti: yeah, indeed.
<Mirv> pitti: greedy/exaoptimizemigration seems to cause severe graphical problems on i965, so it's probably better for i945 series experiencing problems.
<mvo> cjwatson: I honestly don't know. I asked doko for input earlier if that is a design decision or a bug. and if its a bug if the bug is to byte compile for unsupported runtimes when a new python-foo package gets installed or if the bug is that no rtinstall script is run for unsupported runtimes
<mvo> cjwatson: its definitely confusing (and gave me some trouble when I tried to get python-distutils-extra to work with p2.4)
<mvo> cjwatson: but whatever the decision is, I think we can SRU it, we just need to force a rtinstall for lower version than the sru version (we did something similar for python2.6)
<cjwatson> doko: ^- can you comment?
<cody-somerville> Whats the accepted practise for versioning of uploads of snapshots from a git repository?
<directhex> cody-somerville, don't use the git hash in the version number. i saw someone do that once
<cody-somerville> lol
<doko> cjwatson: I'll have a look, but not today. weekend should be ok
<cjwatson> if it's SRUable, yes
<cjwatson> cody-somerville: I believe 1.0+git20090417-0ubuntu1 is fairly usual
<cjwatson> where 1.0 is the previous release. If you're thinking of it as "pre-release of 1.1" instead, then 1.1~git20090417-0ubuntu1
<pitti> mvo: could we tell compiz to not start by default on 965 for now, but still allow people to enable it in the GUI tool?
<cody-somerville> cjwatson, How do you know for sure how upstream will version the next release though?
<pitti> mvo: until we found a real solution for bug 359392?
<ubottu> Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Critical,Triaged] https://launchpad.net/bugs/359392
<cjwatson> cody-somerville: you may have contact with upstream that allows you to guess very accurately, or you may not
<pitti> bryce: also, would the right solution for ^ still be to revert some intel related patches from mesa 7.4?
<cjwatson> cody-somerville: I am not pretending to know what is appropriate in your situation
<cjwatson> cody-somerville: (for example, it's entirely plausible for some packages in Ubuntu that you *are* upstream :-P)
<cody-somerville> <g>
<mvo> pitti: ok
<pitti> mdz:
<mdz> mvo: "ok" meaning it's possible to disable it by default but still allow people to enable it in preferences?
<pitti> mdz: so with tjaalton and Mirv's positive experiences with the mesa PPA package, maybe it's worth a try after all?
<mdz> pitti: what would we do if we find a fix for the bug?  re-enable it?
<pitti> mdz: yes, of course
<pitti> I currently wonder where we could disable it by default
<pitti> one option would be to disable dri by default in -intel on 965
<pitti> then you could enable it in xorg.conf
<mvo> mdz: I need to look at the code and think about a not too intrusive way how this can be done, definitely a bit tricky because we currently have no such mechanism (other than the blacklist/whitelist)
<pitti> the other to blacklist it in compiz, but then you coudln't enable it at all
<mdz> mvo: I don't like the idea of adding more bugs for the sake of a workaround
<mdz> mvo: how about using the blacklist instead?
<pitti> and we have a pretty clear and proven way how to disable DRI for a chipset in -intel
<rickspencer3> is there a way to add post-install step that changes the setting?
<mvo> mdz: that definitely very easy. and still possilbe to override (but not with the gui)
<ericdc> I am attempting to remaster a CD (Ubuntu 8.04 LTS Server) to automate its installation. Then the installer complains about not finding the CD-ROM (USB CD-ROM Drive). I guess some USB module is not installed. So I press "continue". It proposes to load a driver from floppy, eventually it brings me back to the installation menu when it fails. I choose detect cdrom and it works fine but goodbye automation!
<mdz> pitti,mvo,rickspencer3: are any of you personally affected by this bug?
<rickspencer3> mdz: I am not
<tjaalton> pitti, mdz: by dropping the patch we are closer to upstream. it's now known to need more work to allow 4k*4k textures to work, so dropping it is safe and sane
<Lure> pitti: can you look at bug 358576 and comment how likely it is to get exiv2 0.18.1 in that late?
<Lure> pitti: or should somebody rather spend time on hunting individual fixes (may take time)
<ubottu> Launchpad bug 358576 in exiv2 "exiv2 version 0.18 crashes / also crashes digikam / fixed in 0.18.1" [Undecided,New] https://launchpad.net/bugs/358576
 * Lure is sorry if you got it multiple times - my IRC is bad currently
<pitti> mdz: no, I have a 945 and experience a different set of bugs (freezes and slowness)
<mdz> pitti: does disabling desktop effects fix your problems as well?
<pitti> mdz: yes, that fixes the hang after resuming
<Mirv> mdz: if you added the PPA, do you also find that the version number actually isn't shown for updating, since the real ubuntu2 version already come out as well? me and tjaalton build our mesa on our own, just removing the 103 patch similar to what's been done in the PPA packages.
<pitti> mdz: (bug 339091)
<ubottu> Launchpad bug 339091 in xserver-xorg-video-intel "[i945] X freezes a few minutes after resuming" [Medium,Confirmed] https://launchpad.net/bugs/339091
<mdz> Mirv: I have not tried the package in the PPA, I'm not in front of my i965 system right now
<tjaalton> trading the patch for dri/compiz is a no-brainer to me :)
<mdz> pitti: is there any known problem which is *not* fixed by disabling desktop effects?
<mdz> tjaalton: why did it go in in the first place?
<Mirv> mdz: ok, right. well, one has to force to use the version in the PPA. I'm upgrading from my own build now to those built by the build farm.
<pitti> mdz: bug 311895, but it seems that it's very rare (I'm hit by it)
<ubottu> Launchpad bug 311895 in xserver-xorg-video-intel "[i945] spontaneous black screen (major pipe-A underrun)" [Unknown,Confirmed] https://launchpad.net/bugs/311895
<pitti> mdz: it has a workaround as well, though
<Mirv> one point was that the patch doesn't give us anything really significant, so if it helps some it should be an easy decision to drop it
<tjaalton> mdz: because it was requested, and the regression was not known back then
<mdz> the changelog says it was to fix bug 146298
<ubottu> Launchpad bug 146298 in mesa "[i965] intel gm965 compiz dual head issues" [High,Fix released] https://launchpad.net/bugs/146298
<tjaalton> right, and it was a mistake to add it
<tjaalton> leaving it out is not a regression compared to intrepid
<mdz> if it was clear that it caused this regression, I would agree
<mdz> however, it's not at all clear to me that this patch is the root cause
<tjaalton> there are others too which have confirmed that
<mdz> we have multiple reports in the bug that people still see frequent freezes with the patch reverted
<mdz> including one from bryce: https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/xserver-xorg-video-intel/+bug/359392/comments/56
<ubottu> Ubuntu bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Critical,Triaged]
<tjaalton> in some of the bugs
<tjaalton> ok
<tjaalton> gotta go now ->
<mdz> there is no reproducer
<slangasek> kwwii: what tools did you use to make the updated .png for bug #345523, OOI?  I poked a bit with gimp, and haven't seen anywhere near that big of a size increase on the new .png
<ubottu> Launchpad bug 345523 in ubuntu-wallpapers "new ubuntu wallpaper: "simple ubuntu", has a transparent area on the left hand edge and down, exposing the background colour" [Low,In progress] https://launchpad.net/bugs/345523
<mvo> mdz: I can get hold of a 965 system if we need someone to reproduce
<kwwii> slangasek: I didn't make it, it was from the community
<kwwii> slangasek: and I tried to make it smaller but to no avail
<slangasek> kwwii: ah - strange, wonder how that got mangled
<slangasek> well, .jpg seems sensible anyway, but is the extension stored in the gconf settings?
<kwwii> slangasek: well, only if you have selected it as a background :)
<slangasek> kwwii: right, so, that'd be a regression for some people...
<kwwii> yeah, for anyone who has already installed and selected that pic
<kirkland> slangasek: dput -f kvm_84+dfsg-0ubuntu11_source.changes
<kirkland> slangasek: uploaded without the clock fix
<slangasek> kwwii: how about if I continue poking at the original image later today, and see if I can come up with a minimal fix?
<slangasek> kirkland: thanks
<kirkland> slangasek: we'll work on that one a bit more
<kwwii> slangasek: sounds good to me
<pitti> kwwii, slangasek: wouldn't it be enough to just drop the alpha channel from the png?
<kwwii> pitti: no, it will then have stripes on the left and bottom
<pitti> kwwii: uh, why?
<pitti> how's that different to any other background image which doesn't match the screen ratio?
<slangasek> pitti: because the area in question doesn't have any meaningful color data :)
<slangasek> so it'd render as *some* color
<slangasek> but not a pretty one
<kwwii> pitti: we zoom the pics, the pics themselves do not have a solid colored border
<pitti> hm, then could we just cut off the invalid areas?
<Aleksey_S> hi all
<kwwii> pitti: no, it would not have a decent aspect ratio
<slangasek> that, and you would be scaling by a percentage that's just off a sane ratio
<directhex> zoom & crop!
<Mirv> I wonder if tjaalton uses amd64, and if dropping the max texture patch only helps amd64 users. that might be one explanation, or else there are some pretty big differences between even different GMA X3100 implementations (bug 345119)
<ubottu> Launchpad bug 345119 in xserver-xorg-video-intel "[i965 X3100] X freezes/crashes randomly, only mouse pointer still functional" [Unknown,Confirmed] https://launchpad.net/bugs/345119
<BUGabundo> hi
<BUGabundo> just tripped on a memory leak on gnome search tool
<BUGabundo> how can I run it with valgrind ?
<Aleksey_S> Guys, are there someone experienced in audio?
<BUGabundo> Aleksey_S: talk to dtchen if is around!
<Aleksey_S> BUGabundo: : seems as he is away
<BUGabundo> yeah it's a bit soon
<BUGabundo> try after 18h GMT
<slangasek> kwwii, pitti: do you want to see whether http://people.ubuntu.com/~vorlon/simple-ubuntu.png appears correct to you?
<Keybuk> jcastro: SuSE is not coming out happy at all on these graphs :)
<BUGabundo> slangasek: isn't that a bit to bright in the center?
<pitti> slangasek: works fine for me
<slangasek> BUGabundo: art is not my department, I'm trying to fix a technical bug
<BUGabundo> ok
<pitti> slangasek: I see no noticeable difference except for the weird borders going away
<slangasek> pitti: this one is 16K smaller than the original :)
<slangasek> <shrug> :)
<pitti> slangasek: heh, 16KB worth of bugs :)
<calc> Keybuk: looks like f11 could beat us by the time it is released
<kwwii> slangasek: looks good to me
<pitti> kwwii: could you commit that to the branch, and I get it uploaded?
<kwwii> pitti: will do, just take a second
<pitti> slangasek: thanks, I'll shepherd it through
<slangasek> great, thanks
<Keybuk> calc: possibly, they release later
<Keybuk> though harald's numbers are a bit different to mine
<Keybuk> he installed Snap1 and updated, I installed Beta
<calc> what is the boot time goal for karmic? :)
<calc> 10s? :)
<Keybuk> there is no current goal
<ion_> â5 s would be nice.
<calc> ok
<Keybuk> I've suggested 10s, but the desktop team are pushing back very hard and saying they can't make login any faster
<kwwii> pitti: commited to ~ubuntu-art-pkg/ubuntu-wallpapers
<Mirv> calc: note also that harald only measures time to gdm. what is more meaningful is time from grub to usable desktop (timeable with auto-login)
<calc> Mirv: yea
<LaserJock> is the boot time defined as 'til gdm or with gdm starting a session?
<calc> Keybuk: what is your current time to desktop?
<Keybuk> calc: haven't measured since beta actually
<Mirv> LaserJock: for our purposes it's untild desktop, but often casual looks to "boot time" only mean to gdm
<Keybuk> but we're in the 25-30s range I suspect
<Keybuk> unless something has gone horribly wrong
<calc> Keybuk: ok
<Mirv> for me it's a tiny bit under a minute, but I'm using encrypted installation
<LaserJock> I noticed for jaunty that startup -> gdm got very fast, but gdm -> desktop got much slower
<MattJ> Hmm, seemed faster to me
<cjwatson> liw: oh, crap, I know what's happening here
<MattJ> But then without numbers that means nothing :)
<calc> at 25s thats barely within 30s for a cold boot for systems with relatively good bios, so it would be nice to make a bit quicker, but not too bad in any case
<cjwatson> liw: sort your Packages file lexicographically by package name and it'll work ...
<cjwatson> liw: unfortunately there's a bit of undefined behaviour in d-i that's currently resolved by "netcfg" < "ppp-udeb" :-(
<cjwatson> liw: (this is a bug, obviously! please file it)
<cody-somerville> cjwatson, Should ppp-udeb maybe be moved to universe?
<pitti> dendrobates: likewise-open-gui starts here, but I have no way to test it; do you know about positive test results with it?
<cjwatson> cody-somerville: I think the most practical fix might be to take it off the CD
<cjwatson> that way, it'll still be usable for netboot installations
<cjwatson> slangasek: ^- would you be OK with that at this point? the change would consist of moving ppp-udeb from platform.jaunty/installer to platform.jaunty/supported-installer
<cjwatson> or supported-installer-something
<Mirv> bug 327362 might be worth a release note, since it apparently affects sizeable part of Nordic countries' users at least, and possibly other ISP:s
<ubottu> Launchpad bug 327362 in avahi "[jaunty] regression with selected ISP:s: avahi-daemon disabled because there is a unicast .local domain" [Medium,Confirmed] https://launchpad.net/bugs/327362
<slangasek> cjwatson: having trouble finding the referent for this discussion in scrollback; what's the intent of this change?
<Mirv> of course, it's ISP:s fault, but it worked in hardy and intrepid nevertheless
<Mirv> though it can be argued whether avahi is a commonly used feature or not
<slangasek> Mirv: please file a bug on the ubuntu-release-notes project
<Mirv> slangasek: ok.
<slangasek> i.e., open a task on
<slangasek> using the same bug
<kees> Mirv: how did it work in Intrepid?  that's been a long-standing behavior for Avahi.
<radix> sladen: hi, I saw your message from last night, was the landscape-client confusion resolved?
<radix> erg
<radix> s/sladen/slangasek/
<Mirv> kees: I don't really know what's been changed, but probably the detection routine used.
<radix> slangasek: I think it was a mistaken upload; we definitely weren't trying to get another landscape-client released to jaunty
<jdong> Mirv: avahi is pretty important on my home network and within my virtualization system...
<jdong> cjwatson: soyuz bug on arabic transliteration filed.
<Mirv> so far looking at the bug report there is one big ISP culprit, TeliaSonera. I don't know if there are others.
<liw> cjwatson, what package should I file against? (ref. Package file needing to be sorted) -- debian-installer?
<kees> pitti: is the amd64 retracer hung?
<kees> pitti: (specifically 362197, 362256)
 * calc headed to meet with a Ubuntu Tunisia person who is visiting Houston, be back in a few hours.
 * calc hates driving in Houston traffic :\
<pitti> kees: ah, thanks; the reboot killed it
<pitti> kees: removed lock file, will run again soon
<slangasek> radix: was still waiting in the queue pending your response - I've rejected it now, thanks
<slangasek> huh, Ubuntu Tunisia
<calc> https://wiki.ubuntu.com/TunisianTeam/En
<calc> one of them is here in Houston for an international meeting of some sort
<calc> http://isweep.org/
<liw> cjwatson, #362989
<kees> pitti: great, thanks
<cjwatson> slangasek: the referent is bug 362989, which liw just filed
<ubottu> Launchpad bug 362989 in debian-installer "custom ISO breaks due to d-i undefined behavior, Packages file ordering affects issue" [Undecided,New] https://launchpad.net/bugs/362989
<cjwatson> slangasek: both netcfg and ppp-udeb provide configured-network, so which one gets used is essentially random (there's nothing much else to resolve it, in this case); ppp-udeb isn't something I've ever seen used in Ubuntu
<cjwatson> I wouldn't like to rule out that some people are trying to use it in preseeded cases, so I don't want to drop it out of main at this point
<liw> are there still ISPs that require PPPoE for ADSL or cable modems?
<ogra> in germany thats common standard
<ogra> for dsl
<liw> ogra, does ppp-udeb enable use of PPPoE during install?
<ogra> not cable though
<ogra> ugh, no idea, i never used pppoe during install
<ogra> my router is installed from CD and then i simply ran pppoeconf post install
<liw> cjwatson, can I delete the ISO on rookery?
<cjwatson> liw: yes, fefel free
<cjwatson> feel
<cjwatson> liw: regardless of whether it enables it, it's never received any proper testing in Ubuntu, and I can see at least one flaw in it by eye
<ScottK> liw: There's one fiber provider (Verizon FIOS for those who care) in the US that uses PPPoe on their older installs.
<ogra> can someone let the recent usb-imagewriter upload into universe (sitting in unapproved, StevenK gave his ok as mobile RM for universe but is likely asleeep)
<slangasek> well, the ppp-udeb package does include the pppoe module; but if it's not known to be usable, on balance it seems ok to me to drop the package out to supported
<slangasek> cjwatson: ^^ so yeah, go ahead with that seed change
 * slangasek goes back to digesting the very large morsel that is the ubiquity debdiff
<cjwatson> slangasek: I don't think it's even normally installed, FWIW
 * slangasek nods
<liw> cjwatson, do you have instructions handy for replacing the kernel in the alternate image?
<liw> cjwatson, it can't be simple enough to just replace install/initrd.gz and vmlinuz, can it?
<cjwatson> liw: not beyond what's on InstallCDCustomization. Replacing those files (indeed, probably just vmlinuz) is enough as long as the module ABI hasn't changed
<cjwatson> liw: but you'll also need to arrange for the correct kernel to be installed on the target system somehow
<liw> cjwatson, that could be done manually via a chroot from the installer, surely?
<ScottK> ogra: Accepted.
<cjwatson> liw: yes
<ogra> ScottK, gracias :)
<ScottK> No problem.
<liw> cjwatson, excellent, thanks; I'll give it a try later, then
<kirkland> slangasek: with respect to https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/361754 ...
<ubottu> Ubuntu bug 361754 in kvm "guest needs to boot with clock=acpi_pm" [High,In progress]
<kirkland> slangasek: <soren> kirkland: It's hard to say that we shouldn't worry about regressions.. What I /can/ say, though, is that the other clock sources are very well tested.
<kirkland> slangasek: perhaps not entirely the answer you're looking for
<kirkland> slangasek: personally, i'm okay with vetting that fix through the -propsed and -updates channel
<kirkland> slangasek: strangely, dholbach is the only person I know of that has hit that bug
<kirkland> slangasek: and we weren't able to isolate "why"
<azimut> xerakko
<ebroder> This is going to sound more...frustrated than I actually am, but when the release team or SRU team ACKs an upload for someone who doesn't have upload privileges, why don't they just upload it themselves? Why does the contributor have to go hunting for a sponsor after that?
<ebroder> Is it that the release/SRU ACK is just on a conceptual level, and not an ACK on the specific implementation?
<cody-somerville> ebroder, correct
<ebroder> Ok. I guess that makes sense
<jdong> ebroder: generally when  I ACK and there is a debdiff attached and the sponsors have been subscribed, I will just sponsor it in.
<jdong> it isn't standard procedure though, but perhaps it should be
<ebroder> jdong: Yes, you've been particularly good to me in that regard :)
<jdong> otherwise sponsorship latency is a bit annoying
<cjwatson> ebroder: the other reason is that the release/SRU teams are small and tend to be bottlenecks as it is, and need to be able to process requests efficiently
<ebroder> I'm not actually sure I believe that - I feel like when release/SRU hasn't sponsored the upload when the ACKed, I've spent a lot more time trying to find a sponsor than I spent trying to get the ACK
<ebroder> I guess I tend to try and push on my bugs here, which tends to find more release/SRU types and fewer sponsors, at least on a per capita basis
<cjwatson> ebroder: you don't believe that the release/SRU team are bottlenecks? (note that I didn't say the sponsoring teams are any better, although I do think they should be)
<ebroder> I'm sure there are a lot of factors. I probably have good luck, and also tend to push uncontroversial bugs that don't take a lot of time to investigate for the release/SRU signoff
<ebroder> I suspect that bugging people in IRC has a lot to do with being able to move my bugs forward
<jdong> ebroder: well the responsibility of the SRU/release teams is to review and say yes/no, and the job of the sponsors is to upload on behalf of those who cannot...
<jdong> but yeah the sponsor queue can get understandably large
<jdong> and sponsors I found back while I was non-MOTU tended to be a bit gun-shy about rubber-stamping uploads too
<ebroder> *nods* That's understandable - if I could sponsor I wouldn't want to just rubber-stamp either
<LaserJock> originally we thought that 1) that non-MOTU should have MOTU sponsors *before* going to MOTU SRU 2) that MOTU SRU shouldn't be burdened with the whole SRU cycle
<ScottK> But no one would take the time to review stuff for sponsorship they didn't even know if would go in.
<LaserJock> the presumption was that rejections from MOTU-sponsored SRUs would be quite rare
<LaserJock> but yeah, it turns out people want to know if they *should* fix before the do the fix
<dtchen> really? i've found that i have to push quite hard to get fixes in
<dtchen> (...which seems a bit odd, since one would think that a former core-dev would know which fixes are appropriate at the point in the dev cycle)
<LaserJock> well, when we went from no-SRU policy to a SRU policy the idea was that it was just minimal quality control to avoid the X-in-dapper problems
<LaserJock> it was mostly presumed that developers knew what a SRU was and what qualified
<ebroder> Hmm...that's interesting. I didn't know that there weren't always SRUs. I bet the view of what's acceptable for an SRU today has broadened substantially since then
<LaserJock> well, there has pretty much always been SRUs in the sense of having -updates
<LaserJock> but it used to be that a dev could upload directly to -updates, without any paperwork or testing
<LaserJock> dtchen: it is odd, yes
<jdong> ebroder: at one point it was literally universe-glues-shut-on-release....
<jdong> ebroder: everything from unbuildable packages to segfaults-on-launch.
<jdong> Universe was kinda "that crap from Sid nobody bothered to look at carefully"
<LaserJock> ah, the good old days ;-)
<cjwatson> ebroder: the SRU process was introduced as a reaction to the major X regression in 2006
<jdong> LaserJock: brings back so many good memories. Probably nightmares of former jdong to you guys though :)
<LaserJock> "OMG, what the heck is that backports nut doing now!!!!"
<LaserJock> you know we love you and your large MIT brain :-)
<paolob> Hi guys! Let me ask you before opening a bug. In my Jaunty beta gnome, it's happening that when I'm writing a doc with Oo.o, after some 100/200 characters the keyboard begins entering very strange characters, and I haven't found any way to modify this behaviour rather than closing Oo.o and reopening it. I have italian localization, italian keyboard, but I have a spanish layout too in my gnome settings. Any idea about anything similar?
<ScottK> I just did an upgrade to Jaunty and ended up with no 2.6.28 in grub/menu.list.  Do I follow up on that here or #ubuntu-kernel?
<ogra> did you get a debconf question for your menu.lst ?
<ScottK> I did not.
<ScottK> I then ran update-grub and it still isn't there.
 * ogra saw that for people that had edited menu.lst in the wrong place, got a debconf question and asked debconf to keep the old file 
<ogra> but thats the only case i have seen it yet
<ebroder> ScottK: The update did install the new kernel, right?
<ScottK> It's vaguely possible I looked away and accidentallly hit something.
<ScottK> Yes
<JFo> j/k
<ScottK> update-grub lists it as found, but it doesn't get added.
<bryce> pitti, mdz, rickspencer3: mesa change uploaded, to drop patch 103.  Ready for archive admin review.  Moving on to tool packaging.
<pitti> bryce: rock, thank you
<ScottK> So I assume I can manually add it, but wanted to see if there's anything that should be checked first?
<ScottK> I do have a manually edited menu.list.
<slangasek> ScottK: sounds like ucf remembering a previous "no thanks"
<slangasek> ScottK: or, what do you have your debconf frontend set to?
<davmor2> bryce: I'm after a cheapish ati card for testing purposes but I want to get one that will be supported for a while do you have an suggestions on preferred chipsets?
<bryce> R5xx are my favorite
<davmor2> bryce:  Thanks dude
<ScottK> slangasek: This is on my kid's computer, so I didn't set it to anything.
<bryce> at this point in time, on jaunty R5xx with -ati seems to be the optimal point in terms of {performance, stability, functionality, upstream support, openness}
<cody-somerville> Why is linux-generic in restricted?
<dtchen> Depends: linux-restricted-modules-generic  <--
<davmor2> bryce: so any regressions would be quite apparnet then :)
<slangasek> ScottK: the thing would be to compare /var/lib/ucf/cache/\:var\:run\:grub\:menu.lst and /boot/grub/menu.lst (ignoring the diff for the non-managed sections of the file)
<ScottK> Chekcing
<slangasek> if the 2.6.28 shows up in the cache, then it's a ucf issue; if it doesn't, it's a non-ucf update-grub issue
<bryce> davmor2: yep
<bryce> davmor2: RV535 [Radeon X1650 Series] is what I own and use on my desktop
<bryce> davmor2: and I always install new -ati's on it before uploading to check for regressions, so....  ;-)
<ScottK> slangasek:  /var/lib/ucf/cache/\:var\:run\:grub\:menu.lst has all the 2.6.28 options listed in it.
<slangasek> ScottK: ok - and it has other diffs as well, relative to your live kernel list?
<ScottK> No.  Just htat
<ScottK> slangasek: That file contains exactly what I would have expected to see starting with ## End Default Options ## to the end of the automagic kernels list.
<ScottK> Nothing else.
<slangasek> ScottK: hrm, that's odd
<slangasek> ScottK: I can't account for that, then; please open a bug on grub and attach both files
<ScottK> slangasek: OK.  Will do.
<pitti> bryce: the mesa upload will auto-close the bug, but I don't think that's justified since it doesn't help all people
<pitti> bryce: ah ignore me, the bug is against -intel
<slangasek> superm1: ping, re: bug #341898
<ubottu> Launchpad bug 341898 in mesa "MythTV Frontend does not work with RADEON DRI" [High,Fix committed] https://launchpad.net/bugs/341898
<ScottK> slangasek: Bug 363049 filed.
<slangasek> superm1: would like to get that pushed in for you ASAP, but would also like to know that it's getting upstream eyeballs on it
<ubottu> Launchpad bug 363049 in grub "grub/menu.list left unupdated after upgrade to Jaunty" [Undecided,New] https://launchpad.net/bugs/363049
<bryce> pitti: yep.  If it did close it, I'd reopen it.  Although, we have no shortage of other freeze bug reports ;-)
<pitti> bryce: it's just the one we just asked everyone to comment on
<bryce> pitti: yep, I wanted to make sure to link it to the patch in the upload note
<superm1> slangasek, yeah i dropped in #dri-devel, and had some comments that it looked sane.  they wanted me to send it to mesa3d-dev ML, and the upstream wants me to try a different patch not yet in git before resorting to this patch, so i'll have feedback later today about that
<slangasek> superm1: ok, so I should continue sitting on the package in the queue...?
<superm1> slangasek, yeah let it sit in the queue for the moment being
<slangasek> superm1: note that there's some other mesa work in progress related to intel, so it may be better to reject and let you re-upload based on bryce's latest changes once decided
<superm1> slangasek, sure that sounds fine to me
<superm1> tjaalton, bryce: the git tree will need to be adjusted with relation to that though ^
<slangasek> bryce: ^^ sorry for the hassle; can you reupload the intel fix as -3, dropping the radeon change for now?
<pitti> bryce: can you please rebase your upload in -2 then?
<pitti> heh
<bryce> ah, sure... one sec
<pitti> bryce: I rejected your ubuntu4 upload
<slangasek> bryce: also, the previous upload had an extra debian/patches/05_texture_size.patch in it, not mentioned in the changelog (or in the series file)
<bryce> (hrm, I bet there is a simple way to do this in git, but I don't trust my git fu)
<bryce> hmm
<bryce> slangasek: ah, got it sorted thanks.  stray patch
<slangasek> ScottK: well, there is another difference: your menu.lst also mentions 2.6.27-7, which I think is no longer installed?
<ScottK> True
<ScottK> I missed that.
<slangasek> that at least explains a possible path how this happened
<ScottK> That's comforting.
<slangasek> 1) customize menu.lst by hand, 2) remove a kernel, 3) remove the customization in menu.lst but leave the old kernel stanzas in place
<slangasek> is that plausible here?
<ScottK> The customization was still there (it's the rootdelay=90)
<slangasek> ah, yes
<ScottK> There is good news though.
<ScottK> This is the original machine against which the D945 fails to boot bug was filed and it booted 2.6.28-11 without the rootdelay.
<slangasek> ah :)
<ScottK> I'm rebooting again to make sure it wasn't a fluke.
<slangasek> if you want to make ucf happy, you can add '# kopt_2_6_27_11_generic=root=UUID=d73b6252-08ff-4920-b197-7b5492045931 ro rootdelay=90' and rerun update-grub, and it should prompt you to reconcile
<slangasek> oh, maybe it won't
<slangasek> but if you make that change, and delete the stale 2.6.27-7, it will
<slangasek> we do need a better way to be able to trigger a ucf prompt for this
<mvo> mathiaz: should I talk to aobut iscsi: http://paste.ubuntu.com/152977/ - just happendin a auto-upgrade test
<ScottK> OK.  If I like my menu.lst the way it is now, is there an easy way to get ucf just to believe that's what should be there?
<asac> any idea how the /usr/lib/gcc/x86_64-linux-gnu/4.3/32/libstdc++.so link is shipped ? dpkg -S doesnt know about it and some amd64 installs seems not to have that (but i have it)
<jdong> what is the correct place regarding dell mini 9 Hardy specific concerns?
<asac> for me its /usr/lib/gcc/x86_64-linux-gnu/4.3.3/32/libstdc++.so -> ../../../../../lib32/libstdc++.so.6
<jdong> I am pretty unhappy that the udev security update has not propagated into its security repo in an acceptable latency
<slangasek> asac: because /4.3/ is a symlink to /4.3.3/
<mathiaz> mvo: was that an upgrade from intrepid?
<mvo> mathiaz: yes
<slangasek> asac: so canonicalize the parent path
<kees> jdong: ?
<mvo> mathiaz: let me create a proper bugreport with the full terminal log
<asac> slangasek: great. thanks!
<mathiaz> mvo: ok - TBH iscsi is broken in intrepid.
<kees> jdong: on, for the mini
<kees> er, s/on/oh/
<jdong> kees: right, the canonical archive that is used for the mini; for security updates in gneeral it seems to lag at least a month or two or forever behind.
<kees> jdong: yeah, they're trying to keep up.
<cody-somerville> They don't lag a month or two
<jdong> cody-somerville: really? Since day0's update of owning this thing for a month, today is the first set of updates I have received.
<cody-somerville> Security updates are generally deployed within three days
<cody-somerville> hpmini or dell mini?
<jdong> dell mini
<jdong> I will take a closer look but I am 99% confident it is not three days
<ScottK> jdong: Stock Kubuntu works on the Dell mini if you want to run it out of the regular repos (Jaunty)
<jdong> ScottK: right, I plan on moving to a stock jaunty this weekend
<jdong> ScottK: but considering these things are sold with no upgrade path it still concerns me
<ScottK> There was a recent blog post on planet about support for them too I recall.
<jdong> libxine1: Installed: 1.1.11.1-1ubuntu3.1
<jdong> vs libxine1: Installed: 1.1.11.1-1ubuntu3.1
<jdong> err 3.3 rather
<jdong> USN 746-1 Mar 26 2009
<jdong> closing in on a month.
<cody-somerville> Whats the candidate?
<jdong> that is the latest candidate from         500 http://dell-mini.archive.canonical.com hardy-security/main Packages
<bryce> pitti, slangasek, mdz, superm1: Rejiggered mesa 7.4-0ubuntu3 uploaded
<jdong> dash:   Candidate: 0.5.4-8ubuntu1
<kees> cody-somerville: did you mean CVE?  that's  CVE-2009-0698
<jdong> vs   Candidate: 0.5.4-8ubuntu1
<jdong> vs 1.1 rather
<cody-somerville> :P
<jdong> mar 10 USN 732-1
<jdong> more than one month
<slangasek> cody-somerville:   libxine1 | 1.1.11.1-1ubuntu3.3 | hardy-security | amd64, hppa, i386, ia64, lpia, powerpc, sparc
<jdong> sudo
<jdong> 3.2 vs 3.4
<pitti> bryce: thanks
<jdong> USN 722-1 Feb 17
<jdong> two months.
<mvo> mathiaz: look like its bug #306678
<ubottu> Launchpad bug 306678 in open-iscsi "open-iscsi fails to correctly update rc.d on upgrade" [Medium,Triaged] https://launchpad.net/bugs/306678
<mathiaz> mvo: yes.
<mathiaz> mvo: it's one of the issue.
<mathiaz> mvo: I've added the upgrade failure you've just pasted.
<mvo> mathiaz: this one looks relatively simple to fix?
<mathiaz> mvo: yes - there are two things to fix actually.
<cody-somerville> jdong, What is your sources.list?
<mathiaz> mvo: I'm preparing a debdiff. Should this go in release or -updates?
<jdong> cody-somerville: whatever the stock one is that ships, lemme paste it
<jdong> cody-somerville: http://paste.ubuntu.com/152993/
<mvo> mathiaz: this is a release-manager question :) I personally think if its just "remove open-iscsi" -> "open-iscsi remove" (or similar scale) we should aim for release
<mathiaz> mvo: it's this change plus an ln -s to ln -sf
<mvo> mathiaz: thanks, I think this should be -release if  possible (is it on the CD?)
<cody-somerville> jdong, Are you sure dash is not up to date?
<mvo> mathiaz: but of course the slangasek has the final word in this. a sru should be simple enough for it too
<mathiaz> mvo: yes - it's on the -server iso.
<cody-somerville> jdong, nvm
<jdong> cody-somerville: well unless there's an apt-get secret-moo-upgrade ;-)
<mvo> mathiaz: I got a failure with bacula-sd as well: http://paste.ubuntu.com/152998/
<mathiaz> mvo: hm - this hasn't been reported yet. Could you file a report?
<mvo> mathiaz: sure
<mathiaz> slangasek: bug 306678 <- should this go to jaunty or jaunty-proposed?
<ubottu> Launchpad bug 306678 in open-iscsi "open-iscsi fails to correctly update rc.d on upgrade" [Medium,Triaged] https://launchpad.net/bugs/306678
<c_korn> odd, I have an invisible mouse cursor in jaunty using virtualbox. but I can open menus and everything with it
<c_korn> is compiz related. mouse cursor is visible after disabled compiz
<slangasek> mathiaz: jaunty please
<ikus060> Hi, I have an issue with Apple Keyboard here. I manage to fix it in the kernel, but I want it to be in the next one. Is there any way to accelerated the process ??
<mvo> mathiaz: filed as bug #363077
<ubottu> Launchpad bug 363077 in bacula "intrepid -> jaunty upgrade fails" [Undecided,New] https://launchpad.net/bugs/363077
<askand> Anyone here familliar with the new notify-osd?
<pitti> askand: davidbarth or MacSlow, but neither are online any more
<askand> pitti: ever again?
<pitti> well, try Monday during European work hours, or email :)
<askand> ah ok :)
<askand> Well, I might as well bring my toughts now, it won't hurt
<mathiaz> mvo: is there a way to tell do-release-upgrade to not disable local apt repositories when doing an system upgrade?
<ikus060> askand: Ask you question. Maybe someone  can help you
<askand> http://pici.se/396034/ here is a screenshot of pidgin using the new notify-osd, as you can see the image is lowres. The problem is that that image is all we get. I don't know how this can be solved
<askand> Perhaps not upscaling them
<jcastro> pitti: wrt the rotate-forver script, if you right click on the titlebar and check "always on visible workspace" on the terminal with the script that should make sure it's on the screen when it locks up
<mvo> mathiaz: yes, give me a sec
<jcastro> pitti: as opposed to just being unlucky
<pitti> jcastro: good idea
<mvo> mathiaz: create /etc/update-manager/release-upgrades.d/myconf.cfg and put in there [Sources]\nAllowThirdParty=yes
<mathiaz> mvo: great. Will that modify the occurence of jaunty in the third party apt sources.list?
<mvo> mathiaz: it should just rewrite intrepid, jaunty and leave everyhting it does not understand alone
<mvo> mathiaz: let me know if that works as expected
<mathiaz> mvo: awesome thanks.
<kees> language packs are biiig
<ScottK> mvo: If you end up doing another update-manager upload, I'd like to toss Bug 363022 your way for consideration.
<ubottu> Launchpad bug 363022 in update-manager "Need special case for gwenview for intrepid -> jaunty upgrades due to libkipi" [Undecided,New] https://launchpad.net/bugs/363022
<mvo> ScottK: thanks, I have a look
<ScottK> Great.
<ScottK> Does anyone have access to ia64 hardware with Jaunty (or chroot) and can help me figure out a build failure apparantely due to an installability issue with one of the depends?
 * calc thinks users (non bug control) should not be able to change status of a bug once it has been marked as triaged
<calc> i just had to mark a bug as triaged again after some user claimed to be "reopening it" by marking the bug as triaged->new and saying he still saw the bug, when it was already linked upstream and is going to be fixed in the next upstrem release
 * calc thinks having non bug control not be able to change them at all would be better but at least not go from triaged->any other state would be helpful
<ScottK> I'd vote for no non-developer being able to unmark fix released too.
<ScottK> I see plenty of "This bug from two years ago isn't actually fixed because I see something kind of similar"
<mathiaz> mvo: hm - it doesn't look like the AllowThirdParty option in release-upgrade.d is working.
<mathiaz> mvo: my local apt repository has been disabled
<mathiaz> mvo: http://paste.ubuntu.com/153021/
<calc> ScottK: yea that too
<calc> ScottK: anything marked triaged, fix committed, fix released, should be developer only for setting originally and changing (imho)
<calc> ScottK: i've seen people mark my bugs invalid as well, since they were upstream (argh), but i can't remember if i had them already marked as triaged at the time
<ScottK> Gotta get the bug numbers good.
<calc> my bug numbers are already good :-)
<calc> triaged doesn't really count against you, its new/incomplete bugs that hurt the stats
<calc> and unfixed non-upstream bugs
<mvo> mathiaz: hrm, so it commented stuff out in sources.list? or is it just a misleading message?
<calc> only about 7% of my bugs aren't triaged atm :)
<mathiaz> mvo: it commented out stuff in sources.list
<mvo> mathiaz: thanks, testing now
<calc> mvo: do you know if it is feasible to catch out of space errors from dpkg, or have dpkg report out of space issues better. so we don't get bug reports from users for those cases (as noted in my ubuntu-devel post from a few days ago)?
<mvo> calc: hm, it tries to do that :/
<mvo> calc: it checks for ENOMEM errors
<calc> mvo: oh? the reports i've seen it looked like dpkg didn't report it up the stack properly to keep the user from reporting it as a bug
<mvo> and ENOSPEC
<mvo> ENOSPC
<calc> like bug 359176
<ubottu> Launchpad bug 359176 in openoffice.org "package openoffice.org-core 1:2.4.1-11ubuntu2 failed to install/upgrade: ?chec dans ??buffer_write(fd)?? (11, ret=-1)?: backend dpkg-deb pendant ??./usr/lib/openoffice/program/libvcl680lx.so??" [Undecided,Invalid] https://launchpad.net/bugs/359176
<calc> its possible its fixed in jaunty but wasn't in hardy/intrepid i suppose?
<calc> i'm not sure what the user was using to upgrade, so perhaps the various packaging manager frontends need to be fixed to report disk out of space, instead of the dumb buffer_write failure message that the user reported
<mvo> calc: it was added in intrepid, its quite possible that it does not get caught in cases where dpkg send a multi line progress string
<calc> mvo: was the check just added to update-manager or in a way that other programs like synaptic report it properly as well?
<mvo> calc: update-manager tries to figure it out these days, but in general its a hard problem as we do not know what parts of the deb take what size beforehand (e.g. is there enough space in /usr if that is on a different parition etc)
<mvo> calc: just the higher level tools because its a heuristic
<calc> well running out of space is bad... but if we know the system ran of space afterwards we can tell them it did and then make it such that they just don't report the bug in launchpad
<calc> mvo: in case like this bug report it shows that dpkg knows it ran out of space, so it should be reporting up the chain a disk out space error code instead of a general failure code (not sure what it does exactly) and then keep apport from reporting the error
<calc> eg:
<calc> DÃ©paquetage de la mise Ã  jour de openoffice.org-core ...
<calc> dpkg : erreur de traitement de /var/cache/apt/archives/openoffice.org-core_1%3a2.4.1-11ubuntu2.1_amd64.deb (--unpack) : Ã©chec dans Â« buffer_write(fd) Â» (11, ret=-1) : backend dpkg-deb pendant Â« ./usr/lib/openoffice/program/libvcl680lx.so Â»: Aucun espace disponible sur le pÃ©riphÃ©rique
<calc> so dpkg-deb knows it ran out of space
<mvo> mathiaz: could you please pastebin the full /var/log/dist-upgrade/main.log ? that is a bit myserious, when I test it locally here it works
<mathiaz> mvo: ok - give me a few minutes. I'll try again
<mvo> calc: agreed, I suspect the bug is that dpkg send the error message in two parts over the status pipe
<mathiaz> mvo: I've started an apt-get dist-upgrade on the system as I need to test the open-iscsi update
<mvo> mathiaz: sure, thanks (its getting late, I may not be around, just mail it in this case)
<mathiaz> mvo: sure.
<calc> mvo: i wasn't sure what packages need to have the bug reported etc so i just emailed the list, i'll try to remember to talk to you about it more at UDS and to upstream at Debconf
<calc> fsck its hailing here now, we missed it last sunday but not today
<calc> guess i'll have to take my cars into to be fixed next week :\
<calc> s/into/in/
 * calc might vanish soon if the power goes out
<Jordan_U> Is it normal that update-manager wants to install a lot of -dbg packages on upgrade from 8.10 to 9.04 ?
<Jordan_U> Sorry, wrong channel
<calc> Jordan_U: if you have the ddebs line probably
<cjwatson> calc: Triaged->Incomplete "does this still exist?" is my favourite bugbear
<cjwatson> Jordan_U: you might have bug-buddy installed?
<cjwatson> it recommends gnome-dbg, I believe
<Jordan_U> cjwatson: Yes I do
<cjwatson> it's no longer installed by default, although it's surprising that update-manager doesn't offer to remove it since it dropped out to universe
<cjwatson> you might want to file a bug about that ('ubuntu-bug update-manager' after the upgrade)
<Jordan_U> cjwatson: Will do, thanks
<calc> cjwatson: heh yea
<ScottK> mvo: Very nice quick turnaround on the gwenview bug.
<ScottK> Thanks.
<mvo> cheers, np
<bryce> ogasawara: heya, I'd like to stick the 2.6.30-rc2 kernel into a ppa for folks to debug X.org freezes with
<bryce> ogasawara: there's debs available at http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc2/
<ogasawara> bryce: yup
<bryce> ogasawara: however to put it in my ppa I need the .dsc file.  Any idea on if such a thing is available somewheres?
<ogasawara> bryce: hrm, apw would be the one to ask, but he's away I think
<IntuitiveNipple> Some update today has upset metacity: no window-decorations, cursor on 2nd screen becomes the default X cursor, no hot-key responses, blank and vertically extended tomboy notes
<ogasawara> bryce: lemme ask rtg and see if he knows
<bryce> kewl thanks
<IntuitiveNipple> I've looked and the most likely are libgtk, libpanel-applet and libgail, but not sure where to start!
<bryce> IntuitiveNipple: there was a new mesa upload today
<ogasawara> bryce: shoot, rtg doesn't seem to be online at the moment
<IntuitiveNipple> bryce: would that affect nvidia restricted driver?
<bryce> IntuitiveNipple: only -intel
<ogasawara> bryce: apw appears to be in #ubuntu-kernel (or at least logged in)
<bryce> ogasawara: hmm, okay thanks.  I'll just put a link to those debs from my ppa for now
<IntuitiveNipple> bryce: well that eliminates mesa as a cause then :)
<bryce> that's a first ;-)
<LaserJock> bryce: you know, you can build your own .dsc too
<bryce> LaserJock: from just the .deb?
<LaserJock> bah, no, I see what you mean
<LaserJock> you meant source package
<LaserJock> I thought you were just missing a .dsc
<bryce> no... need like a git repo, or source tarball or something
<bryce> not a huge deal, these .deb's should be fine for now
<bryce> but I think folks would like having everything wrapped up in a single ppa
 * calc notes the more he looks at upstream OOo the more scared he becomes :\ fixing this mess is a near impossible task
#ubuntu-devel 2009-04-18
 * chrisccoulson wishes launchpad would unsubscribe people who reply to bug reports via e-mail with "unsubscribe"
<jdong> chrisccoulson: I could never figure out if that monstrous unsubscribe chain bug was a meme or serious
<chrisccoulson> the one on bug 359518?
<ubottu> Launchpad bug 359518 in acroread "acroread failed to update in 8.10" [Medium,Triaged] https://launchpad.net/bugs/359518
<chrisccoulson> i've got an inbox full of unsubscribe e-mails
<jdong> chrisccoulson: I believe even older than that bug
<jdong> I've got a good collection of em too
<chrisccoulson> yeah, this one is really annoying. i might have to unsubscribe myself now;)
<jdong> chrisccoulson: do an e-mail filter for one-line unsubscribe bodies
<chrisccoulson> that's quite a good idea
<chrisccoulson> i think i'll do that. thanks!
<david_hilton_p> a friend of mine was running the jaunty beta, and did a dist-upgrade that hosed his system
<david_hilton_p> unfortunately, he's a neophyte and lives kind of far away
<jdong> well unfortunately that's not much information for us to go on...
<david_hilton_p> yeah, I asked him to grab the exact error message
<david_hilton_p> his computer shut down on him in the middle of the dist-upgrade, and now has a problem booting
<david_hilton_p> ok, the problem isn't with booting, but rather X - I'm having him grab his xorg logfile and xsession-errors
<wgrant> chrisccoulson: Launchpad can't automatically unsubscribe people just because they do that - that's very unsafe.
<pwnguin> wgrant: how about just a filter for messages with the phrase "unsubscribe"
<pwnguin> applied at the lp level
<pwnguin> or perhaps the usual "an unsubscribe request has been sent. click here to unsubscribe"
<wgrant> pwnguin: They are looking into that.
<pwnguin> chrisccoulson: i particularly like https://bugs.edge.launchpad.net/ubuntu/+source/acroread/+bug/359518/comments/91
<ubottu> Ubuntu bug 359518 in acroread "acroread failed to update in 8.10" [Medium,Triaged]
<LaserJock> has anybody noticed that .xsession/.xinitrc aren't being sourced?
<bryce> LaserJock: try ~/.xstartup
<LaserJock> trying, brb
<LaserJock> bryce: same
<LaserJock> there's bug #355721 but that's not very helpful other than to say it seems like other people might have a similar problem
<ubottu> Launchpad bug 355721 in xinit "Jaunty won't source .xsession" [Undecided,New] https://launchpad.net/bugs/355721
<LaserJock> nvm, I think it's just gnome being stupid
<pace_t_zulu> anyone here have experience with gconf?
<glyph> Hey, is this the right place to agitate for a fix to the sqlite package?
<glyph> sqlite versions 3.6.4->3.6.12 have a pretty serious bug that prevents them from loading certain databases created with <=3.6.3
<glyph> I filed this in Launchpad as https://bugs.launchpad.net/ubuntu/+source/python-axiom/+bug/363192
<ubottu> Ubuntu bug 363192 in sqlite3 "sqlite3 packaged in Jaunty cannot open databases which use "indexed" keyword, and is therefore incompatible with Axiom" [Undecided,New]
<pace_t_zulu> does anyone know how to modify gconf values?
<Snova> gconf-editor ?
<geofft> or gconftool-2, which is easier to use programatically
<bluefoxicy> Any chance of promoting libpam-tmpdir to main?  Who's currently maintaining it....
<bluefoxicy> there... I've added that to common-session
<Chipzz> jdong: lol at the unsubscribe bug :)
<xerakko> hi
<xerakko> something have the irc logs in two last days? I had not them enabled for this channel :(
<geofft> you mean as in http://irclogs.ubuntu.com/ ?
<Omar87> My system refuses to continue the update.
<Omar87> It downloaded 51 files out of 69, and then it refused to go on, stating that there's a problem with the connection or something.
<siretart`> Omar87: wrong channel, see #ubuntu or #ubuntu+1 for end-user support
<Omar87> Then what's this channel for?
<Nafallo> Development of Ubuntu (not support, not app development on Ubuntu)
<Nafallo> as clearly stated in the topic
<Omar87> Oops, my mistake then, | haven't noticed that.
<siretart`> didn't we have somewhere old archive mirrors of deprecated, EOL'ed versions of ubuntu like warty, hoary and such?
<Nafallo> old-releases.ubuntu.com
<siretart`> yepp, that's it! thanks!
<ppd> hi. I've got a problem with the new release candidate when mounting dvds. everything is fine for cdrom and the like but dvds are only accessible with "sudo". what application/part of the system should I file the bug for?
<ChosenOne> hi
<ChosenOne> I just installed the 9.04 RC within about an hour without any troubles :) thanks guys, nice work
<cody-somerville> I get the following error when I try to debootstrap Jaunty: https://pastebin.canonical.com/16499/
<cody-somerville> Is anyone else having similar trouble or is it possibly my stupid squid proxy?
<Adri2000> cody-somerville: "this website is restricted to Canonical employees", so either use anoter pastebin or ask in a canonical only place
<cody-somerville> Doh
<cody-somerville> http://pastebin.ubuntu.com/153505/
<ScottK> cody-somerville: I'd vote for the proxy.
<Brucevdk> I hope this is the appropriate channel, but does anybody know if these mockups are just drawn? https://wiki.ubuntu.com/NotifyOSD#Fallback%20alert%20boxes
<ScottK> Brucevdk: #ayatana (don't ask me where the name came from) is a better channel.
<Brucevdk> ScottK: thanks, and I won't ask ;-)
<rubyish> hi. is it possible to make gcc/ld link to shared library with an absolute path?
<rubyish> e.g: <ldd output>
<rubyish> => libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0
<rubyish> becomes
<rubyish> => /usr/lib/glib-2.0.so.0
<Uuu> Hi! I have a possibly bug of locobot (or something else logging Ubuntu irc channels).
<Uuu> ok, found where I can write that; czeÅÄ ;P
<slangasek> superm1: how's mesa coming?
<superm1> slangasek, well i've actually got a smaller patch now that fixes it, but the upstream guy hasn't said yes to it
<superm1> they're saying it's likely a QT problem to which i'm saying no it's not, it works with -intel, -vesa, -nv
<superm1> but here is the updated patch atm: http://pastebin.com/f4e8ecb86
#ubuntu-devel 2009-04-19
<superm1> so all it's doing is adding a 24bit fbconfig whenever you are operating in 32 bit mode now rather than a 8, 16, 24, and 32 in any mode
<slangasek> superm1: sure, that makes sense
<superm1> the guy hasn't responded since i sent that updated patch though, but it's !weekend anyhow, so i'll wait some more
<slangasek> superm1: how much longer?  I think I'd be unwilling to accept this in the release pocket after Monday morning
<slangasek> (UTC)
<slangasek> so maybe we should just plan right now to make this an SRU?
<superm1> slangasek, yeah if we dont have this sorted out by the end of the weekend, i agree make an SRU
<ScottK> Much faster doing upgrades today than on the day the RC was released ....
<LaserJock> does piuparts work in Ubuntu these days?
<Laney> I think so
<Laney> there was a talk at UDW on it
<ScottK> IIRC liw is the puiparts expert.
<LaserJock> I was just reading some sponsorship requirements from a DD and they included piuparts
<LaserJock> and I wondered how realistic it is to run piuparts over every upload
<ScottK> I've never been asked to do that.
<kolby> !help
<ubottu> Hi! I'm #ubuntu-devel's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
<Befolked> Hi.
<Befolked> I'm not sure if this is the right channel, but..
<Befolked> According to this bug report, my issue is fixed in Hardy (https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/295091), but even after applying the latest updates from hardy-proposed my system still freezes on boot.
<ubottu> Ubuntu bug 295091 in linux "kernel crashes at boot on a dell inspiron 531." [High,Fix committed]
<Befolked> adding the acpi=off option to my grub line fixes it, but that has unwanted sideeffects, and it should just work.
<Befolked> so, is this package just not updated or what?
<geofft> presumably that bug wants to have status "fix released", not just "fix committed"
<Befolked> yes, i thought it was released after looking at the committ tree
<Befolked> but it doesn't fix anything on my machine, so i thought maybe it was just me.
<sbeattie> Befolked: did you use the kernel from hardy-proposed? I don't believe it's made it to hardy-updates yet.
<lool> doko, cjwatson: Just a heads up that I assigned ubuntu-toolchain to fix 246625 which seems understood now and is a relatively important issue to fix in my eyes, so I've milestoned it
<lool> It's not clear to me why we're using nosegneg on i386 (and not in i686), but we should ship the file enabling libc6-xen to work out of the box for people running xen with hardy or intrepid (this does seem like a high importance target)
<lool> slangasek: 360989 > the notify-osd change is a workaround gdm's behavior
<lool> slangasek: https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/360989/comments/12 documents what remains to be done in gdm
<ubottu> Ubuntu bug 360989 in notify-osd "notification-daemon started instead of notify-osd in Netbook Remix" [Medium,Fix released]
<lool> slangasek: Albeit I don't know how to keep a task for karmic and not jaunty
<slangasek> lool: mark the jaunty tag 'wontfix'
<slangasek> s/tag/task/
<lool> ah
<lool> thakns
<Lure> slangasek: can you discuss exiv2 0.18.1 exception shortly?
<Lure> slangasek: bug 358576
<ubottu> Launchpad bug 358576 in exiv2 "exiv2 version 0.18 crashes / also crashes digikam / fixed in 0.18.1" [Medium,Triaged] https://launchpad.net/bugs/358576
<dcordero> hi
<dcordero> i sent a debdiff file for fix a bug with has just been approvaled for upload. I never did it before, should i upload the new package? is it done by motu team?
<afflux> dcordero: which bug?
<afflux> dcordero: never mind
<dcordero> afflux: people in #ubuntu-motu already help me :D  Thanks anyway
<afflux> yep, saw that
<savvas> is it a known problem that when you use "sudo aptitude update; sudo aptitude upgrade" (and perhaps apt-get) the packagekit icon tooltip (in the tray/notification area) in gnome still shows that there are "xx updates" to be done?
<ebroder> savvas: You should be doing dist-upgrade, not upgrade
<savvas> sorry, safe-upgrade :)
<ebroder> And you should use #ubuntu for support
<savvas> it's about jaunty, just asking if it's a known problem devel-wise
<ebroder> If you think it's specific to jaunty, then #ubuntu+1
<ebroder> But the behavior you're seeing is intentional
<savvas> ok
<defreng> good evening - is somebody familiar with the new notify-osd API for concatenating two notifications?
<hyperair> defreng: you should poke the people at #ayatana
<hyperair> defreng: also take a look at pidgin-libnotify for an example
<hyperair> defreng: i think the wiki also shows an example
<defreng> hyperair: yeah, I'm already quite far, but I want to concatenate to notifies - the wiki keeps silent exactly on this point
<defreng> but thanks for the channel advice, I'll have a look there
<hyperair> defreng: i remember seeing some C code snippets which worked in the wiki. complete with videos.
<defreng> hyperair: It describes updating but not concatenating, unfortunately
<hyperair> hmm?
<hyperair> strange, i remember seeing concatenating.. but someone on #ayatana gave me the link
<defreng> hyperair: do you hava a link? I'm looking at https://wiki.ubuntu.com/NotificationDevelopmentGuidelines
<hyperair> "How to use append-hint"
<hyperair> that's exactly what you should be looking at
<hyperair> defreng: ^
<defreng> hyperair: yeah, but I'm lazy - I want to append, not update the whole thing ;)
<defreng> and "Concatenating related notification bubbles" is empty
<hyperair> ...for the love of god
<defreng> wait - one moment :D maybe it does work this way ;)
<hyperair> you got eyes?!
<hyperair> read it damnit
<hyperair> read it!
<defreng> yeah yeah yeah - I'm sorry ;)
<hyperair> heh =p
<defreng> thanks a lot for hinting me ;)
<hyperair> =)
<hyperair> no problem
<kees> what exactly is spewing:
<kees> INFO: using unknown version '/usr/bin/python3.0' (debian_defaults not up-to-date?)
<kees> during package updates?
<ebroder> I think pycentral. Either that or pysupport
<kees> hm, looks like python-defaults, via python-minimal
<geser> my guess is python-central or python-support
<kees> /usr/share/python/debian_defaults
<kees> seems to be missing python3.0
<geser> I guess it's ok that python 3.0 isn't listed as most(?) modules won't work with it either way
<kees> doko: should /usr/share/python/debian_defaults list python3.0 ?
<kees> yeah
<Riddell> ArneGoetje: re bug 362229 can we just add the translation files manually to the language-pack packages?
<ubottu> Launchpad bug 362229 in language-pack-kde-fr "Kubuntu language packs miss .desktop translations" [Undecided,Fix committed] https://launchpad.net/bugs/362229
<doko> kees: no, doesn't make sense. 2.x and 3.x code are mostly incompatible
<kees> doko: okay, cool; any way to silence the "INFO: ..." warning?
<doko> hmm, looking ...
<doko> kees: it's info, not warning ;)
<AndyTimUbuntu> I'm considering adding to the initrd to support mounting the squashfs over the httpfs FUSE system.  There isn't already support for the LiveCD environment entirely via HTTP yet, right?
<AndyTimUbuntu> A look at the initrd reveals NFS, CIFS/SMB support...
<lesshaste> hi all
<lesshaste> how do I "enable" /var/crash
<lesshaste> it is permanently empty it seems
<lesshaste> despite gdmsetup crashing every time
<dtchen> see /etc/default/apport
<AndyTimUbuntu> Does this sound like a direction that might be useful as part of Ubuntu in general?
<lesshaste> dtchen: it's very odd..  grep enabled /etc/default/apport
<lesshaste> enabled=1
<lesshaste> ls /var/crash/
<lesshaste> raph@raph-desktop:~$
<lesshaste> blank
<AndyTimUbuntu> Devels must be asleep.  I'll ask another time.  Enjoy your Sunday(s).
<ia> hello. i've found out about "ubunet" project and other related projects, like "ubuntu one" (some clues tells, that it's something like .mac for ubuntu and it's in active development now); it says, that all this projects are proprietary, but will be they free of charge after release? and when will be something, that can be tested by "simple users" (not Canonical developers)? at one of lp pages about this said, that milestone for ubunet is jaunty - does this
<ia> mean, that it will be available in jaunty after release? and where i can find out more about ubunet and ubuntu one?
<ScottK> ia: That sounds like you need to find some Canonical resource to find out about that, not part of Ubuntu.
#ubuntu-devel 2010-04-19
 * slangasek wonders if anyone wants to fix hdf5 on armel
 * persia looks at the log
<persia> slangasek: Am I reading correctly that *sed* segfaulted?
<slangasek> persia: it probably segfaulted when running ./H5detect, *after* running the sed to set LD_LIBRARY_PATH
<persia> Hrm.  Do you have any input information that would help track down the issue?
<slangasek> persia: no, all I know is that this is the root of all the build failure mails I'm getting the last two days :)
<joaopinto> Keybuk, about the "/dev/somehwere" case, can't you just introduce a delay on mountall when there is an error ? to allow for plymouth to start before seding the prompt ?
<persia> That's a charitable explanation that doesn't blame lamont and I for brute-force approaches.  Thanks :)
<persia> Anyway, emulated build is running now.
<joaopinto> Keybuk, I guess a few seconds delay when there is a mount error would not hurt :)
<slangasek> joaopinto: hackish; we should just fix plymouth instead
<joaopinto> slangasek, right, but right now a typo on fstab will render systems unbootable :P
<persia> What should plymouth do in that case?  Isn't it not even running at that point?
<slangasek> persia: no, plymouth is running before mountall
<persia> Even when plymouth isn't in initramfs?
<slangasek> the issue is that messages sent *to* plymouth by mountall, before plymouth show-splash is called, are lost
<slangasek> yes - *plymouth* is running, only the splash screen isn't
<persia> Aha.  I have an improved understanding.
<slangasek> because the splash screen depends on video device -> udev -> virtual-filesystems -> mountall
<joaopinto> how does the mountall <-> python protocol work ? mountalls waits for an answer to the S/M prompt ?
<joaopinto> ops, s/python/plymouth
<slangasek> it continues other processing, but has an event loop to check for an answer to that prompt
<joaopinto> queuing the prompt until the splash is available is not an option ?
<slangasek> of course it is; but that queuing should be done within plymouth
<slangasek> because mountall doesn't know, and shouldn't know, when the splash is available
<slangasek> hence - "we should just fix plymouth instead"
<joaopinto> ok :)
<rojanu> Everytime a user logs in title bars on apps are missing, they appear after I select normal from Visual effect.  I am using nVidia 195.36.15
<rojanu> Any ideas how to fix it permanently?
<slangasek> jdstrand, mdeslaur: what was your bug number for the "nouveau only gives 16-bit fb" issue?  I think bug #565936 is a duplicate
<ubottu> Launchpad bug 565936 in plymouth "Plymouth text theme appears when booting Lucid CD, doesn't fill the screen" [Undecided,Incomplete] https://launchpad.net/bugs/565936
<slangasek> tjaalton: reviewed xorg-server - sorry, this changeset is too large for this stage; can we just cherry-pick the xorg.conf.d part?  (that part makes sense to me to take, because it saves us having to carry config file clean-up code for 2 years)
<slangasek> jdstrand, mdeslaur: found it, bug #554143
<ubottu> Launchpad bug 554143 in plymouth "text logo theme used instead of graphical with radeon 7500 (single video output, pseudocolor fb)" [Medium,Triaged] https://launchpad.net/bugs/554143
<slangasek> oh, that was radeon, not nouveau, doh
<slangasek> tjaalton: "drop 05-evdev.conf, this moved to the server" - should this have some sort of versioned depends or breaks somewhere, to ensure a smooth upgrade?
<slangasek> tjaalton: given that there are no upgrade guards in here, and given that it's a move from /usr/lib to /usr/share (I thought it was a move from /etc/X11 to /usr/share - sorry for misunderstanding), I think this is pretty high-risk for the benefit - I'd like to see versioned relationships set here to ensure partial upgrades work smoothly, and once we *have* that, I think the motivation for getting this in before lucid final is diminished -
<slangasek> ... probably just be deferred to maverick
<slangasek> ArneGoetje, pitti: we're missing language-pack-gv-base, breaks DVD builds due to presence of language-pack-gnome-gv
<ArneGoetje> slangasek: ok, will upload the -gv langpacks only
<slangasek> ArneGoetje: ok, thanks - the other langpack changes you had were just roll-ups, not any particular bugfixes?
<ArneGoetje> slangasek: I'm not sure if there are bugfixes inside, but I guess they can wait for the final export...
<slangasek> alright; I believe that's best at this point
<slangasek> ArneGoetje: though if the fix for bug #565180 is in your current export, language-pack-kde-de is probably a good one to have uploaded before final
<ubottu> Launchpad bug 565180 in language-pack-kde-de "Translation error in Launchpad changes (KMail/kdepim)" [High,Fix committed] https://launchpad.net/bugs/565180
<slangasek> (if not, then we'll wait for the final export)
<ArneGoetje> slangasek: if it's 'Fix Committed', then it's likely that fix is in this export
<ArneGoetje> slangasek: however, as we have versioned dependencies in the langpacks, I will need to upload all -de langpacks
<slangasek> ArneGoetje: that would be fine
<ArneGoetje> slangasek: ok, will upload now
<ArneGoetje> slangasek: hmm... -gv has not been translated enough, so there is no language-pack-gv-base... only the -gnome package exists... I guess we should block that one then.
<ArneGoetje> slangasek: eh... that package is empty... hwo could that happen? So, please remove it from the archive.
<slangasek> can do
<slangasek> ArneGoetje: done
<ArneGoetje> slangasek: thanks...
<ArneGoetje> slangasek: -de uploaded
<slangasek> thanks :)
<psusi> cjwatson, you asked me to do some testing on the slow down caused by the dpkg sync changes... I have completed them.  Time to upgrade with packages already downloaded to disk going from a clean beta 2 install to current goes from 6m21s to 11m15s when switching from -ubuntu3 to -ubuntu4 of dpkg
<chrisccoulson> oh, so dpkg _is_ slower now then
<chrisccoulson> i thought i'd noticed that again
<psusi> yea... -ubuntu4 apparently went back to syncing, but only after unpacking all files in a package... so not quite as bad, but still bad when upgrading many packages
<chrisccoulson> i'm not sure if my issue is only with dpkg, but my laptop is unusable whilst installing/upgrading packages atm
<chrisccoulson> the cursor freezes for some ~30s at a time
<psusi> try downgrading to -ubuntu3?
<chrisccoulson> i might do, but in the morning now
<chrisccoulson> it's getting late ;)
<persia> slangasek: I can't replicate the hdf5 build failure: it builds fine for me.  So unless you can find someone who *can* replicate it, I think you'll have issues getting the FTBFS cleared.
<slangasek> persia: doh
<slangasek> persia: well, thanks for looking
<persia> http://paste.ubuntu.com/418278/ for the curious
<slangasek> mdke: still "today" as an ETA? :)
<tjaalton> slangasek: now that evdev.conf is shipped with the server it means that it's always available, meaning that mouse & kbd works even with partial upgrades
<tjaalton> slangasek: the drivers {build-,}depend on the new xserver too
<persia> tjaalton: But what happens if one *only* upgrades the server, and doesn't upgrade anything else?  Isn't there a conflict with the old version of the file?
<tjaalton> persia: no, the old one is ignored
<persia> And they are in different locations?
<tjaalton> yes
<slangasek> not a conflict, but everything except evdev gets ignored, yeah
<persia> Hmm.
<tjaalton> though it gets more hairy if the server version isnt' bumped
<ccheney> slangasek: ok, sorry didn't see your message until now
<persia> tjaalton: But don't the new drivers depend on the new server version?
<tjaalton> persia: they would, but no point in getting them then
<tjaalton> (bdeps on the new upstream version)
<persia> Right, so really there's no combination of upgrades that dpkg will accept in which anything breaks?
<tjaalton> well, the deps could be relaxed to match our xserver version, though that needs some of the packaging changes from xserver to support xinputver etc
<tjaalton> with that in place, yes, nothing should break too horribly
<tjaalton> slangasek: so just getting that xorg.conf.d patch means that either keep /usr/lib in the search path and ship the current drivers (ugly, but working), or migrate the drivers
<slangasek> my concern is that there are a lot of packages to coordinate, and the change has fairly low impact on the user; but failing to get the packages all built in time for RC (due to any of a number of possible reasons, not limited to bugs in the packages) would have a *high* impact, because the out-of-date driver packages would be installing their files to the old search path
<slangasek> that, plus the fact that partial upgrades are possible that would cause the user's devices (other than evdev) to stop working as intended
<slangasek> the server could declare Breaks: on the old versions of the drivers to address this - but at this point, we're close enough to the time when we need to start ISO mastering that it's just too risky
<slangasek> bryceh, apw: bug #566379 is a regression for an i855 user introduced when disabling KMS by default
<ubottu> Launchpad bug 566379 in linux "Cannot boot past Plymouth with kernel 2.6.32-21 in normal mode" [High,New] https://launchpad.net/bugs/566379
<slangasek> tjaalton: sorry - if I'd have been able to review this for you last night and gotten a new server upload done then, it would've been possible; now we're just out of time
<slangasek> ccheney: no worries - it only took me two uploads to get it right ;)
<slangasek> ccheney: but you may want to look at why OOo bzr was out-of-date wrt the packaging branch - I haven't committed my changes there for the two uploads because I thought you might want to investigate that first and get it in-sync
<tjaalton> slangasek: alright
<tjaalton> slangasek: hmm, actually re-adding /usr/lib/X11/xorg.conf.d to the search path should cover your concerns, but I'll rest my case :)
<pitti> Good morning
<mdke> slangasek: test build hadn't finished by the time I went to bed. Tested now and am uploading
<slangasek> mdke: ack, thanks
<mdke> slangasek: that's for ubuntu-docs. Will it be ok if gnome-user-docs follows this evening?
<slangasek> mdke: that's rather late for inclusion on the RC images.  is there something I can do to help it get done sooner?
<mdke> slangasek: I need to update the translations from Rosetta. I'll see what I can get done now but I would have thought that inclusion on RC isn't absolutely essential
<slangasek> mdke: what's essential is to change as little as possible between RC and final; the standard checklist at https://wiki.ubuntu.com/ReleaseProcess calls for these packages to be uploaded prior to RC...
<slangasek> mdke: if we *have* to pull it in post-RC, we will, but I'd certainly prefer to have it before
<mdke> slangasek: ok, I'll give you a shout in 30 mins or so
<slangasek> mdke: ok - if I can be of any help with the Rosetta importing, I'd be happy to do so
<mdke> thanks. I've started it off now
<baptistemm> heya
<mdke> robert_ancell: legend, thanks
<robert_ancell> mdke, np :)
<joaopinto> good morning
<mdke> slangasek: ok, I've pushed the changes to ~ubuntu-core-doc/gnome-user-docs/lucid and started a test build - will let you know how it goes
<slangasek> mdke: cheers!
<dholbach> good morning
<joaopinto> slangasek, was discussing this with KeyBuck yesterday, imho the recovery mode should not trigger mountall, recovery mode was useless to troubleshoot the hang cause
<joaopinto> mounting all configured systems is not a trivial operation, one of those that you might want to recover from
<slangasek> joaopinto: that's a different level of recovery than the recovery mode menu we've used to date, though; the recovery menu requires /usr to be mounted, and that may be a separate fs
<slangasek> joaopinto: I agree that this mountall bug makes it awkward, but it's not realistic to revisit such a fundamental design decision for lucid
<joaopinto> ok, well, I am most used to UNIX single user modes for recovery, kernel loaded, root fs mounted, init started, and a shell
<joaopinto> someone using a /usr on a different partition should know how to manually mount it :)
<mdke> slangasek: ok, that's uploading now. Sorry I didn't get it done when I said I would
<slangasek> mdke: 'sok, we're still in the game :)
<slangasek> mdke: thanks for the quick turnaround this morning!
<mdke> slangasek: :)
<pitti> slangasek: I have two more keymap fixes for stuck keys for udev; however, these (and similar future fixes) require a slight reorganization (well, really just a renaming) of the maps files: http://people.canonical.com/~pitti/tmp/0003-keymap-Unite-laptop-models-needing-common-volume-key.patch - is that okay for you for lucid final? (two rules additions will go on top of that for two laptop models)
<pitti> slangasek: (this will unfortunately produce some autoconf file noise)
<mantiena> Hi all
<slangasek> mvo: bug #566453> which part of this is the warning that you consider a bug?
<ubottu> Launchpad bug 566453 in plymouth "plymouth-theme-fade-in warns on removal" [Undecided,New] https://launchpad.net/bugs/566453
<mvo> slangasek: feel free to close if the warnings do not matter, it just appreard in the auto-install-tester log
<mvo> slangasek: and user may be confused/scared by it, but its low priority anyway, just wanted to  record it for later
<slangasek> mvo: would moving the update-alternatives call to the prerm fix the warning?
<mvo> slangasek: I think it will,
<slangasek> mvo: ok - could you comment that in the bug so we don't forget?
<mvo> slangasek: will do, thanks
<joaopinto> mvo, question about the motivation for the binary.changelog, is it possible for a source package to generate binaries with random versions ?
<mvo> joaopinto: yes, take gcc-defaults as a example
<mvo> joaopinto: there is a small number of packages that do that
<mvo> joaopinto: but those tend to be important
<pitti> james_w: I upload a new kerneloops with disabling it by default now
<joaopinto> hum, I am puzzled how that plays with binary.changes files
<joaopinto> because you have a single "Version:" field, which I suppose it's related to the binaries, not to the source
<mvo> joaopinto: the version in the changelog refers to the source changelog
<mvo> joaopinto: (if that is what you mean, not sure I understand the question)
<pitti> mdke: we want to disable the "Report a bug" menu item for the final release (https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-bug-management); would that touch documentation?
<joaopinto> mvo, right, I am trying to figure where do you relate a source version X, with a binary version Y, I mean at a control level, without relying on the Files list
<james_w> pitti: thanks!
<pitti> james_w: (I used lp:ubuntu/kerneloops, is that right?)
<joaopinto> mvo, well, I will check gcc-defaults to save your time :)
<james_w> pitti: yup
<mvo> joaopinto: yeah, do that, its a good example, its justing substvars for it
<joaopinto> anyone aware of an ext4 change that might result in a major performance hit on ext4 writes ? I mean from karmic to lucid
<SwedeMike> joaopinto: the disk io scheduler was changed a bit., could affect that.
<joaopinto> SwedeMike, hum I got such a penalty that I had to force barrier=0 on my ext mounts
<joaopinto> a debootstrap was taking 10x more than it previosly did
<SwedeMike> and you were running with barriers in karmic as well?
<joaopinto> I didn't touched barriers there, actually I jut became aware of barriers after noticing this problem now
<joaopinto> SwedeMike, was that changed early on the development cycle or a short time ago ?
<SwedeMike> that was in 2.6.32 so should have been all the way in lucid
<slangasek> seb128: libdbusmenu/indicator-messages> are there more uploads pending from this quarter?  It's only by luck that we haven't started RC ISO mastering yet
<SwedeMike> joaopinto: http://lwn.net/Articles/352863/
<directhex> joaopinto, dlr-languages does the binary-version-mangling trick
<pitti> slangasek: from this quarter> if there's still room, http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=db57bdda04e20667f510262d045c2af6fe335931 falls under that category; it would make SRUing keymap fixes a bit easier, since these would avoid file renames
<seb128> slangasek, no, that is the remaining issue I knew about from dxteam
<SwedeMike> joaopinto: my bad, that wasnt io scheduler, that was cpu scheduler
<seb128> slangasek, ted sent updates my way during the weekend
<slangasek> seb128: yep - I see he even linked the branch; if I had been paying closer attention, perhaps I could've had those sponsored in before today :/
<seb128> slangasek, you think they can still go in RC or better after RC now?
<slangasek> seb128: before RC
<slangasek> always before, if there's a choice ;)
<seb128> ;-)
<slangasek> pitti: udev> can you get that uploaded now, and I'll figure out what to do with it once it's there?
<pitti> slangasek: yup
<joaopinto> SwedeMike, thanks anyway :)
<joaopinto> directhex, checking, tks
<seb128> slangasek, pitti: if,when you review gir-repository consider the newer of the 2 uploads, the was a missing build-depends in the first one, the update drop the gtk gir since that's built by the gtk source now
<slangasek> seb128: pre-emptively dropped the first one from the queue
<seb128> slangasek, thanks
<pitti> slangasek: udev uploaded and tested
<pitti> slangasek: I'm going to look at the pm-utils suspend blacklisting now (bug 526354); but I want to test this carefully, so it might be for post-RC or for the next RC spin
<ubottu> Launchpad bug 526354 in pm-utils "[Dell Studio 1537] temperature sensors and fan stop working following suspend/resume" [High,In progress] https://launchpad.net/bugs/526354
<slangasek> pitti: right, sounds good
<jibel> mvo, could you please review and upload 565816 ? thanks
<mvo> jibel: yes
<mvo> jibel: thanks, merged and uploaded. there appears to be another small issue in the branch, when I double click on something uninstalled it gets marked for install, when I doulbe click again, it does not change status, I think that used to be different (i.e. double click again would unmark again)
<pitti> slangasek: pm-utils uploaded (admittedly a nasty solution, but let's hope it only has to last for some two weeks)
<mdz> ara: I think the "150" figure for Xubuntu testers is misleading, e.g. somehow I am a member of this team through some indirect membership :-)
<ara> mdz, :)
<ara> mdz, I sent the email to xubuntu-devel as well, it might be a better audience
<james_w> by my reading emacs22 shouldn't be on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt as auctex has emacs23 | emacs 22 and it just seems to be depending on itself then. Can anyone see otherwise?
<ara> mdz, found it. ubuntu core -> xubuntu devel -> xubuntu team -> xubuntu testers
<slangasek> james_w: nope, that one I'd been skipping because I was pretty sure it was just an accounting problem
<james_w> right
<ara> mdz, lost in a chain of indirect membership
<james_w> slangasek: any idea why we had an upload a few hours ago that LP seems to be attributing to katie?
<slangasek> james_w: urk, no
<ara> mdz, indirect membership are a bit useless in some cases; I would like to be able to use the Contact Team Members feature without spamming people not interested in testing Xubuntu
<james_w> I can't see a bug for the sync either
<james_w> slangasek: ah, it was a promotion a few hours ago, the sync was a while ago
<mdz> ara: I agree, we get too much spam as a result of nested teams
<slangasek> james_w: ah :)
<mdz> in part because teams are (ab)used for ACL purposes
<mantiena> cjwatson: hi, can you tell me if there are any plans to update ubiquity translations from launchpad before final lucid release? Yesterday O
<ara> mdz, yes. I will file a wishlist bug against launchpad to have the opportunity to "Contact this team's DIRECT members"
<mantiena> Yesterday I've fixed some important Lithuanian translations errors in ubiquity-debconf translation - our translation leader introduced some bugs 10 days ago :(
<ara> mdz, sorry for the noise
<mdz> ara, just remember to specify the problem, not only the proposed solution, since they may have a better idea for how to fix it :-)
<ara> mdz, will do ;-)
<mantiena-baltix> Maybe someone could tell me if Evan Dandrea will be here?
<james_w> ccheney: openoffice.org-common depends on xfonts-mathml. Do you know if it needs ttf-lyx that the latter recommends?
<Daviey> ScottK: bug #566497 is looking valid.. Fresh install of clamav didn't give me a logroate.d/*clam* file.. If it's being too verbose or not i don't know, but there isn't any way i can see it's being rotated.
<ubottu> Launchpad bug 566497 in clamav "logging waaaaaaaay to much (7gb too much)" [Undecided,Incomplete] https://launchpad.net/bugs/566497
<cjwatson> mantiena-baltix: ev updated them yesterday
<cjwatson> mantiena-baltix: isn't this the second release where we've had last-minute Lithuanian updates?
<cjwatson> maybe I don't mean yesterday, looks like Friday - after the non-langpack deadline anyway
<slangasek> IIRC it was gfxboot last time that needed a last-minute update, yeah
<mantiena-baltix> cjwatson: yes, this is the second, last one was Ubuntu 9.04 ;)
<cjwatson> mantiena-baltix: it's possible there'll be an upload after RC to cover installer bugs that come up from ISO testing, and in that event there'll probably be a translation update too
<cjwatson> but I can't guarantee it
<mantiena-baltix> cjwatson: our translation leader accidentally introduced some translation errors just 10 days ago - that's why nobody noticed and didn't fixed these errors :(
<mantiena-baltix> some of these errors are just mistypes - for example "idegta" instead of "Ä¯diegta", but in lithuanian word "idegta" means burned, while Ä¯diegta"
<mantiena-baltix> means installed
<mantiena-baltix> So, currently Lithuanian users see this text in ubiquity "step 7": Your new operating system will now be burned with the following settings !!!
<proppy> doko__: thanks a lot for #560135
<joaopinto> mantiena-baltix, burned looks cool :D
<ara> mdz, bug 566536
<ubottu> Launchpad bug 566536 in launchpad-registry "Contact this team's members shouldn't spam indirect members" [Undecided,New] https://launchpad.net/bugs/566536
<joaopinto> Ubuntu on fire :)
<cjwatson> mantiena-baltix: well, sorry, but I can't help the timelines.  We'll do what we can if there's another opportunity, but if there isn't another opportunity then you may be stuck with it
<ScottK> Daviey: OK.  Thanks.  I'll look into it.  There were some changes in how logging works in the last upload.
<Daviey> ScottK: Yeah, i had a quick look.. pretty confusing how the logrotate file gets generated! :)
<ScottK> Daviey: Can you join #debian-clamav on OFTC?
<Daviey> ScottK: My initial thought is that $LogFile is NULL.
<Daviey> ScottK: done
<lool> doko__: Would it make sense to sync gcc-4.5 over to lucid?
<doko__> lool: ??? late April joke ???
<lool> doko__: Hmm no, in universe?
<lool> doko__: I didn't find mcuh regression potential and thought this might be useful
<doko__> lool: no, overwrites all shared libs
<doko__> lool: use gcc-snapshot
<lool> doko__: Ah, I thought gcc-defaults was masking all of that
<lool> but indeed, does not
<lool> doko__: So nm  :)
<doko__> or the ubuntu-toolchain/test PPA
<doko__> lool: but you can try to convince slangasek ;)
<lool> tss :)
<slangasek> pitti: bug #526354 - your pm-utils fix worked ;P
<ubottu> Launchpad bug 526354 in linux "[Dell Studio 1537] temperature sensors and fan stop working following suspend/resume" [High,In progress] https://launchpad.net/bugs/526354
<pitti> slangasek: right, that's what I meant with "ugly" :/
<pitti> slangasek: hiding the option in the session menu would require code changes in upower unfortunately
 * slangasek nods
<pitti> it doesn't call pm-is-supported, but reads /sys/power/state and greps for "mem"; nothing in between to hook into :?
<pitti> s/?/(/
<dholbach> chrisccoulson: happy birthday! :)
<chrisccoulson> thanks dholbach :)
<pitti> chrisccoulson: ooh, happy birthday!
<didrocks> happy birthday chrisccoulson
<chrisccoulson> thanks everyone :)
<seb128> chrisccoulson, happy birthday! ;-)
<mvo> happy birthday chrisccoulson
<nigelbabu> chrisccoulson, wow, birthday!  Happy Birthday!
<slangasek> chrisccoulson: hi, james_w tells me you might know something about the problems with updating sugar-browse-activity to 0.88?
<slangasek> chrisccoulson: oh, and happy birthday :)
<chrisccoulson> slangasek - thanks :)
<james_w> oh happy birthday chrisccoulson
<chrisccoulson> yes, sugar-browse-activity needs python-xpcom, which isn't packaged anywhere yet
<jhernandez> hi
<jhernandez> anyone knows where and when is generated /etc/fstab during installation, and if it is a file from a template or it is generated on-the-fly??
<seb128> slangasek, pitti: do you prefer small fixes to still go in the lucid queue for after RC approval or to be changed in SRU updates now?
<slangasek> seb128: is "small" a measure of their impact, or their diff size? :)
<smoser> slangasek, with keybuk not around, i will beg to you for a couple thoughts if you don't mind.
<smoser> bug 565018
<ubottu> Launchpad bug 565018 in cloud-init "instance is not reachable via ssh" [Undecided,New] https://launchpad.net/bugs/565018
<seb128> slangasek, things like the change on bug #475090
<ubottu> Launchpad bug 475090 in gdm "Karmic, Lucid: /etc/gdm/Xsession fails to source ~/.xsessionrc or apply ~/.Xresources" [Medium,Triaged] https://launchpad.net/bugs/475090
<smoser> slangasek, can you come up with any reason as to why one (or more) jobs set to start on 'filesystems' would correctly start, but one would not
<smoser> (this is hard to reproduce, somewhere like 2% maybe or less)
<seb128> slangasek, or http://git.collabora.co.uk/?p=papyon.git;a=commitdiff;h=5f9e7e0da5a89b80190087022a633eca7f7f2d8e
<seb128> slangasek, ie changes which are small in code change and limited risk but not fixing bugs which need to be fixed in lucid (ie things which can be sru-ed without issue)
<smoser> but the log i captured shows no evidence of this job ever being started, and the debug output occurs at the very top of 'cloud-init-cfg' that is execed from the job
<slangasek> seb128: I would say SRU for the first; I don't understand the impact of the second, but if you say it doesn't need to be fixed for final, Ithink SRU is best for that too
<seb128> slangasek, the second will lead to a telepathy-butterfly crash when receiving some messages from buggy clients
<seb128> slangasek, ok, I will start to put some sru material fixes in my upload queue and ping you if I've a fix which I think might be worth trying to get in lucid proper rather than a sru
<seb128> slangasek, thanks
<cjwatson> jhernandez: on the fly; the core is in partman-target
<cjwatson> jhernandez: though there's a partial template involved
<cjwatson> jhernandez: what do you want to know?
<jhernandez> thx for your response cjwatson
<jhernandez> ubiquity (or another package) creates a cdrom's line in fstab
<cjwatson> not any more in lucid
<jhernandez> i have pcs without cdrom
<cjwatson> http://launchpadlibrarian.net/38682219/partman-target_64ubuntu5_64ubuntu6.diff.gz
<slangasek> smoser: what job does the 'generating public/private rsa key pair'?
<smoser> the job listed there.
<smoser> cloud-config-ssh
<slangasek> ok
<smoser> (comment 4)
<smoser> as far as I can tell, it just doesn't run
<jhernandez> thz
<jhernandez> thx, cjwatson
<cjwatson> though I'm not aware that it ever created those on systems without CD drives; but it doesn't matter if it did, since that code is gone now
<jhernandez> i have my answers in the link above
<cjwatson> (i.e. I'm not going to debug it if it did create them on a system without a CD drive)
<jhernandez> okok
<jhernandez> lot of thanks
<jhernandez> :P
<slangasek> smoser: have you done the test with the upstart debugging turned on?
<smoser> i've been trying to get one
<smoser> as, yeah, i want that too
<smoser> and my scripts had some bugs so they failed to catch console output the couple times when the other stars were alignged
<ccheney> james_w: probably from what the description of xfonts-mathml itself says
<ccheney> james_w: " You will also need to install the packages: otf-stix (STIX fonts) and ttf-lyx (TeX's Computer Modern fonts) to view MathML properly.
<james_w> ccheney: yes, but it's talking about browsers, so I wondered if it was the same
<ccheney> james_w: oh, hmm i'm not sure i can dig around some more and see
<james_w> as it stands we have to promote the whole of lyx to satisfy it
<ccheney> james_w: eh, why?
<ccheney> james_w: ttf-lyx doesn't depend on anything other than defoma
<james_w> ccheney: xfonts-mathml recommends ttf-lyx which is in the lyx source package
<ccheney> there are lots of instances of binary packages that are split between main and universe, or did you mean it requires the source to be in main too?
<slangasek> ccheney: yes, the source
<ccheney> ok
<slangasek> MIRs are done on a sourceful basis; so all the review for main-worthiness has to be done up front
<ccheney> the person who filed the bug in debian seemed to indicate that probably xfonts-mathml is enough for OOo
<ccheney> which is already in main so we can probably safely ignore the ttf-lyx
<mvo> ccheney: hi, bad news. the OOo pre-depends are still causing some grief bug #566584 and bug #516727
<ubottu> Launchpad bug 566584 in apt "unpack/configure order violation triggered by OOo pre-depends" [Undecided,Confirmed] https://launchpad.net/bugs/566584
<ubottu> Launchpad bug 516727 in openoffice.org "breaks dist-upgrade: E: Couldn't configure pre-depend openoffice.org-core for openoffice.org-filter-binfilter, probably a dependency cycle." [Critical,Confirmed] https://launchpad.net/bugs/516727
<ccheney> mvo: the pre-depends was already fixed back to the way it used to be, can we just fix apt already? :)
<mvo> ccheney: well, that may not be feasible for -final, I would prefer a isolated workaround at this point than to change the apt ordering code
<ccheney> mvo: if i understand what you wrote in that bug report i need to remove the apt workaround in OOo to make it work for libgstreamer0.10-0 but then it fails later in the same upgrade cycle on something else for similar reasons?
<ccheney> oh nm i saw the add libxml2 to openoffice.org-evolution, not sure how i missed that
<ccheney> but you said it still doesn't fix the upgrade?
<mvo> ccheney: correct, I'm looking at it currently in a VM, but I have no real good idea yet. one obvious fix is to get rid of the pre-depends entirely, but as I understand _rene_ they are needed
<ccheney> yea
<mvo> ccheney: the other is to remove ooo-evolution, -emailmerge, -filter-binfilter on upgrade
<ccheney> the pre-deps as they were before the apt workarounds were needed
<mvo> and add them again afterwards
<mvo> but all is very not-cool
<ccheney> thats probably workable too but only would work assuming the people upgrading were following proper procedure :)
<ccheney> sounds like apt's pre-depends resolver is totally broken
<mvo> well, I would say "totally broken" given that it works as it is currently since a couple of year, but definietly broken when confronted with a pre-depdns line like the one from OOo
<ccheney> well it was initially rather simple unless i misunderstand it
<ccheney> just: openoffice.org-core (>= 1:3.1.0-2), debconf (>= 0.5) | debconf-2.0, procps
<dholbach> ccheney: I'm sure mvo would love to see patches to fix it ;-)
<ccheney> i guess the debconf part could have been complicated but it got confused on the openoffice.org-core part :)
<ccheney> so is it an issue with versioned pre-depends?
<ccheney> dholbach: hmm yea maybe i will have time to hack on it during maverick cycle
<mvo> ccheney: right, its openoffice.org-core  that ships a long list of depends
<mvo> ccheney: I don't think its the versionizing
 * ccheney wonders if its an interaction with installing recommends by default
<ccheney> mvo: i see something that might be causing it to be upset
<cjwatson> the extensive Conflicts in OOo seem likely to cause difficulties
<ccheney> mvo: the first depends in openoffice.org-common is: openoffice.org-style-default | openoffice.org-style  which has to be satisified by a virtual package
<ccheney> cjwatson: oh
<cjwatson> I haven't traced it, but that would be my first guess for any problem involving Pre-Depends when there isn't an obvious straightforward Pre-Depends loop
<ccheney> cjwatson: ok
<cjwatson> mvo is probably much further along than I am in tracing it so probably no point in me trying to figure out exactly where it is :)
<mvo> cjwatson: :) its a nightmare
 * ccheney hopes i can get some of those dropped by debian after the next debian release
<ccheney> slangasek: should i go ahead and do the new upload with updated pre-depends on wait for arm to build?
<ccheney> s/on/or/
<slangasek> ccheney: no need to wait before uploading; is this expected to go in before RC though?
<ccheney> slangasek: depends on if mvo thinks its important to make the RC for testing purposes I guess
<ccheney> mvo: ^ ?
<mvo> (on the phone atm, sorry)
<highvoltage> slangasek: hi! I'm not sure if stgraber pinged you about it already, but if there's resources available for it could you fire up another edubuntu build?
<slangasek> highvoltage: you two need to talk to each other more :)
<slangasek> highvoltage: edubuntu DVD is currently spinning
<highvoltage> slangasek: heh, thanks
<stgraber> slangasek: going to be fixed soon, he'll be moving from a continent away from me to the same office and the desk next to mine ;) That should avoid that kind of issues ;)
<slangasek> stgraber: hah :)
<slangasek> ArneGoetje: ttf-takao* are all in main for you; you said language-support-fonts-ja should be changed to depend on them?
<Damascene> hello, any progress on the desktop recording problem?
<ArneGoetje> slangasek: yep
<Damascene> https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/305286
<ubottu> Launchpad bug 305286 in ffmpeg "fails to playback ogv produced by recordmydesktop" [Medium,Confirmed]
<popey> Damascene: have you seen the comments on the bug?
<Damascene> yeah. have you seen me new one?
<Damascene> *my
<popey> Damascene: I suspect Reinhard is the only person who can do much about it
<Damascene> is it right that record my desktop uses theora not ffmpeg?
<popey> unless someone volunteers to do a bisect on all the changes in ffmpeg svn
<popey> Damascene: rmd doesn't need ffmpeg
<Damascene> I see. only the recent ffmpeg could fix the rmd bug by converting
<popey> its not a bug in rmd
<popey> its a bug in ffmpeg
<slangasek> ivoks: why is bug #562832 only 'medium'?
<ubottu> Launchpad bug 562832 in drbd8 "module drbd8 update kernel from 2.6.32-16 to 2.6.32-20" [Medium,In progress] https://launchpad.net/bugs/562832
<Damascene> popey, if rmd doesn't use ffmpeg how come it's a bug in it?
<popey> Damascene: its explained in the bug. rmd uses a newer version of the theora codec. the ffmpeg in ubuntu doesn't support those new features, but newer ffmpeg does. So it's a bug in the current version of ffmpeg shipped in ubuntu
<Damascene> yes
<popey> Damascene: however there are a _lot_ of changes between the version of ffmpeg in ubuntu and the version in upstream, and it's too late in the cycle for lucid to pull in a very new ffmpeg, so Reinhard has asked if someone could figure out the exact patch which fixes the problem
<slangasek> ivoks: (if it's only medium, it seems like it should be moved to SRU; if it's really high - such as if it makes it impossible to use the driver at all - then we can push it and respin server)
<Damascene> but that wont help with the youtube problem. google should fix their system
<slangasek> Daviey, superm1: are we ok with a respin of mythbuntu RC candidates to take this mythplugins library fix?
<superm1> slangasek, yes
<slangasek> superm1: thanks, accepted
<slangasek> bryceh, apw: bug #565415 is probably the same as bug #566379
<ubottu> Launchpad bug 565415 in xserver-xorg-video-intel "Can't boot after latest kernel image and plymouth update" [Undecided,New] https://launchpad.net/bugs/565415
<ubottu> Launchpad bug 566379 in linux "[i855] X doesn't start with kernel 2.6.32-21 unless passing i915.modeset=1" [High,Triaged] https://launchpad.net/bugs/566379
<bryceh> slangasek ok
<ccheney> mvo: still on phone?
<jibel> mvo, thanks looking at the double click thing.
<ivoks> slangasek: it can be uploaded post release
<slangasek> ivoks: well, it's currently in the upload queue; if it doesn't have a critical impact on the package, I'll reject that upload
<ivoks> slangasek: driver is usable unless you install a package on kernel you won't be using
<ivoks> slangasek: i wouldn't mind if it goes trough SRU, so it's your call
<slangasek> ivoks: ok, rejecting from the freeze queue, thanks
<ivoks> slangasek: np
<mvo> jibel: thanks!
<mvo> ccheney: so, given that we have no clear solution I don't think we can block RC for it, if anything I would upload a new update-manager that blacklists currentl openoffice.org-evolution until a workaround/fix is found
<mvo> ccheney: uploading with a revert of the pre-dep changes will just break it in a different way
<ccheney> mvo: ok
<ccheney> slangasek: see ^ :)
<slangasek> yeppers
<ccheney> if any major problems show up wrt OOo feel free to call me if you can't reach me on irc :)
<ccheney> i should be around on irc most of the time i awake though
<slangasek> ok :)
<mvo> I will investigate more when I'm back, but I need to leave for now
<slangasek> highvoltage, stgraber: edubuntu up, posted
<YokoZar> Is backslash special cased at all inside translations for .desktop files?
<stgraber> slangasek: yeah !
<hdon> my capslock light never turns on when i'm in a VT
<hdon> also switching to a VT from X doesn't update my capslock/numlock/scrollock lights
<cjwatson> yes, known casualty of fixing a different bug
<hdon> D:
<cjwatson> bug 425704
<ubottu> Launchpad bug 425704 in console-setup "[karmic server] Capslock don't turn on LED" [Low,Triaged] https://launchpad.net/bugs/425704
<cjwatson> (esp. comment 6)
<Daviey> pitti: Sorry for the delay with the mysql bug, i missed the bug update you did this morning.  Is it valid concern that those who are upgrading that explicitly installed 5.0 won't have an upgrade path?
<ScottK> Daviey: In general people should have the unversioned metapackages installed so they should get upgraded.
<Daviey> ScottK: I agree, but googling --> "apt-get install mysql-server-5.0" ubuntu <-- returns a non-trivial amount of results.
<ScottK> Live by the Google, die by the Google.
<Daviey> Live by Ubuntu mailing lists, die by ubuntu mailing lists
<Daviey> https://lists.ubuntu.com/archives/ubuntu-users/2007-December/131313.html
<ScottK> That too.
<cjwatson> sbeattie: debug instructions in bug 558382 now; TIA
<ubottu> Launchpad bug 558382 in partman-base "Partitioner throws "Unable to satisfy all constraints" when trying to use previously created partitions" [High,Incomplete] https://launchpad.net/bugs/558382
<sbeattie> cjwatson: thanks. I've tried to recreate it, but am not having any luck reproducing it.
<seb128> slangasek, pitti: if you have a chance to accept gtk2-engine-murrine before lucid please do it fixes a crasher collecting duplicates
<cjwatson> I've seen other scattered reports so I don't think it's isolated
<cjwatson> it may depend on exact partition sizes
<cjwatson> but it's in my "a bit scared to release with this" category
 * YokoZar didn't think it was possible for gedit to have an error on saving that causes you to lose most of your work
<smoser> hggdh, ping when you're around
<smoser> please
<lool> kirkland: around?
<lool> kirkland: my laptop is dying under kernel load, I suspect it might be ecryptfs related; is there a way to look at where memory is going?
 * lool really needs to reboot now
<lool> kirkland: So I suspect there's a resource leak somewhere; I'm unison-ing 1 GB of data every 5 minutes and after some days, my laptop grinds to a halt
<lool> kirkland: I rebooted now thought
<ccheney> in looking into why OOo didn't build on sparc it appears to not have built because glib2.0 didn't because someone blacklisted it or something similarly odd
<ccheney> "no really, you do not get to build glib2.0 here."
<ccheney> whats that mean?
<mdke> pitti: sounds fine
<seb128> slangasek, I just uploaded an openoffice.org-dictionaries update, resyncing a debian bug fix revision, let me know if that seems ok for lucid otherwise I will reupload with one one fix from there for the thesaurus install
<ccheney> seb128: oh you pulled it in? i was just waiting for it to get mirrored by debian, thanks! :)
<seb128> ccheney, why do you wait for it to be mirror when it's on incoming.debian.org? we can't sync anyway since we have changes!
<ccheney> seb128: was going to use grab-merge to do it, i thought it wouldn't be more than an hour or so before i could run that
<ccheney> iirc debian pulses a few times a day
<seb128> ok, I looked at that because I had a discussion with the debian maintainer about my previous change there and he let me know there was some thesaurus breakage so I synced that change
<seb128> let's see now if it slangasek thinks it's ok for lucid
<ccheney> seb128: ok thanks
<ccheney> seb128: look like the german fix in the new version is also useful, so hopefully we can just pull the whole thing
<cjwatson> ccheney: lamont did that - glib2.0 builds have been killing the sparc buildds
<cjwatson> (I don't know the details)
<ccheney> cjwatson: ah ok
<seb128> there is a bug about glib
<seb128> the testsuite is taking the sparc builder down for some reason
<ccheney> ok, thanks for the information
<lamont> ccheney: the glib2.0 build was causing the buildd to crash, and the manner was such that it just moved to the next buildd and killed it.
<lamont> and then people kept giving it back after I killed it with prejudice (rm -rf glib2.0-* mid build), so I raised it some more
<cody-somerville> apachelogger, You and Alessandro forgot to update the bzr branch for the xscreensaver package.
<ccheney> lamont: makes sense :)
<apachelogger> cody-somerville: sync'd, thanks :)
<lamont> ccheney: 'faure' is the machine you want to play on, fwiw
<cody-somerville> apachelogger, thanks! :)
<lamont> it was more the automated duck shoot that I was getting annoyed at
<LLStarks> mdz, is the place to ask about ubuntu-release team decisions?
<LLStarks> mark said the new ubuntu-sounds theme won't get into lucid unless you guys give the go ahead
<LLStarks> https://bugs.launchpad.net/ubuntu/+source/ubuntu-sounds/+bug/539169/comments/11
<ubottu> Launchpad bug 539169 in ubuntu-sounds "[FFe] Create "light" sound theme for Lucid" [Undecided,New]
<LLStarks> there's a new theme readdy to go
<elleuca> another late minute bug for lucid: #566909
<elleuca> https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/566909
<ubottu> Launchpad bug 566909 in empathy "Offline contacts not showed by default" [Undecided,Confirmed]
<TheMuso> LLStarks: Has Mark given the new theme the o
 * TheMuso reads the bug
#ubuntu-devel 2010-04-20
<TheMuso> ah I see.
 * TheMuso shudders.
<TheMuso> WHy do I hear Windows in this theme?
<jono> hey all
<LLStarks> themuso, there's a theme ready to go.
<LLStarks> people seem to like it
<TheMuso> LLStarks: Yes, I saw it in the bug.
<TheMuso> LLStarks: Count me out of that group. :)
<TheMuso> But it won't be up to me.
<LLStarks> mark isn't opposed to the theme
<TheMuso> But from that bug, I can't see that he has endorced it either.
<RAOF> That's not exactly a ringing endorsement :)
<TheMuso> RAOF: Exactly.
<elleuca> TheMuso, speaking about FFE, could you please take a look at empathy bug I've linked above?
<TheMuso> elleuca: If it needs approval, I can't give it that.
<elleuca> TheMuso, it needs some sort of coordination: by now there is a regression in a feature advised by canonical design team. Who can mark a bug as "blocker" for final release?
<TheMuso> elleuca: Hrm ok, kenvandine probably is the one who needs to look into it.
<bryceh> slangasek, got a sec?
<slangasek> bryceh: yep
<bryceh> slangasek, we've been debugging 8xx on lucid for a while now
<bryceh> we've been able to get it working well for some, but broken for others
<bryceh> and are in a situation where it seems fixing it for the latter just ends up breaking it for the former
<LLStarks> themuso, who should i speak to regarding the sound theme? who would be responsible for coordinating an implementation?
<bryceh> upstream is busily working on the issue but seems pretty insane - see http://cgit.freedesktop.org/~danvet/drm/commit/?h=stuff/i8xx_cache_coherency_for_oga&id=925114122c4bc9864951478e62169e9f34f9d41c
<bryceh> slangasek, so at this point we see two choices, and your opinion would be helpful
<slangasek> upstream seems pretty insane, or the bug does? ;)
<bryceh> a) disable -intel entirely and default to -vesa for this hardware.  People can still opt-into -intel via xorg.conf
<bryceh> b) ship the buggy -intel, and releasenote the issues, with a list of workarounds documented
<RAOF> slangasek: Have a look at the commit message :)
<slangasek> bryceh: how confident are you that VESA won't also break for some as-yet-unidentified subset of users?
<bryceh> one factor is when 10.04.1 rolls around, if we went with (a) we could consider turning -intel back on, but at this point it's hard to predict whether upstream will have a 100% working solution for you
<bryceh> slangasek, I'm not sure, but in part it's not whether it'll break things but to what degree
<bryceh> i.e. they'll lose 3D, proper modesetting, maybe video playback, etc.  Not sure whether suspend/resume works with vesa, etc. etc.
<bryceh> so... most likely they'll be able to boot and run Ubuntu enough to look for workarounds
<bryceh> enough to open gedit xorg.conf and try switching on intel ;-)
<TheMuso> LLStarks: I don't know who is responsible for choosing what goes into the theme, other than Mark. I will likely help with the technical implementation of it though.
<slangasek> bryceh: has there been subsequent feedback from users that the git commit you pointed to does *not* solve the problem for them?
<bryceh> slangasek, so few people have 8xx that getting solid representative testing has been challenging
<RAOF> slangasek: No.  The upstream bug reporters all report that this (finally) fixes it for them.  We haven't tried pulling it into an Ubuntu kernel yet, as far as I'm aware.
<bryceh> slangasek, the upstream bug report for this is at https://bugs.freedesktop.org/show_bug.cgi?id=27187 and the tail end of it is *not* filled with happy users saying all is well now
<ubottu> Freedesktop bug 27187 in Driver/intel "[i855GM] gtt chipset flush is not cache coherent" [Normal,New]
<slangasek> bryceh: right, which is one of my concerns with plan a) - if we do try to fix it in SRU, we might not get feedback on the regressions until it's a regression-update bug
<bryceh> slangasek, also the description of the patch does not fill me with confidence... he describes it as a hack that "probabilistically" tunes things so it behaves properly according to feedback from the testers so far.
<bryceh> slangasek, *nod*
<slangasek> bryceh: in which case, I would prefer (by a small margin) to ship it broken in release and release note it so that we can make incremental improvements in SRU with some degree of confidence that we're heading in the right direction
<slangasek> oh, though this change means turning DRM back on by default in SRU, doesn't it
<bryceh> you mean KMS?  I think that'd be orthogonal
<slangasek> er, you're right
<slangasek> ok
<bryceh> RAOF, your comments?
<slangasek> RAOF: and yes, that is a beautiful commit message
<bryceh> slangasek, but I think what we'd do is switch DRI back on in the -intel driver (it didn't work around the issues as well as we expected it to, and in fact some people claim it caused further regression for them)
<bryceh> with that patch dropped, the user could still toggle it on or off to experiment with if it helps them
<RAOF> If you think it'll be better to ship with known issues so it's easier to fix later, then I'll go with that.  We're not *really* sure how widespread this problem is, and it's not a deterministically triggerable bug anyway; getting sufficient testing in -proposed will be difficult if we go with vesa.
<slangasek> that's reverting the patch from 2:2.9.1-3ubuntu3 ?
<RAOF> Yes.
<slangasek> hmm, hate to turn that back on post-RC; also hate to respin all of RC for it
<bryceh> well, alternatively we could leave DRI off, and update the patch post-release to allow it to be configurable, although RAOF thought that could be difficult to code
<RAOF> Difficult to code without introducing an Ubuntu-specific xorg.conf option, which I didn't want to do in the initial patch.  If we're ok with that, then it won't be too hard.
<bryceh> RAOF, I don't have a problem with it
<slangasek> bryceh: let me get a feel for where things are with ISO testing; I think we're far enough along that I would prefer to have that DRI reversion made after RC, but still pre-release if we can
<bryceh> slangasek, ok
<bryceh> RAOF, the one thing would be if we add a parameter we'd need to make sure to include mention of it in the man page
<RAOF> bryceh: Right.
<bryceh> rickspencer3, ^^ if you're interested, new plan of attack being discussed for 8xx
<rickspencer3> I was watching
<bryceh> rickspencer3, your thoughts?
<rickspencer3> so basically, turn it back to the way it was before, and then let folks having trouble turn it back on?
<rickspencer3> well, turn off dri and kms
<rickspencer3> am I understanding it?
<RAOF> Yes.
 * bryceh nods
<rickspencer3> so then we ship a cleaner upstream configuration, and then update if there is something we know will help?
<rickspencer3> by "cleaner" I mean closer to upstream 2.0
<bryceh> basically we'd ship known-buggy 8xx support, with anticipation we may be able to improve things in SRU's and/or .1 updates, and document the heck out of workarounds
<rickspencer3> oops 2.9
<rickspencer3> bryceh, so, in total, it seems that the mitigations of disabling DRI and KMS made things worse, or at least not better?
<rickspencer3> is that your opinion now?
<bryceh> well I think we're quite far from "upstream clean" right now
<rickspencer3> right, thus the *er*
<rickspencer3> ;)
<bryceh> rickspencer3, my suspicion is that we shifted the problem rather than reduced it
<rickspencer3> like they are testing it with these turned off and such
<rickspencer3> ok
<RAOF> DRI doesn't seem to have made things significantly better, and also may have regressed things for others.
<rickspencer3> so my thoughts are:
<rickspencer3> 1. I think slangasek's gut it probably right about this, will take more time that we have to figure out something we *know* will help
<rickspencer3> 2. I trust bryceh's judgement about what's help, not helping, and RAOF backs it up
<rickspencer3> so, seems like a good plan if we still have time to implement it
 * rickspencer3 chalks up lesson of turning knobs, never seems to help xorg-server much
<bryceh> heh
<elleuca> TheMuso, thanks, I'll poke kenvandine
<bryceh> rickspencer3, sometimes it does
<slangasek> bryceh: ultimately, are we expecting to turn KMS back on for *all* the intel chips that have been blacklisted in the kernel, or just some of them?
<bryceh> rickspencer3, but you're right we're back in a similar situation as we were with -intel in jaunty with all those X freezes, and knob turning ain't doing it for us
<rickspencer3> it's like Jaunty, except the scope is *much* smaller
<RAOF> I don't think i830 has anything coming along the pipeline that would make us turn KMS back on for it.
<bryceh> slangasek, for 8.10 we'll have to.  Either that or stop supporting 8xx with -intel
<rickspencer3> and users of 8xx can back up to vesa, and have a respectable level of support consider the vintage of their hardware
<rickspencer3> AND there are previous releases that still work well for them
<RAOF> slangasek: So, no.  I don't think we'll be unblacklisting all of those cards.
<bryceh> rickspencer3, *nod*
<RAOF> slangasek: I've obviously interpreted that question differently to bryceh.  I don't think we'll be turning KMS back on *in lucid SRUs*.
<slangasek> bryceh, RAOF: ok, if we wouldn't be turning it back on for i830, that means trying to add /etc/modprobe.d/i915-kms.conf back wouldn't be the right solution
<slangasek> RAOF: ok - I wasn't sure if re-enabling KMS for i810 was related at all to fixing the problem
<bryceh> shall I go ahead and sketch out the release notes entry about this?
<RAOF> slangasek: For i855 it's entirely orthogonal.  I'm not sure that it's known what's needed for i845, and I'm not sure that anyone's *working* on i830 :)
<slangasek> ok
<slangasek> bryceh: written on the assumption that we're keeping intel enabled by default for release, and backing out the DRI patch?
<slangasek> (and giving users instructions on how to get to VESA?)
<bryceh> RAOF, you seem to already know what to do to add the config option to the dri patch, mind doing that part?
<bryceh> slangasek, that's correct
<RAOF> bryceh: Certainly.  We're going to keep DRI disabled by default, rather than backing out the patch entirely?
<bryceh> either backing out the DRI patch or making it more configurable
<slangasek> if we think that's where we're going to end up, I think we should back out the DRI patch rather than adding more knobs
<bryceh> RAOF, guess I missed the part of the discussion where we made that decision
<bryceh> slangasek, okie
<RAOF> bryceh: I did too :)
<bryceh> slangasek, ok sounds like a plan
<slangasek> it may cause a few more users to regress in final, but we have no idea how many, and it will let us converge more quickly on a resolution in SRU if we don't give them another knob
<RAOF> Yes.
<slangasek> everyone happy with this plan?
<RAOF> I wouldn't go so far as *happy*, but I don't think there is a better one.  +1
<bryceh> yeah +1 here too
<slangasek> ok
<slangasek> thanks, guys :)
<RAOF> In a related query - where does checkbox data go?  Could we mine that data to get a better idea of how widespread this problem is?
<slangasek> RAOF: if you brought your pickaxe
<RAOF> I have a trowel, will that do?
<RAOF> :)
<slangasek> bdmurray: ^^ who has the access / expertise to help with that?
<rickspencer3> oh man
<persia> RAOF: You want to catch cr3 to get that data.
<persia> slangasek: Are the changes for that likely to result in a new pre-release kernel upload?
<slangasek> persia: no
<persia> OK.  In that case I won't try to slip anything else in :)
<slangasek> I think you just did... :)
<bryceh> slangasek: short known-issue blurb added to https://wiki.ubuntu.com/LucidLynx/TechnicalOverview with longer blurb added at https://wiki.ubuntu.com/X/Lucidi8xxFreezes
<bryceh> RAOF, please review in case I got something wrong ^^
<slangasek> bryceh: could you please add it to https://wiki.ubuntu.com/LucidLynx/ReleaseNotes as well? (Tech Overview stops being used for errata at RC)
<bryceh> ok
<sbeattie> cjwatson: re bug 558382; it looks like libparted is segv'ing in libparted/label/dos.c on the added DEBUG_CONSTRAINT on the intersection variable.
<ubottu> Launchpad bug 558382 in partman-base "Partitioner throws "Unable to satisfy all constraints" when trying to use previously created partitions" [High,Incomplete] https://launchpad.net/bugs/558382
<rafiyr1> General g++ question.  We have a class which appears to have different sizes from the perspective of main and code within inherited classes.  Any thoughts as to why?
<RAOF> bryceh: We're not turning KMS back on by default for those cards, are we?
<bryceh> RAOF, no
<bryceh> RAOF, really it's too late to be making adjustments to the kernel
<RAOF> I'll fix up the freezes page, then.
<bryceh> thanks
<RAOF> (The instructions are currently i915.modeset=0 to turn kms back on ;))
<bryceh> slangasek: https://wiki.ubuntu.com/LucidLynx/ReleaseNotes updated
<bryceh> RAOF, doh
<slangasek> bryceh: thanks!
<bryceh> cut-and-paste fail
<bryceh> wow, CAB is still listed in the release notes
<RAOF> nomodeset no longer does anything, right?
<bryceh> RAOF, afaik
 * RAOF tests
<RAOF> That should be removed from the release notes, then.
<slangasek> bryceh: it's new since hardy... :)
<slangasek> nomodeset still works
<bryceh> slangasek, aha true
<slangasek> nomodeset just doesn't override an explicit i915.modeset=1
<bryceh> hmm
<bryceh> ok, well I should say I've sene people say nomodeset didn't work but i915.modeset=0 did
<slangasek> bryceh: that was before I uploaded xserver-xorg-video-{intel,radeon}
<bryceh> aha
<slangasek> to take out the explicit i915.modeset=1 ;)
<sbeattie> cjwatson: ah, yeah, at least the first time through _try_constraint(), ped_constraint_intersect() is returning NULL.
<ArneGoetje> bryceh: do you know if there had been any changes regarding i855 chipsets in the latest kernel update? -21 doesn't boot on my machine, while -20 is fine...
<RAOF> ArneGoetje: -21 disabled KMS.  Does booting with âi915.modeset=1â on the kernel line help?
<ArneGoetje> RAOF: I'll try
<bryceh> ArneGoetje, yeah we made some additional changes to try to get things working for more i8xx users
<bryceh> we weren't too successful
<bryceh> RAOF, ok that's one case so far where KMS actually made it work better
<RAOF> :)
<ArneGoetje> RAOF, bryceh: yes, turning KMS back on fixes it.
<RAOF> Hooray for -intel!
<bryceh> *sigh*
<bryceh> the -intel merry-go-round
<bryceh> ArneGoetje, ok thanks
<bryceh> ArneGoetje, not sure if we can update the kernel before release (or if we can, whether we want to) so take that as your workaround for now.  We've documented in the release notes about this.
<ArneGoetje> bryceh: ok, noted
<bdmurray> slangasek: if there is a hardware database query done for something I'm likely the best person
<bdmurray> slangasek: however, I'm heading out the door right now
<slangasek> bdmurray: ok - I think RAOF has a question for you about ancient intel chips, then
<RAOF> bdmurray: When you get back in :)
<ccheney> slangasek: wanted to check on the status of the openoffice.org-dictionaries package waiting?
<slangasek> ccheney: the status is "waiting" - is there a particularly urgent fix in there that would justify resetting all the ISO tests for RC?
<ccheney> slangasek: no, forgot about us already having spun the discs
<slangasek> ccheney: ok.  Do any of these changes affect binary package sizes?
<ccheney> heh guess i should have realized that as nothing new downloaded recently
<ccheney> slangasek: they shouldn't it just changed some symlinks so possibly a very tiny increase due to that
<ccheney> slangasek: seb128 did the actual build so he would be more aware of what the precise difference is
<slangasek> ccheney: debian/openoffice.org-thesaurus-fr.install - that doesn't look like symlinks, and seems to be the main fix people are after?
<slangasek> ccheney: since seb128 isn't around for several hours yet, would you have time to do a build test of that upload and let me know if openoffice.org-thesaurus-fr changes size and by how much?
<ccheney> slangasek: i'll look into it more but i was under the impression from reading what the involved parties said that it was an issue of it being installed with the wrong filenames or something to that effect
<ccheney> i can check to see
<ccheney> slangasek: is there somewhere i can download his merge from, or i can just redo it, should be fairly trivial
<slangasek> ccheney: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1
<ccheney> thanks
<ccheney> slangasek: alright will let you know what i find out, is deb size the most important thing to check or also installed size, etc?
<slangasek> ccheney: both unpacked and packed size are important to know
<slangasek> (even though "unpacked size" -> "size on liveCD" is a total fudge factor :/ )
<ccheney> ok
<un214> About my bug https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/564364
<ubottu> Launchpad bug 564364 in qemu-kvm "dpkg install should not assume any services are running. I had to do apt-get dist-upgrade in emergency mode and it broke because this service assumed it could do update-binfmt from a kernel this di..." [Wishlist,Confirmed]
<un214> I think I identified a way to know if dpkg "owns" the running kernel
<un214> not foolproof, but if our own /sbin/init is pid 1, dpkg probably does
<un214> easy to check as root by running stat on /proc/1/fd/exe and /sbin/init
<persia> un214: So, how do you know if the currnet /sbin/int is pid 1?  Especially, how can you tell when /sbin/init is binary-identical to /sbin/init outside the chroot?
<slangasek> ccheney: oh - it seems openoffice.org-thesaurus-fr doesn't land on any ISOs, so no need to double-check this after all - sorry for taking your time
<un214> dev/inode pair of /proc/1/exe will match if true
<un214> if not true, then even if binary identical some other dpkg owns kernel
<persia> un214: OK.  Now, to ask a more general question, why is this a bug in dpkg?  Why not in update-binfmt?  Should it not detect when the running kernel isn't the filesystem kernel, and perhaps not do something, or do it later?
<un214> I listed it as a bug in qemu-kvm
<slangasek> right, it's not a bug in "dpkg", it's a bug in the qemu-kvm maintainer script called by dpkg
<slangasek> (or, if triggers are involved, then in the package providing the trigger)
<un214> I'd be quite glad to provide a /usr/sbin/owns-running-kernel if you wish
<persia> Is it?  Or is it a bug in binfmt-support?
<un214> (the not foolproof case is a `uname -r` matching kernel with different options on rescue media)
<un214> persia: I'm not sure which
<slangasek> persia: ah - looking at it, yes, I agree it's binfmt-support
<slangasek> (but - most importantly - not dpkg :)
<persia> Yeah, dpkg isn't even in control at this point: it doesn't "own" anything.
<slangasek> OTOH, qemu-kvm-extras-static has a serious bug in its postinst, it calls 'start procps' :P
<un214> I can't even imagine what that would do
<slangasek> in a chroot?  it will fail miserably because 'start' tries to talk to a running upstart that it can't reach
<un214> in my case it would have found upstart, for the wrong architecture
<slangasek> the only stable interface for maintainer scripts to use currently is still 'invoke-rc.d procps start'
<slangasek> un214: isn't it running in a chroot?
<un214> with most stuff crossmounted
<persia> So two bugs: one against binfmt-support (should work in chroot) and the other against qemu-kvm-extras-static (should work in a chroot)
<slangasek> I don't think you can crossmount the control socket
<un214> mount -bind on the directory works
<slangasek> since it's a unix socket that's not exposed in the filesystem :)
<persia> At least it's not safe (or sane) to crossmount the control socket
<ccheney> slangasek: oh ok
<persia> slangasek: You could bind it to a fifo if you *really* wanted :)
<un214> if it's not in the filesystem how to programs open it?
<persia> un214: unix sockets have their own API
<slangasek> persia: hisssss
<un214> well if they're not in the filesystem how are they going to respect chroot then
<persia> un214: The basic rule is: don't use a socket in a chroot unless it's opened in the chroot.
<un214> figured that much
<un214> as you know schroot binds /tmp /proc /var/tmp and /home
<un214> and /dev
<slangasek> un214: they respect the chroot because they have a path which the kernel still interprets *relative* to the current process root, they just don't have paths that are exposed to 'ls' or trivially cross-mountable
<un214> hmmm
<un214> I'll have to go look up how that works (I'd have guess /proc/1/fd/X) personally
<un214> you did know that you can jailbreak if /proc is shared between jails and you have code as same user in both of them right?
<persia> That's just one of many ways.  Let's not go over them now :)
<un214> ok
<persia> But we ought make sure our maintainer scripts work in a way that it's safe to use them in schroot.
<un214> I offer the detect program if it would help you any
<persia> un214: Actually, what would help best is tracking down unsafe cases (like this one), and adding patches to make them safe to the bugs.
<persia> Extra points for getting more involved, and sheparding those patches into the releases, but just finding and fixing them is the key bit.
<un214> probably of me finding another is darn low
<un214> although I found the grub one awhile back
<persia> Most of us only use schroot to build packages, so things not build-dependencies of other things are often missed.
<un214> dist-upgrade inside schroot clobbered the system bootloader
<persia> grub and qemu-kvm-extras-static both fall into that category.
<un214> ah I use it normally
<persia> And it shouldn't, especially now that we have decent support for cross-arch schroots.
<persia> (at least for armel/powerpc on amd64 guests)
<un214> if I get just one more broken driver during apt-get dist-upgrade I'm going to run my whole system in schroot and use core drivers from slackware
<un214> I never could figure out any possible fix for the grub one as it actually needs to do that in some cases
<un214> incidentally, how to build against klibc?
<persia> Set your build depends differently.
<un214> ...
<un214> apt-get source klibc yielded a GPG error
<un214> public key not found
<slangasek> a warning, I'm sure
<un214> yeah warning
<un214> anyway looks like can't link against klibc correctly in the stock packages
<un214> or not, just installed funny
<un214> ugh too tired making stupid mistakes
<un214> good night
<Damascene> hi,
<Damascene> on offline system there is a need for the software list to be downloaded from ubuntu and then the "generate download script" function of synaptic will do the rest. is it possible to do so?
<Damascene> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378
<ubottu> Launchpad bug 251378 in synaptic "Synaptic's Generate download script does not update package lists" [Wishlist,Triaged]
<Damascene> is related
<slangasek> robert_ancell: simple-scan> this doesn't look critical for release; I'd like to redirect this to SRU
<robert_ancell> slangasek, sure, it is not critical
<slangasek> robert_ancell: ok - rejecting, please reupload to -proposed whenever you wish (but please open a bug report about the issue first, and link it in the changelog)
<robert_ancell> slangasek, it already is linked to a bug report...
<slangasek> robert_ancell: oh, was it?  Hmm, somehow I missed it in the debian/changelog then
<Damascene> on offline system there is a need for the software list to be downloaded from ubuntu and then the "generate download script" function of synaptic will do the rest. is it possible to do so?
<Damascene> https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/251378 is related
<ubottu> Launchpad bug 251378 in synaptic "Synaptic's Generate download script does not update package lists" [Wishlist,Triaged]
<mdke> pitti: around?
<mdke> pitti: nm
<pitti> Good morning
<pitti> mdke: thanks
<pitti> mdke: hello
<mdke> pitti: hi :)
<baptistemm> hello
<baptistemm> good morning
<mdke> pitti: I was going to ask you about a bug in pkgbinarymangler but then realised that there is already a report for it
<Damascene> hi, I've asked about providing update packages
<slangasek> mdke: hey - did you see pitti's question yesterday about disabling the "Report a bug" menu item, and whether this will impact documentation/
<slangasek> ?
<mdke> slangasek: yes, I said to him that it sounded fine
<slangasek> mdke: aha - sorry, was asynchronous so I didn't notice :)
<mdke> slangasek: nw. Is this the "Report a problem" help menu item in Gnome applications?
<slangasek> mdke: yes
<mdke> slangasek: ok, no problem
<pitti> mdke: we discussed disabling that on the last UDS, but I totally failed to notice the doc team about that; sorry about this
<mdke> pitti: not at all. We don't document bug reporting actually. there is something in the gnome user guide about it but it doesn't mention that menu item
<pitti> mdke: right, this is an Ubuntuism anyway
<pitti> (launchpad-integration package)
<mdke> ah, I see
<pitti> mdke: we'll keep the other two (get help online and translate)
 * mdke nods
<tseliot> pitti: can you approve my nvidia-96, please?
<tseliot> the source name is nvidia-graphics-drivers-96A
<tseliot> nvidia-graphics-drivers-96
<pitti> tseliot: not right now, sorry; this has to wait for post-RC or SRU
<joaopinto> good morning
<dholbach> good morning
<tseliot> pitti: post RC would be better as it's a rather nasty regression that will break at least dist-upgrades
<slangasek> tseliot: ah, a fix for that dratted bug that users kept blaming on gdm, excellent... :)  yes, I'll take that post-RC
<tseliot> slangasek: yes, that's the bug. Thanks a lot
<seb128> slangasek, those my one liner fixes you don't take but other change you do ;-)
<seb128> slangasek, hey btw
<slangasek> seb128: your one-liners for bugs you yourself marked as 'low'? :-)
<seb128> still would avoid me the sru paper work ;-)
<seb128> slangasek, btw are lucid-proposed uploads already queued?
<slangasek> oh, thanks for pointing out the flaw in our system - I'll design more paperwork for freeze exceptions >:)
<seb128> lol
<slangasek> AFAIK lucid-proposed is open, yes
<seb128> ok thanks
<slangasek> if uploading to it doesn't work, let me know
<Damascene> I guess you are busy with preparing lucid. so my bug need to wait. right?
<slangasek> Damascene: yes, at this time of the cycle most people you find around on IRC have their hands full with other bugs, sorry
<Damascene> ok
<Koterpillar> How do I make an init script not stop at powering down at all?
<pitti> Koterpillar: you mean to not get called on shutdown?
<Koterpillar> Yes, not to get called with stop on shutdown
<pitti> Koterpillar: do not install symlinks into rc0.d and rc6.d, i. e. do not call update-rc.d with 0 and 6
<Koterpillar> They are not there
<Koterpillar> In fact, for 0 and 6, there is neither S nor K link
<pitti> then the script doesn't get called
<Koterpillar> Let me check...
<Koterpillar> Well, the script doesn't get called, but someone kills the daemon it starts
<slangasek> Koterpillar: sure, /etc/rc6.d/S20sendsigs will
<slangasek> there are means for telling sendsigs to skip your process when shutting down, but that's rarely appropriate...
<Koterpillar> I want to do exactly that
<Koterpillar> So if I'm not an Upstart job, I should register with /lib/init/rw/sendsigs.omit.d/ ?
<pitti> slangasek: I uploaded a fixed pkg-create-dbgsym which fixes the missing glib 2.0 dbgsyms (bug 566602); it's all testcase'd, so I'm very confident in that it doesn't cause regressions; the package isn't on any CD/DVD, so it might be okay to accept it? (We'll upload another no-change glib2.0 build after RC then, to get the dbgsyms back)
<pitti> Koterpillar: yes, /etc/init.d/sendsigs most probably
<pitti> Koterpillar: if you have a daemon which needs to run until the very bitter end, you need to add its pid to /var/run/sendsigs.omit
<ubottu> Launchpad bug 566602 in pkg-create-dbgsym "does not build libglib2.0-0-dbgsym" [High,Fix committed] https://launchpad.net/bugs/566602
<cjwatson> sbeattie: the segfault itself is information :-)
<slangasek> pitti: looking
<pitti> slangasek: thanks
<cjwatson> sbeattie: actually never mind that comment, the segfault was during initialisation so not so relevant
 * hyperair wonders if a kind archive admin could look into syncing nautilus-share (Bug #565418)
<ubottu> Launchpad bug 565418 in nautilus-share "Sync nautilus-share (main) 0.7.2-13 from Debian Unstable" [Wishlist,Triaged] https://launchpad.net/bugs/565418
<pitti> hyperair: not right now, we are frozen for RC
<hyperair> pitti: ah. RC.
<ogra> mdz, do you still see OOM ? i seem to only get it while rhythmbox plays music here
 * ogra had a calm system for the last two days ... just started playing some music and OOM returned
<mdz> ogra, I've removed my Google Calendar feed and it seems OK now
<ogra> hmm, k, then i probably see a different bug here
<ogra> my load bumps above 4 if i change windows ... but i dont see any process consuming a lot of ram
<didrocks> I confirm that the google calendar feed is driving evolution nuts here too
<seb128> didrocks, what do you call feed in that context?
<didrocks> seb128: the calendar account
<seb128> didrocks, ok, I've that one configured but I don't notice issues there
<seb128> I don't have lot of things in my calendar though
<didrocks> seb128: I do have multiple calendars (personel and work one), trying to keep just one.
 * ogra dist upgrades to see if rhythmbox stops causing OOM
<ogra> seb128, did you hear about any bug relating the above (i havent found the root cause yet, but firing up RB makes it 100% reproducable for me)
<seb128> ogra: no, is that armel specific?
<ogra> i suspect ubuntuone being at fault
<ogra> seb128, nope, its my laptop
<seb128> ogra: try turning the store off maybe and see if that's still an issue?
<ogra> i commented a lot on bug 563879 to find out its likely a different one
<ubottu> Launchpad bug 563879 in evolution-data-server "evolution-data-server consumes massive amounts of memory, invokes OOM killer" [Undecided,Confirmed] https://launchpad.net/bugs/563879
<ogra> seb128, will do after the upgrade is run
<seb128> don't change to many parameters at one
<ogra> the confusing bit is that i cant seem to find anything that actually consumes memory
<seb128> ie maybe try without change after upgrade
<ogra> but oom clearly kicks in
<seb128> then if you still get the issue try without the store
<ogra> yes
<seb128> do you have free ressources when it kicks in?
<ogra> will do it like that and file a new bug if its still there
<ogra> yes, htop shows about 800MB being used (from 4G)
<ogra> top doesnt show any excerssive ram usage either
<ogra> i see my load bumping up between 4 and 5
<ogra> but no massive CPU or ram usage ...
<seb128> it's weird
<ogra> and after a while i see chromium tabs die
<ogra> looking at dmesg after that i see they die because of OOM
<seb128> do you run package installs during the same time?
<ogra> nope
<ogra> nothing special
<seb128> well that would explain io hits but not ram usage anyway
<ogra> i just have three terminals, about ten tabs in chromium, xchat, evo and rb open
<ogra> but as soon as rb is playing music my mouse is even hard to move
<seb128> weird
<ogra> gets jumpy and stuttering
<seb128> did you try run iotop to see if it lists something?
<ogra> not yet
<seb128> try that too
<jhernandez1> ogra, i usually have more than 20 tabs in chromium without problems
<ogra> i was somewhat on the wrong track looking at mdz's evo bug
<ogra> just to find it still happens if i kill all evo processes
<seb128> well that happens
<ogra> jhernandez1, yes, its not a chromium prob
<seb128> let's try to figure what the issue is now
<ogra> yeah, i'm waiting for the upgrade to finish
<ogra> 10min to go apparently ...
<ogra> i wasnt aware there were that many uploads since friday :)
<jhernandez1> okok
<lamont> so how do I tell whatever gnome is using to authenticate root access to ignore the fact that root has a password, and use sudo anyway?
<ogra> lamont, i think you cant do that easily with gksu apps ... policykit might be able to though
<ogra> so it depends on the app and whats in the .desktop file
<RAOF> ogra: You might be seeing an xorg-server bug where gem objects are leaked; they don't show up in normal memory acccounting.
<ogra> RAOF, triggered by what ?
 * ogra is curious how RB or pulse or anything in the audio stack could trigger that
<RAOF> Triggered by X apps rendering stuff, I think.
<ogra> hmm
<seb128> ogra: do you have effects on in rhythmbox?
<seb128> effects -> visualization
<ogra> then RB would have something thats special beyond other apps here
<ogra> seb128, i dont think so, and i fear to start it while the upgrade runs
<ogra> i'll check asap
<seb128> ogra: no hurry, what videocard, driver do you use?
<RAOF> ogra: bug #565981 would be what I'm thinking of.
<ubottu> Launchpad bug 565981 in xorg-server "[KMS] gem objects not deallocated" [Critical,New] https://launchpad.net/bugs/565981
<ogra> seb128, intel
<lamont> ogra: that makes me very sad
<lamont> don't want to give the family the root password, but do want them able to reboot their computer from the gui
<seb128> lamont, I don't understand your question
<lamont> seb128: sometimes, like say when fsck blows chunks, it's good to have a root password.  so there is one.
 * ogra sees vizualizer and art-display being active in gconf 
<seb128> right, but that shouldn't change the fact that desktop uses sudo by default
<slangasek> lamont: gnome reboots are done via policykit, not asking for a root password, TTBOMK?
<lamont> seb128: as a result, many of the gnome apps want the root password, rather than the users password for sudo, for authentication
<seb128> no they don't
<seb128> we use sudo
<lamont> slangasek: if this is fixed in lucid, awesome.  wife has been resisting the move from karmic so far
<slangasek> lamont: I think the issue you're seeing is that the user isn't in the admin group, so *their* password doesn't authorize them to policykit
<slangasek> oh, or if you're using ancient software, who knows :-)
<seb128> lamont, do you have a desktop software example?
<ogra> or debian packages in ubuntu :P
<lamont> seb128: whatever comes up with the 'machine reboot required'
<ogra> they all use su-to-root instead of gksu iirc
<lamont> slangasek: and you're right - she's not in admin
<lamont> slangasek: OTOH, NFW the kids are going in admin
<lamont> slangasek: which means I need to edit which file for policy kit changes on their machines?
<slangasek> lamont: policykit is infinitely tuneable; but don't ask me how
<lamont> too late
<slangasek> take it back, take it back!!
<lamont> ogra: you mentioned policy kit first.  ^^
<seb128> lamont, what do you want then? not giving them sudo access but still having their password working for admin tasks?
<ogra> lamont, there was a gui tool for managing polkit once ... not sure that still exists
<slangasek> seb128: for one, *specific* admin task... :)
<lamont> sudoers gives them access to the commands in question.  I want it to prompt for their password, not root's
<seb128> lamont, what software is that? gksudo prompts for their password I would think
<seb128> lamont, but polkit might not
<lamont> I'd like to still have them prompted, so they don't fatfinger it and yell at me for _that_
<james_w> lamont: the policykit-desktop-privileges might give you some idea of how to use the fine-grained controls to do what you want
<seb128> I was going to suggest that
<james_w> and pklocalauthority(8)
 * lamont gets his wife to get back to the prompt so he can look what's prompting
<lamont> meh.  and this time, it rebooted just fine for her from System/shutdown system
 * lamont will dig more once she's back in that state
<ogra> System/shutdown system ?
<seb128> you get asked when an another user is loged in
<ogra> heh
<seb128> there a known bug where cron tasks count as logged users
<ogra> i guess you are missing the right indicator thing here
<pitti> re from lunch
<seb128> lamont, ^
<lamont> well, it doesn't help that I'm generally logged into her computer
<ogra> System/shutdown system is the std gnome thing
<pitti> lamont: you get asked for auth when shutting down? that's weird
<seb128> lamont, well just log 2 users and try to reboot
<lamont> ogra: the problem child is the one that handles /var/run/reboot-required, I suspect
<pitti> ah, if there's another user logged in, then yes
<seb128> lamont, the said dialog is using polkit indeed
<lamont> heh.  fsck
<pitti> lamont: it's org.freedesktop.consolekit.system.stop-multiple-users privilege, FYI (/usr/share/polkit-1/actions/org.freedesktop.consolekit.policy)
<lamont> ok - I'll dig through policykit later then.
<pitti> you can allow that to any local user in /etc/polkit-1/localauthority.conf.d/ if you want
<seb128> pitti, he wants to allow some users polkit rights without giving them admin rights
 * ogra reboots after upgrade
 * ogra fires up RB
<ttx> ArchiveAdmins: please reject python-rackspace-cloudfiles from New, I'll upload a fixed one
<ogra> seb128, so after the update i cant trigger OOM anymore, but that might be because of fresh boot, i'll leave it playing for a while
<seb128> ok
<ogra> though RAOF seems to be on something here
<ogra> ogra@osiris:~$ cat /sys/kernel/debug/dri/0/gem_objects
<ogra> 1575 objects
<ogra> 623976448 object bytes
<ogra> after 10 mins running
<ogra> and its rising
<seb128> ogra: it could simply be that graphical changes trigger this gem issue and the rhythmbox bar changes every second if you are playing something
<ogra> yeah
<ogra> ogra@osiris:~$ cat /sys/kernel/debug/dri/0/gem_objects|grep "object bytes"
<ogra> 781213696 object bytes
 * ogra waits for the system to get choppy
<ogra> i think the fact that i dont have swap might also play a role here
<mdeslaur> ara: hi! regarding bug #524318, are you getting the en-us keyboard with existing vms or with new ones you create?
<ubottu> Launchpad bug 524318 in virtinst "Keyboard mapping is not correct in the guest" [Undecided,New] https://launchpad.net/bugs/524318
<ara> mdeslaur, mmm, existing, good point. I will double check with new ones
<mdeslaur> ara: cool, thanks!
<mdeslaur> ara: you can also simply remove the "Display vnc" component and add it back, and it should default to no keymap
<ara> mdeslaur, by the way, I am unable to use network boot in virt-manager now. it always says "no boot device"
<mdeslaur> ara: since 0.8.2?
<mdeslaur> ara: could you please file a bug with a couple of steps so I can reproduce it?
<ara> mdeslaur, I cannot be sure, I hadn't been using virt-manager since I filed that bug
<ara> mdeslaur, sure
<ara> mdeslaur, will do
<mdeslaur> thanks ara
<ara> mdeslaur, confirmed that no keymap is forced to en-us on new machines. I will set again to fix released. sorry for the noise
<primes2h> ev: mvo: Hello, a fix is available for this bug #535061, are you planning a package update soon by chance so it can be added?
<ubottu> Launchpad bug 535061 in humanity-icon-theme "Install and Startup Disk Creator icon is incongruous with the new Ubuntu icon set" [High,Fix released] https://launchpad.net/bugs/535061
<mdeslaur> ara: that's good news, thanks!
<mdeslaur> ara: when no keymap is specified, your localized keyboard works 100% in virtual machines, right?
<mvo> primes2h: a update to app-install-data-ubuntu?
<ara> mdeslaur, trying now
<primes2h> mvo: to both app-install-data-ubuntu and usb-creator
<ara> ubuntu
<primes2h> I mean
<mvo> primes2h: hm, usb-creator is more something for ev
<primes2h> mvo: you about app-install-data-ubuntu
<ara> wrong window :) nice my VM has no sensitive usernames or passwords :D
<mvo> primes2h: I plan to do another app-install-data update before -final
<mvo> (if the release team lets me :)
<ara> mdeslaur, working perfectly fine, thanks
<mdeslaur> ara: ok, cool. That was working for me, so I was hoping it was the right approach for all layouts. Thanks!
<primes2h> mvo: Ok, thanks! I hope to ;-)
<primes2h> mvo: just remember to write that bug down on your todo list ;-)
<mvo> primes2h: heh :) will do
<primes2h> mvo: btw, do you think that icon needs to be converted in png? it's a svg now
<mvo> no, that should be fine
<mvo> I think
<mvo> yeah, plenty of svg
<ev> primes2h: usb-creator> for lucid-updates, definitely.  I don't think it's critical enough to warrant a fix in the lucid release.
<ara> mdeslaur, I filed the bug about network booting as bug 567222
<ubottu> Launchpad bug 567222 in virt-manager "When selecting network as Boot device, I always get a "No bootable device" BIOS error message" [Undecided,New] https://launchpad.net/bugs/567222
<primes2h> ev: Sure, I just asked you to know if an update was on the todo list and then save time. ;)
<mdeslaur> thanks ara
<joaopinto> slangasek, are the "mountall: Plymouth command not found" messages showing up on VT 1 during boot expected ?
<slangasek> joaopinto: 'not found', or 'failed'?
<joaopinto> ops, sorry, failed
<slangasek> joaopinto: probably bug #559761
<ubottu> Launchpad bug 559761 in mountall "mountall needs to flush plymouth message queue before emitting upstart events" [High,Fix committed] https://launchpad.net/bugs/559761
<joaopinto> ok, tks
<MacSlow> where's the default locale for gnome/gdm stored?
<pitti> MacSlow: /etc/default/locale (that's for everything, not just for GNOME)
<pitti> MacSlow: older installations used /etc/environment
<MacSlow> pitti, hm... that's stating de and en, which would be ok... but I get "Afghanistan" as the default one... I 'm also not able to login using the root-prompt of grub
<MacSlow> pitti, for some reason my locale was changed when I updated my system by console-setup
<MacSlow> pitti, I'm trying to fix this since this morning
<pitti> MacSlow: are you sure about console-setup?
<pitti> recently my /etc/default/console-setup was scrambled by a dist-upgrade, but I haven't found out yet why
<MacSlow> pitti, I booted a liveCD to check the usual places... and even there I could ont find any mention of "Afghanistan"
<cjwatson> Afghanistan happens to be the first in alphabetical order
<pitti> MacSlow: it could just be the alphabetically first entry in the available list
<MacSlow> pitti, pure guessing on my side... I didn't pay much attention to the update-process... since I expected by now this would be harmless
<MacSlow> cjwatson, pitti: probably
<cjwatson> the only recent change in c-s was a translation update, though
<pitti> cjwatson: right, that's why I didn't quite believe that this was the culprit
<pitti> coudl be the existing magic in the postinst, of course
<MacSlow> cjwatson, pitti: I only don't get why even passing locale=de_DE on the kernel boot-options line doesn't even allow me to log in using grub's root-prompt
<pitti> I have changed /e/d/console-setup countless times while I was working on the keyboard fixes in gdm/gnome
<pitti> since nobody else complained I just scribed it off to my own stupidity
<MacSlow> cjwatson, pitti: if you've any trick up your sleeve to work-around this, I'd be more than happy to hear :)
<pitti> MacSlow: can you paste your complete /e/d/locale somewhere?
<MacSlow> pitti, that's going to take some time
<pitti> MacSlow: so your keyboard is fine, it's really your language whic his broken?
<MacSlow> pitti, but I can do that
<pitti> MacSlow: i. e. your system is in English now? (since I suppose you don't have language-pack-af installed)
<MacSlow> pitti, well... e.g. if I boot normally and switch from gdm to a VT... I cannot see anything I typed in at the login-prompt
<pitti> MacSlow: or s/paste/tell us how it looks/ -> it should at most have $LANG and $LANGUAGE
<cjwatson> MacSlow: I doubt that your login prompt is related to your locale problem
<cjwatson> s/prompt/problem/
 * MacSlow boots desktop-box via liveCD and mounts root-partition manually to get the /e/d/locale
<pitti> MacSlow: ok, where do you actually see "Afghanistan"?
<cjwatson> oh, unless you mean that you can't log in because the keyboard is horked
<pitti> MacSlow: at this point I think we need some more precise description
<MacSlow> pitti, it's written in italics in the language-selection of gdm
<cjwatson> MacSlow: "locale" is separate from keyboard layout, that's why that makes no difference
<cjwatson> try pressing alt+shift to toggle to US layout
<MacSlow> pitti, there's also USA and German
<pitti> MacSlow: on the left or middle combobox?
<pitti> MacSlow: "USA" is a keyboard layout, not a language
<MacSlow> pitti, middle
<pitti> MacSlow: ah, that _is_ the keyboard layout
<pitti> MacSlow: please check your /etc/default/console-setup
<pitti> I ended up with
<pitti> XKBLAYOUT="us,de"
<pitti> XKBVARIANT="nodeadkeys,nodeadkeys"
<MacSlow> cjwatson, pitti: rebooting
<pitti> i. e. it somehow duplicated the "nodeadkeys"
<cjwatson> unfortunately by the time this happens to somebody (/etc/default/console-setup broken) the evidence of why it happened has usually been erased
<pitti> which completely broke the keyboard
<pitti> and I'm fairly sure that console-setup's postinst had something to do with it, but I haven't had time since last Friday afternoon to investigate this thoroughly
<pitti> but now that it happened to someone else, it's probably time to do so
<MacSlow> pitti, cjwatson: pressing Alt
<MacSlow> pitti, cjwatson: pressing Alt+Shift at the gdm-screen doesn't seem to change the keyboard-layout (I still see my text-entry cursor on the right side of the GtkEntry)
<pitti> on Friday I tried apt-get install --reinstall console-setup a couple of times, but weren't able to replicate the breakage
<MacSlow> odd...but logging in worked
<MacSlow> phew
<MacSlow> at least I'm back at my normal desktop
<MacSlow> pitti, cjwatson: now checking things (and pasting) should be a lot easier
<pitti> MacSlow: ok, please give output of grep ^X /etc/default/console-setup
<MacSlow> pitti, https://pastebin.ubuntu.com/419258
<MacSlow> pitti, there's the af
<MacSlow> pitti, I guess I change that to de again?!
<pitti> eww
<pitti> yes
<pitti> but this is completely different breakage than what I had
<pitti> MacSlow: but regardless of that you should have been able to change the layout in gdm
<MacSlow> pitti, anything else?
<mdz> ScottK, Riddell: any update on https://wiki.kubuntu.org/Kubuntu/UpdatesPolicy for the TB meeting today?
<Riddell> mdz: not as yet I'm afraid
<MacSlow> pitti, I could change it... but only the hint regarding Alt+Shift made it possible to login again (although the GtkEntry still rendered text being entered from right-to-left)
<pitti> MacSlow: saving your /var/cache/debconf/config.dat could come in handy for post-mortem debugging
<mdz> cjwatson, any update on libfaac? does it need action before 10.04?
<pitti> MacSlow: and the current (i. e. broken) version of /e/d/console-setup
<mdz> cjwatson, ah, just saw your email, never mind
<MacSlow> pitti, do you want both files via email?
<pitti> uh, I do see a potential gotcha there -- /var/lib/dpkg/info/console-setup.postinst seems to overwrite the default file with values from debconf
<mdz> pitti, cjwatson won't make it to TB, and I don't know about Keybuk (he's UTC-7 still). are you planning to attend?
<pitti> MacSlow: better attach them to a bug
<MacSlow> pitti,
<pitti> mdz: I am, yes
<MacSlow> ok
<MacSlow> pitti, against which package should I file it? console-setup (if that's even a package)?
<pitti> MacSlow: that'll do for now, yes
<lool> Would someone please sync libhildonhelp from unstable to fix its FTBFS in Ubuntu?  (it's in universe and not on any ISO)
<lool> I can't get requestsync to take it from Debian for some reason
<MacSlow> pitti, prio: High?
<lool> v 2.0.5-4
<pitti> MacSlow: I don't know the scope of this yest
<pitti> yet
<cjwatson> mdz: it's next on my guilt list after this horrible partitioning bug - but I don't see anything in the archive with the prohibited linkage
<cjwatson> so since my impression is that it seems to be distributable but not co-linkable with ffmpeg, I think 10.04 is OK.  But I will check
<MacSlow> pitti, you can change it later anyway
<cjwatson> pitti: overwrite> it's complicated, and has installer tentacles
<cjwatson> even if it is broken, if it's more or less a corner case my inclination would be to leave it as it is for 10.04
<pitti> cjwatson: yeah, that's why I asked about saving config.dat, so that we keep the traces
<pitti> cjwatson: *nod*
<cjwatson> mdz: won't make it> sorry again - am buried in thousand-line debug files full of sector numbers :-/
<mdz> cjwatson, no worries. there's nothing urgent on the agenda, and we may end up skipping it if we don't get a quorum. 10.04 is higher priority as usual
<mdz> cjwatson, let me know if you want another pair of eyes
<pitti> cjwatson: I'm still not able to replicate it, though; it by and large seems to work fine
<cjwatson> mdz: thanks.  at present, bringing somebody else up to speed would probably lose time but I'll see how it goes
<MacSlow> pitti, cjwatson: LP: #567254
<ubottu> Launchpad bug 567254 in console-setup "console-setup overwrote my default language "de" (German) with "af" (Afghanistan)" [Undecided,New] https://launchpad.net/bugs/567254
<MacSlow> pitti, cjwatson: if you need further info about it, just tell me
<pitti> MacSlow: thanks for filing
<MacSlow> pitti, cjwatson: I'll reboot and see if everything is back to normal (also the input-direction of GtkEntry at the gdm-screen)
<seb128> cjwatson, ev: ubiquity used to ask if you really want to continue when typing a weak password and doesn't now, bug or design choice?
<ev> seb128: design choice
<seb128> ev: thanks
<ev> seb128: it now lets you know inline if your password is weak
<seb128> right, I'm not sure if it used to do both, I though it was showing the info but still asking for confirmation before so I figured I would ask to check
<mdz> directhex, /join #ubuntu-meeting if you're around
<ScottK> mdz: Not yet.
<alexp_sssup> hi everyone, I'd like to ask if there is any documentation about including new projects in the core ubuntu. I am the maintainer of the lightspark project (which is a modern flash player implementation). In the current status lightspark is good enough to render youtube videos, even the Flash10 version that are totally not supported by gnash. I think my project has a great potential, and I'd...
<alexp_sssup> ...like to start working to get it into the next ubuntu release in 6 months.
<mdz> directhex, minutes sent to ubuntu-devel and TeamReports
<directhex> mdz, okay, ta. btw your latest blog post has a broken <a>
<mdz> directhex, another one?  I fixed one already
<directhex> ah, planet hasn't noticed
<thebishop> https://lists.launchpad.net/asus-ul30/msg00125.html -- is there an official bug for this issue?  I searched and didn't see one
<thebishop> can't tell if it's a problem with all Intel 4500MHD, or just the Asus UL line
<Ng> thebishop: bug #538648
<ubottu> Launchpad bug 538648 in xserver-xorg-video-intel "[gm45] Irregular sync flashes with compiz on (Lenovo T500)" [Medium,Triaged] https://launchpad.net/bugs/538648
<thebishop> Ng, the symptoms sound very similar, but i can confirm that it happens without compiz
<thebishop> Ng, in the list discussion i pasted, they suggest it's a problem with DRM
<Ng> thebishop: I'm not sure, I'm just one of the people affected by the bug :)
<thebishop> Ng, when it's not happening, this seems like a great release of Ubuntu... haha
<thebishop> when it happens in succession, i want to cry
<awilkins> Is the DRM a different thing to Digital Rights Management, I'm seeing the acronym a lot in things like kernel logs and not really believing that Linux is in league with the MPAA?
<cjwatson> Direct Rendering Manager
<cjwatson> http://dri.freedesktop.org/wiki/DRM
<cjwatson> the acronym clash is slightly unfortunate
<geser> pitti: because it's not very clear for me from the summary about "syncing from testing": how should I set the default in requestsync for maverick: sync from unstable or sync from testing?
<pitti> geser: it's not yet clear to me either yet :) there doesn't seem to be a strong preference either way, but I think we should go back to unstable, since (1) maverick is that post-LTS "crack" release, and (2) Debian will freeze soon
<barry> james_w: any chance you're around?  i have a question about bzr import-dsc cli options
<james_w> hi barry
<barry> hi james_w.  i think there's a discrepancy about the --distribution option to import-dsc.  the online docs say 'bzr import-dsc --distribution debian .../scruff.dsc'
<barry> james_w: but 'bzr import-dsc --help' does not mention --distribution, and import-dsc doesn't accept that option
<barry> james_w: it also doesn't let me say 'debian' as the first arg
<barry> james_w: so, is it still necessary to specify the distribution when doing import-dsc?
<james_w> barry: I think the docs are out of date
<barry> james_w: ftr, i am trying to sync the latest debian package with an ubuntu package
<james_w> barry: and the lp:debian/* branch isn't up to date?
<pitti> "Accepted tzdata 2010i-1" -- oh no, not again
<barry> james_w: ah, it might be
<barry> james_w: it is.  i'll merge debian->ubuntu using that.  but just ftr, is the distribution unnecessary for import-dsc now?
<james_w> barry: yes
<james_w> barry: just committed to correct the docs, thanks
<james_w> all that matters now is which branch you commit it on to, if you commit it on to what you consider to be the "debian" branch then you are saying it was an upload to Debian
<james_w> it's all in the interpretation though, and there is no data stored about that any more, so we don't need the argument
<james_w> I should have deprecated it rather than removing it though, sorry
<barry> james_w: no worries, that's fine.  so if i'm working on an ubuntu branch and want to pull in the debian dsc (say, lp:debian isn't updated yet), then it will Just Work?
<james_w> you should grab the lp:debian branch, import the package on to that, and then merge the result
<james_w> if you import the debian upload on to the ubuntu branch then it won't merge any Ubuntu changes
<james_w> shortcuts you may see in that description are there for the taking if you want
<barry> james_w: gotcha. thanks.  thanks again for a great tool.  i added a link on the wiki page to the file:/// docs - there's lots of excellent material there. :)
<james_w> great, thanks
<mkarnicki> I want to file a bug report about Remote desktop settings window. against what package should I file it?
<ArneGoetje> slangasek: I'd like to drop the xfonts-wqy dependency from language-support-fonts-zh-han{s|t}, since wqy-microhei and wqy-zenhei are more popular nowadays than the bitmap font. Is it okay to get that change in for Lucid? I would submit it to the queue together with the language-support-fonts-ja update...
<nigelb> mkarnicki, Next time, asking #ubuntu-bugs, where you might get a faster response.  the package is vino.
<mkarnicki> nigelb: noted. thanks!
<slangasek> ArneGoetje: there doesn't seem to be much practical benefit to dropping the dependency for lucid, the packages are only on the DVDs?
<ArneGoetje> slangasek: except reducing the amount to download for Chinese users
<slangasek> ArneGoetje: hmm, true; though it's a 6MB reduction vs. a 21MB download - if you can download 15MB, is downloading another 6MB that burdensome?
<ArneGoetje> slangasek: heh... we can leave it for maverick, no problem
<slangasek> ArneGoetje: ok, let's do that :)
<ArneGoetje> slangasek: ok, then I'll upload the changes for language-support-fonts-ja now.
<slangasek> ArneGoetje: cheers!
<ArneGoetje> slangasek: uploaded.
<ArneGoetje> slangasek: fontconfig changes in language-selector will follow later tonight
<Keybuk> slangasek: too many bugs are fixed/worked around by putting plymouth back into the initramfs :-/
<joaopinto> Keybuk, before filing a a wishlist bug, shouldn't initctl have an enable/disable service command, or you don't thin is the proper place to do it ?
<Keybuk> yes, it should
<cody-somerville> cjwatson, for LP #567270, which seed would I add the package to?
<ubottu> Launchpad bug 567270 in live-installer "[MIR] live-installer" [Medium,Fix committed] https://launchpad.net/bugs/567270
<ogra> supported /me thinks
<Keybuk> joaopinto: bug #94065
<ubottu> Launchpad bug 94065 in upstart "init: add non-destructive means to disable a job" [Wishlist,Invalid] https://launchpad.net/bugs/94065
<Keybuk> slangasek: oh, wow, I just saw your patch on plymouth@l.fd.o - awesome
<Keybuk> slangasek: do the watch-for-keypress stuff still work then if show-splash isn't called first?
<joaopinto> Keybuk, ah, great
<Keybuk> joaopinto: I'm basically thinking that services can be in one of three modes
<Keybuk> automatic
<Keybuk> manual
<Keybuk> upgrade
<Keybuk> in automatic mode, Upstart manages their life time
<cjwatson> cody-somerville: supported-installer-common
<Keybuk> in manual mode, only "start" and "stop" etc. will work
<Keybuk> in upgrade mode, nothing works
<joaopinto> upgrade means locked ?
<Keybuk> yes, locked out for a package upgrade
<Keybuk> "this software is being changed on disk - don't touch it"
<cjwatson> ogra: few packages go in supported directly any more
<Keybuk> upgrade may mean the service is stopped when you put it in that mode
<ogra> cjwatson, yeah, i just noticed that there are more fine grained files now
<Keybuk> or may mean that the service is locked (won't respawn, failures not reported) and restarted when unlocked
<Keybuk> may offer both
<ogra> i havent looked at seeds for a while
<cjwatson> it was a nijaba thing for hardy
<ogra> ah
<ogra> (at least not beyond desktop and netbook files)
<joaopinto> Keybuk, is there an option to start a service but blocking it from emitting events ? It could be useful when you want to try a specific job individually
<Keybuk> joaopinto: not sure that would work
<Keybuk> that would mean, for example, the pre-start and post-stop scripts wouldn't get run
<joaopinto> I need to get more familiar with upstart scripts first, but I guess you may want to test a specific job without triggering the subsequent events chain
<joaopinto> without having to manually edit the script for that
<bladernr> Can anyone tell me if there is a way to determine whether a system has woken from suspend-to-ram via a specific method (either keypress, acpi alarm, or WOL packet received?)
<bladernr> hoping -devel is the right place to ask
<joaopinto> Keybuk, bug 530179, isn't a bit abusive to set the bug as duplicate when the person clearly reported that mountall failed to mount the filesystem ?
<ubottu> Launchpad bug 530179 in mountall "[lucid] Adding vboxsf in fstab stops boot process (dup-of: 507881)" [Medium,Incomplete] https://launchpad.net/bugs/530179
<ubottu> Launchpad bug 507881 in plymouth "Plymouth doesn't show messages sent before the splash screen is visible" [High,Fix committed] https://launchpad.net/bugs/507881
<joaopinto> as he commented later, the issue is not only about the missing prompt (the duplicate bug) but the fact that the filesystem was not mounted
<joaopinto> Keybuk, do you mind if I set the bug to incomplete and try to reproduce it and collect more data ?
<joaopinto> virtualbox is available from the repositories, even if it's not a mountall bug it may apply to a universe package
<joaopinto> actually /sbin/mount.vboxsf is available from a package, now let's see if it mounts on boot
<adiroiban> bdrung: hi, can you review a MP for ubufox or should I ask asac ? it's regarding bug 564589
<ubottu> Launchpad bug 564589 in ubuntu-translations "ubufox "about window" badly translated to pt-BR" [Undecided,In progress] https://launchpad.net/bugs/564589
<genii> Could anyone please tell me what values correspond to what states in /sys/bus/usb/devices/*/power/autosuspend  file? I can't seem to find this info anyplace
<bdrung> adiroiban: i think asac is the right person for that, because he is upstream.
<adiroiban> bdrung: ok. thanks
<crimsun> genii: -kernel, really. Anyhow, static int usb_autosuspend_delay = 2;           /* Default delay value, * in seconds */
<crimsun> genii: drivers/usb/core/usb.c
<genii> crimsun: OK, thanks
<highvoltage> qense: did you perhaps add my name next to debian-installer on https://wiki.ubuntu.com/BugSquad/AdoptPackage#Small%20and%20Medium%20Packages ?
<qense> highvoltage: if your name is there it was there already when I pasted the list from the old page
<highvoltage> qense: ah ok. I can't remember doing that but I'll subscribe to the bug mail and go through it's list of known bugs, I guess I might as well adopt it fully :)
<qense> highvoltage: If you'd want to do that, please do so.!
<asac> adiroiban: done
<adiroiban> asac: thanks :)
<josip> Hello, I am not sure if this is right channel to ask the question, so I hope it won't mind you if it isn't. Is there a nobackfill patch for ubuntu lucid?
<Keybuk> joaopinto: sure, if you want to debug it go ahead
<Keybuk> though it's definitely not a mountall bug, so change the package to none
<joaopinto> Keybuk, already identifyed the problem
<Keybuk> what is it?
<joaopinto> it depends on a kernel module which is loaded later
<joaopinto> which is provided by an univer package
<Keybuk> ah, fail
<joaopinto> I just left mountall because I am not sure how it should be handled from a packaging perspective, I mean, for the other package
<joaopinto> are kernel modules loaded before mountall ?
<Keybuk> no
<Keybuk> we have no boot phase where "kernel modules are loaded"
<joaopinto> ok, so currently there is no support for modular filesystem support ?
<joaopinto> ops, redundancy :P
<Keybuk> it's up to the module to arrange for itself to be loaded
<Keybuk> usually this is something like:
<Keybuk>   SUBSYSTEM=="block", ENV{ID_FS_TYPE}="...", RUN+="modprobe ..."
<Keybuk> but that only applies where the block device is visible
<Keybuk> it may be as simple as the virtualbox stuff needs an upstart job
<Keybuk>   start on starting mountall
<Keybuk>   exec modprobe vboxsf
<joaopinto> ok, I will add that o the bug report and remove mountall
<joaopinto> does "starting" guarantee that the job is invoked prior to the mountall start, or is it executed in parallel ?
<Keybuk> I've already commented to that effect
<Keybuk> guarantees provided it also uses "task"
<Keybuk>   start on starting mountall
<Keybuk>   task
<Keybuk>   exec modprobe vboxsf
<Keybuk> is probably more correct ;-)
<joaopinto> ok, this is also a good change for my first upstart job :)
<joaopinto> chance
<joaopinto> is Debian using upstart already ?
<ScottK> ccheney: Did you run into something like Bug 567536 before?
<ubottu> Launchpad bug 567536 in update-manager "Upgrade failed due to OOo predepends problem" [Undecided,New] https://launchpad.net/bugs/567536
<ccheney> ScottK: probably haven't looked yet, but mvo is having to work around it in update-manager as it appears to be some sort of really hard to fix bug in apt pre-depends resolving
<ccheney> ScottK: and fixing it in OOo is non-trivial, we added one thing to help and then it needed another, etc
<ScottK> ccheney: I got that bug using update-manager, so whatever it is, seems to be incomplete.
<ccheney> ScottK: i'm not sure if mvo has applied the change yet, aiui he was going to make it uninstall binfilter along with some other bits and then reinstall after the upgrade process
<ScottK> THanks.
<ccheney> np
<ScottK> I'll paste that in the bug then.
<trijntje> Hi all, are any empathy developers present? I'm translating empathy but i'm not sure about the meaning of some strings
<joaopinto> Keybuk, http://pastebin.com/5tMKVZZz, looks sane ?
<Keybuk> yeah though lose the script/end script
<Keybuk> also worth adding -b to the modprobe call
<Keybuk> so that it can be blacklisted without modifying the job
<slangasek> Keybuk: yes, the keypress watches are installed unconditionally already, they don't look for show_splash
<Keybuk> slangasek: what's looking for the key presses then?
<Keybuk> I thought the terminal and keyboard, input, etc. weren't created until a renderer is loaded
<Keybuk> (on show splash)
<slangasek> Keybuk: oh, you were asking whether the keypress would be /registered/ before splash was up - no, sorry
<slangasek> so /proc/bus/usb is still going to be a problem
<svu_> pitti, ping?
<Keybuk> *shrug*
<Keybuk> either we put plymouth in the initramfs
<Keybuk> or just release note that you should check your /etc/fstab
<ion> Could we check fstab on upgrade?
<joaopinto> a broken fstab resulting in an unbootable system looks really bad
<ion> (Re: his quit message) Are getdeb packages still packaged so that maintscripts create and delete stuff in $HOME/Desktop etc? :-P
<joaopinto> ion, don't worry, they don't hurt more than a random Ubuntu package
<ScottK> If that's true, it's progress.
<joaopinto> the "be respectful" is not something that comes easy to everyone
<joaopinto> good night
<ScottK> joaopinto: You site used to recommend removing all getdeb packages before upgrade.  I didn't check if it still does.
<ScottK> So my statement is nothing but factual.
#ubuntu-devel 2010-04-21
<slangasek> smoser: I guess bug #567392 is the one causing you eucalyptus problems?  how fast does libvirtd run out of fds?
<ubottu> Launchpad bug 567392 in libvirt "__virExec:362 : cannot create pipe: Too many open files" [High,In progress] https://launchpad.net/bugs/567392
<slangasek> ttx: ^^ kirkland asked this fix to be considered for RC; that means respins of ubuntu-server, and ubuntu and kubuntu DVDs
<smoser> slangasek, well, its not the only thing.
<smoser> but it leaks 1 per start/stop
<smoser> so 1000 instances ends up hitting the default fd limit
<smoser> (of 1024)
<slangasek> and are users are going to go through 1000 instances between the time it takes us to release RC and the time it takes us to push the fixed libvirt for final?
<lifeless> slangasek: the canonical UEC instance probably will
<smoser> slangasek, i think probably not.
<smoser> slangasek, its also extremely easy to fix
<smoser> if you just 'sudo restart libvirt-bin' on the node controllers
<slangasek> the limit is per-node-controller, yes?
<smoser> right
<smoser> thats why dustin (with 3) or the UEC in our data center (with a more than that) never saw it, but i did with my measly 1 node controller
<slangasek> lifeless: ^^ 1000 instances on a single NC, in 2 days?
<smoser> my guess is that number would be high for a single phsyical node even on amazon.
<smoser> to me its unrealistic other than testing
<lifeless> slangasek: well, the dx hudson does lots of fairly short builds, and its only one user. I may be being alarmist.
<slangasek> lifeless: ok; I still think we're better off just pushing it immediately post-RC, rather than eating up another 10 tester-hours of time to revalidate
<lifeless> slangasek: works for me; was just adding data.
<slangasek> lifeless: appreciated :)
<slangasek> directhex: should I be expecting to see that indicator-application upload in the freeze queue?
<directhex> slangasek, someone else uploaded it, whereupon it built but failed to upload
<directhex> Subject: 	[Build #1699116] i386 build of indicator-application 0.0.19-0ubuntu4 in ubuntu lucid RELEASE (directhex PPA)
<directhex> Date: 	19/04/10 13:12:58
<slangasek> directhex: eh, I meant to the Lucid archive, not to a PPA
<directhex> was that a PPA upload? i must've gotten confused
<slangasek> it says PPA in the subject, so I assume so :)
<directhex> ah, so it was. serves me right for not naming PPA uploads with a ppa version number
<directhex> so "oops"
<directhex> i'll upload now
<slangasek> cheers :)
<directhex> dputted
<directhex> now i should go to bed
<slangasek> Keybuk: bug #507881> what changed your mind about a blacklist of /proc/bus/usb in mountall being viable?
<ubottu> Launchpad bug 507881 in plymouth "Plymouth doesn't show messages sent before the splash screen is visible" [High,Fix committed] https://launchpad.net/bugs/507881
<directhex> Rejected:
<directhex> Signer is not permitted to upload to the component 'main'.
<directhex> slangasek, ^^
<directhex> anyway, bed
<slangasek> directhex: ah; put it somewhere for sponsorship?
<ajmitch> hopefully it's the one in his PPA now
<slangasek> ajmitch: hmm; probably, but I'm not going to guess - it can wait till he's back
<rickspencer3_> slangasek, seems like you might know this ...
<rickspencer3_> is there a way we can get a list of "stuff" in Ubuntu that uses /usr/lib/libglitz-glx.so.1
<rickspencer3_> ?
<slangasek> rickspencer3_: apt-cache rdepends libglitz-glx1
<rickspencer3_> thanks slangasek
<slangasek> rickspencer3_: that works because /usr/lib/libglitz-glx.so.1 is shipped in the aptly-named libglitz-glx1 package; if it had been in a package with other libraries, acquiring a precise count would be more involved
<ScottK> Do we have any kind of policy that suggests one should replace Vcs-foo fields in debian/control with XS-Debian-Vcs-foo fields?
<slangasek> I'm not aware of a policy
<ScottK> I'm wondering because the topgit upload in the queue has such a change.
<ScottK> It seems to me something we shouldn't just randomly do.
<slangasek> I think it's good /practice/ to move the fields aside when they don't point at something corresponding to the package in question
<ScottK> Corresponding exactly or generally?
<slangasek> but since there's no policy on the name to change it to, and practice has varied, I always fail to do it myself
<slangasek> ScottK: exactly, IMHO
<ScottK> OK.
<slangasek> if I can't find the current package revision in the referenced Vcs-*, the field shouldn't be there
<ScottK> Perhaps then update-maintainer should also remove such fields.
<ajmitch> it's something that's happened for awhile on some packages
<slangasek> I think that would be good
 * ScottK makes a bug.
<slangasek> it won't have the desired result for Vcs-Git if Debian and Ubuntu share a git repository, but the Vcs-Git fields are inappropriately underspecified anyway
<ajmitch> I suspect it's done from a desire that 'apt-get source' not give the wrong information
<ScottK> Seems like overkill for minor deviations to me, but OK.
<slangasek> well, I'd like it to be automatable via update-maintainer, and in the absence of such automation haven't been doing it :)
<ScottK> Bug filed.
<ScottK> Maybe someone will feel inspired.
<ajmitch> Making it point to the proper ubuntu branch could be done
<ajmitch> e.g. Vcs-Bzr: http://code.launchpad.net/ubuntu/+source/apache2
<ajmitch> requestsync isn't liking me today, is the job that updates the version of debian packages in LP having a bad day?
<ScottK> Doesn't requestsync use rmadison?
<ajmitch> I didn't check what it uses for looking up the version of packages in sid
<ajmitch> it's just a new debian revision of gpt that I want synced to fix a FTBFS, nothing major
<ajmitch> looks like it does use the information on LP for the version (which is out-of-date)
<ScottK> Nice.
<ajmitch> I should just create the bug the old-fashioned way, I tested that it built
<slangasek> ajmitch: unless devs are explicitly committing to the ubuntu bzr branch, I don't think it makes sense to tag it in debian/control; debcheckout et al could just be modified to look there by default
<Keybuk> slangasek: huh?
<Keybuk> I've never thought a blacklist of usbfs is viable
<Keybuk> I think that's stupid
<Keybuk> adding any workaround just for that means we're basically working around bad advice given on ubuntu forums
<Keybuk> and that sets a dangerous precedence :P
<psusi> Keybuk, I just got e2defrag working with extents ;)
<psusi> Keybuk, also I was looking at the ureadhead code today... I need to go test it now because I decided to try converting the hda readahead to multithread like ssd.. that should put a stop to that big block of zero IO during all the sequential open() calls
<Keybuk> oh, interesting
<Keybuk> would love to see the before/after blktrace of that!
<psusi> well, combined with defrag it should be one gigantic sequential read ;)
<psusi> even with the threads sending down requests a bit out of order, they should get combined and ordered in the queue by the elevator
<psusi> and if a thread has to block waiting on a directory or indirect block read, the others can queue up a few more reads to be batched
<kirkland> slangasek: i concur that that upload can be pushed post RC
<kirkland> slangasek: basically ttx and I decided to leave that one in the hands of the release team
<kirkland> slangasek: as such, it was only a "proposal" for RC inclusion
<cody-somerville> How odd. When trying to stream mpegs with Firefox and libtotem-cone-plugin.so I get the codecs needed dialogue and then when I click search for codecs it tries searching for the "text/html" codec, lol.
<ScottK> Probably not included due to patents.
<ScottK> ;-)
<rickspencer3> slangasek, hello
<slangasek> Keybuk: oh; well, you certainly were /discussing/ a blacklist of usbfs, apparently I misunderstood your position on it.  I guess that brings me back to my assertion that blocking virtual-filesystems on unknown nodev mounts doesn't make sense
<slangasek> kirkland: hmm, but you marked it for -updates; I was thinking we would still want to grab that in post-RC, no?
<slangasek> (between RC and final)
<kirkland> slangasek: if that were acceptable, yes
<kirkland> slangasek: i assumed we wanted to keep as much unchanged as possible between RC and GA
<kirkland> slangasek: so i started prepping these as SRUs
<slangasek> we do, but that seems like a case where the risks and rewards are well scoped
<kirkland> slangasek: libvirt -- yes, i think so;  very clear fix, IMHO
<kirkland> slangasek: in this case, shall I re-target at 10.04?
<slangasek> kirkland: yes, please
<kirkland> slangasek: cheers
<Keybuk> slangasek: I can't remember why it does
<Keybuk> mountall needs a test suite
<Keybuk> because apparently I didn't add that line of code
<Keybuk> ion did ;)
<slangasek> ah
<slangasek> ion: ping
<Keybuk> I think it's more that it's a creeping thing
<Keybuk> it was added to avoid filesystem checks
<Keybuk> and crept up to mean more as the code changed
<ion> What did i break? :-P
<Keybuk> oh, nothing
<Keybuk> was just trying to work out why "none" in the device column makes a filesystem hold up "virtual-filesystems"
<slangasek> ion: right, ^^ that - since any problem with such an fstab entry means you can never boot, because of a circular dep between plymouth-splash up to skip the broken fs, and virtual-filesystems
<Keybuk> but yeah
<Keybuk> looks like it just crept up the code
<Keybuk> it'll probably break something to remove it of course
<Keybuk> but it's that kind of code
<slangasek> Keybuk: can you think of any specific bugs you would expect us to need to guard against if changing that, or is it just general nervousness about a late change?
<Keybuk> nervousness
<Keybuk> though the worst that should happen is that anything with "none" as a device becomes local
<Keybuk> so it just means it won't hold up virtual-filesystems
<Keybuk> and appear on plymouth
<Keybuk> so it's probably ok
<slangasek> I think there are few possible bugs that would both escape notice during testing *and* be worse than a boot hang that can only be resolved with init=/bin/sh
<Keybuk> but I keep saying that
<Keybuk> and the world burns
<Keybuk> last time I patched mountall, Iceland exploded
<slangasek> oh, I thought Iceland exploded as a pre-consequence of you and jiboumans inventing teleportation to get home
<Keybuk> I did a tech talk on Monday
<nixternal> pfft, that volcano has nothing on jono after eating white castle
<Keybuk> I started off with "thankyou for inviting me to be here, and thank you for setting off a Volcano in Iceland to make sure I could do it"
<Keybuk> (tech talk at Google)
<slangasek> heh
<Keybuk> slangasek: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mountall/lucid/revision/320
<Keybuk> knock yourself out
<Keybuk> if the world burns, I'll deny all knowledge and claim you forged the commit message to make it look like it came from me
<slangasek> right :)
<nixternal> irc logs are like cockroaches though, they will survive
<slangasek> still need to fix the plymouth flush code so we can do that final mountall upload
<Keybuk> nixternal: those can be edited
<Keybuk> the only thing I can't do is get home
<nixternal> that would be a lot of editing though....
 * nixternal locks down rsh and ssh
<nixternal> can't edit mine!
<nixternal> hahahahaha
<nixternal> i can edit your logs, i just can't get home!
<ScottK> nixternal: Don't say that to the guy that writes your boot loader
<Keybuk> nixternal: init --version
<Keybuk> see where it says "Written by" ? :)
 * slangasek grins
<nixternal> doesn't say Written by anywhere
<nixternal> so foo on you :D
<slangasek> Keybuk: btw, bug #567592 doesn't look very nice; I thought this was fixed in mountall 2.13
<ubottu> Launchpad bug 567592 in plymouth "rm: cannot remove `/var/lib/urandom/random-seed': Read-only file system" [Undecided,New] https://launchpad.net/bugs/567592
<Keybuk> slangasek: that's fixed
<lucas> a
<lucas> oops
<slangasek> Keybuk: hggdh reports it with a uec image that has mountall 2.13 in it
<ion> keybuk: The r87 commit message says âdonât queue filesystem check when device is "none"â but the code checks whether type is "none". My r100 actually adds the line to make the change r87 appears to have intended. I canât seem to remember what specific case of device being "none" caused a problem.
<Keybuk> yeah
<kirkland> slangasek: Keybuk: that was today's image
<Keybuk> but I reckon that log is "conveniently edited"
<kirkland> where today = yesterday now
<Keybuk> ion: yeah, I just propogated that behaviour up
<kirkland> latest at the time, anyway
<Keybuk> I would expect that it's *failed* to mount /
<Keybuk> e.g. mount or fsck returned an error
<Keybuk> rather than got bored
<slangasek> mmk
<Keybuk> the bit at the end of the comment implies that
<Keybuk> in that case, it has to either skip or start a shell
<Keybuk> it doesn't start a shell, since then it might overlap with X or getty or stuff
<slangasek> Keybuk: at the end of which comment?
<Keybuk> #3
<Keybuk> "and mountall refused to mount / (more correctly, refused to remount it rw)."
<slangasek> well, that's just a restatement of the log line: | mountall: Skipping mounting / since Plymouth is not available
<Keybuk> that to me sounds more like Scott is trying to tell us mount failed, not mountall didn't try
<Keybuk> yes, but what I mean is that there's mount errors missing here
<Keybuk> --debug might be telling (since it will tell us the exit codes)
<Keybuk> but I'm pretty convinced this is a case where mount -o remount,rw / has failed
<Keybuk> not a case of mountall got bored
<slangasek> ok
<Keybuk> nothing mountall can do there ;)
<Keybuk> that's why we have plymouth - to ask the user
<slangasek> going to be nontrivial to confirm that this is the case, I guess
<Keybuk> --debug should prove it
<slangasek> it's non-trivial to edit an upstart job to set --debug in the UEC image
<Keybuk> they should make that trivial ;-)
<slangasek> heh
<zyga> mvo: morning
<mvo> hi
<zyga> mvo: I signed up to the software-center+pkgcon sprint on UDS
<zyga> I'm looking forward to that :-)
<pitti> Good morning
<joaopinto> good morning
<dholbach> good morning
<mvo> hey dholbach
<dholbach> hey mvo
<amitk> slangasek: have you had a chance to look at bug 563618?
<ubottu> Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged] https://launchpad.net/bugs/563618
<slangasek> amitk: no; that's going to have to be post-rc, regardless
<slangasek> amitk: and I'm still trying to fight my way up through the stack of plymouth/mountall bugs
<amitk> slangasek: ack, thanks.
<slangasek> Keybuk: so, that change seems to make mountall fail at mounting /tmp
<trijntje> What would be a good place to find someone knowledgeable about empathy to ask the meaning of some strings?
<joaopinto> slangasek, about the vboxsf issue, it might affect other packages providing filesystems support via kernel modules, maybe a warning message should be sent ?
<slangasek> joaopinto: a warning message where to whom?  The vboxsf init script was clearly buggy anyway, even before mountall it would be running way later than the mount scripts
<joaopinto> slangasek, to -motu or something like that :) I assuming there are other packages providing such modules, which were working on karmic's boot order and will fail now
<slangasek> joaopinto: frankly, if there are other packages like that (and I don't know why there would be), either the people who care about them have already noticed or there are no people that care about them so I wouldn't expect broadcasting to the developers to have any effect
<joaopinto> ok :\
<IntuitiveNipple> Testing Alternate CD for PowerPC (2010-04-19), installer reports failure during "Install and Setup software" but I can find no mention of errors in the logs, and running the next step (install yaboot) continues on without apparent problems (so far). Are there any logs I should capture to investigate this in either the chroot /target or the installer ?
<persia> /var/log/syslog (outside the chroot) is often interesting
<IntuitiveNipple> Thanks, I'll save that into the /target/ to look at later
<IntuitiveNipple> I'm just testing a boot from the installed system now, to find out if anything did mess up
<persia> IntuitiveNipple: There's a "Save Debug information" option from the main menu, which will save all the files you need.
<IntuitiveNipple> Oh yeah! thanks for reminding me :)
<slangasek> Keybuk: hmm - this code already special cases fuse mounts?
<IntuitiveNipple> persia: OK, looking at the running installed system, it looks as if the failed step was where the choice of meta flavour (ubuntu-desktop, etc.)  should have been offered. The installed system only has ubuntu-minimal. Nothing in the logs to give a clue though. I'll repeat the install to see if it is reproducible, and report a bug if so.
<phuang> hi
<phuang> my PPA seems be locked. all build failed by uploading failed
<phuang> Here is one build. https://launchpad.net/~shawn-p-huang/+archive/ppa/+build/1701077
<phuang> anyone can help me?
<cody-somerville> phuang, Not here. Go to #launchpad for help with PPAs.
<phuang> cody-somerville, thanks
<dholbach> wgrant: HAPPY BIRTHDAY! :)
<wgrant> dholbach: Thanks!
<directhex> slangasek, i uploaded the final indicator-application package to one of my PPAs, but i'm getting more "failed to upload"s following successful builds - "Lockfile /var/lock/process-upload-buildd.lock in use"
<wgrant> directhex: That should be OK now.
<wgrant> directhex: When did it fail?
<wgrant> LP had a couple of crises over the past hour or so.
<directhex> wgrant, few minutes ago
<directhex> 2010-04-21 08:37:29 DEBUG   Lockfile /var/lock/process-upload-buildd.lock in use
<wgrant> Hmmmmm. Concerning.
<directhex> Build #1701095 and #1701096
<james_w> happy birthday wgrant
<wgrant> directhex: Which PPA? Build IDs are only useful if I also know the archive.
<wgrant> Thanks james_w.
<directhex> samarium and iridium for 96
<directhex> osmium for 95
<wgrant> directhex: should be OK now.
<wgrant> Cascading failures FTW.
<directhex> wgrant, can you rescore the builds?
<slangasek> Keybuk: ok, /tmp sorted - needed to poke a bit so the placeholder handling code was still happy
<wgrant> directhex: I have no privileges beyond MOTU.
<wgrant> So, no.
<directhex> boo
<directhex> i386 build seems to be happening now anyway
<free> hi! I have python-specific packaging question
<persia> free: Which one?
<free> I have a package whose postinst depends on python-pycurl, and that fails when upgrading from hardy to lucid because the python-pycurl package in hardy is compiled against Python 2.4 and APT decide to upgrade it *after* my package
<free> persia: ^^^
<free> so one solution would be to explicitely depend on a specific python version like Depends: python2.6-pycurl
<StevenK> Or depend on python-pycurl (> (Hardy's version))
<free> but having a lot of python dependencies that seem a bit sub-optimal, I was wondering if there is a better alternative
 * persia likes StevenK's suggestion
<free> StevenK, persia: yeah, the only thing is that I have to do that manually for all my python dependencies
<free> and maintain that
<persia> The other option is to adjust the maintainer script to work also with python2.4-pycurl
<free> StevenK, persia: I see, I think I'll eat the bullet and go for versions thanks!
<Chipzz> free: isn't that exactly what Pre-Depends is for?
<cjwatson> no, it is not
<free> Chipzz: you Pre-Depends if you need a package to be fully installed and configured even before APT tries to unpack your package
<slangasek> I think Bob the Angry Flower needs to get his gimp on and speak out about Pre-Depends
<directhex> use a trigger!
<james_w> free: does the package depend on python-pycurl at all currently?
<free> james_w: it does
<free> james_w: more details on bug #563063
<ubottu> Launchpad bug 563063 in landscape-client "Problem with pycurl dependency during upgrade from hardy to lucid" [High,In progress] https://launchpad.net/bugs/563063
<james_w> free: I don't have that call in my copy of the postinst, is it not in the lucid package yet?
<free> james_w: it is, but that is kicked in EC2 instances when starting the service from the postinst script
<tseliot> pitti, slangasek: any opinions on bug #567699 and #567690 ?
<ubottu> Launchpad bug 567699 in nvidia-graphics-drivers "Ensure nvidia package works in future for PAE kernel installs" [Undecided,New] https://launchpad.net/bugs/567699
<ubottu> Launchpad bug 567690 in fglrx-installer "Ensure fglrx package work in future for PAE kernel installs" [Undecided,New] https://launchpad.net/bugs/567690
<pitti> tseliot: hm, getting the right kernel headers indeed has always been a problem; I just don't understand why adding another alternative makes any difference here?
<persia> tseliot: If you7re doing that, could you consider all the *other* available flavours?
<pitti> doesn't linux-headers-generic-pae provide linux-headers?
<tseliot> persia: that's my point
<tseliot> pitti: yes, I think it does
 * tseliot doubts that there's a way to get this right
<persia> There isn't a way to get it right.
<persia> The closest would be to catch when the available headers and the running kernel differ, and offer to install the matching headers for the user.
<persia> (this is also true for all dkms-based packages)
<tseliot> can you add some comments in the bug report, please?
<pitti> then I don't really understand how that could help in the slightest
<pitti> tseliot: no, there isn't; we can't express "we need the same kernel header flavour as the installed kernel" in dependencies
<pitti> we could only check that in dkms/jockey at most
<pitti> *nod*
<pitti> tseliot: commented; I guess we should duplicate the bugs and reassign to jockey/dkms
<pitti> bah, except that LP times out on me
<pitti> ah, it's my backup rsync run of doom, which makes my internet connection useless
<tseliot> pitti: thanks
<pitti> (comment went through now)
<tseliot> persia, pitti: thanks for your comments
<yofel> short question: how do you tell upstart to boot to runlevel 3?
<yofel> (from grub if possible)
<joaopinto> yofel, guessing from reading /etc/init.d/rc-sysinit.conf, you can use the runlevel number on the linux kernel line
<joaopinto> ops, init, not init.d
<yofel> ah, thanks for finding that
<cjwatson> yofel: you know runlevel 3 isn't what it means on RH-based systems, right?
<cjwatson> yofel: on Debian-based systems, runlevels 2, 3, 4, and 5 are identical by default, and left to the sysadmin to customise; in particular runlevel 3 does not mean "boot without graphics" by default
<yofel> cjwatson: I know, but I wanted to test something later and couldn't find if that's still possible
<cjwatson> ok, it's just a common confusion so I thought I'd mention it
<pitti> slangasek: hm, I think I need a second opinion about bug 566046
<ubottu> Launchpad bug 566046 in gnome-keyring "the login password is stored in the user's keyring" [High,In progress] https://launchpad.net/bugs/566046
<pitti> slangasek: I now have a patch which stops adding the user's password to the keyring, and removes it on upgrade as well; but it potentially breaks this "user.keystore" feature (which I haven't found out how to use it at all)
<pitti> slangasek: so the question is whether we put it into lucid final to stop spreading cleartext passwords and sort out the possible breakage later in SRU, or whether we do one big and upstream approved fix later on in -updates
<pitti> slangasek: upstream didn't respond at all yet, and at this point I need his input
<slangasek> pitti: is the password stored encrypted or decrypted on disk?
<pitti> I tested it thoroughly on new users, existing users with and without the password, and normal keyring operations (passwords for empathy accounts, and the like)
<pitti> slangasek: encrypted
<pitti> slangasek: but since the keyring gets unlocked during login, every process can retrieve the cleartext through g-keyring
 * slangasek nods
<slangasek> but in practice that's only a problem if you have a malicious process running as the user, right?
<pitti> it's not _such_ a big deal, given that every other password for your web accounts, wifi networks, etc. can also be gotten from the keyring c
<pitti> but the security team seems to be quite eager about it
<pitti> slangasek: correct
<pitti> if the user isn't logged in, there's no way to get the passphrase
<slangasek> pitti: then I think I would prefer SRU
<pitti> slangasek: ok, my feeling as well, thanks; I'll get an ack from security team for this, too
<cjwatson> Keybuk: bug 554009 seems to be a regression from your wait-for-root work
<ubottu> Launchpad bug 554009 in initramfs-tools "Resume from disk (swapfile) fails" [Medium,Triaged] https://launchpad.net/bugs/554009
<simmel> I'm creating a Ubuntu package and I am currently using .install files to copy some files on install. There is one file though that I ONLY want to install if it doesn't exist (otherwise, just leave the original file be), can someone point me in the right direction to do this?
<simmel> (sorry if this is the wrong channel, redirect me elsewhere if possible)
<cjwatson> simmel: erm - you mean, only if it doesn't exist on the user's system when they come to install the .deb?
<persia> simmel: Adding a conditional to debian/rules is likely easiest ([ ! -f foo ] && install -m ...)
<cjwatson> simmel: if so that sounds like an odd requirement.  Could you go into specifics?
<simmel> cjwatson: No, only install one of the files in the package if the files doesn't exist.
<persia> simmel: At package creation time, or at package install time?
<cjwatson> doesn't exist where?
<cjwatson> specifics would help if you can :)
<simmel> persia: Ok, but then I would have to remove it too when the package is uninstalled, right? package install time.
<cjwatson> isn't that what I said, and you said no?
<persia> simmel: Why do you want to do this?  Which file?
<cjwatson> the reason we're asking these questions is that there are various possibilities and the best one depends on why you're trying to do this.
<simmel> It's a post-install configuration file. For host specific configurations that that is applied to configurations of certain applications (think: user/passord/server to connect to)
<cjwatson> make it a conffile, then?
<persia> Or don't ship it, and then create it in the postinst (e.g. postfix main.cf)
<cjwatson> if it's a conffile, dpkg will prompt the user if there's a conflict.  if you don't want that (although consider the consequences of your configuration file never being upgraded unless you go to some effort ...), then creating it in the postinst would work
<lamont> interesting.  postfix {main,master}.cf aren't registered as conffiles... something tells me I should fix that
<simmel> Is the conffiles like package-name.install?
<simmel> I mean, do they behave in the same way?
<Chipzz> just wondering; isn't #ubuntu-motu normally used for packaging questions?
<persia> lamont: Should main.cf be a conffile?  Depending on what one does with the postinst, it may never be generated (No Configuation).
<lamont> persia: if generated, it should confess
<simmel> cjwatson: Can I somehow in the package specify that dpkg never should prompt? (like always use the one that the user already has or such)
<persia> Chipzz: The answering of packaging questions was distributed to all development teams as part of Archive Reorganisation.  #ubuntu-packaging exists as a catch-all for random packaging that any team doesn't want to support (e.g. PPA work, work on derivatives, etc.)
<Chipzz> oh, when did that happen?
<persia> Early February or so.
<Chipzz> I recall users being redirected to #ubuntu-motu up to a couple of months ago
<persia> Yeah, that matches my timeframes :)
<Chipzz> s/users/packaging questions/
<simmel> Chipzz: motu meaning what?
<persia> simmel: conffiles is just a way of marking certain configuration.  If you install stuff to /etc it gests marked as conffiles by default.  There's no way short of maintainer scripts to never bother the user.  If it's host specific data, I'd recommending finding a formal you know will work for all eternity, and then separating that from the rest of the configuration, to ease updates of the non-host-specific configuration.
<simmel> persia: It is seperated (in a seperate file and folder atleast).
<simmel> Thank you persia and cjwatson for your time and answers. I will take this information up with my colleges and chose which one of the two suggested solutions we will take. Next time I will ask in #ubuntu-packaging
<simmel> err, choose
<persia> Then create it in postinst based on user's answers to questions *OR* ship an empty config as a conffile and detail how to add to it in a README (depending on the risks/implications of having it just run with the install-time supplied credentials)
<persia> (or even, ship an empty config as conffile and modify it in postinst)
<mdeslaur> pitti: take a look at bug #567879
<ubottu> Launchpad bug 567879 in gnome-keyring "gnome-keyring no longer enforces application permissions" [Undecided,New] https://launchpad.net/bugs/567879
<seb128> urg, the new gnome-keyring is a fail, we should have stayed away from it for lucid
<tfried2001> sad face
<mdeslaur> pitti: actually, never mind, I just closed the bug.
<seb128> mdeslaur, was that the prompt which was judged confusing rather than useful and dropped upstream due to that?
<mdeslaur> seb128: well, the security value of it was doubtful, and I kind of agree now.
<mdeslaur> seb128: is Stef Walter the only upstream on gnome-keyring?
<pitti> right, this was totally worthless
<pitti> any application could have faked such a dialog
<seb128> mdeslaur, yes
<mdeslaur> it was worthless as gnome-keyring should probably be a root process and access granted with policykit, etc.
<seb128> mdeslaur, I've been mailing "flooding" him for 1.5 months now
<seb128> he got a baby like 2 months ago and doesn't have too much hacking time atm, he sent an email before that saying he would probably not read all bugzilla traffict but to contact him by email for issues that need to be looked at
<mdeslaur> seb128: so, no chance of meeting with him at UDS? :P
<seb128> he has been looking at the bugs I mentioned via email but not on a very responsive timeline
<pitti> once we know what this user.keystore is for, I think we can just upload the patch that we have
<seb128> mdeslaur, I doubt it
<mdeslaur> pitti: I was under the impression it was the pkcs11 cert store, but I may be mistaken
<ogra> seb128, heh, i'm back to stuttering ...
<ogra> ogra@osiris:~$ cat /sys/kernel/debug/dri/0/gem_objects|grep "object bytes"
<ogra> -169566208 object bytes
<ogra> fun
<ogra> so RAOF was apparently right with his assumption
<seb128> ogra: right, read #ubuntu-desktop discussion
 * zyga has a company now, woot :-)
<pitti> zyga: oh, congrats! building a new empire? :-)
<joaopinto> Keybuk, http://pastebin.com/NVWXUS7Y, any idea why /lap is never attempted to be mounted ?
<slangasek> joaopinto: run mountall --debug?
<slangasek> joaopinto: and according to the last line, all filesystems *were* mounted
<joaopinto> slangasek, because he opened an hacked tty and did the manual mount :)
<slangasek> joaopinto: the 'manual intervention here' is shown three lines after the last mountall message
<joaopinto> ops, right, it was after mountall after all
<slangasek> joaopinto: anyway, if something didn't mount right, we'll need mountall --debug to sift through
<joaopinto> ok, I am trying to convince him to open a bug report :P
<slangasek> joaopinto: bug #567910?
<ubottu> Launchpad bug 567910 in mountall "filesystem not getting mounted" [Undecided,New] https://launchpad.net/bugs/567910
<slangasek> ugh, "nodev"?
<joaopinto> oh, great :)
<slangasek> so, this looks like it might be a duplicate of the many reports of LVM+mountall problems that I haven't been able to reproduce
<joaopinto> slangasek, he is at #ubuntu+1, might help
<slangasek> probably not; I've already asked all the questions I've been able to think of regarding those bugs
<joaopinto> ok :\
<joaopinto> hum
<joaopinto>                 /* Check through the known filesystems, if this is a nodev
<joaopinto>                  * filesystem then mark the mount as such so we don't wait
<joaopinto>                  * for any device to be ready.
<joaopinto> they should still be mounted right ? just having a nobootwait behavior
<joaopinto> I mean, there should still be an attempt to mount
<slangasek> joaopinto: no, that's nothing like nobootwait
<slangasek> if you mark it 'nodev', mountall will try to mount it *immediately*, without first waiting for the device
<slangasek> so if it needs a device in order to mount, and the device isn't there yet, --> fail
<slangasek> I have no idea why anyone would mark their LVs 'nodev'
<slangasek> unless they thought it was analogous to 'nosuid', I guess
<joaopinto> but from the log there is no attempt to mount that filesystem
<slangasek> the log is also uselessly incomplete.  Need a debugging log
<jdong> if I've got a struct {char* a; int b};, what Ubuntu security feature is causing a SIGABORT when a strcpy into "a" attempts to overwrite "b"?
<jdong> is that -fstack-protector at work?
<slangasek> oh, wait - that *is* what the 'nodev' mount option does, sigh
<slangasek> keyword overload bad for brane
<zyga> pitti: I hope that's the ubuntu empire :-)
<hyperair> jdong: you shouldn't get a sigabrt at all, afaik.
<hyperair> jdong: in the first place, doesn't char * a point somewhere else, so you won't overflow onto b?
<slangasek> jdong: -fstack-protector might have something to do with it, but fyi, it's not 'b' that would be overwritten in an overflow
<hyperair> jdong: unless you meant char a[something]
<jdong> hyperair: yeah sorry for the lazy notation, I meant char a[something]
<jdong> I've got someone's bot simulator here that contains such a vulnerability...
<hyperair> afaik if it's in a struct it's all part of the same memory so you can just overflow over with no issues? =\
<hyperair> or maybe i'm wrong
<jdong> on Ubuntu I was unable to even go 1 character beyond the end without the program blowing up
<jdong> but on RHEL it can be exploited as expected
<hyperair> jdong: i can't seem to reproduce that.
<sistpoty|work> jdong: I doubt that a security feature can prevent overwriting b during runtime w.o. violating the c standard (though it's been some time since I a last poked at the standard)
<sistpoty|work> jdong: however it might be that overwriting is already visible at compile time from -Dfortify_sources, so...
<jdong> ah, whoops
<jdong> wrong test case
<jdong> incorrectly simplified test case
<jdong> the two resources in the struct are malloced
<jdong> they seem to be coincidentally adjacent in RHEL though
<sistpoty|work> heh, everything malloc'ed is a different corner ;)
<jdong> indeed it is
<jdong> and ok, that actually makes sense why it's possible
<joaopinto> slangasek, I was misreading both the source and the mount manual, "nodev" mount option is not related to the "nodev" property from /proc/filesystems
<slangasek> right
<slangasek> which I knew, then forgot :)
<slangasek> pitti: confused by your email; the 114 patch was introduced Mar 31, not Apr 15?
<pitti> slangasek: oops, yes
 * pitti fixes wiki page
<dawning> Question: Is there going to be a 10.04 Beta 3? Is there any point?
<pitti> dawning: the Release Candidate is due tomorrow, and next Thursday is the final
<dawning> Sounds good, thanks pitti
<zyga> doko: ping
<Keybuk> cjwatson: I don't see why that's a regression
<Keybuk> his resume= and root= are identical
<Keybuk> that's clearly not going to work
<doko> zyga: ?
<Keybuk> slangasek: argh, your -r 323 is *WRONG*
<zyga> doko: here or in private?
<doko> cjwatson: http://people.canonical.com/~doko/tmp/ ppa1 built without multiarch, ppa2 with normal glibc and -fno-strict-aliasing, ppa3 without opt
<Keybuk> slangasek: reverted in 324 with explanation
<Keybuk> slangasek: Re:  #553745 - I don't have any handle on it, I've been unable to replicate
<Keybuk> my only theory had been the patch you tried
 * hyperair wishes that the window manager would retain control even when applications have menus open
<hyperair> every time liferea hangs, i have to switch to a vt to kill it.
<hyperair> i mean every time it hangs while i'm either right clicking or drag dropping
<cjwatson> Keybuk: as I interpreted it, the point of that bug was that resume_offset isn't implemented in wait-for-root
<cjwatson> I didn't debug whether the rest of his setup was sane
<Keybuk> cjwatson: it doesn't need to be implemented in wait-for-root ?
<cjwatson> oh, maybe I misunderstood the bug then
<hyperair> resume_offset? are we supporting swap files for resume now?
<Keybuk> no, i think the reporter has misunderstood that resume from swap files *doesn't work*
<Keybuk> and never has
<hyperair> ah
<cjwatson> he explicitly claimed that his setup worked in karmic; perhaps he was lucky
<Keybuk> I tend to assume they lie
<hyperair> but you can never get them to admit that.
<Keybuk> wait-for-root simply replaces the bad loop that looked for nodes in /dev and kept running blkid and udevadm settle
<Keybuk> instead actually listening to uevents
<Keybuk> comparing the hardy and lucid local-premount/resume scripts, they've changed quite a bit otherwise
<kklimonda> hyperair: when liferea hangs try alt+f - it helps here to unblock it
<hyperair> kklimonda: what's that supposed to do?
<hyperair> kklimonda: but anyway i think the real problem is that X is to susceptible to being hijacked by a hanging application =\
<hyperair> kklimonda: in the first place, why does liferea hang so much? firefox uses sqlite, banshee uses sqlite. i don't see them hanging like this.
<Keybuk> cjwatson: in fact, looking at the current version, it flat out doesn't support resuming from files ;)
<kklimonda> hyperair: when I drag and drop in applications and I get locked (I can't do anything in X because I'm locked in drag&drop mode) opening application menu tends to help.. and I have no idea why does liferea hang so much.. I've hoped that 1.7 would help but no luck :/
<hyperair> kklimonda: the worst part is that there is nothing better >_>
<hyperair> kklimonda: so i'm stuck with either crap, or crappier crap.
<kklimonda> hyperair: heh, true - that's the only reason I use liferea :/
<hyperair> kklimonda: the best part is that upstream is either ignorant to the whole liferea-suckiness, or not seeing the issue at all.
<dylan-m> kklimonda: Hey, drag+drop hanging used to happen to me reallly often with Liferea, too! That was a year ago, though :o
<dylan-m> It taught me one thing: mouse grabs are terrible, evil things and we really need a "release mouse grabs" key
<dylan-m> (Since then I've used Feedly, but I'm just surprised it still happens after all the refactoring)
<hyperair> feedly?
<hyperair> ah feedly.
<hyperair> the whole point for me to use an rss reader is so i don't have to open firefox
<hyperair> that bl**dy mem hog
<dylan-m> hyperair: Cute web service + Firefox / Chrome extension that plugs in to Google Reader, but is sadly not open source so we can't borrow their secrets :)
<hyperair> dylan-m: heh.
<hyperair> dylan-m: i'm betting that giving liferea a multithreaded interface would do the job.
<hyperair> dylan-m: like I/O, one thread. UI, one thread.
<hyperair> then yay no more hangs.
<hyperair> afaik liferea's hangs are caused by sqlite doing blocking writes followed by syncs.
<dylan-m> hyperair: everything that ever performs a grab should be doing it in a separate thread. It's an insanely risky operation
<hyperair> dylan-m: i agree.
<hyperair> dylan-m: well, even then menus suck.
<hyperair> dylan-m: especially when you open a menu and liferea chooses to hang at that point.
<kees> jdong: /me is curious to see your sigabrt reproducer
<matgeek> Serious boot problem - mountall still does not handle >=4 LVM logical volumes.
<matgeek> This is to do with lucid.
<Keybuk> mountall doesn't handle LVM at all
<Keybuk> if you're experiencing problems with LVM, you're experiencing problems with LVM
<matgeek> Keybuk: Definitely not.  I have been triaging this one for the last few days.  My LVM volumes are perfectly fine.
<Keybuk> if you're convinced it's a mountall issue, do you have a patch?
<joaopinto> there was another person reporting LVM problems today, with mountall
<matgeek> Keybuk: I am working on it.  It is early in boot process - therefore harder to debug and get at with gdb etc.
<Keybuk> I think that LVM is busted in Lucid
<Keybuk> my hunch is that a recent kernel broke it
<Keybuk> I've seen people report things like "volumes not activated" etc.
<Keybuk> and it's clear from the debugging that no uevents for them are generated
<Keybuk> enough to make me convinced that it's not a mountall problem
<matgeek> I am running kernel.org 2.6.33.2.  LVM utils are fine.
<joaopinto> he was able to "resume" mountall by doing a manual mount
<Keybuk> that doesn't really mean much
<matgeek> Yes, that is what I have been doing.  I have noticed udev creating the symlinks in /dev/<volume_name>
<matgeek> I suspect that udev is working correctly, and that there is a race in mountall.
<joaopinto> I am refering to bug 567910
<ubottu> Launchpad bug 567910 in mountall "filesystem not getting mounted" [Undecided,New] https://launchpad.net/bugs/567910
<Keybuk> first debugging step - add --debug to the exec line in /etc/init/mountall.conf and grab /var/log/boot.log when done
<matgeek> The plymouht integration seems to have created problems.
<Keybuk> matgeek: sorry, but I disagree; there is no race in mountall
<Keybuk> all the debugging I've seen shows that mountall never gets told that the LVM devices are ready
<matgeek> Well, do you watn to come and see it on my laptop???
<Keybuk> sure
<matgeek> I am a DM with considerable Sys admin experience.  I know what I am talking about.
<Keybuk> that's nice
<matgeek> I am here raisning the problem as even with the latest software it still persists.
<Keybuk> no, you're here bitching and being unhelpful
<Keybuk> <Keybuk> first debugging step - add --debug to the exec line in /etc/init/mountall.conf and grab /var/log/boot.log when done
<Keybuk> ^ that would be helpful and helping prove there's a problem
<Keybuk> right now, there is no proof of any bug
<matgeek> OK, I am trying to prevent a release with a serious mount probelm on boot.
<zyga> matgeek: which arch are you running
<Keybuk> matgeek: if you want to do that, you need to prove there's a serious problem
<matgeek> Keybuk: Don't just easily write me off as venting.
<matgeek> I do not have that much time to debug and patch.
<zyga> several days ago slangasek tracked a kernel bug where LVM drivers were not part of the kernel and ppc systems would not boot
<Keybuk> matgeek: and don't just easily write us off as being idiotic enough to ship with something not working
<joaopinto> matgeek, calm down, the problem is known, is being worked, if you can please provide more info on the bug I have mentioned above
<Keybuk> joaopinto: the problem is not known and is not being worked
<Keybuk> matgeek: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
<matgeek> OK: I will go and do the hard yards on Saturday.  I will attempt to get boot logs loaded today against relevant bug.
<joaopinto> Keybuk, the bug is known, was reported a few hours ago, and I have done some work on it, please calm down
<Keybuk> Give the programmer some credit for basic intelligence: if the program really didn't work at all, they would probably have noticed. Since they haven't noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information; providing this information is the purpose of a bug report. More information is almost always better than
<Keybuk> less.
<Keybuk> matgeek: Saturday will be too late to hold up the release
<Keybuk> joaopinto: I'm quite calm; like I said, I'm convinced there is an LVM bug somewhere - not a mountall bug
<matgeek> Keybuk:  Understand.  This bug is hard to find as it involves >= 4 lvm logical volumes coming up.  early boot process debug is difficult.  I can understand how it has been missed.
<rye> Hello, all. Question - i did dput file.sources w/o specifying  ppa:rye/ppa - it said "Uploading to ubuntu", should I notify anybody to prevent this package into going anywhere?
<joaopinto> Keybuk, there is a problem, for the user it is irrelevant for the exact package, and you tend to ignore there is more than mountall on Ubuntu
<Keybuk> joaopinto: yes, that's because I ignore anything outside of my lines of responsibility ;-)
<joaopinto> he is not arguing about mountall, he is just reporting a problem with his LVM setup, which I believed to be mountall related
<rye> The package in question is "henplus_0.9.8.ds1-0ubuntu1~ppa2~lucid"
<matgeek> FYI, i have been using Linux since kernel 0.99.
<arand> rye: it will just get rejected, unless you do have uploade rights to ubuntu main.
<joaopinto> Keybuk, right, but that is not nice when you do it pushing people for helping with other problems
<Keybuk> this is not a channel for reporting bugs, this is a channel for assisting in the development of Ubuntu - I expect anyone reporting problems here to also be willing to work on the fixes
<joaopinto> I mean, for not helping
<arand> rye: No need to do anything. Just make sure to delete the *upload file if you want to upload it again.
<rye> i hope i don't... Ok, is the current topic about failure to mount LVM volumes during boot ?
<joaopinto> matgeek, just update the bug report, some will check it depending on how much people it affects and how important it is compared to other known and being worked problems
<Keybuk> so if someone comes in saying they have problems with LVM, I'll help point at where I think the current problem is to help them continue to work the problem
<kees> doko: are you able to trivially reproduce 393022 ?
<joaopinto> Keybuk, could you tell me the LVM related package I should assign the bug to ?
<Keybuk> joaopinto: lvm2
<joaopinto> Keybuk, ok, I am going to reassign the bug based on your input
<Keybuk> joaopinto: I've just done that
<Keybuk> if you're referring to bug #567910
<ubottu> Launchpad bug 567910 in mountall "filesystem not getting mounted" [Undecided,New] https://launchpad.net/bugs/567910
<joaopinto> grr, ok
<joaopinto> yes, that one
<Keybuk> the debug log there shows no try_udev_device for laplv
<hyperair> kklimonda: http://launchpadlibrarian.net/27733951/fsyncbegone.c \o/
<gbear14275> anyone here able to talk to power management (specifically battery management)?  I have questions about setting charging thresholds for my new li-ion battery.
<Keybuk> joaopinto: an interesting debugging technique might be
<Keybuk> let mountall fail and go to a maintenance shell
<Keybuk> then run "mountall --debug" and get *that* output
<Keybuk> (from the maintenance shell)
<joaopinto> mountall did not fail
<Keybuk> -v
<gbear14275> are there any gui's available to help set charging profiles for my battery?  If not, how can I set my charging profiles?
<zyga> hyperair: what are you doing with those functions?
<hyperair> zyga: doing nothing.
<zyga> gbear14275: try #ubuntu please
<zyga> hyperair: they looked nice for LD_PRELOAD, right?
<hyperair> zyga: making them no-op. i don't really need that much data integrity with liferea, since ext4's journalling fine.
<hyperair> zyga: yes, correct.
<Keybuk> joaopinto: what do you mean by "did not fail" ?
<jdong> kees: ah, the backtrace comes from 14:14 < temugen> /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb72fded8]
<jdong> kees: ah, -O2 and higher enables that check.
<jdong> hyperair: ^^^
<hyperair> jdong: eh?
<jdong> hyperair: strcpy is hardened at -O2 and above by default
<hyperair> jdong: ah that's cool.
<jdong> hyperair: so if you strcpy 11 chars into a char[10] it'll bork at -O2+
<hyperair> interesting.
<jdong> the software I was trying to exploit was indeed -O3
<hyperair> but isn't -O supposed to optimize things, rather than add more sanity checks?
<hyperair> i'm curious as to how it did the sanity check, as well.
<jdong> hyperair: no I think -O means "don't assume instructions are executed as written"
<hyperair> ah.
<jdong> and that excuses the use of a replacement magical strcpy and such
<jdong> again, kees could give us the real answer :)
<hyperair> jdong: actually -O in the manpage is documented as Optimize.
<jdong> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html
<kees> jdong: yes, it detects buffer overflows when it knows the size of the buffer.
<kees> jdong: https://wiki.ubuntu.com/CompilerFlags
<jdong> kees: cool. I didn't know DFORTIFY_SOURCE involved runtime checks, and I also didn't know it was tied into -O flags.
<kees> jdong: i.e. gcc+glibc believe the code is doing something unsafe.
<jdong> kees: surely enough, compiling with the right CFLAGS in RHEL produced an identical result
<kees> jdong: yup, lots of runtimes checks.  all documented in above wiki (including the -O2 and higher bit)
<jdong> *nods*
<jdong> that's pretty cool
<kees> jdong: this is why Ubuntu is safer than RHEL -- we changed the defaults in our compiler.  :)
<jdong> yeah, I really like that.
<kees> RHEL just uses those flags for their package builds.
<jdong> heh I always ASSumed that RHEL would be more proactively secure than Ubuntu
<jdong> not the case :)
<kees> not since intrepid.  :)
<jdong> kees: you'll love the backstory. For a friend's final project in a programming course, grading was done via an automatic server, assumed to be on RHEL....
<jdong> kees: it had a filename[80] and a blind strcpy, kids tried to exploit that
<jdong> unfortunately the grading was done on an Ubuntu box. people who tried to exploit that didn't score very high.
<kees> hah
<kees> real-world success!
<jdong> yep!
<Nafai> jdong: Nice!
<jdong> always cool to see these features doing something useful in the real world
<hyperair> now time to publicise this =p
<hyperair> and get it dugg, slashdotted and the like =p
<jdong> kees: any guesses as to why RHEL wouldn't turn these features on by default? Is compatibility a huge issue?
<jdong> I mean, RHEL is pretty aggressively marketed for its security technologies; it'd seem like that's a priority for them
<hyperair> not to mention the patch seems to come from redhat in the first place
<jdong> oh yeah, most of this hardened toolchain stuff originated from RedHat/Fedora
<kees> jdong: they're too timid.
<kees> jdong: since it catches a lot of actual problems, people like the whine.  "but it _used_ to compile and run fine!"
<jdong> the irony is, I'd expect their SELinux-by-default to be even a worse offender at "gah it worked before!"
<jdong> especially with LAMP apps
<jcastro> lool, you still have an X200? How's your wireless? Mine started going to sleep.
<kees> jdong: but I (and others) demanded it be done in Ubuntu, since it improves code quality so much.  that said, there are rare cases when gcc gets it wrong.  (usually via insane by valid tricks in source code)
<elmo> jdong: it's easy to turn SELinux off
<elmo> jdong: it's less easy to recompile everything
<jdong> elmo: ah, that's true indeed
<jdong> and so many sysadmins do seem to turn it off
<kees> jdong: they did develop a lot of it (especially fortify), but stack protector was bounced around for ages before.
<jdong> *nods*
<kees> a lot of credit goes to OpenWall and solar designer, actually.
<doko> kees: no
<kees> doko: okay.  I commented on the python upstream bug, trying to add any missing information.  sounds like they're just popping a stack
<doko> kees: thanks
<doko> kees: the *link* with -O1
<doko> they even
 * Keybuk hugs -Wl,-O1
<kees> doko: oh! okay, I misunderstood.
<Keybuk> joaopinto: ooooooh, I've just noticed something!
<Keybuk> are you able to replicate the "LVM doesn't mount" bug?
<joaopinto> Keybuk, nope, I was just proxying a support request from #ubuntu+1, I just known it was a XFS filesystem using LVM
<Keybuk> joaopinto: damn
<Keybuk> I have a theory
<Keybuk> if I'm right, it actually turns out to be a mountall bug after all
<Keybuk> there's a line of code missing
<Keybuk> and this sounds a lot like a different bug we had
<Keybuk> I'll build a package and get them to try it
<joaopinto> how is the default timezone on the installer selected ?
<TMKCodes> Is anywhere in ubuntu needed help from "new" c developer?
<cjwatson> doko: belatedly - thanks, will try those
<cjwatson> doko: I should test busybox-udeb ppa1 with the libc6-udeb from your PPA, right?
<sabdfl> TMKCodes:  lots to do - check out the "how to contribute" page on the wiki
<TMKCodes> sabdfl i did read it already.
<sabdfl> ok
<cjwatson> TMKCodes: in my experience, it's better to find a problem that's annoying you personally and try to solve it (then repeat lots and lots of times!), than to try to filter it in advance by the language
<cjwatson> joaopinto: geoip
<cjwatson> joaopinto: fallback from that to a language-specific value
<TMKCodes> cjwatson my problem is i dont have any problems with ubuntu atm
<cjwatson> not trying hard enough ... ;-)
<TMKCodes> Well i have some boot issues, have not looked into it.
<cjwatson> there are some bugs tagged 'bitesize', although not as many as there should be
<TMKCodes> Damn at last i found the bug tracker at launchpad.. Really hate that site.
<cjwatson> and actually it's possible those are more trivial packaging kinds of bugs rather than anything that involves C
<TMKCodes> Well.. C problems would be nice, but packaging problems are ok too xD
<TMKCodes> packaging is the place where most start contributing.
<cjwatson> seriously though - I got seriously into Debian development back in the day by way of somebody posting a message of the form "<this really important program> really sucks, can somebody fix it?"
<TMKCodes> :P
<cjwatson> and it was a program I used, and I could replicate a fair bit of the suckage, so I did
<TMKCodes> Yeah i can understand that.
<cjwatson> I'd done some packaging before that, but it's really just a means to an end
<joaopinto> the default for my country seems far from ideal, an island is the default instead of the mainland
<joaopinto> should I file a bug for ubiquity ?
<cjwatson> anyway, point is, this worked because I had a personal interest in fixing the problems - it probably wouldn't have done otherwise
<cjwatson> joaopinto: like I say, the defaults often come from geoip ...
<TMKCodes> I have used ubuntu for several years, but there's been much problems with me so i've just waited bit for someone to fix the problem.
<cjwatson> joaopinto: what country?
<ogra_cmpc> joaopinto, likely because your provider routes through that island
<cjwatson> ogra_cmpc: not necessarily, some of the geoip server's defaults are dubious
<ogra_cmpc> ah
<joaopinto> cjwatson, Portugal
<cjwatson>   else if ( strcmp (country, "PT") == 0 ) {
<cjwatson>     timezone = "Atlantic/Azores";
<cjwatson>   }
 * cjwatson hits geoip with a wet fish
<cjwatson> joaopinto: bug on geoip, please
<joaopinto> uhh
<ogra_cmpc> lol
<joaopinto> :)
<TMKCodes> i found the bug that i need to fix.
<TMKCodes> bug number 1..
<ogra_cmpc> TMKCodes, thats rather a yeam effort :)
<ogra_cmpc> *team
<TMKCodes> :P
<joaopinto> cjohnston, geoip-database <- ?
<cjohnston> :-P
<joaopinto> grrr, cjwatson
<cjwatson> sadly, while geoip figures out the country accurately and sometimes an accurate region within it, the timezone it returns is hardcoded really stupidly
<cjwatson> joaopinto: no, geoip.  it's hardcoded.  don't ask. :-(
<joaopinto> cjwatson, where did you paste that code from ? the code is wrong...
<cjwatson> from the geoip source package
<cjwatson> libGeoIP/timeZone.c
<ogra_cmpc> joaopinto, yes thats why he pasted it :)
<cjwatson> I agree it's wrong, but I'd want to send it upstream
<ogra_cmpc> use it in your bug report
<cjwatson> and we'd need to backport the fix to our servers
<cjwatson> it's the geoip package *on the server* that matters
<joaopinto> what, geoip uses source code for the translation ?
<cjwatson> yes
<cjwatson> it's not pretty
<cjwatson> I was kind of horrified when I found that, when dealing with a previous bug of the same form for another country
<cjwatson> (bug 517621)
<ubottu> Launchpad bug 517621 in ubiquity "Default setting of zh_CN locale incorrect" [Undecided,Fix released] https://launchpad.net/bugs/517621
<ogra_cmpc> over time it will be great though if we use it by default
<ogra_cmpc> was probably a bit risky to include it now ... we should have done that in karmic already
<tormod> pitti, I have a fix for the broken -dbg/-dbgsym packages in bug 562418
<ubottu> Launchpad bug 562418 in xorg-server "many -dbg packages have debug symbols mismatch" [Undecided,Confirmed] https://launchpad.net/bugs/562418
<Sarvatt> \o/ \o/ \o/ thanks tormod!
<joaopinto> done, bug 568067, I guess it doesn't need a patch from me :P
<ubottu> Launchpad bug 568067 in geoip "Default timezone for the country 'PT' is wrong, should be 'Europe/Lisbon'" [Undecided,New] https://launchpad.net/bugs/568067
<joaopinto> I guess it's low importance to be fixed before final :\
<tormod> Sarvatt, simple fix but a bitch to hunt down :)
<cjwatson> joaopinto: because the operative code is on the server, it doesn't matter if it makes final
<lool> jcastro: I have a X301; wireless is okay-ish, but had some issues during the cycle
<lool> would disconnect at random
<lool> it's decent now
<cjwatson> joaopinto: we can fix it whenever, and all users will get the fix instantly on deployment
<joaopinto> ah, server side geoip ok, much better :)
<cjwatson> so we should focus on things that don't have that property
<mvo> ccheney: hi, if you could review https://code.edge.launchpad.net/~mvo/openoffice/3.2.0-lucid/+merge/23875 that would be nice. I will go to bed now so no rush
<barry> james_w: any chance you're still around?
<james_w> barry: I am
<james_w> so, yes I guess
<barry> james_w: :)  can we talk about lazr.restfulclient?
<james_w> yup
<barry> james_w: so, i'm trying to get a branch for lucid up to 0.9.13 or .14.  iiuc, there is no lp:debian branch for it even though it's in testing:
<barry> http://packages.debian.org/source/squeeze/lazr.restfulclient
<barry> james_w: but it also looks like we have an ubuntu specific patch, so bzr import-dsc didn't do what i expected it to do
<barry> james_w: and of course, i can't just merge in lp:lazr.restfulclient
<barry> (no common ancestor)
<barry> james_w: it also looks like debian svn has 0.9.14 in it though no source package yet
<barry> afaict
<barry> james_w: so i'm wondering, what is the best way to update the package for lucid?
<james_w> barry: the sid branch has it I think?
<barry> james_w: let's see if i can find that :)
<james_w> lp:debian/sid/lazr.restfulclient
<barry> thanks
<barry> james_w: yep, that looks more sane
<james_w> the reason that the squeeze branch doesn't have it yet is that gina hasn't picked it up yet
<barry> james_w: conflict on the Maintainer and Uploaders fields, but that should be easily resolved
<james_w> yeah, jelmer filed a bug about smarter merging of debian/control
<barry> james_w: cool, this is exactly what i was looking for, thanks.  do you want to review the branch when i push it?
<james_w> sure
<barry> james_w: cool, thanks
<james_w> it would be tomorrow for me though
<barry> yep, no worries
<doko> cjwatson: yes, the libc6 udeb from the ppa
<kees> doko: that python issue is from an already-fixed kernel bug
<doko> kees: fixed in which version?
<kees> doko: all.  it was fixed when karmic released, and went into stable kernels on mar 16th.
<kees> doko: I put all the details in the upstream python bug
<kees> doko: I might be able to find all the bug reports in LP that are dups of this kernel issue, actually.  they stand out when you examine the ProcMaps.txt file
<doko> kees: cool, thanks!
<kees> doko: sure thing :)
<cjwatson> doko: neither (libc6-udeb/ppa + busybox ppa1) nor busybox ppa2 makes any difference
<cjwatson> trying 3 now
#ubuntu-devel 2010-04-22
<cjwatson> doko: no joy with ppa3 either
<cjwatson> doko: I think I'll have to build a debug shell tomorrow with some added printf debugging
<doko> cjwatson: thanks for checking. although I do like the outcome somewhat ;)
<cjwatson> that we don't need a new eglibc?
<cjwatson> I'm not too sad about that myself, I must admit
<doko> yes
<slangasek> Keybuk: ok, sorry - any idea how to fix this properly, then?  Because /without/ that change, after fixing plymouth, pressing 'c' gets you a segfault instead of an fsck cancellation
<cjwatson> anyway, hacking printfs into exactly the right place in the shell requires a special state of mind, and this ain't it, so ... night
<Keybuk> slangasek: why does it give a segfault?
<Keybuk> do you have a bt?
<slangasek> Keybuk: actually, sorry, the segfault was the second bit of the patch; the first bit was that plymouth_answer() returns at line 3028 because plymouth-mnt->error never gets set to ERROR_FSCK_IN_PROGRESS
<slangasek> plymouth_mnt->error
<slangasek> er, no - was the other way around
<slangasek> segfault first
<slangasek> because plymouth_mnt wasn't set
<slangasek> line 3093
<Keybuk> whuh?
 * Keybuk wonders whether slangasek has a sort "in order" button
<Keybuk> so
<Keybuk> plymouth_mnt is initialised to NULL
<slangasek> without the change from > to >=, plymouth_mnt never gets set to anything in the case that plymouth_error == ERROR_FSCK_IN_PROGRESS, because there's no value greater than that in the enum
<Keybuk> so I don't see how it can ever be "not set"
<slangasek> "not set" -> "not set to a value that it's useful to try to dereference"
<Keybuk> but it doesn't need to be set to any value
<Keybuk> S kills all running fsck
<Keybuk> err C I mean
<slangasek> not with the existing code, it doesn't
<Keybuk> that's why the 'C' case never uses mnt
<Keybuk> prove it to me with a bt ;)
<Keybuk> oh, cock
<Keybuk> no, I see what you mean ;-)
<Keybuk> right at the top of the case
<Keybuk> that's just a bug in its own right
<Keybuk> I was adding those, and clearly didn't put my brain on
<slangasek> should that point at plymouth_error, then?
<Keybuk> yes!
<slangasek> ok - you changing, or shall I?
<Keybuk> I'll change that, since I have emacs open right now
<slangasek> ok
<Keybuk> I clearly made it != not ==, but didn't think all the way through
 * Keybuk cleans up the rest of that code
<Keybuk> ok, pushed as -r 325
<Keybuk> what was the first bit of that patch for?
<slangasek> Keybuk: the first bit was knock-on from the second bit
<Keybuk> ah right
<Keybuk> yeah I can see how you got there
<slangasek> so if we're checking plymouth_error now, it should work
<Keybuk> but since we always run fsck, but fsck doesn't always check, I was trying not to do your exact patch ;-)
<Keybuk> the reason mnt isn't set is on the assumption that we "don't know" which message is being displayed
<Keybuk> clearly
<Keybuk> 1) plymouth needs to support these kinds of "press X for" messages/prompts
<Keybuk> 2) plymouth then needs to deal with receiving multiple of them and showing one at a time
<Keybuk> 3) mountall then gets simpler again
<slangasek> so, cool; that means you've fixed a regression I'd noticed but didn't realize was my fault ('press C' showing up when no checks were needed)
<slangasek> sorry about that
<Keybuk> hey, that's ok ;)
<Keybuk> I'm still trying to figure out why /tmp has to be nodev ;)
<slangasek> well, without that, the code for handling placeholder entries never triggers
<slangasek> is never reached, should say
<Keybuk> hahah
<Keybuk> I just found the code
<Keybuk> I'm such a lazy git
<Keybuk> I could have just done mnt->placeholder = TRUE or something
<Keybuk> but no
<Keybuk> I had to abuse nodev combined with strcmp (type, "none")
<Keybuk> I can see why I did it like that - it means anything in fstab with /tmp overrides the lot
<Keybuk> oh well
<Keybuk> that patch is clearly right :p
<Keybuk> btw
<Keybuk> how did we miss http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mountall/lucid/revision/326 ?
<slangasek> Keybuk: oh, geez; well I missed it because I wrongly assumed we already fixed that
<Keybuk> slangasek: so did I
<slangasek> I guess we only fixed it in upstart
<Keybuk> I'm sure I fixed it in mountall
<Keybuk> I bet this is case of I fixed it, and then forgot to push
<Keybuk> or it got overwritten by the importer
<Keybuk> so the fix was lost
<Keybuk> so I'm pretty sure that's the LVM bug ;-)
<slangasek> yeah, so am I
<slangasek> well, before when we were fixing this we were focusing on upstart-udev-bridge (upstart 0.6.5-2), so I was just assuming it was fixed by false analogy - never saw the code to do it :)
<persia> kees: Is it a bug that rng-tools' init script doesn't seem to start for me on boot?  Is this just me?
<kees> persia: if you're using it with TPM, it's a bug -- trousers needs to start first, but doesn't.
<persia> kees: Does it have a bugnumber, or shall I add description to the lamentably short bug #544545?
<ubottu> Launchpad bug 544545 in rng-tools "rngd doesn't start automatically" [Undecided,New] https://launchpad.net/bugs/544545
<persia> (this being a different issue than bug #519427, which also makes it not start under those conditions)
<ubottu> Launchpad bug 519427 in rng-tools "fails to start using TPM device as rng" [Wishlist,Triaged] https://launchpad.net/bugs/519427
<kees> persia: there's no bug number yet, no.
 * persia repurposes 544545 to track this
<kees> persia: what do you think the best solution is for this?  either moving trousers one S-level earlier, or rng-tools one S-level later.  probably the latter.
<persia> I like moving things later better.
<persia> I'm not sure I care enough to fix for lucid though.
<kees> I probably should fix it (and the example typo)
<persia> close all the bugs in the package all at once?  That would be exciting.
<Keybuk> I think we should do that
<Keybuk> close all launchpad bugs
<Keybuk> delete them
<Keybuk> and start over
<persia> Is the example typo really I typo?  I thought it was just your blog software being smart.
<persia> Keybuk: Why?  I often find bugs that are over a year old and still apply to the development releases.
<Keybuk> mostly for fun
<Keybuk> but also because the "find" bit is hard
<persia> Hm.  True.  When we had < 100K bugs, finding them was lots easier.
<kees> persia: no, I mean, like to add an example at all.
<persia> Oh, heh.  I've a patch to do that in the bug.
 * persia forgets why it wasn't just uploaded back in February, precisely
<Caesar> Is it normal practice to have a source package in main, but some of its binary packages in universe?
<crimsun> FSVO normal, yes
<persia> Caesar: It's not uncommon at all.  source packages must be in main if any binary packages are in main.  binary packages are encouraged not to be in main unless they are required to be in main.
<Caesar> ok
<persia> Caesar: Do you have a specific package that is confusing or problematic in some way?
<Caesar> persia: I was slightly confused by autofs5-ldap
<persia> Caesar: Are you less confused now, or do you have more questions?
<Caesar> persia: I'm less confused now that you've explained things
<persia> Great!
<Caesar> I had just assumed that if a source package was in main, *all* of its binary packages should be too
 * jdong cries a bit about vdpau... lower CPU usage != longer battery life
<jdong> not really surprising though
<persia> Caesar: It's an artifact of how "main" is defined.  With luck, it will make more sense once we can abolish components.
<jdong> wow, the splashy issue still exists, doesn't it :-/
<jdong> bug 328089
<ubottu> Launchpad bug 328089 in splashy "[Jaunty] splashy 0.3.13-3ubuntu1 fresh install conflicts with lsb-base" [High,Triaged] https://launchpad.net/bugs/328089
<jdong> I forgot the reason why we decided we didn't want to yank it from Lucid?
<jdong> or make it conflict lsb-base or some other obvious "installing this package won't work" error
<ScottK> It's not too late for removals
<persia> are we in removals-freeze pending RC?
<jdong> ScottK: what's your opinion on the matter? splashy tries to install a file in lsb-base, and it seems like the two parties have reached an impasse for a year
<ScottK> jdong: Since it conflicts with a package in ubuntu-minimal, I don't see how it could be suitable.
<ScottK> So it wouldn't be installable except in a system that had been somewhat heavily tortured.
<jdong> ScottK: really? apt-get -s install splashy happily removes some usplash packages and continues
<ScottK> OTOH, I didn't investigate if the conflicts is correct.
<jdong> ubuntu-minimal doesn't spark the Essential: Yes warning, does it?
<ScottK> Don't think so.
<ScottK> persia: No.  Removals are still being processed.
<jdong> well, it doesn't seem to yell at me when I try to install it, minus an unpack phase overwrite failure
<slangasek> jdong: no, it doesn't - but splashy isn't going to work right with plymouth, and removing that *does* spark the Essential: yes error
<ScottK> Although at least in my case the RM has gone to the length of putting my name in the removal rationale so people know who to go hunt down.
<jdong> slangasek: ah, good point
 * persia only has a few removals pending, for superceded sources
<slangasek> ScottK: don't worry, IME people will still come to me first ;)
<ScottK> persia: If only I had shell access they'd be done.
<persia> They should check +publishinghistory, which should document the bug number, which should answer *all* their questions :(
<slangasek> (I get two or three mails a cycle from users begging me to add back a package that I removed as part of process-removals of stuff disappearing from Debian)
<persia> Oh, removals require shell access?
<ScottK> Yes
<jdong> slangasek: seems like two people on/upgrading to lucid have commented on that bug report, though.
<jdong> is there any benefit to having splashy in the archive if it's not installable?
<ScottK> And will never be installable again ...
<jdong> indeed. it's plain incompatible with the new boot system.
<ScottK> (I don't expect Plymouth is going anywhere)
<persia> Just file the removal bug already :)
<ScottK> jdong: You've already expended far too many brain cell s on it already
<jdong> lol ok, filing removal
 * jdong subscribes ubuntu-archive to bug 568193
<ubottu> Launchpad bug 568193 in splashy "[removal request] Splashy is uninstallable and incompatible with Lucid." [Undecided,New] https://launchpad.net/bugs/568193
<ScottK> There's a goodly number of removal requests stacked up there.
 * ajmitch can think of a few packages which would be nice to remove
<slangasek> jdong: sure, there are two people running lucid saying "splashy error problem exists" - I can't see how this rules out there being a big explosion if they managed to get splashy installed. :)
<jdong> slangasek: haha don't get me wrong, I'm equally amused at how people can have "Lucid" setups that boot with splashy installed
<slangasek> but they /don't/ have splashy installed
<slangasek> because they got the conflicts error message
<slangasek> so the undeclared file conflicts is saving them from themselves
<jdong> lol it would seem that way.
<jdong> but that hardly makes this year-old bug a feature ;-)
<persia> I think 568193 is the clear and obvious solution.
 * slangasek nods
<jdong> ok, and onwards towards more productive uses of our minds!
<Keybuk> every time I see his quit message, I want to shout and rant and rave
<jdong> haha
<Keybuk> because clearly he's never seen a baby try and figure out a nipple for the first time
<Keybuk> or known a woman who understands that babies get it wrong and bite
<Keybuk> et.c
<Keybuk> </downfall moment>
<ion> Perhaps the phrase is deeper. âThe only intuitive interface is the nipple â and even itâs not intuitiveâ? :-P
<Keybuk> I'd go with
<Keybuk> "There's no such thing as intuitive, there's just things that are familiar based on other things you've already learned"
<Keybuk> and I bet I'd get a gold star from mpt for that
<jdong> everything should have one button but it's up to you to figure out what to.... oh.
<jdong> eh I was close.
<Keybuk> if there was just one button, with "PUSH" written on it, somebody would pull it
<Keybuk> to prove that, go to any public restroom and look at the tap on the sink
<jdong> so we just call them security engineers and move on ;-)
<stgraber> Keybuk: you'd need a button that works whatever you do (except nothing ;))
<JanC> <Keybuk> "There's no such thing as intuitive, there's just things that are familiar based on other things you've already learned" --> isn't that the definition of intuition?  :P
<Keybuk> no, the definition of intuition is knowing things without having learned them
<ion> Visits to public restrooms tend to go better if you refrain from looking. In fact, the more senses you suppress the better. (Perhaps Finns just suck more than the saner part of the planet at this whole public restroom business.)
<JanC> you didn't learn those things, you make a guesd based on other things you learned  ;)
<JanC> *guess*
<JanC> (without knowing you base your guess on that)
<Madkinder> Hi. Upon uploading my new package to PPA I get "Unable to find distroseries: unstable" error. I googled for it and everybody suggests to hardcode the series to a particular Ubuntu version.
<Madkinder> The problem is that I want to upload this package to both Debian and Ubuntu.
<Madkinder> I took irrlicht library as an example as it is maintained by the same person and it is present in both Debian and Ubuntu.
<micahg> Madkinder: you can set the series in your dput.cf
<Madkinder> the most weird thing is that debian/changelog version of Ubuntu's package contains unstable!
<micahg> Madkinder: #ubuntu-packaging is a better place to discuss
<micahg> Madkinder: if it's for PPA
<Madkinder> micahg: I didn't configure dput at all. I just used the new ppa/ppa-name syntax
<Madkinder> ok, if I'm on the wrong place
<micahg> Madkinder: I'm in the other channel too
<kees> jdong: did you just say I pull "push" doors?  :P
<jdong> kees: hahahaha :)
<jdong> kees: that buffer was marked char[80] for a reason!
<jdong> :)
<kees> hehehe  :)
<jdong> but hey, I'll admit to making sure push doors don't pull ;-)
<Damascene> how to test the xorg thing?
<Damascene> I heard there is need for testing
<SwedeMike> https://wiki.ubuntu.com/X/Testing/GEMLeak
<pitti> Good morning
<Damascene> glxinfo is not installed
<Damascene> is that normal
<Damascene> https://wiki.ubuntu.com/X/Testing/GEMLeak
<Damascene> UNE
<RAOF> That's not unexpected; I don't think anything depends on glxinfo.
<RAOF> (Or, rather, mesa-utils)
<Damascene> seems like terminal auto-completion become slower
<Damascene> I've extra compiz eanbled
<Damascene> enabled
<RAOF> I'm pretty sure that'll be placebo.
<pitti> auto-completion slowness is usually due to enabled bash-completion
<Damascene> what is placebo?
<Damascene> this is not the first time I use it
<Damascene> sudo aptitude install mesa-u* TAB takes long time
<RAOF> The placebo effect is from medicine, where giving people sugar pills while telling them that the pills will help makes the pills help.
<Damascene> now the completion is back to normal
<virtuald> damascene: that's because there are lots of packages, and now the list is cached
<Damascene> I see. thanks
<Damascene> by the way is there a way to upload photo to the wiki instead of using out side service
<mdke> Damascene: yes, see the "Attachments" link at the top of the page
<pitti> slangasek: gnome-keyring> upstream ack'ed the patch and committed it upstream with one refinement; he also confirmed that storing the password was an inadvertent glitch, not a design issue to make the user.keystore work; also, jdstrand pointed out that this is quite an easy root escalation hole for local processes (through sudo); so my confidence has risen a lot about this, and I'd rather like to see
<pitti>  it in lucid final; WDYT?
<slangasek> pitti: yes, please upload then
<pitti> will do (still giving it another round of testing)
<Damascene> mdke, thanks I see it now
<joaopinto> good morning
<Damascene> morning
<dholbach> good morning
<pitti> slangasek: I have another pkg-create-dbgsym which fixes building debug symbols for X (bug 562418); it's all testcase'd
<ubottu> Launchpad bug 562418 in xorg-server "many -dbg packages have debug symbols mismatch" [Undecided,Confirmed] https://launchpad.net/bugs/562418
<pitti> slangasek: should I upload this now, so that we have it available for the rush of after-RC uploads, or postpone?
<slangasek> pitti: go ahead and upload
<pitti> it's version 42, it *must* be good
<pitti> uploaded
<pitti> slangasek: it's in unapproved now
<lool> mvo: Mind pushing latest apt to bzr?  (ubuntu7)
<mvo> lool: ups
<mvo> lool: done
<lool> thanks
<chrisccoulson> who rejected libjdic-java from the queue? did micahg ask someone to do that?
<pitti> Riddell, ScottK: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt> should knm-runtime stop recommending the vpnc bits?
<pitti> same question about kigo recommending gnugo
<pitti> slangasek: seems http://launchpadlibrarian.net/18628527/mono_1.9.1%2Bdfsg-4ubuntu1_1.9.1%2Bdfsg-4ubuntu2.diff.gz got dropped in some merge in lucid; I'll upload it again to fix the mono-debugger entry in c-m, ok?
<slangasek> pitti: yes please
<pitti> slangasek: (I'll upload recommends fixes for xfonts-mathml and texlive-extra-utils as well, FTR)
<slangasek> pitti: cheers
<lool> bryceh: heya
<lool> pitti bryceh: I'm worried that I see my Xorg using 60%+ CPU ATM after swithing to the xorg updates packages
<ogra> lool, intresting, didnt happen for me
<ogra> it bumps up to 12-15% here in max
<ogra> and ma gem objects seem to look sane
<slangasek> Sarvatt: ^^ seen this issue that lool reports?
<lool> So I stupidly tried stracing Xorg
<lool> don't do that
<lool> I mean don't do that from a xterm in top of the Xorg you're stracing *cough*
<slangasek> haha
<slangasek> lool: has it fixed the actual leak problem for you?
<slangasek> lool: and what wm are you using?
<lool> slangasek: I think it did fix the leak
<lool> slangasek: I didn't try the test case, I had a workload causing the bug to manifest relatively quickly
<slangasek> ok
<lool> I'm unison-syncing my mail/, used to be 1 GB and is now about 500 MB and 30 000 files, that would not fit in the kernel caches after running Xorg for a while because GEM was taking kernel memory
<ogra> slangasek, for me it definately fixed it
<lool> and so suddenly my system would be hitting the disk hard all the time
<ogra> i has the gem objects counter running negative after 24h
<ogra> now it stays around 350000000
<ogra> s/has/had/
<pitti> lool: there's also some program called xrestop which might show you which client is actually causing so much X activity?
<pitti> (sorry, was away for lunch)
<tseliot> mvo: does update-manager disable nvidia on dist-upgrades from karmic to lucid? See LP: #568041
<ubottu> Launchpad bug 568041 in jockey "[Lucid] Upgrade from Karmic broke nVidia installation" [Undecided,New] https://launchpad.net/bugs/568041
<mvo> tseliot: it should not do that
<mvo> tseliot: hm, without the upgrade logs its hard to tell
<tseliot> mvo: can you ask the user to attach the relevant logs, please?
<mvo> tseliot: done
<tseliot> mvo: thanks
<lool> pitti: Ack; I remember using xrestop to track abusive x resource consumption, but not CPU; I will give it a try if I reproduce
<lool> it doesn't render my system unusable, just takes one full CPU, so should be debugable
<pitti> lool: right, that's worrysome; you never had that before?
<pitti> lool: once you can reproduce it, it might help to kill processes one by one, to see which one is causing it
<pitti> usually it's not really X itself, but some particular program which just spams it with requests
<lool> pitti: No, I never had that before
<lool> pitti: it might be another program indeed; unfortunately, I had to reboot
<slangasek> tseliot: hi, have you seen bug #567425?
<ubottu> Launchpad bug 567425 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: dpkg-divert: rename involves overwriting" [High,Triaged] https://launchpad.net/bugs/567425
<slangasek> (yet another divert bug)
<mdeslaur> thanks for fixing gnome-keyring pitti! :P
<c_korn> hm, if I see it corrently some patches in the vlc package make changes to configure.ac but autoreconf is never run. there neither is a autoreconf.patch nor is it run in debian/rules
<pitti> mdeslaur: with pleasure :)
<seb128> pitti is made of awesome no doubt ;-)
<mdeslaur> :)
<seb128> does anybody knows about nis and has an idea about bug #553142
<seb128> ?
<ubottu> Launchpad bug 553142 in gdm "gdm does not obey NIS settings for user groups" [Low,New] https://launchpad.net/bugs/553142
<seb128> not sure if that's a gdm issue
<slangasek> smoser: ping
<smoser> slangasek, here
<slangasek> smoser: hi - just checking to see if you were around yet :) I think the RC will be ready to go out within an hour or two
<smoser> oh wow. i'll get the amazon pages ready.  the images have been pre-published as rc.
<slangasek> yep, saw that, thanks
<ttx> slangasek: are you fully operational /without/ smoser ? I heard he might be lost in a small island during release week.
<smoser> i think they have network access there.
<slangasek> "lost in a small island"? :)
<ttx> slangasek: a tax haven, if you see which one I'm referring to.
<smoser> volcano permitting i'm going to be sprinting with niemeyer
<slangasek> ttx: yes, I have all the info, but it's convenient to have a second set of hands for that stuff since it's highly parallelizable wrt the rest of the publishing
<ttx> slangasek: ok, was just belt-and-suspender checking that we are not vulnerable to subaquatic cable cuts
<smoser> slangasek, the scripts have never been tested for moving from an rc to a release (the promote-daily), assuming we wanted the 20100420 as GA.
<smoser> going from daily to 'release' should be easy, so i will just make sure that daily gets kept around until we know its not fit.
<slangasek> smoser: in practice we've never reused an rc as ga without changes; we already know we have a queue of updates that we'll accept, at least some of which will touch UEC/EC2 images
<smoser> then its not to worry
<apw> pitti, just confirming that your "dell don't suspend" work on the machine i have which is affected
<Riddell> pitti: knm-runtime does not recommend vpnc except on sparc where the newest version hasn't compiled
<pitti> Riddell: oh, thanks; I thought c-m would only consider i386/amd64 (at least it seems to ignore the ia64 ones)
<Riddell> pitti: that's the only reason I can see it would still have that listed anyway
<c_korn> any chance the new vlc-1.0.6 makes it into lucid (before the release)? according to the news it has only security and stability fixes: http://www.videolan.org/news.html
<mvo> ccheney: hi, I uploaded a new OOo based on my branch (the one I proposed for merging). I uploaded from the apt-get source tarball becuase it appears that bzr is not up-to-date with the archive
<slangasek> superm1: do we get a http://mythbuntu.org/10.04/rc page for this round?
<superm1> slangasek, yes; i'll ping the guy to get it up there, thanks for the reminder
<slangasek> superm1: n/p
<slangasek> mterry: hi, is bug #528887 going to make it for release?
<ubottu> Launchpad bug 528887 in netbook-launcher-efl "maximus does not give default focus to newly started apps in combination with efl launcher" [Medium,Triaged] https://launchpad.net/bugs/528887
<mterry> slangasek, ah yes, I was going to look at that today/tomorrow
<slangasek> mterry: ok, great
<tseliot> slangasek: as regards LP: #567425 , I think something like this would suffice: http://pastebin.ubuntu.com/420452/
<ubottu> Launchpad bug 567425 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: dpkg-divert: rename involves overwriting" [High,In progress] https://launchpad.net/bugs/567425
<slangasek> tseliot: what owns the file that you're rm -f'ing?
<slangasek> tseliot: in theory, you should just conflict with that to force it off the system beforehand
<tseliot> slangasek: xorg-driver-fglrx from either the repository or from the ati installer
<jdstrand> pitti: thanks for all your work on gnome-keyring. I've got a couple machines that are affected that I haaven't fixed yet-- do you need more testing (standard desktop installs, nothing fancy)?
<tseliot> slangasek: what I did in the patch is something I've been doing with nvidia for while now to get rid of the diversion ugliness ;)
<slangasek> tseliot: but an older version of xorg-driver-fglrx, right?  So Conflicts: xorg-driver-fglrx (<< $version) is possible?
<tseliot> slangasek: yes, older versions of that package. But still we can't be sure about which version the ati installer installed
<ccheney> mvo: ok
<slangasek> tseliot: ah - argh
<slangasek> tseliot: ok, do it the ugly way then :/
 * ogra_cmpc would suggest to do both
<tseliot> slangasek: it's all about ugliness with these things ;)
<ogra_cmpc> conflict and check if the file still exists
<ogra_cmpc> then rm it if it does
<slangasek> tseliot: then in maverick, you can drop the transitional package and conflict unconditionally :-P
<tseliot> heh
<slangasek> apw: did we overlook something wrt making 'nomodeset' work again?: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539878/comments/15
<ubottu> Ubuntu bug 539878 in linux "nouveau out of sync LVDS (basically card not supported)" [High,Triaged]
<joaopinto> slangasek, yesterday Keybuck mentioned he migh have found a mountall bug related to that LVM mount issue, do you happen to know anything about it ?
<slangasek> joaopinto: yes, mountall didn't have the fix to raise its udev input buffer to a sensible value, so could drop events when they came in too quickly
<slangasek> joaopinto: fix is committed to bzr; chances are this fixes all the unreproducible "my device didn't get mounted" issues
<joaopinto> there is one persone on #ubuntu+1 reporting an issue, but on his case it's LVM+crypted swap, but it's random, so I am not sure it's the same issue to advise him to try the ppa version
<slangasek> I don't know if Keybuk uploaded to ppa
<ion> He did
<slangasek> then yes, advise to test
<joaopinto> ok
<pitti> jdstrand: I'm pretty confident on it by now, but of course more testing is always good
<pitti> jdstrand: there's a package in ppa:ubuntu-desktop/ppa; it's my original patch, though, not the refined one from upstream
<pitti> jdstrand: but if you want to, feel free to grab the source from the queue (dget http://launchpadlibrarian.net/45006207/gnome-keyring_2.92.92.is.2.30.0-0ubuntu3.dsc) and build locally?
<pitti> oh, dget wouldn't actually work there, sorry; you need to grab the diff individually
<jdstrand> pitti: cool, I'll build from unapproved. again, thanks! :)
<lamont> wow.  X performance sucks after the last reboot I did here.  I wonder what got turned on or killed or such
<apw> slangasek, nothing that i am aware of
<joaopinto> slangasek, mountall ppa didn't fix, but this seems to be different case, I will try to reproduce
<slangasek> superm1: still no love on http://mythbuntu.org/10.04/rc
<slangasek> joaopinto: ok
<superm1> Daviey, could you just copy the beta2 page to rc  and s/beta2/rc/ until tgm can more properly give it love?^
<tseliot> lamont: maybe because of this? https://lists.ubuntu.com/archives/ubuntu-devel/2010-April/030673.html
<ogra> lamont, use a bucket to catch gem objects
<tseliot> :-D
<lamont> that would make sense
<lamont> grep: /sys/kernel/debug/dri/0/gem_objects: No such file or directory
<lamont> except for that
<ogra> cat ?
<ogra> hmm, no, indeed
<lamont> # ls -la /sys/kernel/debug/dri/
<lamont> total 0
<lamont> drwxr-xr-x  2 root root 0 2010-04-22 07:35 .
<lamont> drwxr-xr-x 14 root root 0 2010-04-22 07:35 ..
<lamont> #
<lamont> iz boring there
* slangasek changed the topic of #ubuntu-devel to: Lucid release candidate is out! | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<dholbach> wooooo!
<lamont> mind you, I killed all visual effects (Appearance) in order to get my keyboard focus back, since metacity has it, but compiz never learned about strict
<ogra> intel card ?
<lamont> and really DO. NOT. CARE. about visual effects and pretty wizzy stuff... just want machine cycles for me, thanks
<lamont> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
<lamont> inspiron 1520
<ogra> weird
<ogra> even if you dont run compiz the dri module should be loaded and create that file
<lamont> right now, I have overlapping firefox and xchat windows.  switching between them results in 4-5 seconds of X taking 90% of one of two cores
<lamont> more like 96%
<lamont> this is the fresh lucid install, too
<lamont> well, from beta1
<ogra> sounds a bit like what lool reported
<ogra> and i think Keybuk had similar issues
<lamont> and GM card
<ogra> (at least both were load related)
<lamont> I'd be happy to test a fix....
 * ogra hasnt one ... 
<seb128> lamont, do you use the lucid version or the ppa one which had a call for testing?
<ogra> nor do i have a bug with the fixed gem objects thingie
<lamont> and we expect that the GEMLeak fix is different?
<lamont> seb128: stock lucid at this point
<seb128> ok so it's not a bug in the candidate fix at least
<seb128> I doubt it's the issue you are having anyway there
<lamont> seb128: not a regression in it no.  probably a "still a bug" bug
<jdstrand> mvo: is 'do-release-upgrade -d' supposed to work with hardy - lucid upgrades?
<mvo> yes
<jdstrand> mvo: as in, 'right this second'
<jdstrand> hmm
<mvo> what is the error? or just nothing?
 * jdstrand wonders why it said 'No new release found'
<jdstrand> I do use a local debmirror
<jdstrand> but that didn't stop a recent karmic - lucid desktop upgrade via update-manager -d
<jdstrand> mvo: could Acquire::http::Proxy being set affect things?
<jdstrand> mvo: scratch Acquire::http::Proxy -- I'm not actually using that
<jdstrand> mvo: nm-- seems it needs to contact rookery.canonical.com for stuff-- this machine has outgoing http blocked
<persia> jdstrand: That would be getting the newest hints files to work around known issues.
<jdstrand> makes sense
 * jdstrand temporarily adjust firewall
<lamont> jdstrand: the metafiles that say what do-release-upgrade can do live on rookery
<jdstrand> cool, easy enough to fix
<lamont> so not just known issues
<lamont> so first I get to wait for it to slow down again, and thereby see howlong it takes for evil
<mvo> jdstrand: longer term we want to shift them to archive.u.c
<jdstrand> it also seems to want lithium.canonical.com
<jdstrand> lamont: what is that for? ^
<lamont> archive.u.c includes lithium
<jdstrand> hmm, it would be nice if it used my debmirror there...
<jdstrand> ok
<lamont> jdstrand: to do that, you need to remove all mention of *.archive.u.c from sources.list
<lamont> then it goes "ZOMG shall I use yours?"
<lamont> otherwise, it disables all local archives
<lamont> for values of local != *.archive.u.c
<jdstrand> lamont: negative. I don't have any reference to archive.u.c
<jdstrand> and apt-get update just proved that to me
<lamont> I wonder if it's fetching the lucid tarball
<lamont> anyway, dunno
<jdstrand> mvo: is this expected as well? ^
<jdstrand> extracting 'lucid.tar.gz'
<jdstrand> seems that was it, yes
<lamont> \o/
<lamont> that's one of them special files from update-mangler
<AaronMT> Which build of Firefox is bundled in the RC? 3.6.2?
<Pici> AaronMT: 3.6.3
<AaronMT> Thanks
<persia> lamont: jdstrand: There's a confuguration file that lets you change the "official mirror" if you want to get something network-closer when using python-apt's sources.list munging.
<lamont> persia: nice
<lamont> persia: I just cheated when I did my mirror, and abused DNS like there was no tomorrow
<lamont> archive.ubuntu.com has address 192.168.35.42
<lamont> but I won't support such activities
<Caesar> So https://wiki.ubuntu.com/Bugs/HowToFix has the most contrived example possible
<Caesar> What I'd like to know is if I'm fixing a bug in a package that currently lacks a patch system, should I be introducing a patch system or just fixing the bug and letting the change wind up in the diff.gz directly?
<cjwatson> just fix the bug
<Caesar> If it makes a difference, I'm trying to cherry pick a fix for bug #539814
<ubottu> Launchpad bug 539814 in tar "FFe: Sync tar 1.23-1 (main) from Debian squeeze (main)" [Unknown,Fix released] https://launchpad.net/bugs/539814
<Caesar> cjwatson: ok thanks
<cjwatson> the general rule is that we should avoid changing the packaging structure of packages we modify relative to Ddebian
<cjwatson> *Debian
<Caesar> cjwatson: makes sense
<ScottK> Caesar: This is even more true for SRUs (like I assume you are working on)
<zul> slangasek/pitti: when you get a chance can you have a look at #533029
<persia> For those that have extra time, if there are no other patches in the packaging, it may be worth trolling through the Debian Maintainer's other packages to see if they have a preferred patch system, etc. but in most cases, this isn't useful or necessary. (and never correct for SRUs)
<cjwatson> hopefully all this will become irrelevant over time given http://upsilon.cc/~zack/stuff/dpkg-v3/
<cjwatson> I don't think converting 1.0 to 3.0 (quilt) in Ubuntu is any wiser than other conversions, though
<Caesar> Grr. This is not easy :-(
<tseliot> slangasek: ok, I have tested and uploaded my fix for fglrx. The fix is also upstream, in git
<jdstrand> pitti: fyi, tested gnome-keyring on a few systems and it worked beatifully. nice work! :)
<pitti> jdstrand: cheers :)
<Q-FUNK> slangasek: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/416305   does it make sense to merge this now?
<ubottu> Ubuntu bug 416305 in base-files "please invert shell prompt and profile.d sections in /etc/profile" [Unknown,Fix released]
<ccheney> slangasek: i got a bug today about openoffice.org-hyphenation file conflict that i will probably need to fix, will try to get it prepared and tested by later today/early tomorrow
<ScottK> ccheney: There's an OOo upload in queue right now.  I think we have at most one more OOo upload before release.
<ccheney> ScottK: openoffice.org-hyphenation isn't part of the OOo source
<ScottK> ccheney: Oh, right.  Sorry.
<ccheney> ScottK: the new ooo-dictionaries package added some more bits that used to only be in the hyphenation package so it needs those parts removed and verify the replaces line, maybe more checking to verify thats all that broke
<ccheney> ScottK: openoffice.org-hyphenation only exists in Ubuntu and is there to fill in the gap from the dictionaries source package
 * ccheney bbiab
<mathiaz> mvo: hi!
<mathiaz> mvo: it seems that there is some issue with mysql on upgrade from 8.04 to 10.04 - bug 568606
<ubottu> Launchpad bug 568606 in update-manager "mysql-server removed when upgrading from 8.04 to 10.04" [High,New] https://launchpad.net/bugs/568606
<mathiaz> mvo: I've attached all the logs from /var/log/dist-upgrade/ as well as /var/log/apt/term.log to make sure mysql-server was installed before the upgrade
<mathiaz> mvo: do you need anything else?
<Keybuk> slangasek: is bug #567964 matching a pattern you know about?
<ubottu> Launchpad bug 567964 in mountall "mountall keeps on running " [Medium,Confirmed] https://launchpad.net/bugs/567964
<slangasek> Keybuk: I would infer that's bug #559761
<ubottu> Launchpad bug 559761 in mountall "mountall needs to flush plymouth message queue before emitting upstart events" [High,Fix committed] https://launchpad.net/bugs/559761
<Keybuk> that's the one I was thinking of
<Keybuk> thanks
<Keybuk> couldn't find/remember the bug'
<upd> this tcptraceroute program really don't seem like it would work, i get anywhere  * * * for response ? is this event ubuntu question ?
<ScottK> upd: No.  That's the same no matter where you run it.
<upd> ah okey
<ramvi> Building plymouth from source returns an error only when building for i386... What can I do?
<mvo> mathiaz: thanks, the logs looks complete
<persia> ramvi: Track down the error.  Last time I encountered a per-arch build failure on plymouth, it was related to the build-status of libdrm2 (but I suspect it's unlikely to be the same cause).
<Chipzz> upd: I have used tcptraceroute on numerous occasions, and yes, it does work
<upd> well it does not work for me.
<Chipzz> I do however not see how your question is relevant here ;P
<Chipzz> problems on your side then.
<upd> i send syn packet's and get back icmp packet with time-to-live flag set on, but tcptraceroute doesn't show anything
<Chipzz> are you aware that tcptraceroute is not traceroute?
<upd> yes
<Chipzz> and that both do very different things?
<upd> yes..
<upd> well, i'm not sure how it works, i think the response is the same in both program, but tcptr send tcp/syn packet instead of udp packet
<ScottK> This probably isn't the best channel for the discussion, however.
<upd> so, tcptr will work only if target has open ports ?
<Chipzz> that's the whole point...
<upd> ScottK, wher can i ask than ?
<upd> ah okey than
<ScottK> upd: No idea, but it's nothing to do with Ubuntu development
<Chipzz> upd: small suggestion: you are expected to read the topic of a (/any) channel before talking there; pls make a habbit out if it ;)
<upd> yes yes
<pitti> directhex: indicator-application> erm, renaming binary packages after RC? any chance that this could be moved to maverick, and we just fix the .pc?
<directhex> pitti, already went through this with slangasek. it'll mess up backports badly to need to re-break the packages each time
<pitti> directhex: ah, did he ack it?
<pitti> at least those packages don't have any rdepends
<directhex> pitti, yeah. 1 rdepends, banshee-community-extensions in universe
<directhex> pitti, i can find the logs if you like
<directhex> or #ubuntu-release is logged i guess
<pitti> directhex: oh, if he ack'ed it, that's fine for me
<pitti> directhex: i. e. your word for it
<directhex> pitti, hopefully next time canonical folks are making a mono binding, they can copy-paste the packaging from lib1u or now from libappindicator
<directhex> or make raof do it, he's your best mono person on staff
<apw> pitti, this keyring update, does installing that do the cleanup you mention or is some other part of the upgrade process responsible..  ie. if i am already upgraded to close to -rc will i get cleaned too?
<pitti> apw: it's not in the postinst, since it's per-user; cleanup happens on startup of gnome-keyring-daemon, i. e. when you log into GNOME
<pitti> apw: yes, we'll keep the cleanup in lucid final
<pitti> and drop it in maverick
<pitti> we might perhaps drop it in 10.04.2 or so, but it doesn't really hurt
<persia> Seems a bit invasive for 10.04.2
<apw> pitti, cool as long as i will be cleansed too i am happy, thanks for the clarification
<pitti> directhex: ah, found the discussion
 * pitti accepts and watches NEW
<pitti> directhex: why is there a version mismatch? libappindicator0.0-cil vs. libappindicator0.1-cil-dev ?
<directhex> pitti, i'm just going with the API and ABI versions that upstream (i.e. you guys) have in the source
<pitti> ok, so that's intended?
<pitti> NEWed, so banshee-community-extensions shold build now
<directhex> pitti, it's intended for the package to fit upstream. whether that's what *upstream* meant to say is another matter ;)
<sebner> directhex: let's ask upstream *muahahahaha*
<directhex> pitti, should i request an immediate rebuild of b-c-e then? is there any publishing delay to worry about?
<persia> You probably at least want libappindicator0.1-cil-dev to build and be published.
<ScottK> directhex: You'd actually rather just wait.
<directhex> ScottK, thought as much
<ScottK> Automatic retries get the build priority the package originally got.  Manual retries get a build priority of 0.  Touching of a manual retry will actually slow things down.
<directhex> ooh, advanced technology
<persia> Well, it depends on why the rebuild will be required.  For things not DEPWAIT, you still have to press the button.
<Caesar> Whoa: http://www.osnews.com/story/23191/Rumour_Apple_To_Acquire_ARM_
<ScottK> Caesar: I imagine they're too busy sueing themselves now that Android can run on iPhone.
<Caesar> ScottK: heh
<joaopinto> more people reporting unable to mount with LVM, but no one caring enough to test the fix :\
<arand> joaopinto: Could be done in VM?
<joaopinto> arand, I was not able to reproduce, but I don't know much about LVM either
<arand> joaopinto: Ah, well me neither, but would happily mess about a bit in a VM if it would help.
<joaopinto> arand, I just know it fails to mount some LVs
<jdstrand> slangasek: hi-- is it accurate to say that everything that is in main should be in a seed file?
<seb128> jdstrand, no, lot of things are depends of things which are seeded
<seb128> jdstrand, no, lot of things are depends of things which are seeded
<seb128> ups
<persia> Or recommends od stuff that is seeded.
<persia> And lots of stuff is seeded but not in main.
<persia> Because only some seeds are considered for main inclusion.
<jdstrand> so a seed it the very toplevel, and it will pull in what it needs
<jdstrand> is that accurate?
<persia> All this will actually make sense once components go away, and we don't have "main"
<jdstrand> (for the seeds considered for main inclusion)
<persia> Kinda.
<persia> It actually requires manual action by an archive admin to move stuff between components.
<persia> But that's driven by a combination of MIRs and http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<jdstrand> right
<persia> And component-mismatches is generated by actions on the seeds.
<persia> (well, a subset of the seeds)
<ScottK> Or changes in build-depends, depends, and recommends of seeded packages and the packages they pull in.
<jdstrand> I didn't mean it automatically happens-- I mean that everything a seeded item depends on, if that seed is considered for main, should end up in main-- if it isn't, there is component-mismatches
<persia> Well, let's say component-mismatches is generated based on the current state of the archive and a subset of seeds.
<persia> jdstrand: That's roughly correct.
<persia> jdstrand: That said, the answer is to clear component-mismatches.  The right way to do this may not involve promotion/demotion: it may involve changes to other packages so that something does/doesn't end up as part of the depends/recommends tree.
<persia> jdstrand: And whilst you're at it: how about those binary-only demotions :)  linux-headers-2.6.32-21-versatile is only interesting for folks running in qemu, which isn't well supported, libappindicator0-cil/libappindicator-cil-dev will go away soon thorough NBS.  libboost... ought get investigated to find out why it's no longer in the depends/recommends tree
<jdstrand> persia: is does seem that component-mismatches won't complain if something is in main, but isn't seeded and/or nothing in the rdepends chain is seeded
<persia> It should.
<jdstrand> persia: devio is an example
<persia> That's where the source and binary demotions list is generated.
<persia> jdstrand: How many architectures did you check for depends/recommends?
<jdstrand> it's rdepends in slugimage
<jdstrand> good point
<persia> jdstrand: I'd recommend checking the component-mismatches code directly (although I don't remember what geneates it: I thought it used to be anastasia, but I heard that was deprecated at one point)
<persia> That should give you a better understanding than speculations :)
<jdstrand> heh
<persia> I've just gotten confused between  lp:~ubuntu-core-dev/ubuntu-seeds/unr.lucid and  lp:~ubuntu-core-dev/ubuntu-seeds/netbook.lucid : Does anyone know why both exist?
<persia> Also, if anyone feels like marking https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/mobile.lucid as Abandoned, I'd appreciate it.
<lool> cjwatson: While upgrading, got prompted on which devices to run grub-install on; I had recently dpkg-reconfigured grub-pc and selected sda, sdb, sdd, sde after sdc had failed and had been replaced with sda in my RAID10 setup, but in the upgrade dialog only sde was selected; will file a bug
<YokoZar> Keybuk: poke
 * persia advocates avoiding contentless pokes for all the same reasons one avoids contentless pings
<jdong> pitti: do you have a preference on SRU versioning conventions for lucid-proposed? Most of the debdiffs I'm coming across are using bump-by-1 versions as if they are non-SRU uploads...
<persia> That would be just plain wrong.
 * jdong also bawks at the sheer complexity of http://launchpadlibrarian.net/45030477/poppler_0.12.4-0ubuntu4_2_0.12.4-0ubuntu5.debdiff
<mathiaz> slangasek: hi - do you think bug 529686 is worth fixing?
<ubottu> Launchpad bug 529686 in acpid "Depressing power button does not shutdown computer" [Medium,Triaged] https://launchpad.net/bugs/529686
<mathiaz> slangasek: in time for the release of lucid?
<seb128> jdong, persia: I've always updated the version by one when doing sru updates
<seb128> especially when the new serie is not open and there no way to conflict
<seb128> and usually after too because we often get new versions in the new serie anyway
<persia> I'd think that dangerous, as there's no good way to communicate with others that one is doing this, so the same increment with entirely different contents could get pushed to maverick.
<seb128> the sru team review debdiffs
<persia> I recall that the convention of using .X was encouraged for SRUs (although I'm not an SRU person)
<seb128> I fail to see where it would be dangerous
<seb128> the good way is the upload target in the changelog
<persia> Because you might upload foo-1.2-3ubuntu5 to lucid-proposed, and I might upload a completely different foo.1.2-3ubuntu5 to maverick.
<seb128> that would fail
<persia> Safer to have had you upload 1.2-3ubuntu4.1 in the first place, because then I don't have to check what you did.
<seb128> 2 versions of the same source can't be accepted
<seb128> if you do that one upload will fail and then you have to fix what you screwed
<persia> Even to different series?
<seb128> yes
<seb128> well I think so, I didn't try recently I think
<jdong> seb128: for packages where the maintainer keeps a VCS, I don't have any issues with full version bumping, but the SRU versioning policy is the same as the Security versioning policy...
<jdong> which means you should be doing X.Y bumps
<seb128> security has an harder job that they touch packages they don't usually maintain
<seb128> so it's easier to not screw with that convention
<seb128> but for a source you maintain and where you know what you are doing...
<persia> jdong: Regarding painfully long patches: You could always insist on DEP3
<seb128> the patch is a git commit backport
<jdong> persia: it's not the length, it's that the diff seems to completely reimplement the text selection algorithm, though as a upstream git commit, it seems fine
<seb128> the issue has been discussed already and pitti said to do a sru rather than try to get the change in lucid now
<seb128> the issue is an annoying want that we would like to see fixed in a lts
<seb128> the issue is an annoying want that we would like to see fixed in a lts
<seb128> ups
<jdong> *nods* I totally agree with you on the merit
<persia> I only suggested DEP3 to force the link to the git commit: not to suggest it shouldn't go.
<seb128> I tend to not tag git commit
<seb128> they have the commit id info already
<persia> I try to do at least author/source/bug when cherrypicking just for ease of reference by others.
<persia> But I generally like to try to make it easy for *anyone* to be the next person making a change to a package I touch.
#ubuntu-devel 2010-04-23
<psusi> Keybuk, last night my testing showed some improvement on ureadahead after the defrag, but still not as good as I think it should be... today I've been working on an idea that I think could punch it up another level... right now it calls readahead() on each file, but this stalls on indirect blocks, and can't be done on the directories, which is where the open() loop waits a lot
<psusi> Keybuk, so what if instead when generating the pack file, we first, add the directories on the paths to the files to the list of files, then translate the block addresses to absolute block addresses, use e2fslibs to look up any indirect blocks and add them tot he list, then merge the list into a series of extents of raw block addresses
<psusi> then readahead() that list on the raw block device
<psusi> in theory that could result in a single massive read
<Caesar> ScottK: you're captain backports, aren't you?
<smoser> hggdh, you there ?
<ScottK> Caesar: I'm involved in them.
<kees> hm, LP doesn't like my src-format-3 package..
<kees>   dpkg-source: info: applying networkmanager.patch
<kees>   1 out of 8 hunks FAILED -- saving rejects to file
<kees> policy/modules/services/networkmanager.te.rej]
<kees> this doesn't happen for me locally...
<hggdh> smoser: I am here
<Keybuk> psusi: no idea, try it :-)
<Keybuk> YokoZar: hello?
<YokoZar> Keybuk: There was some discussion in #ubuntu-motu earlier about using invoke-rc.d procps start || true   instead of start procps || true  in postinst scripts
<Keybuk> YokoZar: since procps is an Upstart job, that would be wrong
<YokoZar> Keybuk: Well let me link to you what lool said: https://bugs.launchpad.net/ubuntu/+source/wine/+bug/447197/comments/52
<ubottu> Ubuntu bug 447197 in wine1.2 "Packages with custom /etc/sysctl.d/30-foo.conf files can fail to install: start procps returns exit status 1" [Undecided,Fix released]
<kees> YokoZar: the "|| true" will fix that.
<YokoZar> kees: the || true fixed that in the bug report, yes, but we're talking about the first part (start procps vs invoke-rc.d procps start)
<kees> YokoZar: it must be "start".
<kees> YokoZar: using invoke-rc.d for an upstart job is wrong.
<Keybuk> lool is wrong
<Keybuk> any new code should be written to use the native Upstart interfaces
<Keybuk> the /etc/init.d/procps symlink is only there to teach humans to use the new interface
<YokoZar> Keybuk: kees: what about policy-rc.d ?
<Keybuk> using that for Upstart jobs is also wrong
<Keybuk> anything *-rc.d is wrong for Upstart
<Keybuk> those are sysvinit tools
<YokoZar> So people who have made one should migrate configuration to upstart?  Does upstart cover everything in 10.04 now?
<Keybuk> no, not yet
<YokoZar> So how do we handle the mixed case then?
<Keybuk> we are migrating from one system to another
<kees> YokoZar: procps moved to upstart, therefore it should use "start" instead of the *-rc.d commands
<Keybuk> things migrated to the new system should use the new interfaces
<YokoZar> ok that makes sense
<Keybuk> otherwise what is the point of spending years writing a new init system if everyone carries on pretending it's still the old one?!
<jdong> is KDE4 going to spend another year writing an init system abstraction layer wrapper?
<jdong> *ducks*
<Keybuk> KDE4 will probably write an abstraction layer to an init system abstraction layer
<jdong> :)
<Keybuk> in case they want to change init system abstraction layers later on
<jdong> I can totally see that happening though :)
<YokoZar> Keybuk: well one option is to keep using the old one as compatibility until everything is in upstart and then deprecate it
<Keybuk> YokoZar: if we do that, we'll have a great big flag day
<Keybuk> and realise that the Upstart interface isn't up to the job
<YokoZar> Yeah
<jdong> on a slightly related note, what's the purpose of the "service" command
<YokoZar> red hat compatibility I think
<kees> YokoZar: so now we'll have wine back in the archive?  did you test all the conffile transitions?
<Keybuk> jdong: compatibility with RHEL
<jdong> Keybuk: ah. so we're not supposed to use it as the replacement for invoke-rc.d
 * Keybuk wonders whether the RHEL 6 "service" command knows about Upstart
<Keybuk> jdong: no
<jdong> *nods*
<YokoZar> kees: Yes that was working before it disappeared from the archive (it's the same as the wine1.2 code too)
<YokoZar> kees: actually technically it didn't disappear so much as have source but no binary
<kees> YokoZar: okay.  I guess it's okay to have two binary packages fiddling with the same debconf value.
<Keybuk> YokoZar: Upstart is still being developed
<YokoZar> kees: two conflicting binary packages at that
<Keybuk> and I want it to not just be "good enough" but *perfect*
<Keybuk> so the whole point of using its interfaces now is to discover where they're not good enough, let along not perfect
<Keybuk> something to do with eating dog food ;)
<YokoZar> That's fair
<kees> YokoZar: oh! they conflict? excellent, that makes me worry much less.
<jdong> kees: btw, when is Ubuntu planning to issue a patch for that fun reiserfs xattr root exploit?
<Keybuk> +CONFIG_FS_REISERFS=y
<Keybuk> -CONFIG_FS_REISERFS=n
<jdong> hahaha :)
<YokoZar> Keybuk: This whole discussion tells me we need to document this somewhere official-sounding, preferably debian-inclusive (policy manual?)
<ion> I was under the impression the point of the service command was to run init scripts under a consistent environment, i.e. with / as the pwd and no crap in environment variables, in case the scripts/daemons are written poorly and shit themselves in the wrong environment. And they are, and they do.
<Keybuk> YokoZar: feel free to include it in the Ubuntu policy manual
<Keybuk> ion: it doesn't really do that though, does it?
<YokoZar> Keybuk: if I do that will you write a lintian test that complains about rc.d?
<Keybuk> YokoZar: no, lintian is written in a programming language I do not write
<kees> jdong: it's in progress; I'm waiting on the kernel team for an update.  http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-1146.html
<ubottu> The Linux kernel 2.6.33.2 and earlier, when a ReiserFS filesystem exists, does not restrict read or write access to the .reiserfs_priv directory, which allows local users to gain privileges by modifying (1) extended attributes or (2) ACLs, as demonstrated by deleting a file under .reiserfs_priv/xattrs/. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1146)
<ion> keybuk: It does cd / and env -i ...
<Keybuk> ion: that's nowhere near a "sane environment"
<jdong> kees: ah, cool. We don't mount -o user_xattr by default if a user installs onto reiserfs... right? *cringe*
<Keybuk> ion: e.g. where's the code to reset the process mark and clear pending signals currently masked?
<kees> jdong: no, user_xattr is highly non-default
<jdong> kees: ok, *whew*, that's at least... better :)
<Keybuk> mark? mask!
<ion> keybuk: I never said sane. ;-)
<YokoZar> kees: while I have your ear can I talk about cautious-launcher?
<kees> YokoZar: sure thing
<YokoZar> kees: If I remember our UDS discussions, it's supposed to permit removable media (CDs, sticks) correct?  Is this handled through the gvfs mount options?
<ajmitch> jdong: that's a rather special bug there for reiserfs :)
<Keybuk> in fact
<Keybuk> I'm going to be mean
<kees> YokoZar: it follows the filesystem markings, so if an external device has been mounted without execute, that's a bug with the mounting process.
<jdong> ajmitch: oh it's a really fun one. (1) make your own biinary, (2) mark it suid root, (3) profit!
<Keybuk> I'm going to add code to initctl to refuse to run if called from invoke-rc.d ;-)
<jdong> ajmitch: let's hope there's no hapless reiserfs+beagle users that decided to mount -o user_xattr ;-)
<kees> Keybuk: please don't do that for lucid.
<ajmitch> first upload to maverick will be upstart with that change?
<YokoZar> agree 100% with kees here ;)
<Keybuk> kees: no, not for lucid
<Keybuk> for maverick
<YokoZar> If you do that we don't need the lintian test since the package will fail to install
<ajmitch> I wonder how many universe packages would need to be updated for that
<YokoZar> ajmitch: I'm guessing it's on the order of 10
<ajmitch> YokoZar: all ones you've been touching?
<kees> Keybuk: maverick, yes, +1.  :)
<YokoZar> ajmitch: I've touched about 3 so far, and they're all "weird" compared with most universe stuff.  Init script stuff seems like something main packages are far more likely to deal with
<ajmitch> having lots of nice intentioanl breakage is what maverick's all about, isn't it?
<jdong> ajmitch: can't we just rely on a pulseaudio upload to do that?
<YokoZar> Maverick will take the "light" theme to a new level by continually increasing the gamma correction as you use the computer
<jdong> YokoZar: and maybe it'll finally be completely impossible to tell which window is in the foreground!
<ajmitch> jdong: it isn't yet?
<jdong> ajmitch: it's pretty close to.
<jdong> but if you sit around scratching your head and alt-tabbing a few times, you'll eventually figure it out
<jdong> or realize it's time for an eye exam
<YokoZar> There will be an innovative solution to that using the empty upper right of the window jdong
<YokoZar> jdong: it will say "I am your window, use me!"
<ajmitch> or the active window title will have <blink>
<Keybuk> huh?
<Keybuk> it's easy to tell which one is active
<jdong> YokoZar: awesome! Now I can click the magical orb thing when I mean to close the window.
<jdong> Keybuk: well maybe Santa needs to buy me an IPS panel but they look like very similar shades of cream to me.
<Keybuk> jdong: I tell by whether the window controls are lit
<YokoZar> I'm going to be at UDS using the Human theme and feel like a total curmudgeon it's gonna be fantastic
<jdong> Keybuk: oh I guess that works if I retrain myself to take my cue from there.
<ajmitch> YokoZar: or you could install that scary fvwm95
<ajmitch> that screenshot just looked ugly on planet
<jdong> but I've likekd the ability to just look at the center of the bar where the title is.
<YokoZar> More likely is you were looking at color unless you were using the dark theme
 * ajmitch was using clearlooks with its glorious blue
<Caesar> ScottK: I'd like to get the latest upstream rsyslog 4.6 into lucid-backports and hardy-backports
<Caesar> I'll do the legwork
<ScottK> Caesar: First it needs to be in Maverick.  We only backport from later Ubuntu releases.
<ScottK> But it'll need testing in any case, that can start now.
 * ccheney sees Jono's post and wonders if he can manage to install his first Linux distro in vmware still
 * ccheney has no idea what it even looked like anymore
 * ccheney isn't sure if ide cdrom even existed back then
<ccheney> seems even older than bootable cds
<jdong> psusi: haha http://jdong.mit.edu/~jdong/fragraph.svg
<jdong> psusi: whenever your defragger is ready to have a UI ;-)
<jdong> psusi: (we hacked a quick graphing library to output those cliche Windows defragger ring-block graphs)
<ccheney> yuck installing this in vmware will actually be harder than installing it originally 15+ years ago
<psusi> jdong, hrm... I've been wanting a graph like that of the ureadahead pack file lately ;)
<psusi> jdong, though defrag already has a super sexy ncurses ascii gui, hehehe
<ccheney> whee, got the Slackware 2.1.0 bootloader to show up :)
<jdong> psusi: haha some perverse part of me wants to quickly hack together a script that visualizes what my current disk looks like.
<psusi> jdong, :)
<ccheney> hmm virtualbox doesn't support old enough either, qemu might be but its only back to ppro
<jdong> is there a magical pulseaudio way of redirecting audio output to microphone input?
<jdong> i.e. if you're voiceconferencing with someone and want to play a bit of music?
<persia> Yes, but.
<persia> So, pulse operates on the idea of sources and sinks, and you can connect any arbitrary source to any arbitrary sink, at any arbitrary gain, and it does the right thing.
<persia> But this complexity is painfully comfusing to users, so there's no UI for doing it.
<persia> If you're crafty, you can do things with pacat and named pipes.  There might be a less baroque way to do it.  The API is fairly powerful.
<persia> But you probably don't want to redirect to microphone input anyway (as sending to a source doesn't make sense), but rather to the audio sink for your application.
<jdong> right, I guess I meant audio sink for application
<jdong> I'll look at pacat then
<persia> If you have a sound file, `pacat -d ${SINK}` should work, assuming you know the sink identifier.
<jdong> where can i get the sink identifier?
<persia> If you need to redirect the output of one program into the input of another, that's harder.
<persia> Extra points for a nifty routing tool for complex routing maps that everyone can use :)
 * persia doesn't know pulse well enough to know
<jdong> yeah, I'd love to learn more pulse tricks as well
<TheMuso> I think pulse allows you to record what you hear out your speakers, i.e it will directly monitor the output sink.
<persia> That's pamon, isn't it?
<TheMuso> Not sure what paman has to do with it, I have seen the option I talked about in pavucontrol.
<TheMuso> pamon even
<persia> I thought pamon was PulseAudioMonitor
<persia> I may be wrong.
<TheMuso> never used it personally, and I thought it was deprecated.
<persia> You're probably more up-to-date than I.
<persia> The only feature that doesn't "just work" for me is the ability to automatically route different applications to different audio interfaces.  I'd like something like patchage for those special times I want to do something fancy, but for now all my fancy stuff can be done with alternate applications.
<persia> Anyone have a PS3?  I worry that https://launchpad.net/ubuntu/+source/ps3-kboot/1.6-2build1/+build/1517259 might make it hard to support any issues with PS3 for lucid.  Perhaps not as hard as the recent firmware update, but ...
<bilalakhtar> Has the memory leak problem been solved?
<pitti> directhex: right, I checked before that the package was in depwait, so it should have built by now
<pitti> good morning
<directhex> pitti, it has indeed!
<pitti> jdong: SRU versioning> I don't have a strong preference either way; 0.1 style is safer for avoiding future conflicts, but then again we'll just copy lucid-proposed SRUs to maverick, so for those cases it doesn't matter
<persia> And it fixes the bug
<directhex>  Depends: banshee (>= 1.6.0), banshee-extensions-common (= 1.6.0-1ubuntu4), libappindicator0.0-cil (>= 0.0.19), libglib2.0-cil (>= 2.12.9), libgtk2.0-cil (>= 2.12.9), libmono-addins0.2-cil (>= 0.4), libmono-corlib2.0-cil (>= 1.2.2.1), libnotify0.4-cil (>= 0.4.0~r2998)
<directhex> deps! sweet sweet deps!
<directhex> just like momma used to make!
<pitti> :-)
 * pitti puts some ice cream on top
<directhex> cdbs is incredibly poor at dealing with library packages containing both arch and indep pieces, if left to its own devices. the trick is binary-predeb/someindeppackage:: binary-fixup/archpackageitneeds
<ArneGoetje> slangasek, pitti: uploading final langpacks.
<joaopinto> good morning
<pitti> ArneGoetje: thanks, I'll shepherd them through the queue
<pitti> apw: linux-headers-2.6.32-21-versatile wants to go back to universe, but I think it would be much easier to have it in main, so that all linux binaries are in main; WDYT?
<pitti> apw: it just seems that this should be depended on by some metapackage?
<persia> pitti: Why should it be in main?  It's only useful for folks running qemu against armel targets, and isn't used for any images or in any flavours.
<persia> And the armel board it supports fails to match any of the boards for which there are images.
<pitti> persia: the source is in main, so that binary might just as well be
<persia> There's a substantial list of packages where source is in main and binary is in universe.
<pitti> persia: the entirely selfish concern is that it's about 20 times easier to NEW a package which has all binaries in the same component :)
<pitti> and due to changing the ABI very often, NEWing happens frequently in stable updates
<persia> Oh, then stick it in the "supported" seed (or whatever it's called).  You guys have to NEW linux *far* too often to fiddle about with it.
<pitti> that was my idea, but I was interested in (1) why it doesn't have a metapackage, and (2) whether there are particular reasons why we don't even want to show it in main
<persia> Because archive-admin-convenience is the only decent reason to have that kernel in main, but that's indeed a decent reason.
<persia> It's useless for nearly everyone.
<persia> It works fine, but it's not tested heavily or anything.
<pitti> ok, so that explains the lack of an rdepends; thanks
<persia> And I think mostly lool supports it/.
<dholbach> good morning
<pitti> persia: I'm a bit hesitant to seed it, though, again because the ABI changes so often
<pitti> hey dholbach! *hug*
<dholbach> hey pitti
 * dholbach hugs pitti back
<pitti> persia: (but there's a trick to catch all binaries of a source, so that's not a big problem)
<persia> Use the trick.   A new linux-meta upload to create an rdepends would be annoying :)
<dholbach> if an archive admin could have a look at bug 567208 I'd appreciate it
<ubottu> Launchpad bug 567208 in freebsd-buildutils "Please sync freebsd-buildutils 7.2-2 from sid" [Undecided,Triaged] https://launchpad.net/bugs/567208
<dholbach> it wouldn't surprise me if all the tools are currently broken in that package
<pitti> apw, persia: seed change committed, thanks
<apw> pitti, are you saying that the linux-headers for versatile are not depended on by a meta package?
<pitti> apw: right; persia gave some clarification about that above
<apw> pitti, i am a little supprised, i thought i was linked to linux-meta
<apw> pitti, yeah there is a linux-headers-versatile <version> package built by linux-meta ?  would that not be the link we are expecting?
<pitti> indeed
<apw>  Depends: linux-headers-2.6.32-21-versatile
<pitti> Depends: linux-headers-2.6.28-18-versatile
<apw> and it does have a dep of the form i was expecting
<pitti> oh, I see -- linux-headers-versatile itself is in universe
<apw> so would the thing to be to promote that?
<pitti> I don't know
<apw> where is linux-image-versatile ?
 * pitti looks a little confused and points archivewards?
<apw> htm thats is universe too, i wonder why you don't have the same issue with the linux-image
<slangasek> jdstrand: no, not everything in main is in a seed file; many things are in main as /dependencies/ of things in seeds
<slangasek> jdstrand: but I see that was already answered :)
<pitti> apw: no, linux-image-2.6.32-21-versatile is in main
<pitti> indeed, but the metapackage is universe
<slangasek> ArneGoetje: yay langpacks
<apw> stranger and stranger
<pitti> apw: so I guess for any kind of consistency we should either seed linux-{image,headers}-versatile, or drop the entire thing to universe?
<pitti> and go back to this kernel-overrides script
<pitti> persia: ^
<apw> pitti, i have often wondered whether the package could supply the defaults ... so once you are happy they are right in the package you can just say 'do what the package says'
<pitti> apw: they can: Section: restricted/linux
<pitti> or universe, etc.
<apw> so is that the error, that we are not and we should be
<pitti> at least they could in the past; not sure if these days soyuz tries to be more clever
<apw> if there is something i can do to make this work without lots of pain
<apw> even if its just so that your script doesn't need a list, just can take the contents of those fields in the packages
<pitti> apw: for now I'm primarily interested in where versatile should be; right now it's half-main/universe
 * persia doesn't like the idea of components, but doesn't think there are enough versatile users to justify being in "main" as long as we have them, but prefers to make archive-admins lives easy, making main a reasonable choice.
<pitti> apw: we have a "kernel-overrides" script which copies the sections from a previous ABI
<pitti> so once we get it right in final, we can just use that for SRUs
<apw> ahh right
<pitti> persia: the thing that I'm puzzled about is why linux-image-2.6.32-21-versatile is in main without http://people.canonical.com/~ubuntu-archive/component-mismatches.txt complaining
<pitti> (note that versatile just went away due to my explicit seeding)
 * persia tries to find a reason
<pitti> but that seeding is still inconsistent
<pitti> we have linux-{image,headers}-2.6.32-21-versatile in main, and linux-{image,headers}-versatile metapacakges in universe now
<pitti> ooh
<pitti> ./platform.lucid/installer: * Kernel-Version: 2.6.31-607-imx51 2.6.32-204-dove 2.6.33-500-omap 2.6.31-800-st1-5 2.6.32-21-iop32x 2.6.32-21-ixp4xx 2.6.32-21-orion5x 2.6.32-21-versatile
<pitti> persia: ^ got it
<persia> Right.  netboot images.
<apw> heh was just going suggest netboot
<pitti> persia, apw: so with that I suggest to just seed the versatile metapackages, too; ok?
<persia> So if that's going to happen anyway, may as well toss the linux-meta versatile stuff in supported to avoid archive-admin work.
<apw> pitti, yeah seems reasonable they should be in the same place to me
<persia> They may have a 2-digit userbase, but it's simply not worth the extra archive-admin work to have them in universe.
<baptistemm> good morning ladies & gentlemen
<pitti> persia: it's not that big of a deal, but kernel in main and metapackage in universe doesn't make sense
<slangasek> ogra: what makes bug #568736 "higH"?
<ubottu> Launchpad bug 568736 in netbook-meta "Having Evolution installed along with Desktop-Email is pointlessly redundant" [High,Triaged] https://launchpad.net/bugs/568736
<ogra> slangasek, waste of space and ram ?
<persia> asac: Maybe you can help out slangasek there?
<pitti> persia: hey, that's one digit more than hppa! *duck*
<ogra> slangasek, along with the duplication of apps
<slangasek> ogra: yeah, I'm not letting you make a seed change a week before release for that
<ogra> slangasek, SRU ok ?
<persia> pitti: Right: the only reason we care more about versatile than hppa is that there's like 4 devices anyone can buy that can actually run Ubuntu armel.
<pitti> ScottK, Riddell: should kigo just drop the gnugo recommends at this point?
<persia> ogra: SRU is pointless, because it doesn't change images.
<ogra> persia, hmm, and u-m wouldnt uninstall the package anyway
<persia> Right.
<ogra> right
<persia> So it ought be wontfixed for lucid and opened for maverick.  Unfortunately, the UI doesn't actually support that.
<lool> pitti: linux-versatile > we could add it to supported-kernel
<lool> pitti: Just like kexec, it's used in some use cases
<lool> pitti: versatile being mostly for qemu
<pitti> lool: ok, thanks; I seeded the metapackages now
<lool> Keybuk, YokoZar, kees: When I uploaded my last qemu-kvm uploads, slangasek noticed the use of "start procps" in the maintainer scripts and requested that I use invoke-rc.d instead to be nicer to the chroot use case (policy-rc.d I assume); he referred to a discussion which had just taken place on #ubuntu-devel; I think we need to have a public discussion on the pros and cons of each approach in the short term, and how to address the concerns in ...
<lool> ... upstart on the long term; there is a bug about chroots support in upstart covering the issues as well; let's move this to ubuntu-devel@
<dholbach> asac: HAPPY BIRTHDAY! :)
<slangasek> YokoZar: contrary to Keybuk's statements, start/stop do not provide a sane interface for use in maintainer scripts (and I believe he knows well what's not sane about this interface, he and I have talked about the problems before and he's said he plans to fix them).  It's fine that Keybuk wants to get rid of invoke-rc.d, but there needs to be a robust and publically-vetted interface, with sane error handling, available *first* before mand
<slangasek> ... people *not* use the thing that actually works.
<YokoZar> slangasek: All right then, I'll leave the invoke-rc.d using packages there ;)
<asac> dholbach: \o/
<sebner> asac: happy birthday from me too \o/ :D
<asac> alll this public mentioning of a day ;)
<RAOF> Happy birthday asac!
<pitti> asac: happy birthday, man!
 * pitti hugs asac
<asac> man ;)
 * asac hugs all
 * sebner thinks about sending a mail to -ubuntu-devel about asac *hrhrhr*
 * cjwatson scratches head over sbeattie's d-i resizing bug
<cjwatson> AFAICT, tune2fs is just lying
<sbeattie> lol
<sbeattie> cjwatson: I still have that vm up if you want me to grab any more diagnostic info from it.
<cjwatson> it's saying block count 2497791, block size 4096.  that's about 10GB - on a partition around 250MB long
<cjwatson> sbeattie: currently trying to work out what I would need, and if I can reproduce it locally instead
<sbeattie> cjwatson: well, tune2fs isn't lying; I just tried manually mounting the partition and the kernel wouldn't mount it, saying the same thing (the block count exceeds the size of the device)
<cjwatson> oh!
<cjwatson> so the fs there is bogus?  do you know why?
<cjwatson> if it's genuinely bogus, I can certainly make d-i safe against that
<cjwatson> I just didn't want to do so when the effect would be hiding some other problem
<sbeattie> cjwatson: I don't know why it's bogus.
<Riddell> pitti: hmm, if gnugo isn't installed kigo just complains that it needs to be installed
<cjwatson> would you agree that it would be best to just guard against this, and otherwise write the underlying problem off as probably transient until reproduced?
<cjwatson> or is the bogus fs reproducible by some sequence of installation steps?
<pitti> Riddell: well, we need a MIR or a lowering of the dependency
<pitti> Riddell: do you have kigo on the CDs? (gnugo is 1.7 MB)
<Riddell> pitti: no it's not on the CD
<Riddell> pitti: let me look into gnugo and see if it's an easy MIR
<sbeattie> cjwatson: writing it off as a transient is fine by me; I don't recall how I got it into this state.
<cjwatson> so then I'll just error out if the size reported by ntfsresize or tune2fs is outside [minsize, cursize] as per the partition constraints
<cjwatson> which would result in that partition just not being resizable, which I think is the correct response here
<sbeattie> cjwatson: that seems sensible. Thanks.
<cjwatson> sbeattie: are you still awake enough to be able to do a test run with a candidate patch for me?
<sbeattie> cjwatson: yes
<cjwatson> sbeattie: so, there are two patches here; I need you to apply http://paste.ubuntu.com/420942/ to /lib/partman/lib/resize.sh, and http://paste.ubuntu.com/420943/ to /lib/partman/automatically_partition/10resize_use_free/choices
<cjwatson> sbeattie: if you like, you can apt-get source partman-partitioning and partman-auto respectively, apply the patch there, and then scp in the result - that's probably quicker than typing it in by hand
<cjwatson> sbeattie: I'd like you to keep the 'set -x' at the top of /lib/partman/lib/resize.sh to speed debugging of further problems, too
<cjwatson> again, best to do all of this while it's sat at the hostname prompt
<sbeattie> cjwatson:  sure thing, give me a few minutes.
<cjwatson> sbeattie: np, thanks
 * ogra wonders what we need to make a PAS change take effect ... apparently libx86 was added to PAS for armel but i still see it on http://qa.ubuntuwire.org/ftbfs/
<persia> ogra: The only thing that clears that is a working build: it's based on the build records from LP.  A P-a-s change would make it not build for maverick.
<ogra> ah
<ogra> i guess an upload/sync/merge would clear it up too, right ?
<ogra> well, i'll live with the uglyness on the list then
<persia> ogra: An upload might.  I'm not sure.
<persia> ogra: But I doubt the RMs would accept an upload just to make the FTBFS list look pretty :)
<persia> (actually fixing a FTBFS is another thing)
<ogra> you really think so ? :P
 * ogra wasnt planning any upload indeed :)
<ogra> i just wanted to know why i still see it on the list ... the explanation was good enough
<ogra> it bites my eyes that we still have one red bar ... even though its moot
<ogra> its just the german in me :)
<persia> One?
<persia> There's *lots* of red on that page.
<slangasek> ArneGoetje: I find a certain irony that Hungarian users need the hunspell dictionaries symlinked into the myspell directory
<sbeattie> cjwatson: okay, with those patches applied, I'm not getting offered the option to resize the partitions (which is probably correct). /var/log/syslog output at http://paste.ubuntu.com/420957/ and /var/log/partman at http://paste.ubuntu.com/420958/
<sbeattie> cjwatson: note that I have a snapshot of the vm's disk state taken when I initially ran in to this, so I can do destructive things to the image like mke2fs /dev/sda5 (which doesn't appear to currently be a valid partition) if you'd like me to exercise different conditions.
<sbeattie> s/partition/fs/
<cjwatson> sbeattie: that's fine now - the shell trace is exactly as I'd expect
<cjwatson> and I see it doesn't offer auto-resize because there isn't enough free space
<cjwatson> /lib/partman/automatically_partition/10resize_use_free/choices: Found resizable partition '/var/lib/partman/devices/=dev=sda//5757730816-10462691327' (/dev/sda6), but not offering because only 2299432960 bytes free
<cjwatson> sbeattie: so thanks, I think that's all!  I'll go ahead and upload that, with just a correction to the ntfsresize-case error messages
<sbeattie> cjwatson: okay, cool.
<apw> is there is standard way to access package dependancy information in a debian/rules context?
<cjwatson> what sort of information?
<apw> i have a package with a dependancy on linux-source but i would like to know which package linux-source points to
<baptistemm> apt-cache rdepends
<apw> or indeed the version number of linux-source
<baptistemm> ah I misunderstood
<apw> and i can use apt-cache in deban/rules
<cjwatson> what are you trying to do with this information?  plug it into some other dependency?
<apw> cjwatson, the build rules need to know the name of the directory whihc will be in existance as a result of installing linux-source
<cjwatson> anyway, Depends is run-time, you can't generally validly analyse it at build time
<apw> which depends on linux-source-2.6.NN and it needs the 2.6.NN information
<cjwatson> sounds like it would need to depend on an explicit linux-source-2.6.NN anyway
<cjwatson> because when linux-source changes to point to a new version, this package will need to be rebuilt
<apw> i was hoping to avoid that, but you are indeed correct
<cjwatson> the other way to do it would require the package detecting things at run-time, rather than in debian/rules
<apw> yeah ... it would, and so this is a bust, thanks for the advice
<slangasek> apw: any chance of us getting that kernel-lucid-kernel-config-review report to ubuntu-devel this week? :)
<apw> slangasek, yeah thats on my todo for today (though i has been for two weeks)
<slangasek> k
<apw> slangasek, i am leaning towards putting all of the configurations on my people page
<apw> and only including the i386 generic one
<slangasek> hmm
<apw> as to include them all there are about 8
<slangasek> I dunno, seems to me that the "lvm support not built in on ports" bug is exactly the kind of thing that could have been caught by having more eyeballs directly on this stuff earlier
<apw> slangasek, well some actual testing of any of the ports kernels before release would have caught that
<persia> I did catch it a couple weeks ago.
<persia> (admittedly not early enough, but)
<slangasek> apw: only the users who were testing with LVM and knew to look for a kernel problem amid all the reports of mountall being broken
<apw> slangasek, though do you really think that anyone would read the all the ports configs and 1) detect that BLK_DEV_DM was not =y, and 2) realise the significance of that
<slangasek> apw: I would have looked over the differences in the configs, yes
<apw> slangasek, hrm i had not considered it would be possible to do that kind of comparison
<slangasek> would probably have taken a bit of work, but it was work I was intending to do :)
<apw> the problem to my eye is that the arch configs are all different so there is masses of delta which is expected and a small nuggest which is
<apw>   64543  101937 1440383 total
 * slangasek nods
<apw> for all the normal and all the ports configs (ie only for master branch) you are talking about 1.4MB of configs
<apw> slangasek, would a delta from karmic make more sense?
<slangasek> apw: well, if you post them to your people page, that's better than nothing (i.e., better than me trying to dig them out of the git repo) - at least if they're *somewhere* that I can look at them without hunting them down, I can give a good think to the problem of generating meaningful diffs
<slangasek> a delta from karmic is probably also useful, but not to the exclusion of the other bit
<apw> slangasek, ok i can cirtainly do that, i'l see if i can get the karmic ones up as well
<apw> so there is a pair to compare that way too
<slangasek> great, thanks
<apw> and sorry its been on my list for too long really
<apw> for M we'll put an earlier task to get it out
<apw> if you could think about whats actually useful as a reviewer as well that would be great
<slangasek> will do
<apw> slangasek, one major thing we are doing now, is that when we have an option which has to be set is to record that and enforce it at build time so it is harder for it to become lost
 * slangasek nods
<apw> slangasek, it would probabally make sense to publish these somewhere which is not 'apw', i think i will put them in the kernel-ppa user, which can then persist forever
<slangasek> ok
<apw> slangasek, is there a release meeting today?  i don't see an agenda
<slangasek> apw: will have it out within the hour
<slangasek> (it was the agenda that reminded me of the outstanding WI ;)
<apw> yeah i'll get it out today
<ogra> sigh, whats up with wiki.u.c ?
<slangasek> chrisccoulson: reviewing thunderbird - it's not clear to me why the thunderbird-gnome-support maint scripts have been removed without this moving elsewhere
<chrisccoulson> slangasek - the maintainer scripts were just used to touch /usr/lib/thunderbird-3.0.4/.autoreg
<chrisccoulson> which is not needed anymore
<slangasek> chrisccoulson: what's .autoreg for?
<pitti> free: the current landscape-client SRU mentions bug 522688  which is for libvirt, and 503384 and 542215 are private; also, since there are two uploads stacked on each other, can you please fix the changelog and reupload one with -v1.4.4-0ubuntu0.9.04 (jaunty), respectively -v1.4.4-0ubuntu0.9.10 (karmic) so  that the .changes will have both changelogs?
<ubottu> Launchpad bug 522688 in libvirt "/etc/init.d/libvirt-bin does not check that libvirtd has terminated on stop" [Undecided,Confirmed] https://launchpad.net/bugs/522688
<pitti> free: I'll sort out the task approval etc. now, and reject the two older uploads
<pitti> free: oh, 567515 is private, too
<free> pitti: yeah, we spotted a couple of bugs in the process
<chrisccoulson_> wow, my laptop just crashed big time there
<free> pitti: turned to public, thanks
<chrisccoulson_> slangasek - i'm not sure how much of my response you got
<slangasek> chrisccoulson_: "which is not needed anymore"
<slangasek> then I asked what it was for
<chrisccoulson_> because thunderbird-gnome-support doesn't actually ship any components any more
<chrisccoulson_> the autoreg file is to tell thunderbird to re-register all the components on the system, so that it picks up newly installed/removed ones
<slangasek> ok
<pitti> free: so I guess the reference to #522688 is just wrong?
<free> pitti: so you're suggesting to make a new upload, whose last changelog entry would be the merge for the last two changelog entries?
<free> pitti: yeah, likely a typo
<pitti> free: right, either merge the changelogs into one record, or use -v to include the last two changelogs into the .changes file
<pitti> free: (the former would be even less confusing indeed)
<pitti> plus fix that bug reference
<pitti> free: I sorted out the tasks and nominations for all bugs now
<free> pitti: thanks, if I use -v do I need a new revision or can I just re-upload? (actually zul will have to sponsor)
<pitti> free: just reupload (i. e. no new version number) in both cases
<free> pitti: fine, thanks
<pitti> free: (well, with the bug ref typo fix, of course)
<free> pitti: sure
<pitti> free: thanks!
<slangasek> chrisccoulson_: why is this added code in thunderbird.postinst needed?  The only package in the archive using this directory is thunderbird itself
<chrisccoulson_> slangasek - dpkg doesn't replace the existing directory with the symlink on upgrade
<slangasek> chrisccoulson_: the directory shouldn't exist on upgrade
<chrisccoulson_> slangasek - the current lucid package has a directory there, and we want to replace it with a symlink
<slangasek> chrisccoulson_: oh, yes - sorry, was misremembering the upgrade rules on this
<chrisccoulson_> yeah, i'd forgotten about it too ;)
<chrisccoulson_> we can actually drop that when we update to the next upstream version, as the install location changes anyway
<slangasek> heh, ok
<chrisccoulson_> it's only needed because we want to fix it with the current version
<ArneGoetje> slangasek: well, it seems that certain applications look only in one directory and that's the myspell one.
<ArneGoetje> slangasek: I'm planning to have a roundtable session about writing aids at UDS. I found it to be quite messy.
<slangasek> chrisccoulson_: since a fix for bug #543064 wasn't in this upload, can I safely conclude that this should be deferred to -updates?
<ubottu> Launchpad bug 543064 in thunderbird "ensure that x-www-browser is used if no http handler is found through gnome integration" [Medium,Triaged] https://launchpad.net/bugs/543064
<slangasek> ArneGoetje: are they using libhunspell when they look there, or something else? :)
<apw> pitti, something odd occuring with the WI graphs today, http://people.canonical.com/~pitti/workitems/canonical-kernel-team.html, is showing some green and yellow bits just sticking out from behind
<chrisccoulson_> slangasek - i don't think that's really needed now. the change just uploaded mitigates that by moving the gnome component to the main package
<ArneGoetje> slangasek: not sure, need to investigate. Will do that when I feel better
<chrisccoulson_> we can probably just defer that to next cycle
<ArneGoetje> slangasek: but since the myspell and hunspell dictionary packages conflict on each other, it's definetely something we need to take a look at, IMHO.
<pitti> apw: the bright yellow ones are WIs from persons which aren't member of kernel-team, but are assigned to WIs of kernel-team specs
<pitti> but yes, the rendering looks broken
<apw> something odd has happened cause the green seems to be on the top in some cases
<seb128> slangasek, not sure what the discussion is but we should be using the hunspell dictionaries according to the debian maintainer but we didn't rebuild enchant for example with that dir in lucid
<seb128> slangasek, debian did it already and we will follow next cycle I guess
<slangasek> seb128: ah
<dholbach> if an archive admin could have a look at bug 567208 I'd appreciate it
<ubottu> Launchpad bug 567208 in freebsd-buildutils "Please sync freebsd-buildutils 7.2-2 from sid" [Undecided,Triaged] https://launchpad.net/bugs/567208
<ArneGoetje> seb128: let's have a roundtable at UDS to figure out what problems still remain, shall we?
<seb128> slangasek, ArneGoetje: we can discuss that at UDS if you want but the debian maintainer has been pretty clear the dictionnaries are in the hunspell dir now and that the other dirs are only there for compatibility reason but should be dropped, Debian apparently has migrated everything to use hunspell now, we didn't because you didn't sync some of the work they did yet
<ArneGoetje> seb128: are all the applications using libhunspell?
<seb128> not sure I didn't check
<seb128> we can discuss it at UDS if you want but it seems rather a question of having somebody to do the work of checking what needs to still be changed
<seb128> rather than a topic for discussion at uds
<Riddell> pitti: bug 566520 if you're in a MIR mood
<ubottu> Launchpad bug 566520 in gnugo "MIR for gnugo" [High,New] https://launchpad.net/bugs/566520
<pitti> Riddell: thanks, will have a look soon
<ArneGoetje> seb128: there are still other problems: e.g. oo.o seems to contain static language lists, so adding a language which is not in that list, is not trivial. And mozilla products also need some additional magic to use the hunspell dictionaries.
<seb128> hum, k
<seb128> your call if you think we will have people who know enough about this at UDS to have a discussion
<ArneGoetje> seb128: I don't know if we will have... but I think it's surely a topic to raise.
<persia> slangasek: Are the image builders going back to daily for a few days, or are they staying manual until release?
<slangasek> persia: manual until release
<persia> Would it be possible to do a kubuntu-netbook-armel+omap build?  It apparently needs a flash-installer fix that landed after the most recent build.
<persia> ogra: Do you have the reference bug for that handy?
<ogra> (flash-kernel )
 * ogra doesnt rememebr if there was a bug open ... its the compcache issue 
<ogra> persia, bug 568038
<ubottu> Launchpad bug 568038 in casper "compcache leaves too little free RAM for systems with 256M when installing with ubiquity" [Critical,Fix released] https://launchpad.net/bugs/568038
<pitti> ttx: would you mind having a look at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, in particular the moin -> wsgi dependency? (the rest is just noise)
<ttx> pitti: looking
<Riddell> ev: what do you think about bug 568890 ?   I could have a go at fixing it but it's not easily tested since it would need a full install to test
<ubottu> Launchpad bug 568890 in ubiquity "KDE frontend only allows bootloader installation to the MBR." [High,Confirmed] https://launchpad.net/bugs/568890
<ev> Riddell: it looks fairly straightforward, at least for adding the other device nodes to the list.  I'll give it a quick go.
 * ttx grumbles about the moin branch not being up to date
<ttx> pitti: python-moinmoin Recommends: libapache2-mod-wsgi | httpd-cgi. At that point I suggest we pick another httpd-cgi provider as the recommended one, and push wsgi to suggests. Would that work for you ?
<pitti> ttx: yes, if libapache2-mod-wsgi isn't appropriate for main (in general|at this point)
<pitti> ttx: but I don't know whether moin will work with just general apache
<ttx> it should, since the recommends would also be satisfied in that case
<ttx> plain CGI is alright, just slower
<ttx> pitti: "Recommends: libapache2-mod-wsgi | httpd-cgi" is staisfied if you just have plain apache2
 * ttx checks again
<ttx> pitti: right, it's working well without that wsgi module, just by following instructions in README.debian
<pitti> ttx: thanks for checking; mind uploading a fix? then I can review it quickly (four-eyes principle)
<ttx> pitti: sure, I'm on it... in a few
<pitti> merci
<pitti> this is the last item on component-mismatches then
<pitti> we're ready for prime time!!! :-)
<bigon> is a bug that cause some partition to not be mounted on boot already known?
<joaopinto> bigon, LVM ?
<dholbach> ScottK: is syncing bug 567208 fine for you?
<ubottu> Launchpad bug 567208 in freebsd-buildutils "Please sync freebsd-buildutils 7.2-2 from sid" [Undecided,Triaged] https://launchpad.net/bugs/567208
<dholbach> ScottK: if you don't have time - should I ask somebody else?
<joaopinto> shouldn't bug 558378 get some importance ?
<ubottu> Launchpad bug 558378 in linux "Please blacklist ATI XPRESS 1250 from Kernel mode-setting" [Undecided,Confirmed] https://launchpad.net/bugs/558378
<ScottK> dholbach: I've been reviewing the sync requests that ubuntu-archive is subscribed to, so as long as the normal process is followed, I'll look at it.
<ccheney> slangasek: thanks the conflicts somehow slipped my mind
<doko_> pitti: sun-java6 6.20 already is in lucid/partner
<pitti> doko_: yep, noticed my error, I set the bug to fixed again
<bigon> joaopinto: yep
<bigon> it ask if I want to skip mount or doing manual recovery
<dholbach> ScottK: yeah, you reviewed it already, I just gave more info
<ScottK> OK
<joaopinto> bigon, check bug 561390
<ubottu> Launchpad bug 561390 in mountall "LVM - /var failed to mount during boot" [Medium,Fix committed] https://launchpad.net/bugs/561390
<\sh> stgraber, ping https://blueprints.edge.launchpad.net/ubuntu/+spec/improve-netbooting-with-udhcp <- it seems nobody was interested during karmic...I would push that again for lucid+1
<stgraber> \sh: we are using udhcpc in ltsp since karmic
<stgraber> \sh: udhcpc was promoted to main for that, though it seems the spec wasn't updated accordingly
<\sh> stgraber, did you test it with multiple nics (e.g. /etc/initramfs-tools/initramfs.conf: set DEVICE= and not to eth0)?
<bigon> joaopinto: thx
<stgraber> \sh: I don't have any thin client with multiple-NICs around
<\sh> stgraber, hmm..so only ltsp benfits from that..it seems
<\sh> plain initramfs-tools/scripts/function uses still ipconfig
<stgraber> yep, the ltsp_nbd script is using but it wasn't changed in scripts/function as AFAIK that one comes from Debian so the change should probably happen there
<Laibsch> ArneGoetje: If you have a minute, I'd appreciate some input on the changes to Japanese fonts.  I may be doing something wrong but the Takao font looks vastly inferior to the VL-PGothic.  Is that the same for you?  My understanding for making Takao the default is merely a question of size (1MB saving) or is there anything else?
<pitti> ev: "(LP 536673)" -> please try to use the official syntax (LP: #536673) to auto-close bugs
<ubottu> Launchpad bug 536673 in ubiquity "ubiquity crashed with InstallStepError in configure_hardware()" [High,Triaged] https://launchpad.net/bugs/536673
<ev> pitti: that was purposeful
<ev> I don't want to close that just yet
<pitti> ah, ok
<ev> as I'm not entirely convinced that it fixes everything that's breaking there
<ev> just most of it
<pitti> understodd, thanks
<\sh> micahg, why do we need xulrunner in chouchdb? it brings us a full fledged X and half of gnome
<micahg> \sh: for the javscript engine
<micahg> \sh: we'll look into a no-x version for Maverick possibly
<\sh> micahg, do we need it really why not back to moz-js
 * \sh is sorry about "I don't have the no-clue about that" ;)
<micahg> \sh: mozjs is not guaranteed to be have a stable API even across minor releases
 * micahg really can't type today
<micahg> \sh: there are a few bugs already on the topic
<\sh> micahg, yeah..it's really useless to have a server only setup but with a full bloated X setup because of a db server ;)
 * pitti reads about ppa-purge -- what a gem! thanks Sarvatt
<Nafai> very nice thing to have automated!
<seb128> slangasek, pitti: can we sync http://packages.qa.debian.org/g/gtk-smooth-engine/news/20100411T104208Z.html ?
<seb128> slangasek, pitti: the only change we have now was to fix some depreciation issues but new gtk added new issues so it's easier to take the debian way
<micahg> \sh: the bug is bug 286906
<ubottu> Launchpad bug 286906 in xulrunner "provide and support a top-level library package for libmozjs (Was: Unable to use libmozjs.so in an application, because of library path problem.)" [Unknown,Confirmed] https://launchpad.net/bugs/286906
<pitti> seb128: seems okay, please go ahead
<seb128> pitti, thanks
<Sarvatt> no worries, it's pretty much required to use xorg-edgers since you need to downgrade at least 50 packages at some point to be able to upgrade a release since the packages in the PPA are newer than the next release's and the world will be broken just disabling the PPA :) I need to have a very large amount of packages in that PPA because all of the drivers require rebuilding every xserver release (and weekly just about during development)
<ccheney> ArneGoetje: added comment to bug 568760 to you
<ubottu> Launchpad bug 568760 in openoffice.org-dictionaries "Hungarian spell-check is not supported" [High,Triaged] https://launchpad.net/bugs/568760
<ev> pitti: if you have any spare cycles, I would appreciate knowing any thoughts you how on what might be causing udisks --inhibit to time out in bug 567899
<ubottu> Launchpad bug 567899 in ubiquity "udisks --inhibit times out in ubiquity-wrapper during boot." [Undecided,Incomplete] https://launchpad.net/bugs/567899
<ev> have*
<pitti> ev: I opened a tab for it; still in the release meeting, and I have to run after that, but I'll have a look later tonight or tomorrow in the train
<ev> pitti: no rush, I'm going to keep chipping away at it
<ev> thanks!
<pitti> ev: this rather looks like an udisks-daemon crash, though
<pitti> that's at least the usual cause of that message ("no reply")
<ev> okay
<pitti> might be worth asking him to check /var/log/apport.log and /var/crash/ ?
<pitti> ev: can you reproduce it?
<ev> pitti: unfortunately not
<pitti> i. e. the effect can probably be reproduced with calling udisks --inhibit [...] and then sudo killall udisks-daemon
<ev> given that apport is still enabled, surely there'd be something in /var/crash, right?
<ev> noted
<pitti> ev: it's disabled in the release, but I think casper enables it
<pitti> ev: hm; sudo udisks --inhibit sleep 10, and then a killall udisks-daemon doesn't actually reproduce it
<pitti> but there's no inherent timeout
<pitti> ev: so it seems to have crashed right in the inhibit method, not when just waiting for the subprogram to terminate
<ev> hmm
<mvo> slangasek, Riddell: the support time for kubuntu is in the process of getting fixed, it needs a LP cherry pick that just got approved
<ev> not exactly a complicated bit of code
<pitti> ev: so, the inhibit stuff isn't really hw specific in udisks, so either it was a weird one-off error, or he hits a weird d-bus race condition on his machine
<ev> it's two people
<ev> I'm leaning towards the race
<ev> especially as one of them has a quad core machine
<ev> and this is happening at boot
<pitti> ev: I'm afraid I don't currently have an obvious idea what could have gone wrong; if that guy can reproduce it, I suggest that he should try the sudo udisks --inhibit sleep 60 thing and see whether that works
<Riddell> mvo: lovely thanks
<ev> pitti: thanks for the help, I think you've got me on the right track now
<pitti> ev: also, it's worth checking pidof udisks-daemon after that happens; if it's gone, it most probably crashed
<ev> indeed, thanks
<mvo> Riddell: you can review the status here http://archive.dogfood.launchpad.net/ubuntu-misc/more-extra.override.lucid.main.supported
<mvo> Riddell: and use supported-desktop-extra in your seed to bump sutff more
<mvo> Riddell: it will do 3y for kubuntu-desktop and dvd and dvd-live currently
<LLStarks> hi. quick question. was audacious-plugins-extra dumped after karmic?
<LLStarks> it's not in the lucid repos.
<LLStarks> and that leaves timidity as the only way to listen to midi on ubuntu
<ScottK> bdrung would be the expert on that.
<LLStarks> thanks.
<bdrung> LLStarks: audacious-plugins-extra was merged into audacious-plugins
<LLStarks> oh okay.
<LLStarks> the description should be updated then
<bdrung> and one buggy module was disabled
<bdrung> LLStarks: patches are welcome ;)
<bryceh> slangasek, you had a question on the xserver upload?
<seb128> slangasek, I sponsored a gnome-settings-daemon change from chrisccoulson now, the debdiff drops a change not listed in the changelog but that was a leftover not in series
<seb128> not an actual code change or error there
<blackxored> Hi guys, I was wondering, is grub2 on lucid compiled with LUKS support?
<slangasek> bryceh: was just the question about the first change and whether it was intended to go to lucid; looked fine to me, it was more pitti's question
<slangasek> seb128: ack
<bryceh> slangasek, well I can redo the package to exclude it if it is causing concern
<bryceh> one sec
<seb128> bryceh, don't
<bryceh> slangasek, ok xorg-server uploaded with that dropped
<seb128> bryceh, it was pitti double checking not really a concern
<bryceh> hrm
<slangasek> bryceh: no, I prefer the one with this change :)
<seb128> well both are in the queue now
<seb128> so slangasek can do what he wants ;-)
<bryceh> let me know which is taken so I can fix up git accordingly
<psusi> oh wow, just found a link to this on the forums.. this sounds like a really retarded bug in blkid: http://sourceforge.net/apps/mediawiki/bootinfoscript/index.php?title=Boot_Problems:minix
<blackxored> hi guys, anyone knows if grub2 for lucid is LUKS-enabled?
<blackxored> anyone guys?
<bryceh> slangasek, procedural question for SRUs
<bryceh> slangasek, I've got a couple changes to do to xserver as SRUs
<bryceh> slangasek, is it preferred to combine them in one upload, or to have individual uploads?
<slangasek> bryceh: combine, please - and the first xorg-server is the one I accepted
<bryceh> slangasek, if the latter, my concern is with the numbering
<blackxored> ActionParsnip: I was wondering if grub2 for lucid has LUKS support compiled, and whether if I need to setup a proxy server or NAT if I have access by ssh to a machine which "seems" the outside world, and I don't
<bryceh> slangasek, ok great
<slangasek> bryceh: combining them is preferred, though if you think the SRU is going to get dragged down because one fix will be hard to get validated, then it's reasonable to split them
<bryceh> slangasek, alright good to know
<bryceh> slangasek, the ones I have in mind are pretty widely tested and the fixes are established upstream from us so I think they should be really straightforward srus
 * slangasek nods
<bryceh> but I do think they could benefit from the usual -proposed testing and are not emergencies for including in the release, so SRUing seems best
<slangasek> right
<bryceh> having them in one package definitely will make things easier
<ccheney> debian.org domains (other than www.debian.org) seem mostly dead today, already report to #debian-devel
<slangasek> oh, is that why I couldn't raise bugs.d.o earlier
<Keybuk> KEYBOARD = YAY!
<ccheney> slangasek: yea i can't get to packages.qa, incoming, bugs, debian.org without www, etc
<ccheney> slangasek: "weasel is fixing them." so hopefully they will be back up soon
<Keybuk> I like the "â¨ â¹ â" screen
<slangasek> mathiaz: bug #529686> not before release
<ubottu> Launchpad bug 529686 in acpid "Depressing power button does not shutdown computer" [Medium,Triaged] https://launchpad.net/bugs/529686
<Keybuk> mathiaz: have you tried cheering the power button up instead of depressing it?
<mathiaz> Keybuk: I haven't run into that bug
<mathiaz> slangasek: It was assigned to me by random person
<ScottK> Right, but it's Ubuntu custom that when you get bugs randomly assigned to you right before release you're morally obligated to fix them.
<mathiaz> ScottK: hu?
<Keybuk> tedg: random question; if I wanted to disable just the "messaging" indicator, is there a way I could do that?
<tedg> Keybuk: Without just removing the package?
<Keybuk> tedg: can I remove the package without losing most of ubuntu-desktop?
<Keybuk> I like the other indicators - that one just takes up screen space and never shows anything
<tedg> Keybuk: Yes.  It's very independent.
<tedg> Keybuk: kenvandine wrote an xchat indicator plugin, if that works for you (don't know what you use)
<Keybuk> I use xchat
<Keybuk> though I have a custom notifications patch of my own that I should probably port to be an indicator
<Keybuk> or merge with kevandines's
<tedg> Keybuk: You've got until 11.04 ;)
<tedg> (assuming you use the notification area)
<Keybuk> yeah
<Keybuk> basically it's just a hack
<Keybuk> unlike the built-in one, it doesn't remove the icon as long as there are unread notifications
<Keybuk> so if I miss an unread message in one channel, the icon stays
<tedg> Ah, that seems like an important feature.  Surprised the original didn't do that.
<Keybuk> so what will happen with e.g. empathy?
<Keybuk> right now that uses a notification area icon, right?
<tedg> Empathy?  It already has a patch to use the Messaging Menu.
<Keybuk> then I'm confused
<Keybuk> the messaging menu never changes
<Keybuk> it just shows that envelope all the time
<tedg> Yes, unless someone pings you, and then it turns green.
<Keybuk> no?
<Keybuk> when someone messages me on empathy, the little green bubble icon turns into a flashing ! icon
<tedg> Hmm, that's odd.  I thought that was patched out as part of the Empathy patch.
<tedg> Are you running the distro version?
<Keybuk> yes afaik
<Keybuk> right, just got ev to test both with a chat window open and with one closed
<Keybuk> didn't go green
<Keybuk> I must admit, I assumed the envelope was open because "I had new mail"
<Keybuk> and that was hiding all other notifications
<tedg> Yes, the icon is an issue.  But one that I claim no ownership on :)
<Keybuk> ;-)
<seb128> Keybuk, empathy has a preference option to use the indicator or not
 * Keybuk always has new mail
<tedg> In your Empathy preferences is there "Show incoming messages in the messaging menu" ?
<Keybuk> tedg: yes, it's ticked
<Keybuk> I did uncheck the bubble crap
<tedg> Keybuk: Hmm, did you uninstall the messaging menu?
<Keybuk> tedg: no
<Keybuk> it's still there
<tedg> And there's a indicator-messages-service running on your system?
<Keybuk> scott     1504  0.0  0.1  17612  2544 ?        S    Apr22   0:00 /usr/lib/indicator-messages/indicator-messages-service
<Keybuk> yup
<seb128> Keybuk, what icon theme do you use?
<Keybuk> seb128: no idea, the black one
<seb128> you get empathy messages going in the menu if you don't have a conversation dialog open?
<Keybuk> err, white icons, black windows
<Keybuk> seb128: no
<Keybuk> am going to reinstall in a few hours, so will see if this still happens
<Keybuk> could be just an upgrade issue
<tedg> Hmm, I thought that listen-and-print was in a package somewhere?
<Keybuk> this laptop was installed with karmic RC and has been upgraded all the way through lucid
<tedg> Doesn't seem like it.  Keybuk, if you grab lp:libindicate there's a little tool called "listen-and-print" that'll dump what libindicate is doing on dbus.
<Keybuk> tedg: k, will do that after reinstall if still having issues
<slangasek> Keybuk: regarding bug #561390 and /var/log/udev - I've been noticing that my own /var/log/udev doesn't show any entries for LVs that were initialized in the initramfs; is this expected?
<ubottu> Launchpad bug 561390 in mountall "LVM - /var failed to mount during boot" [Medium,Fix committed] https://launchpad.net/bugs/561390
<Keybuk> slangasek: no, that should certainly not be the case
<Keybuk> and implies some kind of issue
<Keybuk> (indeed, that *may* be *the* issue here)
<slangasek> Keybuk: all of my LVs are seen by mountall, device nodes are there, and everything is mounted - so I'm not sure how it's related to the bug people are reporting
<Keybuk> weird then
<Tm_Tester> ScottK: all seems to be ok, I'll go thru some logs to see if there's been anything
<ScottK> Cool
<Tm_Tester> some apps already tested in method "launch, do something, quit"
<Tm_Tester> ScottK: all seem ok, though knetworkmanager fails to see my wlan
<ScottK> OK.
<ScottK> That probably merits some troubleshooting.
<ScottK> Fortunately for me, I'm completely unqualified to help.
<ScottK> maco is an expert though.
<Tm_Tester> I'll try something
<maco> what?
<maco> lies!
<maco> ScottK: im not a network manager expert...
<Tm_T> (:
<ScottK> No, but you taught me the underlying runes to get WPA working without it
<maco> thatd be asac
<maco> ahh
<Tm_T> ... and I though I were in k-devel
<ScottK> So you can probably help with seeing where in the stack the problem is
<maco> gotcha
<maco> Tm_T: was that you?
<maco> possibly you just need to "sudo ifconfig wlan0 up"
<Tm_T> maco: yes, was me
<maco> i have to manually do that sometimes. not sure why.
<Tm_T> maco: I was from livecd (:)
<maco> ah
<maco> you can sudo on a livecd :P
<maco> woah CNN is talking about a dog going all Lassie and luring a cop to a burning house
<ScottK> maco: It's not clear from the information you provided if that's a good dog or bad dog story.
<maco> ScottK: good dog. the dog went to get help
<ScottK> OK.  Luring people into burning buildings isn't inherently a good thing.
<rafiyr> Um, what a note upon which to enter a room.
<maco> ScottK: "to" not "into" :P
<ScottK> OK
<sebner> ScottK: depending on much you like those people :P
<maco> rafiyr: i mentioned the news talking about a dog acting like the one in the show Lassie and luring a police officer to a burning house
<maco> rafiyr: and ScottK asked if that was good or bad, and i said good because the dog went to get help
<sistpoty> huhu sebner
 * sebner hugs sistpoty :D
<rafiyr> I see, so not the result of developers under stress just before a major release....
<maco> heh no
<Tm_T> ScottK: my bad, forgot that I need closed drivers/firmware/something
<ScottK> Ah.  OK.
<Tm_T> ScottK: but jockey fails with it, hrrr, I'll pastebin the log
<Tm_T> ScottK: works eventually, so all good
<ScottK> Tm_T: No Jockey problem?
<Tm_T> ScottK: other than no clear error when it doesn't have network connection, no
<ScottK> OK
<Tm_T> had to replug wire to get connection up properly
<ScottK> Might be worth a bug.  That doesn't sound idea.
<ScottK> idea/ideal
<Tm_T> ye, jockey just says "failed, see log" and log doesn't say "hey I don't have connection" either (:)
<Keybus> tedg: so, err, the envelope icon changed after a reinstall
<Keybus> it's a closed envelope now, not an open one
<Keybus> but it's still white
<tedg> Keybus: Changed from open to closed on getting a message?
<Keybus> no, just closed now
<Keybus> before it was always an open envelope
<Keybus> does that mean anything?
<tedg> Keybus: I don't think so.  Mine is open, but it seems it might have changed in the theme.
<tedg> Keybus: It's toggled several times throughout Lucid.
<Keybus> heh
<Keybus> bit of luck we have UI freezes
<Keybus> oh, wait
<tedg> Yeah, I am an icon them version behind...  :-/
<tedg> Keybus: You live closer to Millbank than I do.  I'll send you with the foam bat ;)
<Keybus> whoah, empathy has a totally different theme now
<Keybus> it looks like someone copied the iphone
<Keybus> but yay, it does go green
<tedg> Woot!
<tedg> I think that OMG! Ubuntu described it as "puke green" but yes ;)
<Keybus> I don't seem to have the extra empathy icon now either
<Keybus> so whatever it was must have been an upgrade issue
<tedg> Keybus: Cool, thanks for checking.
<slangasek> Keybus: envelope> ubuntu-mono 0.0.18, I suppose
<Keybus> oh, I thought that was something to do with Mono
<ccheney> anyone happen to know the difference (or why) between dictionary files named eg de_DE vs de-DE ?
<micahg> ccheney: files or symlinks?
<ccheney> seems a lot of our upstream dictionaries aren't named uniformly and didn't know if it would cause a problem
<ccheney> micahg: some might be symlinks, looking in Contents file right not to spot any other bugs before release
<ccheney> s/not/now/
<ccheney> micahg: enchant didn't get migrated for lucid so we need to make sure they are correct so they can be used
<ccheney> some dictionaries have it both ways - _ but others only have it one way or other
<micahg> ccheney: idk the whole story, but that's part of what I was discussing with you the other night
<ccheney> micahg: yea
<ccheney> micahg: i found the information, it should always be _ as - used to be needed for old mozilla but not anymore
<micahg> ccheney: right, but what about other apps
<ccheney> micahg: apparently other apps use _
<ccheney> "For better mozilla integration, xx-XX.{dic,aff}->xx_XX.{dic,aff} symlinks were previously needed. Mozilla* now understands both variants, so this is no longer the case."
<micahg> ccheney: so should it be cleaned up for Lucid or wait till Maverick?
<ccheney> micahg: wait for maverick, but now i know that i need to make sure there are _ symlinks for all dictionaries in myspell/dicts
<micahg> ccheney: kk
<ccheney> so i don't have to worry about the -'s being missing
<ccheney> it looks like they might not be missing actually just a bug with my sorting
 * ccheney bbiab getting food, then back to more testing
<psusi> Keybus, is there a mailing list for discussion of e2fslibs?  I wrote a patch today to ureadahead that changes preload_inode_group() so that instead of calling ext2fs_get_next_inode to synchronously read inodes until it gets one not from the desired group, to instead look into the opaque e2fslibs structures to find the block bitmap, inode bitmap, and inode table for the bg and readahead() those blocks on the raw block device, but I feel l
<psusi> ike I should be using e2fslibs functions instead of looking into the opaque structures to do this
<Keybus> psusi: the usual linux-ext4 mailing list
<psusi> cool... I'll have to find that and sign up... want to find out if I can do what I did in a more proper way
<psusi> but so far, looks like it does increase performance a bit
<Keybus> linux-ext4@vger.linux.org  iirc
<psusi> and is relatively simple
<Keybus> it might be -ext2 :p
<psusi> Keybus, if you care to take a look at it I made a bzr branch in lp:~psusi/ubuntu/lucid/ureadahead/mine... it turned out to be fairly simple... half a dozen lines or so
<Keybus> psusi: mid-reinstall at the moment, can you e-mail me and I'll take a look in a bit
<psusi> Keybus, just send a reminder, take a look at url:?
<Keybus> ?
<Keybus> well, include the URL and stuff :p
<psusi> yuo just want me to send a mail saying reminder, check url://blah to scott@zelda.netsplit.com?
<Keybus> yes
<psusi> sure
<Keybus> otherwise I won't remember
<psusi> think I'll see about fixing defrag to change the height of the extent tree now when required/beneficial
<kees> jdong: where is Debian's vlc 1.0.6-1 ?  I only see 1.0.5-2
#ubuntu-devel 2010-04-24
<YokoZar> Why does my launchpad PPA keep an all time failure log for me.  Did I really need to know that I had 424 successful uploads and 37 build failures?
<YokoZar> This is going to turn into a vanity stat very soon
<crimsun> ...or you could not consider it a mark of vanity.
<YokoZar> crimsun: If launchpad published userid numbers I'd use that as a mark of vanity too
<jfb_h2o> is there a reference for how to create a package like science-engineering for an organization to use for deployment?
<jdong> kees: *defers to siretart* probably in debian's VCS?
<kees> cool
<psusi> damnit!  shit's complicated.
<mdziczkowski> hello
<mdziczkowski> are here any developers from Ubuntu 10.04 ?
<slangasek> superm1: mythtv 0.23.0+fixes24158-0ubuntu2 - no bug numbers referenced in this log?  what's critical about making the shutdown/reboot commands *not* configurable?
<slangasek> superm1: also, bug #550100 has been targeted to 10.04; if that's correct, presumably we should wait for that to land as well so we only have to build it once?
<ubottu> Launchpad bug 550100 in mythtv "white noise or no sound after seeking when using PULSEAUDIO:default" [Unknown,Fix released] https://launchpad.net/bugs/550100
<slangasek> ArneGoetje: export generated empty gv language packs again; I've rejected them from the new queue
<YokoZar> oh goody gwibber is crashing on startub
<hdon> when was the last time istanbul worked on ubuntu?
<hdon> it seems that it's been like 8 months, and i've tried on a bunch of different ubuntu installs on several machines with no success
<hdon> it always freezes hard
<hdon> i filed a bug a loong time ago
<hdon> very shameful. screencapture is important for the ubuntu generation of computer users
<hyperair> is it? i've only used it like.. once?
<gartral> hello all, i figured here is the best place to post this: ubuntu 10.04 is NOT supplying proper power over usb, as my droid no longer charges after upgrading to the RC
<gartral> also the tigerjet device known as magicjack causes x too fail on load if the device is plugged in when i boot lucid
<mantiena> hi all
<mantiena> ev: Hi, thanks for updating ubiquity translation after Release Candidate - now Lithuanian users will see correct and easy to understandable translation without errors
<mantiena> maybe someone knows if today will be new daily build at cdimage.ubuntu.com/daily-live/ ?
<mantiena> nobody knows if today will be new daily build at cdimage.ubuntu.com/daily-live/ ?
<Mirv> ccheney: could you push your OOo to bzr so that I could see the code changes in the last upload?
<mantiena> Maybe someone knows if today will be new daily build at cdimage.ubuntu.com/daily-live/ ?
<egalia> hey peops
<egalia> where should I look for the final artwork for lucid?
<egalia> would like to print some flyers for an upcoming lucid lynx party.
<egalia> https://wiki.ubuntu.com/Brand
<egalia> thx
<hyperair> crimsun: are pulseaudio sinks always physical devices?
<egalia> bye
<persia> hyperair: No: see http://pulseaudio.org/wiki/Modules for a list of sink types.
<hyperair> persia: i see. that makes things harder..
 * hyperair should probably start with filing a bug
<persia> hyperair: What are you trying to do?
<hyperair> persia: see, if you have multiple pulseaudio instances running on the same computer... and you put the computer to sleep.. the hook will record the state of, and mute each sink.
<ogra_cmpc> i dont think you can put the computer to sleep if multiple people are logged in
<hyperair> ogra_cmpc: can't you?
<hyperair> ogra_cmpc: well in my case i had a gdm session and my own session.
<ogra_cmpc> i remember lamont complaining about that a week ago or so
<hyperair> so there was a gdm pulseaudio, and my own pulseaudio session.
<hyperair> the problem was... the sinks on both instances were both mapped to the same physical device
<ogra_cmpc> yeah, thats different
<hyperair> so it went like this: it muted the sink of gdm's pulseaudio, and recorded that state. then it queried the state of my pulseaudio's sink, and then also muted it.
<hyperair> the problem is: regardless of the state of the sink, it is now muted after recording gdm's pulseaudio's state.
<hyperair> when resuming, the states are restored in the same order
<ogra_cmpc> yeah, sounds like a bug
<hyperair> i know, i wrote that script >_>
<persia> hyperair: So, you need to find a way to serialise and track each instance separately.
<hyperair> persia: yep.
<hyperair> persia: but i don't have the time to do it now. i wonder if it counts as a SRU..
<persia> hyperair: It needs fixing anyway.  Fix it as soon as you can: if you get it before release, ask the Release Team if it can be in lucid.  If it's after, ask the SRU team if it can be backported.  Either way, make sure it's fixed in maverick.
<hyperair> persia: no problem.
<hyperair> persia: it's really a corner case though, so i wonder what priority to assign it
<persia> Ask for guidance in -bugs, really.  I'd probably call it "Medium" offhand, but I'm not entirely confident, and not a good candidate to have an opinion since I mute audio all the time, and rarely suspend.
<hyperair> weird, is launchpad's email interface not working?
 * hyperair kicks launchpad
<hyperair> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/569395 for anyone who was listening earlier
<ubottu> Ubuntu bug 569395 in pulseaudio "Having multiple pulseaudio instances open causes physical sinks to be muted upon resume" [Undecided,New]
<directhex> can we release note the "proprietary NVIDIA driver nvidia-current installed on non-nvidia systems during upgrade which previously had libmyth-0.22-0 on them" issue?
<directhex> had it happen again, on wife's netbook this time
<directhex> well, either release note it, or actually add a conflicts/replaces on nvidia-185-libvdpau in libvdpau1, since that's the cause?
<ScottK> directhex: open a bug task against the ubuntu-release-notes project and provide proposed text for the note.
<simon-o> james_w, the lucid branch for system-config-printer is outdated. https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/system-config-printer/lucid Do you have an idea why?
<james_w> simon-o: package-import.ubuntu.com/status/system-config-printer.html
<james_w> so it's hit a bug in the importer and so failed to import the most recent versions
 * james_w heads out
<simon-o> james_w, I see. thanks
<bgamari> How exactly does mountall fit into the boot process?
<bgamari> All but one of the kernels on my Lucid test machine will not boot
<ion> It does the fsck, mount and swapon when devices appear.
<bgamari> Instead they get stuck waiting for mountall
<bgamari> I can't seem to coax any useful debugging output from it
<bgamari> It emits upstart events as devices come up (i.e. root partition)
<bgamari> ?
<ion> I take it your kernels are new enough (â¥ 2.6.32 IIRC) and not missing important configuration options?
<bgamari> The only kernel that does work is my self-built 2.6.34-rc
<bgamari> Even the -ubuntu kernels are failing
<ion> Please provide the --debug output from mountall with a working kernel and a failing ubuntu kernel.
<bgamari> ion, alright, give me a few minutes
<bgamari> ion: It's --verbose, not --debug?
<bgamari> vice versa rather
<bgamari> --debug doesn't seem to be documented
<ion> Add --debug >/dev/mountall.log 2>&1 to the âexec mountall ...â line in /etc/init/mountall.conf
<bgamari> yep
<ion> Dunno why --help doesnât list --debug.
<bgamari> It would be helpful if --debug were reported in --help
<bgamari> yeah
<bgamari> I can open a bug for that if that would help
<bgamari> I think libnih handles --help
<bgamari> ion: I just realized, piping the output to a file might not be the beste idea
<bgamari> I won't be able to read the file in the case of the non-working kernels
<bgamari> I can put a serial console on the machine
<ion> mkay, nih/option.c says --debug is deliberately hidden from --help.
<bgamari> arg
<ion> Do as you seem best, but you could always use sulogin.conf from http://upstart.ubuntu.com/wiki/OMGBroken to get a command line.
<ion> deem
<kirkland> is it really, actually impossible to boot 10.04 with plymouth entirely disabled?
<akk> kirkland: I've tried moving plymouth* out of /etc/init on two machines and it made no noticeable difference.
<akk> both machines still boot fine, though I haven't tried with a gnome desktop after that
<ScottK> kirkland: I think it's best described as not reliable.  plymouth handles some I/O serialization tasks (IDK the specifics), so it may work, but shouldn't be dependend on.
<ScottK> </parrot mode>
<kirkland> ScottK: hmm, okay;  that's make pure text-style server consoles impossible now?
<ion> akk: Just wait until mountall really, really needs to interact with you. :-P
<bgamari> ion: Well, it actually seems thata my hypothesis was wrong
<bgamari> it's not mountall
<bgamari> It seems I don't even get to mountall
<bgamari> The working configuration gave me quite a bit of output
<ScottK> kirkland: That's my recollection of how I've seen it explained.  IDK the details.
<ScottK> I'm not saying you're at all wrong.
<bgamari> the dead configuration doesn't produce much of anything
<ion> bgamari: Did you try sulogin.conf? Do you get a command line in a virtual console?
<bgamari> I do get a command line
<bgamari> yes
<bgamari> and root has been mounted
<ion> Does mountall start at all?
<bgamari> I really don't think so
<bgamari> I didn't get any debugging output
<ion> /dev/mountall.log doesnât exist?
<bgamari> one moment
<bgamari> I wasn't redirecting to a file
<bgamari> ion: Nope, mountall.log doesn't exist
<ion> Ok, some job that has âstart on starting mountallâ seems to block mountall then.
<bgamari> ion, alright
<ion> hwclock, plymouth, ureadahead on my system. Try commenting out the âstart on...â line from each job that starts on âstarting mountallâ. If that lets mountall start, try reverting that change one by one.
<akk> Are there any programs for showing the upstart event tree, or for asking questions like "what jobs might block mountall" ?
<ion> grep 'starting mountall' /etc/init/*.conf
<akk> Works as long as it's only 1 level deep.
<ScottK> persia: Congratulations.  You resolved the last non-sparc depwait in Main.
<bgamari> akk, that would be nice
<akk> bgamari: I've been idly thinking about trying to write something like that but was hoping it already existed. :)
<akk> The upstart docs are still pretty sketchy, though.
<bgamari> ion, akk: the problem was one of hwclock, plymount or ureadahead
<bgamari> Enabling hwclock still works
<bgamari> plymouth*
<bgamari> the problem appears to be plymouth
<ccheney> Mirv: ok will get that done soon
<bgamari> ion, akk, yep, reverting plymouth.conf makes the machine unbootable again
<ion> Iâm not familiar enough with plymouth to give specific debugging tips, but you might try e.g. strace -s100000 -f -o/dev/plymouthd.strace /sbin/plymouthd --mode=boot --attach-to-session.
<ion> Anyone here familiar with the inner workings of plymouth?
<ion> plymouthd --mode=boot --attach-to-session --debug --debug-file=/dev/plymouthd.log might also be helpful.
<bgamari> ion: alright
<bgamari> ion: well, not much happened
<bgamari> plymouth took control of the VT after producing some pretty generic debugging output
<bgamari> mostly about it deciding whether or not to log
<ion> Keybuk and slangasek have done a lot of work on plymouth, they should be able to help debug the issue.
<bgamari> ion: alright
<bgamari> thanks for your help!
<bgamari> slangasek: ping
<crimsun> hyperair: no, not always.
<crimsun> hyperair: also, regarding that bug, the real fix is (I think, noted, but I'm not sure given my phone's acting oddly) to remove the pm-utils hook altogether
<ion> bgamari: You should report a bug with all the information you have so far, asking for instructions for debugging further.
<hyperair> crimsun: remove the hook? are all the audio drivers fixed well enough for it to be removed?
<bgamari> Will Lucid really make it's scheduled release date?
<bgamari> its*
<bgamari> If I'm not mistaken, it's set to release in less than a week
<hyperair> why wouldn't it?
<bgamari> Yet several pretty important bugs remain unsolved (the IPv6 name resolution issue, a few boot issues I've heard people experiencing, the GEM memory leak was only solved a few days ago)
<bgamari> just seems like there's been a lot of flux for being so late in the cycle
<hyperair> there's an IPv6 issue?
<hyperair> i haven't heard any boot issues
<ScottK> As Ubuntu releases go, this is pretty calm.
<hyperair> lol
<bgamari> hyperair: https://bugs.launchpad.net/fedora/+source/glibc/+bug/417757
<ubottu> Ubuntu bug 417757 in eglibc "[regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups" [High,Fix released]
<bgamari> ubottu: The Fix released is for Karmic
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<bgamari> oops, wrong nick
<bgamari> hyperair: Still no fix for lucid
<bgamari> yet we're in freeze
<crimsun> hyperair: no, hence the comment in the bug report
<bgamari> I'm having trouble digging up the boot issue
<crimsun> hyperair: we discussed this upstream; ultimately we want the suspend notification over dbus instead of using pm-utils hooks.
<hyperair> crimsun: hmm interesting. looks like there are a lot of things which want suspend notification over dbus, but upower isn't moving.
<hyperair> that makes.. pulseaudio, gnome-screensaver, gnome-power-manager..
<crimsun> lennart usually gets his way :)
<hyperair> who's lennart?
<crimsun> the creator of avahi and pulseaudio
<hyperair> oh cool
<hyperair> well, if he gets upower to budge, everyone will be happy =)
<ScottK> bgamari: I don't think that ipv6 bug is valid for Lucid.  When I ping a new site via ipv4 I get an almost instant response.
<hyperair> ScottK: i think you need a sucky DNS server.
<ScottK> It was via a D-Link router, so I suspect that would qualify
<ScottK> but OK
<bgamari> ScottK: yeah, our network on campus is administered by a whole department of idiots
<bgamari> and it is absolutely abysmal
<bgamari> In Karmic it was fine
<hyperair> bgamari: oh you too? =p
<bgamari> hyperair: It seems to be a pattern
<hyperair> we have a bunch of idiots who occasionally decide that the network needs to be restarted, thereby bringing the whole university network crashing down.
<bgamari> Universities seem to have an aversion to hiring intelligent, competent people for IT roles
<hyperair> agreed.
<hyperair> "okay, we'll put your server in the DMZ." "oh hey all my ports are still blocked. only 80 seems to be opened." "we recommend that you do not host ___ and ___ and __ services"
<hyperair> so that's what a DMZ means -- opening port 80.
<bgamari> hah
<bgamari> well, ath9k seems to be completely broken on my machine with the stock kernel
<bgamari> locks up the machine hard
<ScottK> Did you try linux-backports modules?
<bgamari> A deadlock perhaps, Sysrq-W does nothing but output "SysRq : Show Blocked State
<bgamari> ScottK: Nope, not yet
<bgamari> I'll give it a try
<ScottK> That may not be the exact package name.
 * ScottK can never remember
<bgamari> yeah, I know what you mean
<akk>  /sbin/alsa-utils in lucid has comments explaining how to disable storing on an sysv-rc system, but not on upstart.
<hyperair> ScottK: tab completion ftw
<akk> The upstart file has start on starting rc RUNLEVEL=[06] and always calls exec /sbin/alsa-utils stop
<akk> which looks like it's calling stop on boot, and nothing on shutdown, but actually it seems to be saving on shutdown and restoring on boot.
<akk> I'm having trouble understanding how that works from the docs I've found (man 5 init and the upstart getting-started guide).
<crimsun> akk: err?
<crimsun> akk: if you want to disable storing, either move the upstart job out of the way, or comment out the invocation in the stop target
<akk> crimsun: There doesn't seem to be a stop target. That's what I'm trying to understand -- why it gets called on shutdown at all.
<akk> (and also how alsa-utils ever gets called with anything besides "stop" on startup)
<crimsun> akk: I'm quite certain that /sbin/alsa-utils does have a stop target.
<crimsun> line 376
<akk> Yes, but it also has a start target. Don't they do different things?
<crimsun> yes, and the start target is only invoked from the udev rule.
<akk> Ah! So the upstart job is only for shutdown, not for startup?
<crimsun> that's correct.
<akk> And "start on starting rc RUNLEVEL=[06]" happens any time runlevel is changed?
<crimsun> no, only when entering runlevels 0 or 6
<akk> (so in this shutdown case, going from 2 to 0)
<akk> Oh, right, sorry, I was thinking there was a dash there.
<akk> Is that the recommended way to do something at shutdown -- "starting rc RUNLEVEL=[06]" ?
<crimsun> "it depends." For that particular use case, it needed to be serialized, so starting rc RUNLEVEL is correct
<akk> I'd like to understand this stuff better, and understand why starting rc is better here -- but I don't want to be a pest (you've already answered my main questions).
<akk> If you have time to explain it (or know of good docs to read) I'd appreciate it, but if you don't have time, I quite understand.
<jdong> *giggles* lucid RC's installer was at 884% of contacting NTP server
<jdong> I'm using VMWare's magical autoinstaller though, so I don't know whose glitch that is, at ubiquity's startup
<Sarvatt> jdong: if you're using the vmware autoinstaller be aware you'll probably have to mess with the xkb settings since it sets screwed up ones - https://bugs.edge.launchpad.net/ubuntu/+source/console-setup/+bug/548891
<ubottu> Ubuntu bug 548891 in console-setup "keyboard input broken due to invalid "SKIP" keyboard model" [High,Confirmed]
<jdong> Sarvatt: yup, just did that.
<jdong> thanks for the heads up
<Sarvatt> pointed it out to a vmware guy yesterday and he said he can't reproduce with the beta versions - http://communities.vmware.com/community/beta/ws
<jdong> ok so probably their beta version no longer uses SKIP
<superm1> slangasek, it's a problem that we discussed in #ubuntu-mythtv-dev due to a change upstream in the behavior that broke upgraders.  re bug 550100, the fix is targetted, but that patch still isn't blessed - but we're hoping it will make it and be good to go
<ubottu> Launchpad bug 550100 in mythtv "white noise or no sound after seeking when using PULSEAUDIO:default" [Unknown,Fix released] https://launchpad.net/bugs/550100
<superm1> it causes some lipsync problems still
<hdon> hi all. where is the repository for this project? https://launchpad.net/game
<kklimonda> lp:game ?
<hdon> kklimonda, lp?
<hdon> that doesn't look like a url to me :(
<rafl> hi there. i've wrote a couple of patches for the linux kernel to fix the issues #418282 and #512192 and put them in the elantech_fw41 branch at git://github.com/rafl/linux-2.6.git - however, i don't particularly feel like creating a launchpad account just to comment on the tickets. it'd be much appreciated if one of you guys, who presumably already have an account, would add that repo url to the tickets.
<kklimonda> hdon: you can use it with bzr like bzr clone lp:game
<hdon> kklimonda, oh... i'm very unfamiliar with bzr.. and it seems kind of like magic to me that "lp:game" could actually reference something on the internet!
<kklimonda> hdon: you can use http://launchpad.net/game instead - the lp: is just a shortcut for the convienience of people using lp every day.
<Brimstones> Some dick has banned my ip in #ubuntu
<Brimstones> Going back to dumbing myself up and watching some tv then.
<Brimstones> Hmm, ill just change ip and then do both things! :)
<Brimstones> There
<hdon> kklimonda, ahh
<hdon> that's a cool feature
#ubuntu-devel 2010-04-25
<m4t> anyone here know which work-arounds are in place to ensure aligned partitions on drives using 4096phys/512log sectors ?
<YokoZar> Is it possible to delete a dummy package from the archive and replace it with a non-dummy older version?
<LaserJock> ScottK: around?
<ScottK> LaserJock: I am now.
<YokoZar> ScottK: Ahh, good.  Now I can bother you too
<ScottK> YokoZar: Hi.
<YokoZar> ScottK: In order for the replaces/conflicts solution to work we'd still need for the binary wine package to be deleted from the repository
<YokoZar> ScottK: Which is why I think we may have to do something like I have in my PPA where I make original Wine a new version like 1.1.42-0ubuntu3~1.0.1
<ScottK> YokoZar: Let's wait for slangasek to make an appearance.  He knows strange and magical things about this sort of problem and may be able to save us.
<YokoZar> all right
<YokoZar> I'll update my PPA to have replaces/conflicts in wine1.2 like it should anyway (since it really does conflict)
<ScottK> I think he's in transit to London for the release sprint this weekend.
<YokoZar> If there is a release sprint, he's clearly going to it ;)
<ion> bgamari, meet Keybuk. Keybuk, meet bgamari. bgamari appears to have the starting of plymouth block the system startup indefinitely on the ubuntu kernel, but it works with his own 2.6.34-rc build.
<Keybuk> ion: meet the calendar
<Keybuk> the calendar: meet ion, explain about "Saturday" ;-)
<ion> Heh
<Keybuk> sounds like a drm bug anyway
<ion> bgamari: While reporting the bug, please attach dmesg output with both kernels after plymouth has at least tried to start.
<Keybuk> and file it on the kernel, rather than on plymouth
<mantiena> hello
<mantiena> maybe someone knows when new daily build will be available at ftp://cdimage.ubuntu.com/cdimage/daily-live/ ?
<mantiena> maybe someone knows when new daily build will be available at ftp://cdimage.ubuntu.com/cdimage/daily-live/ ?
<lool> persia: thanks for poking qemu-kvm on ia64 and ppc; in theory ppc has a kvm port, not sure how current it is
<slangasek> bgamari: pong
<persia> lool: KVM on powerpc works fine *if* you have a significantly newer kernel than lucid: I'll test, and probably reenable for maverick.  ia64 has some preliminary stuff upstream for qemu: we should be able to build with --disable kvm in maverick, but I didn't see any evidence that kernel support had landed.
<slangasek> YokoZar, ScottK: I think I'm missing conflict for what "the replaces/conflicts solution" is
<persia> lool: I should mention that there has been a longstanding *embedded* powerpc solution for qemu/kvm, but that's not interesting to us, really, as we don't have kernels that can run on that target.  Note also that we need a slightly newer libvirt to do anything useful on powerpc (0.7.7+).  I'd appreciate any thoughts you have on how to do foreign-arch hosting with libvirt.
<lool> persia: What do you mean with embedded powerpc solution for qemu/kvm?
<lool> persia: I looked a bit into libvirt hosting for qemu-system-arm, and it seemed doable, but I didn't try it; you can request a XML of the vms which libvirt thinks it supports, and you can extend that list
<persia> lool: upstream kernel support for "embedded" class processors.  KVM support for PPC970/PPC7447A only landed in .33 or .34 (I forget).
<persia> Cool, that sounds not too difficult: I suppose we'd want to have qemu-kvm-extras-static drop in some hint file to enable it?
<lool> persia: Ok; didn't know that there was a class of CPUs named embedded; I think Debian got things working with qemu-system-ppc -M prep, but I didn't manage to get that to work on Ubuntu
<lool> persia: qemu-kvm-extras-static is for the qemu-$arch linux-user helpers
<lool> persia: So only CPU emulation
<lool> persia: qemu-kvm-extras carries the qemu-system-foo for non-x86 arches
<persia> But I'll want to wait for 0.7.7+ anyway, as it currently fails for any platform without /sys/class/dmi/*
<persia> Ah, right.  So qemu-kvm-extras should provide the libvirt hints.
<persia> There isn't a class named "embedded"
 * persia hunts a more specific reference.
<persia> lool: Seems there was in-kernel KVM support for powerpc 44x hosts, but not more common desktop processors.  KVM upstream seems to be intentionally avoiding doing anything with the POWER series (probably because of PowerVM)
<lool> persia: I couldn't find whether powervm is free software, so I suspect not?
<persia> I think it's zero-additional-cost when you purchase an appropriate hardware solution from IBM.  I don't believe the code is available.
<persia> I'm uncertain whether it's delivered as "firmware" or "software".
<persia> (note that zero-additional-cost above is in the same way that Mac OS X is zero-additional-cost with the purchase of an appropriate Apple hardware solution)
<persia> Hrm.  Looks like there's some ia64 kvm stuff in 2.6.34: maybe we can get full kvm there too.
<ScottK> slangasek: The problem we are trying to solve is that there was a wine package and a wine1.2 package.  Eventually wine1.2 became "the" package and wine was a dummy package provided by wine1.2.  Now it looks like we want to ship both wine and wine1.2 because there are now wine reverse build-deps in the archive from Debian.  So YokoZar uploaded a wine1.2 that no longer provided wine and a wine that (of course) failed to upload due to having a
<ScottK>  lower version than the wine package that wine1.2 used to provide.
<ScottK> So the goal here is to disentangle the two package namespaces somehow.
<ScottK> Any existing user that has wine installed has wine1.2 and should stay with that, but there should be an ability to install wine.
<cjwatson> m4t: parted 2.2 does most of it, plus partman telling it to use optimal partition alignment (unless you override it).  These aren't really workarounds - they're upstream-supported fixes
<doko_> siretart: could you update http://qa.ubuntuwire.org/ftbfs/test-rebuild-20100407/ for the superseded status?
<persia> imbrandon: do you still have access to that?
 * persia suspects it's too early for the rest of UWSA
<siretart> doko_: I think you should ask lucas, I have no idea about these ftbfs lists :-(
<doko_> siretart: no, lucas doesn't do the ubuntuwire stuff
<persia> doko_: Just to confirm: are they being superceded in the rebuild as well?
<doko_> persia: what do you mean?
<persia> doko_: Are new uploads to lucid *also* being auto-copied to the rebuild job?
<doko_> no
<persia> I know that script collects data from the LP buildd status output, so it may be tricky to get it to analyse based on two different archive build statuses.
<siretart> doko_: ah, while I have you here on irc. Do you remember if you left out 'scan-build' and 'scan-view' out of the clang package on purpose? - the clang static analyzer is really great, but it seems these utilities are just not installed into the binary package
<doko_> checked that the superseded build build ok in main
<persia> geser: Do you know if that's possible with the script?
<doko_> siretart: clang is just the debian package. please file a report, I don't mind a sru for that
 * persia suspects it may require additional script hacking to get the desired dataset
<siretart> doko_: debian seems to ship 2.6, while you already uploaded 2.7. the debian package does install clang-scan
<doko_> siretart: probably enabled after I switched to 2.7
<siretart> doko_: see debian bug #568499, fixed in 2.6-2
<ubottu> Debian bug 568499 in clang "clang: please ship scan-build and ccc-analyzer" [Wishlist,Fixed] http://bugs.debian.org/568499
<siretart> our changelog only includes 2.6-1
<doko_> siretart: has to go into a sru
<persia> doko_: At least from a quick glance at the code, I suspect it's hard to achieve what you request without pushing more stuff to the PPA (although you may be more proficient with that sort of thing than I)
<doko_> persia: thanks for checking, won't do that for this rebuild
<persia> doko_: OK.  The source link is at the bottom of the page: it's fairly easy to run locally.  Maybe you can find a way to get the results you desire.
<geser> persia: the FTBFS script for the archive rebuild checks if there is a newer version of a package in the main archive (those are the superseded packages)
<persia> Hrm.  I missed that bit somehow.  So it's already up-to-date regarding superceded status?
<geser> yes, but the status of those packages listed below superseded is that from the rebuild archive and not from the main archive (it's just "old" entries moved to separate tables)
 * persia grumbles about IRC clients.
<persia> doko_: So, as described, your request is already accomplished :)
<persia> geser: Thanks a lot for the explanation.
<doko_> geser: ??? there are no newer packages in the test archive, so why superseded at all?
<geser> doko_: because there is a newer package in the main archive and a package listed as FTBFS in the rebuild archive might got fixed already. So those packages gets moved into their own list to not distract from those which still FTBFS.
<doko_> geser: right, but this checks seems to be only made, when the new ftbfs package gets added to this list, not when the list is generated
<imbrandon> persia: pong
<doko_> geser: e.g. kdebindings
<geser> doko_: the FTBFS page for the archive rebuild lists it in the non-superseded lists and according to LP 4:4.4.2-0ubuntu2 is still the most recent version for lucid
<geser> or did I miss something or misunderstood?
<doko_> geser: gtkhtml3.14 is not, kdebindings maybe was wrong
<geser> hmm, let me check why it doesn't get listed as superseded
<doko_> geser: compiz is superseded as well
<persia> imbrandon: geser/doko may want your help to fiddle http://qa.ubuntuwire.org/ftbfs/test-rebuild-20100407/ later (but it may be not requied)
<doko_> geser: kdebindings, is not newer, but it was requeued, and then the build succeeded. maybe compare the build time stamps for the case where the version is identical?
<persia> Could someone from the release team make a release/proposed call on bug #249295?  It was highlighted in -java, and has a one-character fix
<ubottu> Launchpad bug 249295 in java-common "incorrect path to jinfo file when doing "update-java-alternatives -list"" [Undecided,Confirmed] https://launchpad.net/bugs/249295
<YokoZar> slangasek: one (possibly ugly) option would be to delete the dummy wine binary package from the archive and then replace it with the lower versioned wine 1.0.1 that failed to upload earlier.  Is that possible?  The other options all involve creative use of package versioning that's similarly ugly
<YokoZar> ScottK: ^^
<ScottK> YokoZar: No. You can't remove the history.
<ScottK> YokoZar: Maybe a new wine1.0 package?
<YokoZar> ScottK: Then we're left with either weird versioning or a new package entirely, yeah
<ScottK> The binaries would have to be wine1.0 too
<YokoZar> ScottK: wine1.0 is probably least ugly at this point, yeah.
<YokoZar> ScottK: That even allows reintroducing the wine dummy package for upgrades
<ScottK> Yes.  It should.
<persia> Yave wine-dummy (1.2) depend on wine-1.0 (1.0)?
<persia> Your risk is really those users who still have the dummy wine package installed.
<YokoZar> persia: dummy wine depended on wine1.2, we can reintroduce that and add a wine1.0 package that they will remain unaware of
<YokoZar> Though I'll have to update app-install-data
<persia> And patch all the reverse-build-deps that flow from Debian.
<persia> When was the dummy package introduced?
<YokoZar> only one exists anyway
<persia> (so far ...)
<YokoZar> dummy package was introduced in Lucid build cycle
<YokoZar> persia: debian will need to be more specific anyway, as wine 1.0 and 1.2 differ in how they build things
<persia> When will Debian have both?
<YokoZar> I'm not sure, I'm in touch with someone from Debian at the moment about just using my packages there.  Most likely transition is around wine 1.2 full release in a couple months
<YokoZar> ScottK: Ok, I'll bang out a wine1.0 package later today and put it in a new ppa to test the transitions
<persia> Cool.  There were a few people asking about dssi-vst today.
<imbrandon> persia: qokies, just have em ping me
<imbrandon> okies*
 * persia hopes they will, at this point :)
<persia> But it may be that it doesn't need to change: from the conversation earlier, I'm left unsure as to the final result.
<imbrandon> k
<slangasek> YokoZar: deleting the wine dummy to downgrade the version> nope
<slangasek> YokoZar: so the current wine source fails to upload, I guess?
<slangasek> YokoZar, ScottK: if what is wanted is a 'wine' package that continues to point to wine 1.0 the way it did in karmic, instead of wine1.2 as it does now, I think the only reasonable options are 1) keep building it as a dummy package from wine1.2 source but make it depend on wine1.0, or 2) add an epoch to wine1.0
<slangasek> i.e., 1:1.0.1-0ubuntu11 > 1.1.42-0ubuntu2
<elleuca> hi, anybody using lucid and USB speakers that could verify this: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/569926
<ubottu> Ubuntu bug 569926 in pulseaudio "[Regression] wrong audio volume output stepping for USB speakers" [Undecided,New]
<chrisccoulson> slangasek - are nvidia users meant to see a text mode plymouth theme? i just upgraded my nvidia desktop tonight and i've got some weird issues
<chrisccoulson> (upgraded from karmic -> lucid)
<slangasek> chrisccoulson: no, they're not
<chrisccoulson> slangasek - oh, ok. what vt is xorg meant to run on for nvidia users? it's running on vt6 on my desktop (on top of getty), and it uses a lot of cpu :-/
<slangasek> chrisccoulson: it's obviously not meant to run on the same vt as a getty, no matter what X driver you're using ;)
<chrisccoulson> slangasek, that's what i thought ;)
<slangasek> and I haven't heard of that happening and honestly am not sure how you would get in that state
<slangasek> using gdm?
<chrisccoulson> if i restart gdm, then it restarts on vt7
<chrisccoulson> but it's on vt6 when i boot
<chrisccoulson> so, i'm confused ;)
<slangasek> so there is a possible race condition here
<slangasek> actually a pair of race conditions that, if you hit them both, could give you that result
<slangasek> plymouth-stop.conf is 'stop on (starting gdm or [...] stopped rc RUNLEVEL=[2345])'
<slangasek> if you have very little in /etc/rc2.d, rc could stop before gdm has started
<slangasek> if this happens, you don't get the smooth transition from plymouth to X (which you wouldn't anyway in this case, due to the binary driver)
<chrisccoulson> ah, ok. and that could cause xorg to start on the wrong vt?
<slangasek> and tty6.conf is 'start on runlevel [23]', which means it starts in parallel to all this other stuff
<slangasek> so if gdm starts before the getty has started, when it looks to figure out the first available vt, it might get it wrong
<slangasek> but I thought gdm had some code to guard against this, too
<slangasek> (and the race I've described is *very* unlikely to be hit)
<Aquina> Oh someone saw these Microsoft Internet Explorer 8 ads? They really wanna tell us their shit is secure! :-(
#ubuntu-devel 2011-04-18
<dobey> hey guys, anyone around?
<lifeless> fsvo
<dobey> i saw my ubuntuone-client upload got accepted, but i have a couple of merge proposals for libubuntuone and ubuntuone-control-panel that i'm concerned about getting in for tomorrow
<lifeless> you could talk to the pilot
<lifeless> or main sponsors I guess
<dobey> topic says "Patch pilots: " :)
<lifeless> right
<lifeless> schedule is on the wiki
<dobey> nobody on the oz side of the planet for monday it seems. and probably not a good time for cnd or seb right now :-/
<RAOF> They might be a little bit asleep  :)
<Jerub> what's that ubuntu bug reporitng thing called again?
<Jerub> actually, nevermind.
<dobey> well i doubt cnd is asleep this early, unless he's travelling somewhere :)
<ajmitch> when do they need to be uploaded by?
<dobey> Mon 00:00 UTC afaik
<dobey> so i guess 10 minutes ago? :)
<ajmitch> heh
<dobey> but i proposed them on friday :-/
 * ajmitch can't upload right now, otherwise would sponsor them
<dobey> guess i should probably apply for motu soon
<dobey> and more specific package rights for main
<ajmitch> wouldn't make a difference for this stuff in main
<ajmitch> yeah, more per-package rights would help here
<dobey> would help with the ever-expanding suite of ubuntuone projects though, and initially getting them into ubuntu
<Jerub> facinating, removing python-apport removes ubuntuone
<JanC> ubuntuone-client depends on python-apport
<JanC> I suppose that shouldn't be a hard dependency...
<dobey> why would you remove python-apport anyway?
<JanC> dobey: there might be no good reason to remove it, but I so no good reason for the dependency either?  ;)
<JanC> *but I see*
<dobey> JanC: well it installs an apport reporting module for ubuntuone which requires python-apport
<dobey> i suppose it could recommends instead
<JanC> yeah, a recommends would be reasonable, but a hard dependency seems a bit strong
<dobey> eh, we like to get useful information in our bug reports :)
<JanC> dobey: most people won't remove it anyway
<dobey> right
<cnd> dobey, it's still sunday here, but even so I don't really have the powers you seek :)
<cnd> I only have upload rights for a very small set of packages
<dobey> cnd: guess will have to wait for seb or someone to wake up :-/
<dobey> cnd: thanks anyway
<cnd> sorry!
<JanC> dobey: so Ubuntu isn't global enough yet?  âº
<dobey> JanC: hrmm?
<JanC> the developers I mean  ;)
<dobey> sure, but i don't know who to ping in oz right now to upload my stuff :)
<JanC> like, 24/7 uploaders available
<JanC> hehe
<stgraber> dobey: what do you need uploaded ?
<dobey> stgraber: i have 2 merge proposals pending. one to lp:ubuntu/libubuntuone and one to lp:ubuntu/ubuntuone-control-panel
<stgraber> ok, looking at it now. I'm really not familiar with these two packages, so I'm hoping it's not too big changes :)
<dobey> no, just a couple of bug fixes
<dobey> thanks
<stgraber> dobey: ok, they are both uploaded. You'll just need to wait for an archive admin to review them and let them through.
<stgraber> dobey: just wondering, was there a need to re-generate the configure in libubuntuone ?
<dobey> stgraber: new tarball release does that
<dobey> stgraber: thanks for the uploads
<RAOF> kees: Rumour has it that you've got the full source of the archive unpacked somewhere to grep through.  Would it be possible to grep for the string âGEMâ and â20100330â?  I'm interested in how many programs are checking the GL_RENDERER string for these values.
<kees> RAOF: it's just a full source archive but it unpacks quick enough. if you can produce a regex for me to search for, I can run it. takes a few hours
<RAOF> Ta.  I'll see if I can generate a suitably specific regex.
<RAOF> kees: "([[:space:]]|\'|\")GEM([[:space:]]|\'\")" is the best I've been able to come up with.  Hopefully that won't generate *too* many false-positives.
<pitti> Good morning
<pitti> ScottK: p-d-e> seems someone already NMUed it, so seems alright; I'm really happy to see 2.7 in sid, I can finally upgrade calibre then :)
<dholbach> good morning
<didrocks> good morning
<steveire> dholbach: Is there an ubuntu release party in Berlin?
<dholbach> steveire, yes: http://ubuntu-berlin.de/natty-release-party
<steveire> Ah, on Wednesday.
<steveire> oh wait, that's next month :)
<bambee> It's normal that I am able to bypass polkit auth with the language selector dbus backend ? (I just cancel the password request from the agent)
<bambee> hello btw
<bambee> typically just try this program http://paste.ubuntu.com/595420/ , with "de_DE.UTF-8" as argument (for example) and don't enter the password (click cancel).  Then log you from tty1 and try "locale".
<bambee> (I am on natty)
<JanC> bambee: I can confirm that your test case works
<bambee> JanC: from the user point of view, he can reproduce this test case via language-selector-kde (which no longer runs as root and uses polkit only)
<JanC> bambee: same for the GNOME equivalent
<bambee> pitti: ping
<pitti> hi bambee
<bambee> hi
<bambee> see my test case above
<debfx> bambee: I think the backend just doesn't check the result of the authorization
<bambee> then look at http://bazaar.launchpad.net/~ubuntu-core-dev/language-selector/ubuntu/view/head:/dbus_backend/ls-dbus-backend#L94
<bambee> debfx: it does not
<bambee> you're right
<pitti> *headdesk* good catch
<bambee> the fix is easy , just check the value returned by self._authWithPolicyKit() :)
<pitti> I'll better check all instances of PK there
<bambee> or raise an exception... see an example at lp:bambi there is a userconfig repository.
<bambee> http://bazaar.launchpad.net/~bambi/guidance/userconfig-kde4-dbus-helper/view/head:/dbus_backend/userconfig_helper#L95
<bambee> ;)
<bambee> (still in development, but polkit auth works fine)
<pitti> bambee: thanks; I actually know how this should work, I've done quite a bit with PK myself
<pitti> (I didn't write the lang-sel code)
<pitti> thanks for spotting this!
<bambee> yw :)
<pitti> bambee: would you mind filing a bug about it? I suppose we'll need to fix it in stable releases, too
<bambee> pitti: I will open a bug for that and also attach a patch (we could do nothing if the authentification fails..)
<bambee> what do you prefer ?
<pitti> bambee: doing nothing at all is fine; avoids introducing a new dialog, and PK itself should already display "wrong password", etc.
<bambee> I agree, ok
<lifeless> pitti: ping
<pitti> hey lifeless
<lifeless> pitti: whats the right forum to discuss changing the way apport managings dupes and private bugs?
<pitti> lifeless: as it concerns everyone, I'd say ubuntu-devel@ ?
<lifeless> sure
<lifeless> pitti: but lets do a quick chat here if you have time
<lifeless> can take it to ubuntu-devel if you think it needs that afterwards
<lifeless> basically we get a query quite often - perhaps once every 2 days - where apport detects a dupe
<pitti> ok
<lifeless> strips the backtrace etc and marks it a dupe
<lifeless> but the master isn't audited yet, so is still private
<pitti> right, I hear some complaints about that, too
<pitti> the alternative is to leave the dupes private, too
<pitti> that makes it harder to see which bugs already have been reported, though
<lifeless> pitti: how would that fix it ?
<pitti> i. e. will lead to filing more duplicates
<pitti> lifeless: fewer people getting confused when looking at the public bug
<lifeless> pitti: the people getting confused are the ones filing the bug
<lifeless> pitti: so they will still be confused as they wouldn't be able to see the master.
<pitti> reporter yes
<lifeless> pitti: if the master is private, users cannot read it and thus will still file duplicates.
<pitti> but I don't see a way around that
<pitti> we can't just make all of them public
<lifeless> pitti: could we:
<lifeless>  - file a public master bug with only the metadata needed to detect that its a dupe.
<lifeless>  - leave the raw data dupes private
<lifeless>  - and optionally not strip them at all.
<lifeless> LP will know how many dupes there actually are for calculating heat.
<lifeless> and bugcontrol + devs can read the raw data at their leisure (we could include a 'original filed bug with private attachments is bug 12345' comment which can explain that only Ubuntu developers can read that.
<ubottu> Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
<pitti> more convenient for reporters, less convenient for developers
<lifeless> pitti: I contend that dealing with confused reports subtracts from the convenience developers have
<pitti> and it would mean that the retracer had to open the new master bug itself, so all bugs will appear to have been filed by apport, not by real people
<pitti> which might be ok, just pointing out that it looks odd
<lifeless> pitti: apport could open a new one and shuffle the attachments around, if that angle is important.
<lifeless> pitti: (expanding) - open new bug to be private; move attachments to that bug; purge the original bug; make the original public.
<lifeless> once we have bug relationships this can be easier still
<pitti> should be possible in principle, yes
<pitti> a lot of data downloading/uploading, so I hope that'll be robust enough
<lifeless> its in the DC
<lifeless> right ?
<pitti> yes
<pitti> but that doesn't help much
<lifeless> should be fine; if its slow we can add an API to move attachments between bugs
<pitti> it's slow and not transactional either way
<pitti> I've seen it break way too many times to have a solid confidence in it, so error handling will be hairy :)
<lifeless> pitti: thats true; OTOH the new bug is private, so you can start it with just apport viewing it, copy up the attachments one at a time, and only when its ready expose it.
<pitti> but if attaching the data to the new private bug fails, we can just fall back to what we have now and leave the master private
<lifeless> certainly
<lifeless> we can also look at doing direct to librarian uploads.
<lifeless> which we should do anyway for LP
<lifeless> pitti: ok, should I take this to u-d@?
<pitti> lifeless: if we'll need LP changes anyway, would it be hard to do private attachments?
<pitti> harder than moving them or re-linking attachments to a new bug?
<lifeless> pitti: we don't necessarily need LP changes; doing privacy per-attachment would be a data model change at minimum, not to mention needing a whole new way to describe visibility.
<pitti> ok
<lifeless> so yes, private attachments on public bugs is interesting but tricky to do well - and then there is the likelyhood of someone copying from a private attachment to the bug to make a point, and disclosure fail.
<lifeless> s/tricky to do well/tricky to do -acceptably-/
<pitti> well, subscribed folks can just as easily make the entire bug public
<pitti> but if it's hard to implement, then let's use what we hahve
<lifeless> it is, yes.
<lifeless> pitti: rightiho - so, does this need to go to ubuntu-devel ?
<lifeless> pitti: I'll summarise and send there now if it does.
<pitti> lifeless: I guess at this point a bug report works as well
<pitti> but there might be some more input on the changed workflow then
<lifeless> pitti: whats the bugtracker for the backend?
<lifeless> just the package, or ?
<pitti> right
<hrw> helo
<hrw> I have a question. on friday there were builds of gcc-4.4-armel-cross done and then upload was rejected by archive admin. should I get FFe for it?
<hrw> https://launchpad.net/ubuntu/+source/gcc-4.4-armel-cross
<lifeless> pitti: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/764414
<ubottu> Ubuntu bug 764414 in apport (Ubuntu) "private master bugs are confusing and lead to more duplicate filings" [Undecided,New]
<lifeless> pitti: I'll drop a note to u-d about this
<pitti> thanks
<lifeless> done
<ogra_> TheMuso, still awake ?
<ogra_> TheMuso, seems you miss one of the panda patches in your ppa build (i noted which one in the bug)
<smoser> cjwatson, what do you think about bug 759545 ?
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Confirmed] https://launchpad.net/bugs/759545
<stgraber> mvo: ping
<tseliot> hi pitti, what do you think about bug #763331 , especially comment 2 ?
<ubottu> Launchpad bug 763331 in fglrx-installer (Ubuntu) "VA-API packages helper should be installed with the proprietary drivers" [Undecided,Won't fix] https://launchpad.net/bugs/763331
<stgraber> mvo: I was wondering if you have any comment on bug 760035 and if you are going to include that in the next python-apt upload + push it to debian ?
<ubottu> Launchpad bug 760035 in python-apt (Ubuntu Natty) "Ubuntu.info template doesn't allow deb-src lines using archive.ubuntu.com on ports architectures" [High,Triaged] https://launchpad.net/bugs/760035
<mvo> hey stgraber
<mvo> stgraber: I have a look in a wee bit
<speakman> I'm creating a .deb package, but how do I specify some example files to go into /usr/share/doc/mypackage/examples/ ?
<speakman> It's an autotools package, but the example files are just within the tarball and not installed during "make install"
<directhex> speakman, you can refer to them in your debian/install file
<directhex> speakman, i.e. you can say "foo/bar/baz /usr/share/doc/mypackage/examples/"
<speakman> hm?
<tkamppeter> pitti, hi
<geser> directhex: wouldn't add them to debian/examples be better?
<directhex> geser, or that, sure
<speakman> geser: are there any example of an debian/examples file? /me is totally newb
<speakman> debian/examples was awesome! thanks!
<speakman> When making a new "version" of the package - do I always have to edit the changelog?
<speakman> Adding a new entry in it, I mean
<speakman> Or can I just change the version specified in the latest (and currently only) entry?
<speakman> It's for testing purpose currently.
<speakman> are there any more similar files like "examples" which takes a list of files and make sure they're installed?
<speakman> There are so many great benefits with .deb packageing, but it's terribly difficult for a newbie to learch packaging from scratch :(
<geser> speakman: "man debhelper" contains a list of all those dh_* commands and a short summary of what they do. Some of them use files in debian/.
<speakman> geser: thanks! will look at it!
<directhex> speakman, you only need to worry about package versions when they are uploaded to an archive - for local testing the changelog's version doesn't matter
<directhex> if you upload to a ppa, then the only thing that matters is a newer changelog version than the last upload
<directhex> for a real distro, the history matters. "dch -i" inserts a new log entry
<jjardon> Hi, currently lp:glib points to ~jjardon/glib/trunk instead ~vcs-imports/glib/trunk , how Can I fix this?
<mr_pouit> mvo: thanks for xubuntu-meta ;-)
<mvo> mr_pouit: your welcome, sorry for the delay in looking properly at it
<ohsix> how can i get apport to re-send a crash report i dismissed earlier, it's insisting on full reports now for things and they're quite large; but i can submit them later when i'm not at home
<Mirv> ffe/bug #714861 is stuck in universe new queue, could someone let it through?
<ubottu> Launchpad bug 714861 in fgfs-base (Ubuntu) "ffe: Sync fgfs-base 2.0.0-1 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/714861
<tkamppeter> pitti, around?
<Kurisutian> cjwatson: I checked the ubuntu server install today and it still messes up with the btrfs installation. So the problem from the previous installation still remains....
<barry> mvo: hi do you have some time to chat about bug 458872?
<ubottu> Launchpad bug 458872 in computer-janitor (Ubuntu) "Don't mark for removal manually installed packages" [Wishlist,Triaged] https://launchpad.net/bugs/458872
<brendand> does anyone know if a usb-vga adapter or similar is going to show as having the USB 'Video' base class (0Eh)
<brendand> ?
<brendand> from what i've read it looks like only input devices are given this class, but could be wrong info
<seb128> jamespage, hi, you sent the milestone of bug #764391 to 11.10, is that wanted or an error? (i.e you want it for next cycle not this one)
<ubottu> Launchpad bug 764391 in cobbler (Ubuntu) "cobbler fails to manage bind9 " [Medium,Fix committed] https://launchpad.net/bugs/764391
<jamespage> seb123: no that's not what I mean't - should be 11.04 - doh!
<jamespage> seb128: thanks for pointing that out :-)
<seb128> jamespage, thanks ;-)
<seb128> kirkland, seems like you maintain cobbler, do you want to upload jamespage's fix on https://code.launchpad.net/~james-page/ubuntu/natty/cobbler/fix-764391/+merge/58112 or should I review it?
<seb128> (you know the software better so you are probably best placed)
<jamespage> seb128, kirkland: I think Daviey might already be on it - but I might be wrong
<cr3> tseliot: hi there, regarding brendand's question above, I noticed you participated on this thread: http://ubuntuforums.org/showthread.php?t=260863. might you happen to know how to distinguish usb video and usb capture devices from udev and/or sysfs?
<seb128> Daviey, hey, ^
<seb128> jamespage, thanks for the notice, I'm just doing sponsoring and I'm not in an hurry so I will wait for them to reply
<Daviey> seb128 / kirkland, it is in the queue already
<seb128> Daviey, right, which is why I'm asking, I'm piloting, I can upload but I would appreciate a review from someone who has a clue about the software
<seb128> I don't fell qualified to decide if the template change is right for example
<tseliot> cr3: no, sorry, I wouldn't know. If you have a look at the udev rules in /lib/udev/rules.d/ maybe you'll find something useful though
<seb128> Daviey, doh, you meant natty unapproved queue, not sponsoring queue
<Daviey> seb128, Oh yeah... I've not long reviewed and uploaded it..  Thanks for looking out for it.
<Daviey> seb128, Yes.. sorry - i should have been more verbose.
<seb128> Daviey, would be nice to unsubscribe the sponsors or mark the bug fix commited when you upload to avoid someone else to duplicate work ;-)
<seb128> Daviey, thanks
<Daviey> seb128, i did mark it Fix Committed :P
<seb128> which you did...
<seb128> right
<seb128> one less on the list ;-)
<seb128> Daviey, kirkland, jamespage: thanks
<RoAkSoAx> jamespage: correct me if I'm wrong, but .pc files and stuff should not appear in the branch. right?
<RoAkSoAx> s/branch/diff
<Daviey> RoAkSoAx, No, they should IMO... Whilst it makes it harder to review... That is what dpkg-source -x generates for deb src 3 files
<Daviey> If you merge that into the real branch, then it'll be uncommited by james_w's bot.. and a new merge proposal raised.
<Daviey> fugly yes, requires yes, ideal no.
<RoAkSoAx> Daviey: right, but for example, because something was wrong and there were changes in .pc that weren't reflected in patches, then everytime a new patch was created automatically by quilt
<RoAkSoAx> and that's just wrong
<RoAkSoAx> Daviey: so the fix was to simply remove the "old" .pc
<RoAkSoAx> and let quilt create new one
<Daviey> RoAkSoAx, In that case, you'd need to commit in patch unapplied status
<RoAkSoAx> Daviey: right, but that's what I'm saying. Isn't it the best approach to commit with a patch in unapplied status, and when debuild'ing, the .pc will be automatically updated by quilt avoiding situations as the one explained above?
<Daviey> RoAkSoAx, Hmm.. i agree you can't really merge .pc files.. but overwrite.  So i do agree..  If you want to propose a workflow to ubuntu-devel, i'm sure people will have thoughts and comments on it.
<Daviey> I do tend to suggest merge proposals in patch applied, with .pc files currently.. Happy to revist that if there is a consensus on work flow.
<RoAkSoAx> Daviey: yeah, I preffer not have them in applied status, cause I've seen many cases on which .pc changes sometimes appear in debdiffs or simply, quilt creates new patches for changes that are in .pc that shouldn't be there... so the fix is really to cleanup .pc
<Daviey> RoAkSoAx, Please write a proposal :)
<Daviey> seb128, So, i didn't mark it as merged because i didn't think it was a clean thing to do - incase the release team nack the upload.
 * Daviey afk's
<RoAkSoAx> Daviey: won't exactly write it as a proposal but rather I'll raise a discussion over it :)
<cnd> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: cnd
<mvo> barry: sorry, was in a call, let me look at the bug
<kees> RAOF: started the search. I'll email you the details when it's done. :)
<robbiew> ev: ping
<ev> robbiew: pong
<robbiew> hey..any chance of getting some wordsmithing in the Installer for bug 420080
<ubottu> Launchpad bug 420080 in debian-installer (Ubuntu Oneiric) "Configure encrypted volumes destroys existing data" [Critical,Triaged] https://launchpad.net/bugs/420080
<ev> it's a bit late for that, no?
<ev> oh, Oneiric
<robbiew> ev: yeah
<robbiew> Oneiric
<ev> yeah, I don't see that being a problem for O
<robbiew> ev: agree...too late for Natty
<ev> for a second there I thought you were going to have work for me to do :-P
<robbiew> ev: heh
<robbiew> ev: thnx
<ev> any time
<robbiew> ev: got another for ya
<robbiew> bug 764750
<ubottu> Launchpad bug 764750 in casper (Ubuntu Natty) "No shutdown/Restart menu on live session" [High,Confirmed] https://launchpad.net/bugs/764750
<ev> boo
<robbiew> fixable now...or punt to Oneiric
<ev> yeah, I've been trying to sort that.  I put what I thought was a stopgap measure in place, but that doesn't seemed to have solved it
<ev> there's another bug where Iv'e been tracking this
<ev> but yes, I think it's o at this point
<ev> I can't reproduce it locally
<ev> and it seems to be intermittent
<robbiew> ack
<ev> either way, it's not that common
<robbiew> thx
<ev> most people go through the installer only session, I think
<ev> so they wont ever hit this
<ev> and presumably most people click "reboot now" in the installer anyway
<robbiew> agree
<infinity> That's an... Odd bug.
<robbiew> just checking to see if it was a "easy" fix
<robbiew> if there is such a thing
<robbiew> hehe
<infinity> I disagree on the "most people boot installer only" though. I know plenty of people that use the LiveCD as a LiveCD.
<ev> but then they're likely not installing
<infinity> Sure...
<ev> ubiquity is what's removing these items
<ev> for the duration of the actual install
<ev> s
<infinity> At which point, a midding "reboot" menu option is confugin.
<infinity> confusing, too.
<infinity> Oh, it's dying during the install?  Okay, that's weird.
<ev> well, ubiquity sets it for the file copy phase
<infinity> The bug implies that the menu item is missing after boot.
<ev> so people don't reboot their computer in the middle of that
<ev> oh
 * ev re-reads
<ev> maybe this is different
<infinity> Burn -> Boot -> No menu item.
<ev> in the live session
<ev> not the installed system
<infinity> Yeah.
<infinity> No reboot item on a live system isn't world-ending, since the odds of data loss on hitting the reset button are next to zero, but it sure is confusing.
<ev> sure, I'd really like to nail this
<ev> but I don't see that happening in natty
<infinity> Yeah, fair enough.
<robbiew> +1
<infinity> And, to be fair, the sorts of users that intentionally use LiveCDs as LiveCDs are also the sorts of users who know how to reset a computer.
<infinity> (Unlike say, my parents, who literally would have NO idea how to reset/reboot their machine without a GUI button to do so, short of pulling the power)
<robbiew> heh...good point
<infinity> ev: It's possible the bug reporter's intermittent issue was that he fired up Ubiquity and then cancelled the install?
<infinity> ev: That would be hard to reproduce if you forgot that's how you got there in the first place. :P
<ev> infinity: it's an atexit call
<ev> so even that would catch it
<ev> haha
<infinity> Unless Python cores when you cancel.
<infinity> Just saying. :)
<infinity> (Or any number of other reasons an exit hook can get skipped)
<kklimonda> doko: hey, any idea what's happening with clang in natty? I can't build applications that include (directlry or indirectly) curl/curl.h: http://paste.ubuntu.com/595577/
<kklimonda> doko: If I make a symlink asm-generic -> asm then it works fine.
<tkamppeter> pitti?
<bdmurray> mvo: Are you still working on bug 683904?
<ubottu> Launchpad bug 683904 in grub2 (Ubuntu Natty) "natty: memtest86+ fails to run, reboots immediately" [High,Confirmed] https://launchpad.net/bugs/683904
<mvo> bdmurray: I did not make any progress on this, sorry
<bdmurray> mvo: okay, I just wanted to know where we stand
<infinity> kklimonda: It's actually /usr/include/$gnu-machine-type/asm/ that you want.
<infinity> kklimonda: I imagine clang isn't down with the New World Order there.
<maco> ev: afaict, accerciser gets very unhappy with sudo. i think i had to DISPLAY= to get it to even start, but it still wasn't playing nicely
<kklimonda> infinity: ah, that makes sense. Thanks
<pitti> tkamppeter: I already ponged several times, didn't I? what's up?
<ev> maco: oh, I completely forgot.  So I do: sudo -u ubuntu DISPLAY=:0 python test_ubiquity.py
<ev> where test_ubiquity is:
<ev> http://bazaar.launchpad.net/~ev/+junk/ubiquity-ldtp-tests/view/head:/test_ubiquity.py
<maco> ev: thank you!
<ev> sure thing
<tkamppeter> pitti, sorry, did not see your pongs, something must have gone wrong. It is about several segfaults of CUPS, like for example bug 759031.
<ubottu> Launchpad bug 759031 in cups (Ubuntu) "cupsd assert failure: cupsd: ../avahi-common/dbus-watch-glue.c:205: timeout_data_ref: Assertion `t->ref >= 1' failed." [Undecided,New] https://launchpad.net/bugs/759031
<ev> let me know if you're still having trouble, though I wont be able to do anything until tomorrow
<maco> ev: i'll be doing taxes tonight anyway ;-)
<pitti> tkamppeter: ah,  right; are there better patches available for the avahi integration?
<tkamppeter> pitti, they seem to be all caused by the Avahi patches but I cannot say exactly as Apport retracing generally does not work with CUPS. In addition, I did not succeed to reproduce any of these crashes.
<pitti> tkamppeter: hm, that particular bug wasn't touched by the retracer at all as it seems; I marked it for retracing and will have a look what's going on
<tkamppeter> pitti, What I have done now is asking twaugh about whether he has done fixes on these patches and he told yes and so I have regenerated our patch based on twaugh's newest version and there are indeed two small changes.
<tkamppeter> pitti, Now I am thinking about replacing our patch in the hope that these two little changes cover some of the crashes.
<pitti> tkamppeter: as long as the effective delta is small and looks sane, that sounds ok
<tkamppeter> pitti, that is the case. It is one addeed check for a variable, one forgotten "free()" added, and a variable initialized to 0 (so actually three).
<pitti> these sound like good fixes
<pitti> tkamppeter: we have the cups-pdf apparmor fix queued as well, so we'll need another upload anyway
<tkamppeter> pitti, I will add the updated patch ASAP.
<tkamppeter> pitti, bug 754567 is another CUPS crasher ...
<ubottu> Launchpad bug 754567 in cups (Ubuntu) "cupsd crashed with SIGSEGV in dbus_message_iter_append_basic()" [Medium,New] https://launchpad.net/bugs/754567
<JFo> micahg, that plink error you reported against the kernel... it happens every time the chroot is destroyed?
<tkamppeter> pitti, and bug 711875 is even worse, as 8 people tell they are affected by it.
<ubottu> Launchpad bug 711875 in cups (Ubuntu Natty) "cupsd crashed with SIGSEGV in main()" [High,Confirmed] https://launchpad.net/bugs/711875
<micahg> JFo: yes, but I think it might be related to being in /dev/shm
<JFo> ah,
<JFo> micahg, is that something you need to be in for building, or are you testing an alternative?
<pitti> ev: how can something be infinitively better than the old thing if the old thing wasn't completely broken? :-)
 * JFo knows next to nothing about aufs
<jibel> mvo, we are currently receiving many duplicates of bug 764883
<ubottu> Launchpad bug 764883 in aptdaemon (Ubuntu Natty) "<type 'exceptions.NameError'>: global name 'trans' is not defined" [High,Triaged] https://launchpad.net/bugs/764883
<ev> pitti: mind the hyperbole :-P
<mvo> jibel: yeah, a fix is uploaded, sorry for this
<JFo> micahg, this aufs version seems wrong as well
<JFo> well, wrong/different from ours
<mvo> jibel: aptdaemon 0.41+bzr646-0ubuntu2
<mvo>  * debian/patches/01_fix_locking.patch:
<mvo>     - cherry pick from evfool, many thanks (LP: #764422)
<JFo> micahg, <tgardner> JFo, the file that the WARNING is coming from is only 396 lines in our version
<micahg> JFo: well, jdstrand added a way to use sbuild in /dev/shm, so I thought I'd try it
<JFo> ah, I see
<micahg> JFo: idk, I should be using the latest kernel
<jibel> mvo, seems to be the version affected by this bug. Package: aptdaemon 0.41+bzr646-0ubuntu2
<micahg> JFo: 2.6.38-8.42
<tkamppeter> pitti, new patch is pushed to the BZR.
<tkamppeter> pitti, can you have a look at bug 711875, bug 754567, bug 751770?
<ubottu> Launchpad bug 711875 in cups (Ubuntu Natty) "cupsd crashed with SIGSEGV in main()" [High,Confirmed] https://launchpad.net/bugs/711875
<ubottu> Launchpad bug 754567 in cups (Ubuntu) "cupsd crashed with SIGSEGV in dbus_message_iter_append_basic()" [Medium,New] https://launchpad.net/bugs/754567
<ubottu> Launchpad bug 751770 in cups (Ubuntu) "cupsd crashed with SIGSEGV in dbus_connection_get_is_connected()" [Medium,New] https://launchpad.net/bugs/751770
<pitti> tkamppeter: hm, your commit will close all four bugs in the changelog, but that's not proven yet, is it?
<tkamppeter> pitti, that is true. So perhaps remove the ":" or so.
<pitti> tkamppeter: ok
<tkamppeter> pitti, I only want to have the reference to the bugs in the changelog.
<pitti> tkamppeter: 711875 just got closed
<pitti> tkamppeter: ok, will upload, then we'll see how it goes
<tkamppeter> pitti, I see, seconds ago.
<tkamppeter> pitti, perhaps a fix in a library which CUPS uses.
<tkamppeter> pitti, there are many bugs of the kind "cupsd crashed with SIGSEGV in dbus_...()" with different D-Bus functions. Looks like that something is wrong with the D-Bus library. Perhaps it formerly supported certain calls from CUPS which it does not support any more. Can be a problem of libdbus.
<pitti> unlikely, though; we don't see a lot of dbus crashes in other parts of the system; most likely it uses dbus in a wrong way
<tkamppeter> pitti, so seems that they messed up the D-Bus use in CUPS 1.4.6? Or CUPS used a deprecated way of using D-Bus all the time and now it does not work any more (and all other programs use D-Bus correctly).
<pitti> the dbus api hasn't changed in ages really
<pitti> the only changed thing I'm aware of is the avahi patch (and avahi uses dbus extensively)
<tkamppeter> pitti, so we must hope that these fixes in the Avahi patch solve also these ones.
<tkamppeter> pitti, more we cannot do in the moment as CUPS is not retracing correctly. This needs really to get fixed.
<SMG> im sorry about this, I know this is not the place, but running out of options " can someone help me, i need to update the "ar" file under "binutils", because it causes "*** buffer overflow detected ***: ar terminated" while compiling anything, but I cant update binutils because of the same problem?"
<pitti> doko, chrisccoulson: seems doko's last upload of icedtea-web was against a previous  version and just reverted Chris' upload completely?
<pitti> http://launchpadlibrarian.net/68408826/icedtea-web_1.1~20110320-0ubuntu2_1.1~20110406-0ubuntu1.diff.gz
<pitti> chrisccoulson: I can sponsor it tomorrow morning if needed, but really need to run now
<SpamapS> interesting..
<SpamapS> the new chroot support in upstart can confuse things a bit
<SpamapS> schroot doesn't stop all upstart jobs.. so processes stay alive in the chroot even on exit because upstart respawns them
<mvo> jibel: oh - that was supposed to be the fix
<mvo> jibel_: looking
<achiang> doko: ping
<SpamapS> jhunt: ugh, just now got to your email from 9 hours ago. ;)
<cyphermox> hi, could someone please review this? --> https://code.edge.launchpad.net/~mathieu-tl/ubuntu/natty/mobile-broadband-provider-info/20110415/+merge/57946
<stgraber> cyphermox_: looks good.
<cyphermox_> stgraber, thx
<stgraber> cyphermox_: merged and uploaded. You just need to wait for an archive admin to review it.
<cyphermox_> ok, thanks
<phb> hey guys, not sure if my channel fits here. I'm wondering if ALL of HAL (dbus) is deprecated, or only certain parts?
<phb> s/channel/question/
<ohsix> ok what do i do here. https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/764874 a bug i posted earlier got marked as a dupe of a bug that's "resolved fixed": https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/711429 but it is still happening, the retracing service is the one that marked it as a duplicate; i don't know how it chooses to do that, but could someone manually confirm they're the same?
<ubottu> Ubuntu bug 764874 in nautilus (Ubuntu) "nautilus crashed with SIGSEGV in g_closure_invoke() (dup-of: 711429)" [Undecided,New]
<ubottu> Ubuntu bug 711429 in nautilus (Ubuntu) "nautilus crashed with SIGSEGV in g_closure_invoke()" [Medium,Fix committed]
<ubottu> Ubuntu bug 711429 in nautilus (Ubuntu) "nautilus crashed with SIGSEGV in g_closure_invoke()" [Medium,Fix committed]
<ohsix> moreover, it looks like an unrelated bug that was marked upstream as having solved it
<ohsix> seb128: ping
<seb128> ohsix, hi
<ohsix> can you look at the above? you marked it with the upstream bug
<seb128> ohsix, it's fix commited
<ohsix> it's happened twice today so i expect it to annoy me for some time :|
<ohsix> yea it's happening again, presumably i have whatever fix was added then, or is it not included yet?
<ohsix> this is the second bug i reported that was marked dup of that one i think, but the last time i reported it was like 5 months ago; on mav, it started happening again today, though
<ohsix> i don't know how to tell if i'm using packages with the fix included, or if it should be marked new again; or another bug should be filed for the same thing if it's a bug at the same site
<seb128> ohsix, there is just a workaround in upstream git but it's not really a fix
<seb128> ohsix, there is no fix in ubuntu
<ohsix> oh ok
<ohsix> a notice would be on the bug when a package is rolled with it, right?
<seb128> the bug would turn to fix released
<ohsix> ahh
<ohsix> ok thank for the information
<m4n1sh> in which package is mozilla/ModuleUtils.h file contained?
<m4n1sh> this is for upgrading a firefox extension for FF4
<ohsix> seb128: perhaps you can advise me on something else, i created a patch to restore functionality upstream dropped, and they are particularly brickwall about it; i want to get the patches included in more than my ppa, how do i do that? https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/713604
<ubottu> Ubuntu bug 713604 in transmission (Ubuntu) ""Proxy" tab feature removed" [Wishlist,Won't fix]
<ohsix> they're even moderating their trac bug reports and removing comments on the related bugs
<seb128> ohsix, no idea about how transmission upstream is working
<ohsix> i contacted them a few days before i bothered with the patch and i was really surprised :[
<ohsix> the patch is small and it's a revert of a change that was made just before the 2.13 release was tagged; basically all that changed besides bug fixes in 2.12 -> 2.13 was removing the tab and the suppot
<ohsix> i tried contacting the packager but he hasn't replied yet, i just don't know the process of proposing it for inclusion
<ohsix> need a sponsor i guess?
<ohsix> thanks again for your time, and as i've said before you've touched a lot of my bugs! i really want this patch in but don't know where to start
<ohsix> argh the same person that's very very very very rude and also moderating their ticket comments is the driver/maintainer for the package on launchpad, i really need someone bigger than myself to work with them; i already tried to negotiate with them with an abundance of good will and politeness and they just brushed me off
<bloops> would there be any problems if I have two different versions of g++ installed on my system?
<ohsix> seb128: is there someone with time to discuss these things available somewhere? or is patience and asking here all i can do
<seb128> ohsix, you can open a bug with the diff and subscribe ubuntu-sponsors for review but we don't to no revert decisions from the upstream project
<seb128> it's their code
<ohsix> yea, in understand that; but they are being underhanded about accepting public comment, their public correspondence suggests they invited it but they are very very very rude if you even mention bringing it back
<ohsix> theres no other public discussion than the trac bugs either, and as i've said they're moderating them to keep discussion down; so on the one hand they say they want public comment, but also won't allow it to get through
<ohsix> it makes transmission useless for me, and 2.12 isn't packaged for natty; so it's a big deal, at least for me
<ohsix> if they're not accepting public comment, even though they "are"; i need someone that frankly, matters; to ask them about it, so they will be as rational as you can get them
<ohsix> seb128: i posted a diff on the original bug, should i open a new one just for it?
<ohsix> (just for ubuntu-sponsors)
<seb128> ohsix, if the bug is closed yes
<ohsix> seb128: ok thanks
<ohsix> seb128: any special things to put in the title? like [PATCH] or [FFe]
<seb128> no
<ohsix> k thanks
<ohsix> seb128: https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/765248 posted, i'm very interested in things i might do well to correct :D
<ubottu> Ubuntu bug 765248 in transmission (Ubuntu) "patch to add proxy support from 2.12 to 2.13" [Undecided,New]
<ohsix> if you could add your weight to it even better! like i said, i wasn't even given the respect you think they'd give a human being
<seb128> ohsix, some extra context like the upstream commit reference and the upstream bug url would be nice
<ohsix> they're on the ppa summary page but i can add them there
<seb128> that would be useful
<seb128> you want to subscribe ubuntu-sponsors to the bug as well
<ohsix> oh i added it as a tag, not a subscriber :|
<ohsix> i tried not to sound hyperbolic, but man you won't believe how i was treated :|
<ohsix> added the references from the ppa page to the bug
<ohsix> on the plus side i learned all about how to package and upload things :]
<ohsix> i'll have to find something to package!
<ohsix> seb128: ooh just realized i left the window open; saved the log
#ubuntu-devel 2011-04-19
<ohsix> hah why does the copy dialogue notification icon just have a mouse cursor on it
<ohsix> it used to be a file cabinet
<kklimonda> the problem with this transmission patch is that it would restore a functionality that upstream doesn't want in this form.
<kklimonda> I'm reluctant to restore functionality removed by upstream, as imo it's not our call what they want to do with their software. This particular issue has been discussed in the upstream tracker to death, there is a workaround, and the better proxy support will come soon..
<kklimonda> ohsix: I think I've lost your email in the pile of emails to reply to.. I can't find it right now, but I do remember reading it.
<kklimonda> ohsix: there are more problems with the patch, we are 9 days before release and the patch would break user interface freeze, and there are no longer translations shipped in the package (I wonder if they are available in the language packs)
<ohsix> kklimonda: yea i tried to speak with them about what form is acceptable, they weren't having it
<ohsix> it's just "WE DONT WANT IT", caps usesd for emphasis and to cover the frankly obscene interaction i had with them
<kklimonda> ohsix: that's because the decision how to bring proxy support back has been made.
<kklimonda> the idea is to use system-wide settings
<ohsix> kklimonda: i've discussed that with them as well; torrent clients are in a unique position that ptoxy options will probably differ between the different types of connections they make; you really need private settings
<kklimonda> the problem is this solution doesn't make everyone happy.
<ohsix> the problem was proxy support didn't suit everyone in the first place, so they removed it alltogether
<ohsix> they really seemed to invite public input but they aren'ty, they're moderating trac comments and the like
<kklimonda> have you given good and legal reasons for not wanting to use system-wide proxy settings? afair at no point did anyone give a reason for private proxy settings that didn't involve vague words like "privacy"
<ohsix> kklimonda: i couldn't find the "to death"
<ohsix> yes, and i told them
<ohsix> i can provide the entire irc log if you wish
<ohsix> but the long short of it is i use it to scrape/announce trackers as if i were at home; while i roam with  my laptop
<ohsix> (ssh -D to home ... etc)
<ohsix> i know about people saying they want privacy and thinking thats what they get, and about the protocol itself; frankly all of it
<kklimonda> no need, I have the logs.
<kklimonda> but really, what are the reasons anyone would want a privacy?
<ohsix> ok, i hope you'll see that i was perfectly frank in my intentions and polite to no end
<ohsix> no clue; i don't want or need for privacy or i wouldn't be using a torrent client
<ohsix> my very narrow case is having a socks proxy to home, so it looks like the scrapews/announces are from there
<ohsix> you can probably see that having global options when that's all i want is untenable
<cnd> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<kklimonda> really, from where I stand the issue is rather simple - some people want to use private trackers, and T devs knowing what is being shared there don't give much thought about it.
<ohsix> the discussion was far from exaustive, at least the things archived in trac tickets
<ohsix> so you mean they have made a moral judgement  with regard to the usage, expecially concerned with proxy support?
<kklimonda> I can't speak for them, but that's how I see the whole issue.
<ohsix> after all the software can be used to pirate things, just like the proxy support can be used in ways they don't like; but they don't remove the torrent downloading ability
<ohsix> it's getting very tough to type, on 3g at the moment
<ohsix> so is my use case unlike the concerns you've heard aired before?
<kklimonda> I'd have to read your discussion with jordan to really comment on this particular case.
<ohsix> i could certainly use a voice other than my own, apparently, to get my concerns aired
<kklimonda> but my main issue with reintroducing proxy support doesn't have anything to do with whether I agree with their judgment, or not.
<ohsix> btwe, notwithstanding; current "global" support doesn't work with socks, though jordan pointed out where it would need to be fixed AND he didn't disapprove my ttrac ticket like they've been doing with my comments on trac tickets
<kklimonda> as I see it there are three problems: It's really late in the cycle to reintroduce this patch given that it adds the new interface, and requires translations. I don't know if those translations are still being shipped, or not.
<kklimonda> We, as maintainers, shouldn't really make calls about whether some changes made by upstream are good or bad.
<ohsix> so i have to setup privoxy to forward http to socks (ssh -D) and only for certain hosts, since i don't want to send my web traffic through the same proxy
<kklimonda> (can't think of the third point, as it's getting late)
<ohsix> i get that, and don't expect you to do much more than comment; at best speak for my concerns since nobody is listening
<kklimonda> jordan did acknowledge that he has handled the removal of proxy badly.
<ohsix> i have to say it's the worst treatment i've _ever_ gotten trying to work with another project
<ohsix> my beef is that they invited public discussion but didn't really mean it
<kklimonda> but it's his decision, him being the lead developer, how he'd like to handle it further.
<kklimonda> them moderating trac most likely have nothing to do with moderating the discussion.
<ohsix> (re: censoring trac tickets and the treatment of people politely airing their concerns)
<kklimonda> moderation has been enabled some time ago for other reasons
<ohsix> well if my comments show up; i'll let you know, they were quite specific and only on one bug
<ohsix> i can't impress upon you how rudely i was treated, that i'm being moderated on trac is not far fetched
<ohsix> as i said during that conversation, i'm being romantic about switching away from transmission; i should just do it if it no longer suits, but i'm having a very hard time doing so, it is the most usable client
<ohsix> it's really a shame they only have forums, trac, and irc; i couldn't find any public discussion outside of those trac tickets
<ohsix> i offered to completely own the feature and implement it in a shape and form they could agree with it
<ohsix> obsequiousness is a word roused in the mind about the situation
<kklimonda> hmm, no - from what I have read jordan has given you hand in implementing socks support in the current code (which takes socks configuration from gnome proxy settings)
<ohsix> kklimonda: thanks for your time, like i said; maybe you can speak for the use-case, i've been dismissed and thrown into the memory hole
<ohsix> as i've explained that isn't useful to me
<kklimonda> but you were pressing the issue of restoring the original private proxy support, and you were told over and over that it's not going back
<ohsix> privoxy is going to nee dto be in the middle even if socks support worked
<kklimonda> and then the entire discussion went south.
<ohsix> i don't want all my web traffic to go through my home connection; it is heavily metered
<ohsix> only "original" insofar as not using the global settings, i don't care what the ui looked like; and was willing to own it
<kklimonda> but it's not a matter of how gui looks like, they are just not interested in the private proxy support.
<ohsix> he would not be forthwright in telling me what was wrong with it; he was not being intellectually honest, it was his choice of course, but
<ohsix> i have to stop using the best torrent client available because of that
<ohsix> i hope you understand that i don't want that
<ohsix> i don't care if it's only available by edfiting settings.json directly; or anything
<ohsix> you cant get tsocks to pick one port to forward either; so you can't use it
<ohsix> torrent clients are in a unique situation, one where having different proxies for different types of connection the client makes is desirable
<ohsix> that can only be supported in the client itself; as it's the only one that makes any real discrimination
<ohsix> i couldn't get him to explain why it was there at all if it didn't please them now, either; he didn't have to of course, but i kept grasping at connections i could make and still treat him as a reasonable person
<kklimonda> many features are being added because it seems to be a good idea at the time.
<ohsix> right
<ohsix> i'm not asking for exaustive proxy support like some people were either; just what was there
<ohsix> kklimonda: do you at least accept the premise that torrent clients are unique with the respect to how they connect? i can't think of anything that uses several connection types in one program that you'd desire proxying
<ohsix> it's an exceptional scenario for sure
<ohsix> what really blows my mind is the global proxy support still only uses it for scrapes/announces; which doesn't account for the most requested option to be added, the stuff that probably prompted its entire removal in ffrustration
<ohsix> i get your position as maintainer; but it'd be nice to have another person speak for my use case, since i'm appaarently not leet enough to do so
<lifeless> ohsix: how are torrent clients unique?
<kklimonda> ohsix: I accept that some people don't want to have their torrent activity tracked to themselves.
<ohsix> lifeless: unique in the sense that it can be desirous to have different proxying options for only certain types of connections they make
<ohsix> kklimonda: no, that's exactly what i want
<lifeless> ohsix: like voip clients, lots of fps games and web browsers?
<ohsix> kklimonda: just like i ssh'd in here on my laptop, with my phone; to use the resources i have at home
<ohsix> i roam a lot and i want it to scrape/announce from my home connection
<ohsix> i know the implications, and i also know you can't tell transmission to use your local ip for scrapes like you can for some other clients, but i still desire to scrape/announce from home
<ohsix> and i still desire to use transmission D:
<kklimonda> change trackers that you use - binding ratio to ip is a retarded idea.
<ohsix> there are no ratios involved my friend
<kklimonda> what's the point then?
<kklimonda> I'm really curious
<ohsix> i'm thinking you are implying some things in our conversation that just aren't the case
<kklimonda> well, not really. I just know only of two reasons to use proxy for tracker communication.
<ohsix> i'll tel you privately if you really wish to know
<kklimonda> neither of them really imply anything.
<ohsix> i told you my reason; you fit it into some preconcieved notion
<ohsix> i don't know of any trackers that use your ip to track ratios, either; but lets not digress
<ohsix> i get the sense that i'm sort of being dismissed again; since you assume i'm making the case for something you've seen made before, with respect to "privacy" or whatever
<ohsix> but at least you're being very honest about your concerns, and out in the open
<kklimonda> I'm not dismissing you, I understand your concerns, and I'm aware of the entire issue.
<ohsix> but you misconstrue my intent to announce/scrape from my home computer as something else; you even mentioned ratios
<ohsix> as i say that though, i get how you might
<ohsix> but i'm literally only connectiong home, not to some 3rd party shell or "vpn" provider, and only so it scrapes from home
<kklimonda> it's just that I have a feeling that we are going in circles.
<kklimonda> All I'm saying is that the removal of feature is upstream developers' decision.
<ohsix> i got that
<kklimonda> I've even tried to give you my point of view on why has they made this particular choice.
<ohsix> my use case is valid for me, and i will have to use another client, i do not want to; as it's the most usable client packaged in ubuntu; my dillema is that i'm being irrational about just switching
<ohsix> and i'm asking you to voice my concern, since i tried and failed
<ohsix> let me message you and tell you why i do it
<kklimonda> sure
<ohsix> hm re: adding ubuntu-sponsors to a patch request, if it's within the guidelines for a possible change is it generally well considered and most likely added?
<ohsix> can someone unsub ubuntu-sponsors here https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/765248 the bug is all sorts of garbage now; and i don't want to spam them with every reply
<ubottu> Ubuntu bug 765248 in transmission (Ubuntu) "patch to add proxy support from 2.12 to 2.13 (dup-of: 713604)" [Undecided,New]
<ubottu> Ubuntu bug 713604 in transmission (Ubuntu) ""Proxy" tab feature removed" [Wishlist,Won't fix]
<TheMuso> Hrm either someone didn't beat me to it, or https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/765248 doesn't have ubuntu-sponsors subscribd.
<ubottu> Ubuntu bug 765248 in transmission (Ubuntu) "patch to add proxy support from 2.12 to 2.13 (dup-of: 713604)" [Undecided,New]
<ubottu> Ubuntu bug 713604 in transmission (Ubuntu) ""Proxy" tab feature removed" [Wishlist,Won't fix]
<SpamapS> TheMuso: ditto ;)
<TheMuso> s/didn't//
<ohsix> ok thanks whoever did it
<ohsix> and apologies to the messages that did get to them :[
<ohsix> i'm just forehead slapping amazed, over and over again
<SpamapS> hmm.. is there an easy way to extract the core dump out of an apport crash file?
<TheMuso> SpamapS: Apport does have a way to unpack a crash file, apport-cli does anyway.
<TheMuso> Manpage or -h should give you the info.
<SpamapS> TheMuso: its just telling me I have out of date packages
<SpamapS> --save should just save it anyway, damnit. :-P
<TheMuso> SpamapS: apport-unpack is what you want.
<TheMuso> I knew it was there somewhere.
<SpamapS> yes thats what I wanted.. :)
<ilea> someone here that helps on ubuntu 11.04?
<cinerama> hi ilea, you might want to join #ubuntu and ask over there...
<ohsix> specifically #ubuntu+1
<ilea> i want to talk with someone that is in the team that makes ubuntu 11.04
<ilea> not to chat
<ohsix> about what?
<ilea> because there is a bug in ubuntu 11.04 and i need to talk with them
 * SpamapS bets $5 on Unity
<ohsix> ilea: bugs can be filed on launchpad, security bugs are private by default if you want only developers to see it
<SpamapS> ilea: tho to add to ohsix's point, it is appropriate to ping this channel about important bugs that have been filed and ignored.
<ilea> after i make a dsl conection (username, service, pasword) i try to conect and after a time it dosnt conect
<ilea> the indicator is going up like a wi-fi conection
<ilea> but nothing
<ohsix> that sounds like grist for #ubuntu+1, and if they figure something out; filing a bug
<ohsix> ilea: networkmanager keeps logs, you can see what it does when it brings the link up
<ohsix> grep NetworkManager /var/log/daemon.log
<ilea> i cant fill a bug report because i cant send it with no internet conection and i am a litle new and dont now how to save it and send it from another distro
<ilea> after conection fails to try and type that in terminal?
<ohsix> that's alright, the information that will help will be in that file; if you can save a text file with the output, people in #ubuntu+1 can help you find the real cause
<ilea> grepnetworkmanager....?
<ohsix> yep
<ohsix> case and spacing is important
<ilea> so i have to wryte that is terminal after conection fails and then save a text file with it and go on ubuntu+1?
<ohsix> yep, once they can read it they can try and help fix it
<ilea> but how to send it on irc? i have to paste it here for them to read it
<pitti> Good morning
<SpamapS> howdy pitti
<pitti> hey SpamapS, how are you?
<SpamapS> pitti: good. Way too busy. :-P
<didrocks> good morning
<steveire> Hi, I'm trying to learn packaging. I've got the source of grantlee, and I've got the newer source tarball from http://downloads.grantlee.org/
<steveire> (I'm the grantlee upsteam)
<steveire> What's my next step?
<broder> hmm...what makes plymouth actually show the splash on shutdown? on bootup, it's the plymouth-splash job, but none of the conditions there will trigger on shutdown
<broder> oh, wait - just noticed the post-start script. bah
<SpamapS> broder: shutdown is all sysv
<diwic> steveire, unfortunately there are several ways of doing packaging and how to easiest update to a new upstream version depends on how it is currently packaged
<SpamapS> steveire: there's a new tool thats somewhat experimental, called pkgme, that may help
<SpamapS> steveire: what language is grantlee in?
<broder> SpamapS: i think i'm seeing a race between the plymouth upstart job and the casper sysv init script on shutdown. does that seem plausible to you?
<steveire> C++/Qt
<SpamapS> broder: yes its always a possibility
<steveire> diwic: How do I find out whihc it is?
<broder> SpamapS: yeah, i think a race there is consistent with what i'm seeing. i guess this puts me in support of your plans to upstart-ify the shutdown for O :)
<diwic> steveire, from looking at debian/rules we can see that it uses cdbs
<SpamapS> broder: plymouth is  start on stopped gdm
<broder> yeah, and gdm is stop on runlevel [016]
<SpamapS> broder: if you need to make sure you run before plymouth 'start on starting plymouth' works
<dholbach> good morning
<diwic> steveire, and from debian/source/format we can see that this is a quilt patch system
<steveire> Ok
<broder> SpamapS: plymouth looks at the $RUNLEVEL variable it inherits from the runlevel event. will my job get that variable as well?
<steveire> So do I need to set up pbuilder?
<diwic> steveire, that is helpful for checking that your package does not need more dependencies than you actually state in the control file
<diwic> steveire, or for compiling for another version than you're currently running
<SpamapS> broder: only if plymouth exports it
<diwic> steveire, I'm realizing I'm not very helpful to you because I'm not sure what the easiest way of updating a 3.0 quilt package is, sorry
<SpamapS> broder: so, in short, no. You could fake it tho..   start on runlevel [016] and stopped gdm
<broder> well, if i wanted it to be strictly after plymouth, i'd do runlevel [016] and started plymouth, right?
<broder> or is that going to get in the way of plymouth starting at boot? start on clauses with "and" still trip me up...
<steveire> diwic: Ok, I'll scan through some docs
<doko> which package should be used to file issues about the new scrollbar?
<pitti> doko: overlay-scrollbar
<doko> thanks
<abhinav-> pitti: hi, I noticed that the man pages of apport haven't been updated for the -w/--window option ?  http://manpages.ubuntu.com/manpages/natty/man1/apport-cli.1.html
<pitti> abhinav-: ah, good catch
<abhinav-> pitti: thanks :) . should I file a bug ?
<pitti> abhinav-: sure, can't hurt
<smb> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: smb
<pitti> you don't happen to want to add it yourself? :-)
<abhinav-> pitti: I can do that, provided I will have to look at the man page syntax :D
<akheron> it's not hard
<pitti> abhinav-: syntax-wise you can just copy&paste
<pitti> abhinav-: anyway, it's quick, I can also do it myself, I just wanted to know whether you'd like to try
<abhinav-> pitti: yes , alright I will do it :)
<pitti> great, thanks!
<steveire> "If a package for the application does not exist in Debian, then the Debian revision is 0 (e.g., 2.4-0ubuntu1). " https://wiki.ubuntu.com/PackagingGuide/Complete
<steveire> The grantlee package has 0.1.7-0ubuntu3
<steveire> Even though there is an upsteam debian version
<pitti> dpm: so, Thursday is the final langpack translation deadline
<pitti> dpm: so I think if we get a full export on the weekend, I'll be able to kick off a build on Monday, in time for the final release
<dpm> pitti, that sounds good. Let me re-check the schedule for when we get the export.
<pitti> dpm: I think we usually get one Friday, don't we?
<pitti> I'll try to kick it off earlier than Monday, but no promises due to holidays
<dpm> pitti, we get an export on Thursday 14:00 UTC, which we could use -> https://dev.launchpad.net/Translations/LanguagePackSchedule. I remember we changed it so it aligned better to the deadline. If that works for you, we could use that. If not, we can just ask the LP guys to set up a one-off export on Friday.
<pitti> dpm: sounds fine
<pitti> dpm: so yesterday's is already done, and I could request a full export now?
<pitti> hm, I don't see one for Apr 19, though
<dpm> pitti, it might take longer to be generated. But yeah, that's strange, especially because delta exports appear earlier in the day than full ones. But I think if you request it now it should be fine. AFAIK, the exports are simply on a cron job, and requesting the full export now would not interfere with the previous delta one, which was already triggered yesterday
<pitti> dpm: right, as long as it's already runnning it should be okay
<pitti> dpm: but I guess I'll just keep the tab open and request it tomorrow then
<dpm> pitti, sure, sounds good
<geser> steveire: Debian has only 0.1.4 while Ubuntu has 0.1.7 (there is no 0.1.7 in Debian on which to base the Ubuntu delta -> revision 0)
<steveire> geser: Ah, right
<steveire> http://dpaste.com/533477/ How do I remove that patch from the package?
<abhinav-> pitti: I have added this content in apport-cli.1 http://paste.ubuntu.com/595871/
<abhinav-> is it ok ?
<pitti> abhinav-: looks fine
<abhinav-> pitti: alright. thanks. pushing the branch
<pitti> $ change-override.py -S -c universe xulrunner-2.0
<pitti> chrisccoulson: ^ MUHAHA!
 * pitti ^5s chrisccoulson
<chrisccoulson> pitti, excellent, thanks :)
 * chrisccoulson ^5s pitti
<chrisccoulson> pitti - we'll probably kill it entirely next cycle ;)
<abhinav-> pitti: https://code.launchpad.net/~er-abhinav-upadhyay/apport/bugfix-765600/+merge/58241  ,thanks for letting me do this :)
<ubottu> Ubuntu bug 58241 in emacs-goodies-el (Ubuntu) "m-x debian-bug doesn't point to ubuntu instead" [Undecided,Confirmed]
<pitti> abhinav-: cool, thanks! will merge in a sec
<abhinav-> smb: Hi, can you review this ? (https://code.launchpad.net/~er-abhinav-upadhyay/ubuntu/natty/tomboy/bugfix-757635/+merge/57282) or it has to come from upstream ?
<ubottu> Ubuntu bug 57282 in xorg-server (Ubuntu) "After upgrading dapper 22:nd of august, X doesn't start (dup-of: 57153)" [Undecided,New]
<ubottu> Ubuntu bug 57153 in xorg-server (Ubuntu Dapper) "xorg-server 1:1.0.2-0ubuntu10.3 breaks X: "no screens found"" [Critical,Fix released]
<smb> abhinav-, I am not sure but I have a look. hm, ubotu seems slightly confused...
<pitti> ubottu tries to interpret merge request IDs as bug numbers
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<abhinav-> smb: thanks, :)
<abhinav-> lo
<abhinav-> lol
<c2tarun> can anyone help me with Xauthority authentication failed error in ubuntu?
<speakman> A few days ago I asked how to maintain the debian/ dir in my own source, and then I was suggested to keep it in a separate branch. But in the mean time, why can't the debian dir be part of the project? The one could use debian/changelog for the projects own changelog? Ideas?
<pitti> speakman: some projects do, but at least I find it highly inconvenient
<pitti> and apparently others as well, the current dpkg source format even allows stripping the upstream debian/ dir
<pitti> so that it doesn't get in the way of the real debian/ dir from the distro
<pitti> it's also inconvenient for upstream, as it will constantly be out of date, not match anythign real in debian/ubuntu, and over time you'll accumulate spec files, debian/ dirs, ebuild recipes, and what not
<smb> abhinav-, The change itself look reasonable. though for ubuntu merge the code change should be done by a patch in debian/patches, not directly
<speakman> pitti: thanks alot for your comments! But what if I _am_ upstream and the deb maintainer as well?
<pitti> speakman: as I said, some projects do that, so if you find it more convenient, there's nobody stopping you :)
<pitti> IMHO packaging stuff doesn't belong into upstream tarballs/VCSes, but that might just be me
<pitti> (main reason: it's the wrong level to have it, as upstream releases are not tied to a particular distro and release)
<speakman> pitti: Fair enough! But since this will be just my own private project shared with only a few mates, I think I make the exception and manage the debian/ dir within it's source tree :)
<pitti> speakman: sure :) you can always drop it again if the project becomes more popular and it gets in the way
<abhinav-> smb: alright thanks for the review :) . But I think the bug is not Ubuntu specific, so it should be merged directly. perhaps we should wait for it to come from upstream ?
<speakman> pitti: you're absolutely right :) thanks alot!
<pitti> abhinav-: it should still be a separate patch; directly modifying the upstream source is both hard to maintain and also hard to see what actually changed
<speakman> By the way - is there some good documentation about managing a patchset within the debian/ dir? If I'm not the upstream owner, that is. :)
<pitti> speakman: https://wiki.ubuntu.com/PackagingGuide/PatchSystems might be of some help
<speakman> pitti: thanks! again! :D
<abhinav-> pitti: that link explains it :) . so until the upstream developers don't review and merge the patch in their repo , the patch can be included in Ubuntu through debina/patches ?
<pitti> abhinav-: rightg
<abhinav-> alright, thanks. then I will do that :)
<steveire> Why is this telling me there's no orig.tar when there is a orig.tar.gz? Shouldn't it find that?
<steveire> http://dpaste.com/533496/
<steveire> Discovered I need to add a '.1' to the tarball file name kdepim_4.5.95.1.orig.tar.gz
<steveire> But why?
<directhex> steveire, what's the version number in debian/changelog?
<steveire> Ah, 4:4.5.95.1-0ubuntu2 indeed
<steveire> But what is the '4:' about?
<mdz> anyone else seeing syndaemon spin on the CPU?
<directhex> steveire, it's called an epoch. it bumps the version number up ahead of 3: and 2: and 1: and 0:
<directhex> where no epoch at all is the same as 0:
<directhex> usually you use an epoch when you mess up & want to go down a version number, permanently
<directhex> e.g. you had a metapackage with version numbers like "100", and suddenly you want a real version of "4.4"#
<Kurisutian> cjwatson: I checked again with the beta 2 of the server install with a btrfs rootfs but I get the same error like I had with beta 1
<steveire> directhex: Ah, so probably related to the kdelibs5 stuff
<directhex> steveire, i'm afraid i don't know the specific history, but yeah, moving from one package to another might be related
<Kurisutian> is anyone here that knows how to install ubuntu server beta2 on a rootfs.... I get some weird behaviour when using the installer..... or is it possible to bootstrap from an existing live cd. I need to put it on btrfs because of the snapshot capability it has....
<Riddell> debfx: what are the relative merits of your patch compared to Sarvatt's in bug 753370 ?
<ubottu> Launchpad bug 753370 in mesa (Ubuntu) "No Desktop Effects in Kubuntu 11.04 Beta1" [Medium,Confirmed] https://launchpad.net/bugs/753370
<debfx> Riddell: he discovered a case where his patch doesn't work
<Riddell> debfx: groovy, uploading
<debfx> Riddell: oh, tjaalton already uploaded it
<Riddell> oh but it's in the queue?
<tjaalton> yes
<Riddell> in that case, accepting
<speakman> hm... is it hard to setup my own apt repo? Like a local ppa with just a few packages?
<pitti> speakman: no, not at all; you can just run apt-ftparchive and then add "deb file://... /" URL
<pitti> see example section in the manpage
<speakman> oh, cool! :)
<speakman> just fired up man apt-ftparchive :)
<TeTeT> speakman: I find reprepro to be a good fit for maintaining a custom repo. It had some issues with parallel writes in the past though, so you want to make sure only one reprepro is running at any given time. Think that was fixed upstream though
<abhinav-> dholbach: how should I generate a patch for debian/patch of Tomboy ? I have patch both in debdiff and git format ? or should I start from scratch using quilt ?
<dholbach> abhinav-, best use   edit-patch <some-name-for-the-patch>
<dholbach> then apply the patch from git, then hit Ctrl-D
<abhinav-> dholbach: ah great :)
<abhinav-> dholbach: and how to submit the patch ? normal merge proposal ?
<dholbach> yep
<abhinav-> dholbach: great. thanks :)
<speakman> TeTeT: great thanks!
<abhinav-> dholbach: I did the steps as described in the packaging guide but something seems to be going wrong. After editing the dch , it asked to commit the changes, I said 'yes', but the new patch created in the debian/patches directory contains code from all the  patches :-/
<dholbach> abhinav-, I'm just about to get lunch - can you just ask in the channel and see if somebody else can help?
<dholbach> see you later
<abhinav-> dholbach: alright. no problem
<abhinav-> I will try again
<m4n1sh> abhinav-, #ubuntu-motu whenever you are stuck up in packaging issue
<abhinav-> m4n1sh: oh thanks :)
<ogra_> ogra@panda:~$ ls /var/log/messages
<ogra_> ls: cannot access /var/log/messages: No such file or directory
<ogra_> hmm, is that normal ?
<ogra_> did we drop messages from rsyslog ?
<seb128> ogra_, see the changelog
<ogra_> ah, pitti's fault !
<ogra_> :)
<diwic> ogra, actually it's my fault, I thought people running ARM *hint hint* would be happy for the extra disk space ;-)
<ogra_> haha
<diwic> ogra_, everything is in syslog anyway, so...
<ogra_> its a great move, just need to get used to it
<ogra_> yeah
<ogra_> diwic, btw, i dont seem to get forward in any way with the panda sound stuff
<diwic> ogra_, oh is it still bad?
<ogra_> diwic, yes, i tried TheMuso's test packages, added and removed patches but no go ...
<ogra_> in dmesg i end up with "asoc: no valid backend routes for PCM: SDP4430 Media"
<ogra_> in the UI i managed to see the pulse profiles once but thats gone again with the last test build, i'm not sure how i made it work actually
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: smb, jdstrand
<ogra_> i kept the packages that showed this around ... but reinstalling them doesnt get me back the items in the UI
<diwic> ogra_, hmm, are you sure that's from dmesg? I'm trying to grep for that message in a kernel tree but find nothing
<ogra_> ogra@panda:~$ dmesg|grep -c "asoc: no valid backend routes for PCM: SDP4430 Media"
<ogra_> 96
<ogra_> i get it every time i restart pulse manually or re-login
<ogra_> funnily it initializes the HDMI interface just fine
<ogra_> (though that was there even before UCM was added to alsa)
<diwic> ogra_, is that a standard natty kernel?
<ogra_> yes, its a beta2 image i'm running
<ogra_> (with recent updates)
<ogra_> though there was a new upload that should have built now, i can upgrade to it ... but i dont think there were any asoc related changes in that revision
<diwic> naah, just thought if there was some patchset that might have added the message
<ogra_> well, omap4 uses its own kernel tree
<ogra_> you are grepping in that one, right ?
<diwic> ogra_, where's that tree?
 * ogra_ looks on the kernel git server
<ogra_> i never use it, so i have to dig
 * ogra_ wonders if http://kernel.ubuntu.com/git will ever load
<diwic> ogra_, it does, be patient
<ogra_> heh
<ogra_> *twiddle*
<ogra_> desnt load but doesnt time out either
<jdstrand> smb: fyi, I'm looking at bug #644632
<ogra_> i see the gitweb header though
<ubottu> Launchpad bug 644632 in libnss-ldap (Ubuntu) "nssldap-update-ignoreusers needs to be configurable to ignore users" [Low,New] https://launchpad.net/bugs/644632
<jdstrand> smoser: I think you pinged me about that ^
<diwic> ogra_, so how well are things functioning at the alsaucm layer?
<ogra_> diwic, not at all ?
<smb> jdstrand, ookaaayy (not exactly sure what to do with that information) I suppose it is somewhere on the pilot list
<jdstrand> smb: it is in the pilot list. fyi only so we don't both jump on it :)
<ogra_> diwic, i honestly have no clue how to check it, apart from running alsaucm (which tells me its setting defaults) and seeing the pulse profiles in the UI i dont know where else to look
<ogra_> oh, it loaded !
<ogra_> 7me hugs his browser "... and i thought you were dead !"
<smb> jdstrand, Ok. :) Well as I am mostly useless outside the kernel area (missing rights and such) I would be concentrating on kernel bugs with patches anyway, ;) Though I should also do a bit more in the other direction
<ogra_> diwic, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=tree;h=refs/heads/ti-omap4;hb=ti-omap4
<diwic> ogra_, thanks
<ogra_> or better http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4
<pitti> ogra_: "messages is not the file you are looking for" </jedi wave>
<ogra_> lol
<mterry> james_w, ~ubuntu-branches/ubuntu/natty/libgnome-keyring/natty seems stalled -- can it be poked?
<james_w> mtaylor, poked
<james_w> mterry I mean
<mterry> james_w, thanks
<tjaalton> i've uploaded xorg-server 1.10.1, which has one single upstream commit since 1.10.1rc2, which reverts a patch that caused bug 757972
<ubottu> Launchpad bug 757972 in xorg-server (Ubuntu) "Easystroke doesn't recognize button release" [Medium,In progress] https://launchpad.net/bugs/757972
<abhinav-> smb: if you are still reviewing proposals, please look at my new proposal, I have now moved the changes to be included in debian/patches (https://code.launchpad.net/~er-abhinav-upadhyay/ubuntu/natty/tomboy/patch-757635/+merge/58303)
<smb> abhinav-, yup will check
<abhinav-> smb: thanks :)
<smoser> smb, just to be clear, above, jdstrand had tab-complete failure.
<smoser> his comments were intended to be to me
<jdstrand> smoser: actually, no. he is a patch pilot and I didn't want to step on his toes, but I also wanted you to know I was looking at it :)
<smb> smoser, Ah ok. Well it actually could have been for me as well as we both doing piloting today
<smoser> oh... i see.
<smoser> funny
<smoser> sorry
<smoser> jdstrand, yes, i did ping you on that. only because you had worked the other bug in that area.
<jdstrand> interestingly, I did tab complete looking for smb, but got smoser, which reminded me that I needed to point this out to smoser too :)
<smoser> jdstrand, how is my suggestion incomplete?
<smb> abhinav-, I know I may get the pedantic award... but why is the patch numbered 21_... and then sorted after 30_.. in the series file? Sure it does not matter... it just looks a bit odd
<abhinav-> smb: I had no idea what number to give, 21 seemed good :D
<jdstrand> smoser: OKUSERS=`awk -v vname=nss_initgroups_okusers '$1 == vname { v=$2 }; END { print v }'` doesn't work on its own (now filename or cat)
<jdstrand> s/now/no/
<smoser> ah. ok. i'll suggest adding '$CONF'. you're correct.
<smoser> jdstrand, i was more interested in your feelings on whether or not it would be wise to carry this patch.
<smoser> if upstream implements the feature, then we'll have a much more difficult time implementing the 'okusers' functionality on top of that.
<dschulz> hi all
<jdstrand> smoser: well, we've been carrying this patch for ages
<smoser> yes. and upstream is considering adding that function.
<smoser> (for ages)
<smoser> but if they *did*, then it would be difficult to implement the "okusers"
<smoser> possibly impossible to do so and retain backwards compatibility
<smoser> unless we patched out the upstream function and relied on our own.
 * jdstrand fingertaps waiting on upstream bug
<dschulz> does anyone knows if theres a chance to get python-django 1.3 package before natty release? It's currently at 1.2.5
<smoser> jdstrand, if you dont think its a concern, then thats fine.
<smoser> but i didn't want to provide function in ubuntu that people would use, then be unable to retain backwards compatibility withthat function.
<jdstrand> smoser: I think that is a valid concern. it looks like it was revisted as late as 8 months ago
<smoser> right.
<jdstrand> smoser: I'll comment in the bug
<jdstrand> (our bug)
<dschulz> pitti: Hi. Do you have a plan to build postgresql 9.x packages for natty soon? And more important, do you have an Amazon wishlist?
<pitti> dschulz: 9.x natty> yes, there's a new microrelease from today which I'll package also for natty in my PPA
<pitti> amazon wishlist> no, I don't
<pitti> (how's that psql related? :-) )
<dschulz> Thanks pitti :-)
<smb> abhinav-, So basically I think the numbering thing is a bit odd, the description line may need a space at the beginning of the second line and Origin/Author could be Author alone. But I heard that a sponsor may fix this while doing the bits. Unfortunately I lack the rights for real sponsor things and can only complain err suggest.
<smb> jdstrand, do you have the rights to do so?
<jdstrand> smb: I have upload rights, yes, but all that really needs be done here is either an ACK with your changes, or you can hand me a corrected debdiff
<abhinav-> smb: alright thanks. I can fix these and request another review ?
<jdstrand> s/ACK with your/ACK conditional upon your/
<smb> jdstrand, I think I would have to do the latter as I think lp does not offer me any action
<jdstrand> smb: it isn't an lp action afaik anyway. it would just be me fixing the debdiff myself and uploading
 * smb` thinks there has been a disruption in his force (irc timeout). I might have missed things
<bjf> ##
<bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
<bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
<bjf> ##
<smb`> bjf, #ubuntu-kernel?
<bjf> smb`, ack
<abhinav-> smb`: I have made the changes, pushing them to launchpad
<bjf> smb`, being friendly, inviting everyone :-)
<smb`> bjf, We'd need to add "be on time or you miss it here". :)
<smb`> abhinav-, thanks
<abhinav-> smb: updated (https://code.launchpad.net/~er-abhinav-upadhyay/ubuntu/natty/tomboy/patch-757635/+merge/58303)
<stgraber> tkamppeter: ping
<smb> abhinav-, Ok, I approved (for what that is worth)
<abhinav-> smb: thanks :)
<mvo> dpm: is there a way to exclude certain translations for a given package from the langpacks? friendly-recovery is having trouble with the CJK fonts on the console and I'm looking into how to blacklist that currently
<stgraber> tkamppeter: I'm trying to debug bug 742935 and one of the things that seem weird on the report's system is "cnijfilter-common:i386" being in state "iU" which might explain why aptdaemon doesn't work so well on that system. I was just wondering what's installing that package and how I can try to install it in my VM
<ubottu> Launchpad bug 742935 in aptdaemon (Ubuntu) "aptd crashed with OSError in release(): [Errno 9] Bad file descriptor" [High,New] https://launchpad.net/bugs/742935
<dpm> pitti, how is the langpack-locales package used? I'm just trying to find out the supported locales in Natty, and I was looking at http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/langpack-locales/natty/view/head:/SUPPORTED - however, I've noticed that langpack-locales is not installed on my system
<SpamapS> jhunt: will you be around in about 1 hour?
<jhunt> SpamapS: sure will!
<pitti> dpm: that's the source package name; the binary is "locales"
<dpm> pitti, ah, thanks
<stgraber> mvo: yep, there's a way to do it in pkgbinarymangler IIRC. There's a blacklist in there (skipranslations.blacklist) which might be what you're looking for. Though my understanding is that it'd simply block all .pot for that package from being imported in LP
<stgraber> (I use it for ldm as it ships its own translations and it's installed in an environment where we don't have langpacks installed)
<stgraber> though maybe there's a LP way of doing it (as in, filter what gets in the langpacks) that could be slightly cleaner :)
<mvo> thanks stgraber not sure this is what I need as I want some languages, but not all (only the ones where we have good console fonts)
<OdyX> Hi. Is it possible to have new packages in natty ? (my case is "pyside-tools", a much needed companion for PySide. It has no issues in Debian, for two weeks now.
<stgraber> mvo: hmm, yeah, pkgbinarymangler probably isn't what you're looking for then as you'd need to manually import the translations in the source package and ship them yourself. Probably would be a lot better to patch whatever builds the langpacks then.
<OdyX> Lemme rephrase. What more can I do to get https://bugs.launchpad.net/ubuntu/+bug/750295 solved ?
<ubottu> Ubuntu bug 750295 in Ubuntu "FFe: Sync pyside-tools 0.2.8-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
<tumbleweed> OdyX: looks like ScottK didn't subscribe ubuntu-archive to do the sync
<ScottK> Sure I did.
<ScottK> Just not until now.
<ScottK> ;-)
<tumbleweed> :)
<ScottK> tumbleweed: Thanks for pointing it out.
<OdyX> thanks to you both.
<OdyX> (I had a user request, which reminded meâ¦ Otherwise I wouldn't have noticed)
<smoser> pitti, i've a lang related quesiton, and unfortunately for you, i think you're knowledgable.
<pitti> jdstrand, kees, sconklin: linux-ti-omap4/maverick copied to -updates and -security
<praveen_> can i ask a question about qt here???
<pitti> smoser: just shoot :) (busy with two other things, so might lag a bit)
<smoser> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html gives says that accept-language might be 'en' or 'en-gb'. if it is just 'en', is there something i can correlate that to in an LC_ALL or LANG setting ? is there a  way to chose default _XX value?
<praveen_> please have a look here--http://ubuntuforums.org/showthread.php?t=1733402
<pitti> smoser: this is mixing two concepts; "en" is a language, LANG/LC_ALL set locales (which are always country specific0
<pitti> smoser: so you cannot translate a language name like English or Spanish to a "default country" easily, unless you make some hardcoded assumptions
<pitti> smoser: like default to US for English (and screw the Brits), to Spain for Spanish (and screw south America), etc.
<smoser> pitti, right... so the goal is to take what is in accept-language and give the desktop user an appropriate language
<pitti> smoser: so in this case this is a language and nto country specific
<ScottK> praveen_: There are more Qt knowledgeable people in #kubuntu-devel.  I'd try there.
<pitti> smoser: what you can do is to map this to $LANGUAGE
<smoser> would you hvae a suggestion on how to hack without hard coding (i dont want to come up with hard codes for all languages)
<pitti> smoser: without setting a different locale
<pitti> smoser: LANGUAGE is a list of languages and can e. g. be "de_DE:de:en_GB:en"
<pitti> smoser: this would mean "if German (Germany) is available, use that, otherwise fall back to any German dialect, if that's not available, use British English, and as a last resort any English
<smoser> pitti, thats good. i'm just exposing vast ignorance here :)
<smoser> i can potentially get country code also.
<pitti> smoser: we set $LANGUAGE by default now in language-selector, so chances are that your /etc/default/locale already has it even
<smoser> thanks pitti.
<AlanBell> kirkland: got a few minutes to chat about an etherpad server for UDS?
<mvo> could someone eyeball the shell code in  https://bugs.edge.launchpad.net/ubuntu-jp-improvement/+bug/573502/comments/15
<ubottu> Ubuntu bug 573502 in Ubuntu Japanese Kaizen Project "unreadable characters in recovery mode" [High,Triaged]
<jcastro> pitti: I think my mail to the techboard might have gotten stuck in moderation - I need someone from the TB to add the linaro track leads to the ~uds-organizers lp group.
<pitti> jcastro: moderated
<mvo> jhunt: bug #575469 sounds like something for mountall/upstart? being able to tell it to boot in ro mode ?
<ubottu> Launchpad bug 575469 in friendly-recovery (Ubuntu) "recovery mode mounts filesystems read-write rather than read-only" [Undecided,New] https://launchpad.net/bugs/575469
<ev> bum, apt-clone doesn't like being disconnected from the internets.
<mvo> ev: ohh, what is it doing? exploding then :/ ?
<ev> no, it thankfully doesn't error out
<ev> but it equally doesn't preserve the packages
<ev> because it can't fetch them, but doesn't add them to the list to repack
<mvo> hrm, hrm, bad
<ev> digging into it now
<mvo> thanks!
<ev> sure thing
<psurbhi> mvo, bug 575469 needs a grub cmd line change
<ubottu> Launchpad bug 575469 in friendly-recovery (Ubuntu) "recovery mode mounts filesystems read-write rather than read-only" [Undecided,New] https://launchpad.net/bugs/575469
<psurbhi> on which mountall can take better action
<mvo> aha, nice - what needs to be added?
<psurbhi> i am not sure, but say we add some option like "--recovery"
<psurbhi> then mountall can have a look at that and then mount "ro" instead of whats in fstab
<psurbhi> i will like to work on that bug :)
<mvo> nice, thans!
<psurbhi> mvo, np! :)
<ev> mvo: I've filed bug 766171 for the apt-clone issue and will track my progress there.
<ubottu> Launchpad bug 766171 in apt-clone (Ubuntu Natty) "apt-clone does not repack debs that it will not be able to download when there isn't an Internet connection" [High,Confirmed] https://launchpad.net/bugs/766171
<bdmurray> cjwatson: you worked on bug 746758 with ev? it seems that it isn't fixed as there are still some of these coming in with the new version of ia32-libs.
<ubottu> Launchpad bug 746758 in ia32-libs (Ubuntu Natty) "11.04 64bit Beta1 CD Installer crashed [no appropriate viewer found for /usr/lib/flashplugin-installer/libflashplayer.so on amd64]" [Undecided,Fix released] https://launchpad.net/bugs/746758
<ev> bdmurray: cjwatson is on vacation, but interesting...
<bdmurray> ev: I've consolidated the new reports into bug 762968
<ubottu> Launchpad bug 762968 in flashplugin-nonfree (Ubuntu Natty) "package flashplugin-installer 10.2.159.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Triaged] https://launchpad.net/bugs/762968
<ev> I'll try to find time to look at that, but I'm knee deep in apt-clone at the moment
<bdmurray> ev: okay, thanks!
<doko> pitti: what package would you suggest for bug #760544?
<ubottu> Launchpad bug 760544 in Ubuntu "trying to scroll a maximized window moves a window on the adjacent virtual screen instead" [Undecided,New] https://launchpad.net/bugs/760544
<mdz> apw, bryceh, I haven't been able to do much with bug 747205 today unfortunately. silbs has been in meetings and I need her to grant me access
<ubottu> Launchpad bug 747205 in xserver-xorg-video-intel (Ubuntu) "[arrandale] Black screen on all outputs when external VGA is connected" [High,Triaged] https://launchpad.net/bugs/747205
<pitti> doko: my initial guess is compiz, I assigned it there
<doko> ok, thanks
<SpamapS> jamespage: ping re your conditional patch question
<jamespage> SpamapS: hey
<SpamapS> jamespage: what about #ifdef ?
<jamespage> SpamapS: within the patch itself? that was my thinking on option #3 - rework the patch using #ifdef
<SpamapS> jamespage: I haven't looked at the patch. Would that be super difficult?
<apw> mdz no worries
<jamespage> SpamapS: do-able if a little fiddly
<jamespage> some of the patch is already written this way - it might not take to long to sort out the rest of it.
<mdz> apw, ok, I'm on it now
<mdz> apw, GL_MAX_TEXTURE_SIZE = 4096
<apw> mdz, i assume the width of her display, plus the monitor is less than that in pixels
<mdz> apw, her displays are 1440x900 and 1920x1200
<dholbach> seb128, 'harvest' is now in natty
<seb128> dholbach, great ;-)
<mdz> apw, can you think of anything I might try to get the display to switch back on?
<mdz> xrandr --auto gets me a black screen with a mouse cursor
<mdz> suspending and resuming gets me a text console with a mouse cursor over it :-)
<mdz> tjaalton, around?
<roadmr> hey! I notice the ubuntu-netbook package is no longer installed on our netbooks, and the package description now says it will be used only for armel systems
<roadmr> so will the ubuntu-netbook not be used in intel netbooks going forward?
<apw> mdz hmmm, well i feel we don't even know if the GPU is hung
<apw> when it gets into this state, knowing that would be helpful as well i think
<apw> mdz i believe the contents of /sys/kernel/debug/dri/0/i915_gem_seqno will tell us
<kirkland> AlanBell: sorry, i'm pretty tied up today
<kirkland> AlanBell: what's up, though?
<kirkland> AlanBell: there's a few people willing/interested to work on this
<AlanBell> np, just wanted to know who is planned to provide the server for test/deployment?
<AlanBell> I have proposed some summit changes to integrate summit and etherpad nicely
<hallyn> Daviey: all right, so again - for packages in universe (vmbuilder), I can just dput now?  Either release team will have to look at it and approve (or deny - I can take rejection), or it'll go through with no problems, but no reason for me not to dput?
<mdz> apw, how can I check?
<mdz> sysfs?
<mdz> apw, /sys/kernel/debug/dri/0/i915_error_state shows "no error state collected"
<mdz> so does .../64/i915_no_error_state (is it normal to have two?)
<apw> what does /sys/kernel/debug/dri/0/i915_gem_seqno say
<mdz> apw, in both i915_gem_seqnos, "current sequence (render ring)" and "IRQ sequence (render ring)" are incrementing, and everything else is zero
<apw> ok so that says to me that things are continuing normally, that things are being displayed
<apw> bryceh, ^^ would that make sense to you as well
<doko> bdmurray: is this your bot? bug #766129 ?
<ubottu> Launchpad bug 766129 in openjdk-6 (Ubuntu) "package openjdk-6-jdk 6b20-1.9.7-0ubuntu1~10.04.1 failed to install/upgrade: failed in buffer_write(fd) (10, ret=-1): backend dpkg-deb during `./usr/lib/jvm/java-6-openjdk/lib/tools.jar'" [Undecided,New] https://launchpad.net/bugs/766129
<bdmurray> doko: looking
<bdmurray> doko: yes
<doko> bdmurray: please could you avoid filing these reports? doesn't add any value, it's a corrupt .deb
<Daviey> hallyn, yes!
<doko> or a damamged file system
<mdz> tseliot, around?
<tseliot> mdz: what's up?
<hallyn> Daviey: one :)
<bdmurray> doko: to be clear my bot is ubuntu qa's bug bot which moved it to the openjdk-6 package and didn't file the bug.  additionally it makes some checks regarding the number of comments etc.  I'm pretty sure these types of bugs re corrupted debs aren't reported in newer releases.
<doko> hmm, ...
<mdz> tseliot, I'm trying to get to the bottom of bug 747205. any chance you could have a look?
<ubottu> Launchpad bug 747205 in xserver-xorg-video-intel (Ubuntu) "[arrandale] Black screen on all outputs when external VGA is connected" [High,Triaged] https://launchpad.net/bugs/747205
<mdz> I'm in front of the machine now and will only have access to it for another 35m or so
 * tseliot has a look
<bdmurray> doko: I'm double checking the code that stops the reporting of these now
<doko> pitti: would it be possible to update apport for older releases for issues like these? ^^^
<bdmurray> doko: the check is actually in apt
<tseliot> mdz: can you reproduce the problem if you start the Classic desktop without 3D effects?
<rickspencer3> tseliot, before ou go down that route, bryceh did a ton of investigation on this
<rickspencer3> tseliot, https://bugs.freedesktop.org/show_bug.cgi?id=35870
<ubottu> Freedesktop bug 35870 in Driver/intel "[arrandale] GPU lockup (ESR: 0x00000001 IPEHR: 0x7a005502)" [Normal,Reopened]
<mdz> tseliot, if she logs in with classic, it shows the same problem
<pitti> doko: sure, if we have a fix, it's easy to backport, and justifies an SRU as well IMHO
<tseliot> mdz: ok
<tseliot> rickspencer3: thanks for the link
<doko> pitti: well, looks as it would be on mvo's plate :-/
<tkamppeter> stgraber, hi
<bdmurray> there is an ENOSPC check in lucid
<mdz> tseliot, very interesting discovery: https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/747205/comments/57
<ubottu> Ubuntu bug 747205 in xserver-xorg-video-intel (Ubuntu) "[arrandale] Black screen on all outputs when external VGA is connected" [High,Triaged]
<tseliot> mdz: ok, maybe I know what's going on
<tkamppeter> stgraber, cnijfilter-common is a package from Canon, not a Ubuntu package. It is a closed-source printer driver which exists only for i386 arch not for x86_64, probably therefore the ":i386".
<AlanBell> kirkland: reading back through the mails, is the plan that James Troup will provide a server if it is packaged to a satisfactory standard?
<tseliot> mdz: log in with the user which can reproduce the problem and type the following command: rm ~/.config/monitors.*
<mdz> tseliot, maybe something in the compiz settings?
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: smb
<bryceh> mdz, tseliot, heya
<tseliot> mdz: either that or the gnome-display settings (I suggested to clear the latter)
<tseliot> bryceh: hi
<bryceh> to save you guys a little work...  I investigated a lot of the (apparent) dupes of this issue yesterday.  I've had other folks test some various theories, but I *think* the issue is just lack of kernel support for Ironlake/Arrandale
<tseliot> bryceh: https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/747205/comments/57
<ubottu> Ubuntu bug 747205 in xserver-xorg-video-intel (Ubuntu) "[arrandale] Black screen on all outputs when external VGA is connected" [High,Triaged]
<mdz> tseliot, bingo
<tseliot> mdz: :)
<mdz> tseliot, I've attached the monitors.xml to the bug
 * tseliot has a look
<tseliot> mdz: maybe one of the resolutions listed there caused the problem (probably 1920x1200 for VGA1)
<tseliot> mdz: it's still weird though
<mdz> tseliot, I think it has to do with having the laptop display switched off
<mdz> she says that she does that normally
<tseliot> mdz: the display app remembers the last settings and loads them when the session starts. So yes, it can be that
<bryceh> mdz, tseliot, right, from what I've seen in other bug reports, it happens on modesetting changes, but it varies from person to person
<bryceh> there are a variety of ironlake/arrandale patches proposed at http://lists.freedesktop.org/archives/intel-gfx/2011-April/thread.html#10071 but not yet upstream, including several changes to ironlake's modesetting functionality
<bryceh> so I think the next step for this bug is to test that kernel
<bryceh> I asked apw and tgardner if we could get a build of that kernel for folks to test
<mdz> bryceh, it's starting to look like maybe it's related to the external monitor being primary
<mdz> testing that on its own now
<bryceh> mdz, tseliot, one other step you could take if you want to make good use of this testing time:
<mdz> switching it to be primary didn't break it (and also didn't get saved across sessions)
<bryceh> install xdiagnose and tick on the 'Kernel Debug" flag, which will enable the modesetting debugging messages in dmesg, and collect a dmesg when reproducing the problem
<tseliot> mdz: because you didn't do it from the gnome app. That's the only way it can remember its settings
<tseliot> mdz: the gnome app has no way to set the primary output
<tseliot> you should edit the xml file manually
<mdz> bryceh, we have "extra graphics debug messages", "display boot messages", "disable VESA framebuffer driver" and "disable PAT memory"
<mdz> I assume it's the first one we want?
<mdz> tseliot, oh
<mdz> and the gnome app has no way of setting which one is primary afaik
<tseliot> yes, it's what I said ;)
<bryceh> mdz, yes the first one
<tseliot> bryceh: BTW I didn't know about xdiagnose, thanks for the tip
<bryceh> tseliot, yep
<kirkland> AlanBell: that was my impression from elmo's email, which required a) to be packaged, and b) to have been tested at scale
<elmo> the testing isn't a requirement
<bryceh> mdz, tseliot, ok looking at apw's review of the patches I mentioned, he's doubtful they'll help but will be spinning up that kernel for testing
<kirkland> AlanBell: I think we have put a significant dent in (a), if not solved entirely to satisfaction
<elmo> we'll be running gobby anyway/additionally, so if you want to make UDS the 'at scale load' you can
<apw> bryceh, yep, that is in the queue to build sometime to day
<kirkland> AlanBell: I think jcastro and statik were going to try and organize an Ubuntu community-wide scale test of Etherpad
<kirkland> AlanBell: okay, so see elmo's comment; we'll offer both gobby and etherpad at UDS-O and let the two offerings duke it out;  if etherpad fails miserably, we'll have gobby too
<smb> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<mdz> bryceh, ok, did that, but I don't see anything extra in dmesg
<bryceh> apw, excellent; I think even if it doesn't provide a fix in this particular case that'll help as we go forward, since ickle appears to be slotting his patches in there for people to test
<apw> bryceh, yeah seems appropriate, and indeed what we planned those builds for
<kirkland> elmo: are you willing to run an etherpad.ubuntu.com on your hardware, or should we plan on running our own in ec2, or some such?
<mdz> I do see this though: [343681.753493] compiz[24098]: segfault at 2e38f80 ip 0000000002e38f80 sp 00007fff71356758 error 15
<elmo> kirkland: that depends on the state of the packaging
<elmo> kirkland: but we're not pointing u.c at ec2 :-P
<mdz> bryceh, tseliot, copying in the old monitors.xml reliably reproduces the problem
<kirkland> elmo: understood, of course
<bryceh> mdz, ok thanks, well it's a long shot
<stgraber> tkamppeter: ok, thanks. is that something that jockey (or similar stuff) might pull directly from Canon or is that manually installed by the user for sure ?
<stgraber> tkamppeter: (just trying to understand if that's something that Ubuntu might have installed somehow and that we should fix or if that's just a case where the user did something unsupported and the bug should therefore be closed)
<bryceh> mdz, tseliot, there's a number of sections in that monitors.xml; maybe try narrowing it down to the particular section?
<kirkland> elmo: latest packaging is in ppa:etherpad/ppa, if you'd like to test and/or review
<mdz> bryceh, I'm pretty sure I saw this problem myself
<kirkland> elmo: jamespage has vastly improved my initial cut with his java build mastery
<mdz> on a different chipset
<stgraber> tkamppeter: nevermind, bug report says it was done from a script
<mdz> I use a similar setup to Jane with an external monitor as primary
<tseliot> bryceh, mdz: yes, one of those combinations in  monitors.xml will show the problem
<kirkland> elmo: jamespage can confirm, but I believe we're at a point at which we'd like your IS feedback
<speakman> how do I find out which package installed another package?
<tseliot> bryceh, mdz: I see both LVDS and LVDS1 in monitors.xml. I think it's a bit... unusual
<jamespage> elmo, kirkland: almost - I've been really struggling on removing the last bundled jar;
<bryceh> mdz, I'd be interested to see a report on that; what I'm basing my theory that it is arrandale-specific on is that I went through all natty bug reports we've received relating to external monitor or modesetting->blank issues, and found that out of about a dozen or more bug reports, only 2 were *not* arrandale, and one of those two had very different symptoms
<kirkland> jamespage: which jar is that?
<mdz> tseliot, yes, that's what triggered my memory in fact
<elmo> kirkland/jamespage: cool, I'll have a look when i can - thanks for working on this
<mdz> I remember having a problem similar to this when all the xrandr display names changed
<mdz> VGA->VGA1 etc.
<tseliot> yep
<bryceh> tseliot, yeah there was a name change about a year ago; -ati, -nouveau, and -intel were all using different naming systems for the output, and they unified them all to be consistent
<jamespage> kirkland: well its a patched version of rhino; but I can't tell which version (might be 1.6) and it gets shaded alongside Rhino 1.7R1 so both can co-exist
<jamespage> kirkland - really horrible :-(
<jamespage> kirkland: jar name is rhino-yuicompressor.jar
<tseliot> bryceh, mdz: but still, from what I recall, the gnome app should skip the configurations that don't match the current outputs. This in theory, of course...
<jbicha> hi, I'm hunting for a sponsor for bug 426215
<ubottu> Launchpad bug 426215 in apturl (Ubuntu) "[UIF exception] apt:package-name isn't handled by the Store when appropriate" [Wishlist,New] https://launchpad.net/bugs/426215
<kirkland> jamespage: okay, yeah, that's nasty
<tkamppeter> stgraber, Canon does not do LSB-based downloadable printer driver packages (yet), so the user must have installed something manually which finally triggered the installation of the mentioned package.
<kirkland> jamespage: we will need to clean that up for archive inclusions
<stgraber> tkamppeter: ok, thanks
<kirkland> jamespage: but I'd hope that we can forgive that one for a trial run of Etherpad at UDS-O
<jamespage> kirkland: i'd like to spend a few more hours on it tomorrow; but I am running out of available time...
<kirkland> jamespage: k
<bryceh> mdz, tseliot, hmm interesting... looking through these other arrandale/modesetting bug reports, I'm noticing their monitors.xml don't have this LVDS/LVDS1 issue but many of them do show LEN as the monitor manufacturer
<bryceh> maybe that's coincidental though
<tseliot> bryceh: a half broken EDID, perhaps?
<bryceh> tseliot, we've certainly seen that before...
<bryceh> tseliot, LEN is lenovo?  could be just that it's a popular brand amongst arrandale purchasers
<tseliot> bryceh: yes, I think so
<mdz> bryceh, what's written on the front is "iiyama"
<mdz> (of Jane's monitor)
<bryceh> mdz, I mean the laptop panel is LEN
<mdz> bryceh, oh. yes, it's a lenovo x201
<mdz> the external one is iiyama
<AlanBell> kirkland: elmo: my summit modification, links on the schedule http://libertus.co.uk:8000/uds-o/2011-04-14/ to pages like this: http://libertus.co.uk:8000/uds-o/meeting/full-of-awesome/
<AlanBell> kirkland: elmo: so the etherpad server gets hidden and exposed through the summit UI in an iframe for each meeting
<bryceh> mdz, hmm, examining the product numbers for these that are all LEN, they have differing product id's.  So it probably is just coincidental.
<bryceh> mdz, btw one question I think has not been discussed on the bug so far - I assume this is a regression from maverick (where it was working fine), and immediately started after upgrading to natty?
<stgraber> AlanBell: that's really cool
<AlanBell> thanks stgraber
<bryceh> mdz, the plan of attack I'm thinking about is a) have people test the intel-drm-next-proposed kernel to verify it's still an issue upstream (and if not, locate the patch for kernel team to backport), b) (re-)forward the bug upstream, c) do a git bisect between maverick and natty kernels to isolate what patch brought the problem
<mdz> bryceh, understood. now that we know how to work around and reproduce the problem, we should make quick progress
<SpamapS> ScottK: re the opendkim issue.. it does appear that opendkim doesn't daemonize properly.. :-P
<ScottK> SpamapS: Right, but looking at the init, I don't see anything particularly unusual.
<ScottK> Since upstream doesn't use Debian/Ubuntu, I wonder if they have a different definition of "properly"?
<bryceh> mdz, mind attaching that debug dmesg to the report?  Even if it has nothing useful, that itself may give someone some clue
<SpamapS> ScottK: I think the issue is that they are not releasing stdin properly
<mdz> bryceh, I've emailed it to you, so you can decide if it's useful and attach if so
<bryceh> mdz, comment #59 is interesting; I'd like to see the monitors.xml produced from that action (so we know what settings go with the error)
<SpamapS> ScottK: its broken on RH/CentOS too
<mdz> bryceh, it's a bit annoying because some wifi driver is spamming dmesg
<bryceh> yeah
<ScottK> SpamapS: I'd really appreciate it if you could explain this in the thread in a way that the upstream will understand.  He's generally very reasonable.
<mdz> bryceh, emailed you the other monitors.xml
<SpamapS> ScottK: yeah, I think the attempt to dup2 devnull and stuff is just wasted.. setsid() pretty much takes care of all of that once the parent exit()'s .. will get a patch together and then explain to upstream
<bryceh> mdz, thanks
<ScottK> SpamapS: Thanks.
<tkamppeter> pitti, hi
<AlanBell> elmo: any idea what the hostname would be? something like pad.ubuntu.com perhaps?
<elmo> AlanBell: sure
<AlanBell> perfect
<tkamppeter> any buildds expert around? It is about bug 710881, last comment.
<ubottu> Launchpad bug 710881 in cups (Ubuntu Natty) "cups: Test Page /usr/lib/cups/filter/bannertops failed, test page and banner pages do not get printed" [Critical,Confirmed] https://launchpad.net/bugs/710881
<mvo> stgraber: I followed up in the python-apt bug, got a test failure. given that the code there is a bit fragile I am inclinced to do the fix as a SRU instead
<stgraber> mvo: ok, my understanding was that this bug was basically breaking some ARM image where SRU wouldn't do much good (as it wouldn't fix their sources.list)
<mvo> stgraber: ok, I check back with ogra
<mvo> stgraber: thanks a bunch, test failure needs investigation then, put on my agenda for tomorroow morning (yet again :)
<stgraber> mvo: oh, I see the test failure, that's weird. I'll see if I can easily fix that before you're back tomorrow morning (currently doing some test upgrades for smoser's grub issue)
<stgraber> aptsources/sourceslist.py
<stgraber> argh, wrong window :)
<mvo> stgraber: ok, cool
<mvo> I go to bed now
<mar> Hello. Anyone has idea what's this dot? Looks like dead pixel ;) (top toolbar, white dot, right) http://mar.lt/uploads/Screenshot.png
<ohsix> mar: it could be a broken notification from some app
<ohsix> nm
<ohsix> dunno w/unity
<mar> looks like it's skype
<ohsix> missing its icon?
<mar> i managed to click on it :)
<ohsix> nice
<mar> ohsix: don't really know, i've seen skype icon before so it's not missing
<mar> do I need to report it somehow? :)
<ohsix> probably, but it could be a temporary problem, try quitting skype and restarting it
<mar> it'll probably resolve that way
<mar> i also have problem skype icon not showing some times, is it common?
<mar> i mean it's running, minimized but no icon there
<ohsix> i don't know; i don't use skype
<ohsix> if there was a problem you'd probably have to report it directly to them, i'm not sure what the procedure is for sw in the partnetr archive
<jcastro> kees: I sent a mail to TB about adding those linaro folks to ~uds-planners, if you could do that today before EOD I would love you.
<kees> jcastro: ~uds-organizers ?
<jcastro> in launchpad
<jcastro> sorry, ~uds-planners
<kees> you mean uds-organizers ? (there's not uds-planners)
<jcastro> ah right: https://launchpad.net/~uds-organizers/
<jcastro> (sorry, long day)
<kees> jcastro: sure, done.
<mar> https://bugs.launchpad.net/ubuntu/+source/skype/+bug/764828
<ubottu> Ubuntu bug 764828 in skype (Ubuntu) "Natty Beta: Skype icon 1 pixel in size at logon" [Undecided,New]
<mar> found it :)
<ohsix> nice
<ScottK> slangasek: Might https://bugs.launchpad.net/bugs/759525 be multi-arch related?
<ubottu> Ubuntu bug 759525 in libxml2 (Ubuntu) "update-mime-database segmentation fault on libxml2 and __strncmp_sse42" [Undecided,New]
<slangasek> ScottK: nope, that's the other upstream sort of "multiarch" being mentioned in the backtrace :)
<ScottK> OK.
<ScottK> Hopefully doko or barry will look at it then.
<ScottK> Thanks.
<slangasek> ScottK: could be that the code is being built with the wrong optimization options; we don't want sse4 in the default code path, which seems to be what's happened here
<ScottK> Good point.
 * barry reads up
<doko> barry: about jsquery, it's debian policy to share the jquery.js. so better find out what is wrong with the one in natty. do 2.6, 3.1 and 3.2 work?
<barry> doko: personally i think it's a silly policy
<doko> slangasek, ScottK: no, it's independent of optimization options, the implementation is selected at runtime depending on the cpu
<barry> doko: i do not yet know.  i'm still trying to nail down exactly what's going on
<slangasek> doko: right, and I see see4_2 in the cpuinfo flags... so it doesn't seem to be a bug with the selection
<slangasek> and no segfault for me here with that command
<doko> hmm, this is lucid
<slangasek> ah
<matttbe> Hi,
<matttbe> I'm looking for a sponsor in order to upload our cairo-dock packages on Ubuntu Natty.
<matttbe> Bzr branches have been linked to these bugs reports and I've also joined the .debian.tar.gz generated by 'debuild' command and a link the original tarball given by the upstream.
<matttbe> https://bugs.launchpad.net/bugs/723994
<ubottu> Ubuntu bug 723994 in cairo-dock (Ubuntu Natty) "FFe: Please update Cairo-Dock to 2.3.0~1 version" [Wishlist,In progress]
<matttbe> https://bugs.launchpad.net/bugs/723995
<ubottu> Ubuntu bug 723995 in cairo-dock-plug-ins (Ubuntu) "[FFe] Please update Cairo-Dock Plug-ins to 2.3.0~1 version" [Wishlist,Confirmed]
<matttbe> Is somebody can help me by uploading these packages?
<matttbe> Should I have to upload another file or add another comment?
<ScottK> Subscribe ubuntu-sponsors to the bug if you didn't.
<matttbe> done :)
<matttbe> These bug reports are available there: http://reports.qa.ubuntu.com/reports/sponsoring/
<vish> couldnt the cairo-dock team (create and) get a PPU access?
<vish> (they are active and maybe they could have been uploaded a while ago)
<SpamapS> ScottK: so far I'm not able to reproduce the opendkim bug at all
<ScottK> SpamapS: OK.  I didn't manage either, but I was sure I was doing something wrong.  Would you mind joining the upstream discussion?
<ScottK> I'm kind of out of my depth in it.
<matttbe> Hello vish :)
<matttbe> vish: What's a PPU? The possibility to only upload a few packages directly on Ubuntu repositories?
<SpamapS> ScottK: yeah I'll jump in if this last ditch effort (putting usleeps in a few places) doesn't reproduce it
<maco> matttbe: yes
<ScottK> Thanks.
<maco> matttbe: "Per Package Uploader"
<vish> matttbe: hey.. :)  per-package-upload access  some packages have them not sure what the process is though
<matttbe> oh interesting
<maco> vish: ask the tech board to create a package set
<matttbe> I thought that this PPU only exists on Debian
<maco> give a list of which packages they are too
<maco> they vote, and colin makes a packageset
<maco> matttbe: well anyone with upload rights overall could still upload it. NMU approval isnt a thing we do
<maco> its just that someone who isnt trusted to touch *everything* can be trusted to touch *some* things
<matttbe> ok
<vish> matttbe: you guys could go for that.. /me wants cairo-dock fixes asap ;)
<SpamapS> You don't have to have a package set either
<maco> hmm...maybe the DMB can vote on packageset creation too? not sure
<maco> SpamapS: true
<SpamapS> you can just request access to a few packages that you are interested in maintaining
<matttbe> vish: sure :)
<maco> but if you're going to be doing a group of people with the same set of packages, then its easier administratively
<maco> if its only one person, then sure, just list which packages you want to be able to upload
<maco> Laney: can we vote on packageset creation or just packageset access?
<maco> ...i should ask someone who's not also new to the dmb, huh
<matttbe> it's easy, it's only one person (me) and only 2 packages: cairo-dock and cairo-dock-plug-ins.
<matttbe> these packages doesn't have a library which is used by other packages (there is a library but only used by our plug-ins)
<Laney> maco: Yeah, I think so.
<Laney> also, please help progress the mail applications going on!
 * Laney whips the DMB
<maco> Laney: i'm in the middle of typing questions for cyphermox
<Laney> excellent :-)
<maco> matttbe: in that case https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
<matttbe> maco: thank you!
<Laney> how many packages is it? If it's just a couple then PPU is probably preferable
<Laney> also I'd /really/ like to see this Debian situation with cairo-dock resolved
<maco> Laney: 2
<matttbe> Laney: yes, me too...
<maco> so yeah, matttbe should just request PPU
<ohsix> situation?
<matttbe> ohsix: https://bugs.launchpad.net/ubuntu/+source/cairo-dock-plug-ins/+bug/657564
<ubottu> Ubuntu bug 657564 in cairo-dock-plugins (Debian) "Duplicated package with cairo-dock-plugins (coming from Debian)" [Undecided,In progress]
<ohsix> thanks
<Laney> in general making it syncable
<matttbe> ohsix: the official maintainer of cairo-dock debian packages want to split all plugins (more than 50 packages, with a few wrong dependences, wrong names, etc.) and he doesn't want to remove a few patches.
<matttbe> And we don't know what to do...
<ohsix> matttbe: fwiw, with split packages at least their relationship can be defined; presumably themes will also be packaged and depend on the right ones to get it going; and an "-all" metapackage that would just depend on them all
<ohsix> matttbe: i've seen projects do well to clean their own house when interacting with people who distribute their software :P
<matttbe> ohsix: yes but if we split packages and finally we only can install all of them, it's strange...
<matttbe> maybe we can have something like compiz packages...
<matttbe> yes but :) I also have to maintain these packages for our ppa and repository
<ohsix> compiz split their own plugins up when they merged with beryl didn't they? sorted by quality & origin
<ohsix> similarly, gstreamer has good/bad/ugly and base
<matttbe> and we have plug-ins and plug-ins-integration :)
<ohsix> are all the plugins of equal quality?
<matttbe> mmh no
<matttbe> the -integration plug-ins are important
<ohsix> what percentage might you consider well done and vital?
<matttbe> some of them are used by the default theme so it can be interesting to install them. Some plug-ins are used by other, etc.
<matttbe> it's hard to give you a percentage but... yes maybe we can create a few groups
<ohsix> it might help to keep focus on the important first class ones too
<ohsix> if you had groups, people doing themes could say which group & version instead of exaustively listing them, if they do at all
<matttbe> ohsix: yes but if these people do that, it'll be only for Debian and Ubuntu users
<matttbe> or we've to create these groups into the code...
<ohsix> sure, i was talking about your grouping of them though
<ohsix> if you chose to do so
<matttbe> and if we have a look to compiz packages, they are split because these plug-ins are not in the same git branch...
<ohsix> well, that's one reason
<matttbe> but yes, I'll try to find something else in order to sync Debian and Ubuntu version
#ubuntu-devel 2011-04-20
<cleary> hi folks
<cleary> I'm hoping someone can help me - I'd like to change the default xsession in use on 11.04 installs to gnome-classic
<cleary> there are a couple of complications: 1. unity needs to be left installed as an option
<cleary> 2. since ldap will be used for authentication, ~/.dmrc is not an option
<cleary> these are the only two options my searching has turned up - does anyone know where gdm pulls it's initial choice from?
<cleary> a dirty way around it would be to just swap the /usr/share/xsessions/[gnome|gnome-classic].desktop entries
<ohsix> doesn't the contents dictate the order? you could divert one of them
<cleary> ohsix: I'm not sure what contents you're referring to?
<ohsix> the desktop files, but i just looked and they don't
<cleary> I can't see any debconf selection options either, gconf doesn't seem to have anything
<ohsix> well they did it by calling unity "gnome" and classic something else, gnome is the default; hmm, i don't know what controls the order
<Sarvatt> cleary: /etc/gdm/custom.conf?
<cleary> Sarvatt: what would I put in it?
<Sarvatt> [daemon]
<Sarvatt> DefaultSession=gnome-classic maybe?
<ohsix> bam
 * ohsix commit to memory
<cleary> I'll give it a shot - I didn't see that key in the gnome library
<Sarvatt> http://library.gnome.org/admin/gdm/stable/configuration.html.en#daemonconfig
<cleary> that's what I was reading...
<cleary> still can't see the defaultsession key
<Sarvatt> yeah, sorry, maybe it was removed in gnome 3?
<ScottK> Aren't any remaining features in Gnome 3 considered bugs?
<ScottK> </troll>
<cleary> Sarvatt: fwiw, that seems to have worked :)
<cleary> thanks
<kees> hi, can an archive admin pocket-copy linux-meta-ti-omap4 from -updates to -security to match the kernel in -security?
<slangasek> kees: that's maverick-updates?
<slangasek> kees: done
<highvoltage> it's a LaserJock!
<LaserJock> hi there
<LaserJock> highvoltage: been a while :-)
<highvoltage> LaserJock: how are you?
<LaserJock> oh, pretty good
<LaserJock> thought I'd check in with my *buntu friends, spending a little time this evening doing some hacking
<highvoltage> and that's how it starts :)
<LaserJock> lol
<LaserJock> kinda quiet, I guess Natty must be all wrapped up :-)
<highvoltage> yeah that's a weird thing about this timezone :)
<ScottK> LaserJock: Wrapped up/Broken beyond repair.  You say Tomato, I say tomatoe.
<highvoltage> broken, maybe. beyond repair, no way!
<LaserJock> I've been running it since Beta 1 and it's been pretty nice
<LaserJock> I'm even having to take back some of those nasty things I said about Unity ;-)
<ScottK> Opinions seem mixed.  As with most things.
<LaserJock> highvoltage: I'm in Mountain time now, I'm all screwed up
<LaserJock> ScottK: yeah, seems to be the open-source way
<ajmitch> hi LaserJock
<LaserJock> hi there ajmitch
<LaserJock> I just wish things could stay around long enough to learn any of it. I was just getting used to gnome-panel and PyGTK and  now ....
<ajmitch> there does seem to be a bit of churn over time :)
<highvoltage> gnome-panel was the visible part of gnome that I though needed most improvements. and now that it's gone I miss it dearly.
<LaserJock> well, I had just figured out this year how to make it work well on my netbook
<LaserJock> oh well
<LaserJock> this week though I was reminded how it could be a lot worse ... I tried getting a decent Ruby development platform going
<ajmitch> so have you found some free time to return to ubuntu development?
<LaserJock> oh, probably not much
<LaserJock> my time away has taught me 2 things: 1) Ubuntu is just fine without me and 2) I'm so totally not a programmer
<LaserJock> so I dunno, I love Ubuntu as always, I just don't know what I could actually contribute
<ajmitch> I'm sure there's still plenty you (or I) could get involved in again :)
<LaserJock> maybe
<LaserJock> ajmitch: with all these rock starts around, I'm not sure what a couple of old buzzards like use could do ;-)
<ajmitch> heh
 * ScottK <--- So not a programmer either.
<ohsix> your comments are peculiar
<lifeless> who is, really?
<LaserJock> lifeless: whatever, you *totally* count :-)
<lifeless> heh :)
<LaserJock> like, I can usually follow along the simple tutorials and can read along with several languages
<LaserJock> but I can barely write anything useful
<ScottK> LaserJock: You didn't get to be a core-dev because people found you unable to contribute.
<ScottK> LaserJock: So what, most of what's needed isn't writing, but the finding and the interating.
<ScottK> ... integrating.
<LaserJock> I just don't know that I can keep up with packaging anymore
<LaserJock> finding sounds ok though
<highvoltage> LaserJock: bah, you're an old-time pro when it comes to packaging. and you literally wrote a book on it!
<LaserJock> lol
<LaserJock> that's because back in my day the person who got to write the book was the one asking all the dumb questions ;-)
<ScottK> That's still the best way to do it.
<highvoltage> I don't think I've asked all the dumb questions yet, but I'm making progress with it.
<LaserJock> I've always loved QA, maybe I can find something to do there, who knows
<kees> slangasek: yup, and thanks!
<hallyn> 'apt-get source libvirt-bin' on a lucid-proposed system gives me newer result than 'bzr branch lp:ubuntu/lucid-proposed/libvirt.'  Is that something that can get kicked back into sync?
<james_w> hallyn, not without some investigation and possibly a bug fix unfortunately
<pitti> Good morning
<ajmitch> morning pitti
<pitti> hey ajmitch, how are you?
<ajmitch> pitti: good, how are you?
<pitti> ajmitch: quite well, thanks! preparing to move to another city soon, so my rooms look more and more like a Sokoban level
<ajmitch> you must be busy, with it coinciding with a release :)
<pitti> ajmitch: somewhat :)
<didrocks> good morning
<dholbach> good morning
<ion> that
<tseliot> pitti: hi, I'm going to upload nvidia-173 today as it finally works with the new xserver. I guess we'll have to re-enable it in jockey too
<pitti> tseliot: actually no; as long as it depends on the correct X.org ABI it should be available automatically
<pitti> that was the point of this dynamic check :)
<tseliot> pitti: oh, right, I forgot about that. Very good :)
<pitti> tseliot: this will also make it a lot easier to test drivers in a PPA and such
 * tseliot nods
<pitti> jj:q
<pitti> sorry
<abhinav-> Hi, can someone merge this branch ? or is it too late for natty ? https://code.launchpad.net/~er-abhinav-upadhyay/ubuntu/natty/tomboy/patch-757635/+merge/58303
<pitti> abhinav-: seems ok, I can merge; however, the MP has a conflict in debian/changelog?
<pitti> abhinav-: and wrong branch, we use Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/tomboy/ubuntu
<pitti> so I'll just get the patch and apply it manually
<abhinav-> pitti: oh , I have no clue how the conflict came in debian/changelog, although I did a few changes in the code today and pushed but didn't touch dch (perhaps edit-patch did it ?)
<pitti> could also be some internal bzr magic
<pitti> unfortunately bzr tries to be too clever when merging changelogs
<abhinav-> pitti: oh , I have been struggling all the way to create this patch :-/ , thanks for taking it :)
<pitti> kees: polkit> FYI, quilt po patch sent upstream, and changes applied to Debian git and uploaded to sid
<pitti> abhinav-: thanks for fixing!
<matttbe> Hello,
<matttbe> I'm still looking for a sponsor in order to upload our cairo-dock packages on Ubuntu Natty.
<matttbe> Is somebody can help me by uploading these packages?
<matttbe> Bzr branches have been linked to these bugs reports and I've also joined the .debian.tar.gz generated by 'debuild' command and a link the original tarball given by the upstream.
<matttbe>  https://bugs.launchpad.net/bugs/723994
<ubottu> Ubuntu bug 723994 in cairo-dock (Ubuntu Natty) "FFe: Please update Cairo-Dock to 2.3.0~1 version" [Wishlist,In progress]
<matttbe>  https://bugs.launchpad.net/bugs/723995
<ubottu> Ubuntu bug 723995 in cairo-dock-plug-ins (Ubuntu) "[FFe] Please update Cairo-Dock Plug-ins to 2.3.0~1 version" [Wishlist,Confirmed]
<matttbe> Should I have to upload something else and/or add another comment?
<pitti> abhinav-: looks like upstream now likes it too, good work!
<seb128> matttbe, didn't someone review that said it was not ready yesterday?
<abhinav-> pitti: yes, they are going to merge it for next release . Thanks :)
<matttbe> seb128: I think not
<seb128> matttbe, jdstrand did, he mentioned it in his patch pilot summary email on the ubuntu-devel list yesterday
<matttbe> seb128: yesterday they spoke about cairo-dock packages in Debian
<seb128> "
<seb128> Review/discuss at length with upstream LP: #723994 (FFe: Please update
<seb128> Cairo-Dock to 2.3.0~0rc1 version). Not ready yet. Will provide
<seb128> packages/packaging changes to review. Updated bug so it is more clear
<seb128> what needs to happen to move forward."
<seb128> he wrote
<matttbe> yes but I've updated the bug report :)
<seb128> oh, so your reply was confusing, seemed like you didn't know it was reviewed yesterday and now you know about it and say your updated since?
<seb128> well anyway I will let someone who has a clue about it already did a first review sponsor ;-)
<matttbe> yes but jdstrand said : "Matthieu, please update the other bug to more accurately reflect this (or open a new one)."
<matttbe> I did that and nobody had reviewed it since this change
<seb128> ok
<matttbe> seb128: but should I have to do something else? or to contact someone in particular?
<seb128> matttbe, no, just wait for someone to do sponsoring and pick it up
<matttbe> seb128: ok thank you
<seb128> your welcome, thanks for your work!
<ogra_> pitti, ping
<seb128> ogra_, contextless pong
<ogra_> seb128, are you pitti ? :P
<seb128> no
<seb128> but contexltess pings don't have a defined receivers ;-)
<ogra_> well, i have a udev related question
<seb128> well just ask it? you never know maybe someone else can reply and at least pitti will have context to reply even if you are not around when he pong
<pitti> ogra_: on phone, what's up?
<ogra_> pitti, i need an advise for bug 746023, apparently its easily solvable by two lines to the soundcard rules in udev ... i would like to have that fixed for release but that would mean a udev upload for these two lines
<ubottu> Launchpad bug 746023 in alsa-lib (Ubuntu Natty) "No sound on omap4" [High,In progress] https://launchpad.net/bugs/746023
<pitti> ogra_: which rules? I don't see a patch there
<ogra_> there is no patch yet
<ogra_> /lib/udev/rules.d/78-sound-card.rules would need two additional lines
<pitti> if they are generally useful and not vendor/product specific, i. e. they can go upstream, I have no objection
<ogra_> pitti, if you say an udev upload is possible for that i'll add a debdiff (or even do the upload) i just dont want to "just upload away"
<pitti> otherwise they can be shipped by just about any other package
<ogra_> they are HW specific
<pitti> ogra_: my condition for that would be that it is upstreamable
<ogra_> and i have no arch sopecific package at all i could put them in
<pitti> alsa-utils? well, let's see the rules first
<ogra_> there is currently only one board that uses this sound chip, if others come the handling might have to change
<ogra_> ATTRS{id}=="SDP4430", RUN+="alsaucm set _verb HiFi"
<ogra_> ATTRS{id}=="SDP4430", RUN+="alsaucm set _verb Record"
<pitti> if they are working around a kernel bug, no upstream will like them, and we can only quick fix them in natty
<ogra_> thats the two lines needed
<pitti> alsa-utils: /usr/bin/alsaucm
<pitti> so they should go into alsa
<ogra_> its not a kernel bug, arm uses alsas use case manager nowadays, you need to initialize that with the right profiles
<pitti> udev doesn't ship alsaucm, so the rules don't make sense there
<pitti> anyway, need to run out for a bit before the next confcall
<ogra_> ok
<ogra_> pitti, thanks, i'll roll an alsa patch
<devurandom> Hi!
<devurandom> Has anyone already noticed that there is an ugly conflict in the repositories for maverick?
<devurandom> "linux-image-generic: Depends: linux-image-2.6.35-29-generic which is a virtual package."
<devurandom> And also this: "libpolkit-qt-1-1: Conflicts: libpolkit-qt-1-0 (<= 0.99.0-0ubuntu1) but 0.95.1-1ubuntu1 is to be installed."
<directhex> devurandom, which repositories do you have enabled?
<directhex> security, backports, proposed, updates?
<devurandom> maverick, maverick-updates, maverick-security (reading sources.list)
<devurandom> Ah, also maverick-backports and maverick-proposed, yes.
<devurandom> Is it possible to have a look where the offending update comes from?
<devurandom> i.e. which repository
<tsimpson> "apt-cache policy <package>" should tell you
<devurandom> Ah, nice. Candidate for linux-image-generic is version 2.6.35.29.37 from -proposed
<directhex> devurandom, proposed does this. that's why it's proposed
<devurandom> And polkit is a kubuntu-ppa issue.
<devurandom> directhex: Does what?
<directhex> devurandom, blows up on missing things
<devurandom> Well, I assume it is available to get some feedback?
<directhex> devurandom, and not everything in proposed gets published. i'd avoid it unless testing specific stuff
<devurandom> devurandom does this ;)
<devurandom> Ok, so I better disable it? If I do, so, will everything be downgraded to non-proposed?
<directhex> no, it won't
<directhex> downgrades are never automatic
<devurandom> Are there scripts to do it?
<devurandom> Anyway, thanks for that suggestion, directhex!
<stgraber> mvo: hey! Saw my update on that python-apt bug ? Apparently some templates have their type set to None ... it's now fixed
<ogra_> stgraber, oooh, awesome !
<stgraber> ogra_: yeah, we should hopefully have something that can be uploaded to fix your issue :)
<tgall_foo> GrueMaster, ping
<cjwatson> stgraber: mind if I grab bug 759545 and finish it off?
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Natty) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Confirmed] https://launchpad.net/bugs/759545
<cjwatson> stgraber: I just committed a fix on the Debian side
<cjwatson> stgraber: http://paste.ubuntu.com/596541/
<dpm> mvo, are such strings supposed to go in app-install data -> https://translations.launchpad.net/ubuntu/natty/+source/app-install-data-ubuntu/+pots/app-install-data/ca/1036/+translate ? I think it sneaked in from the firefox quicklist entries
<stgraber> cjwatson: sure, go ahead. Thanks!
<cjwatson> stgraber: thanks for pointing out my negligence in failing to update that file :-/
<cjwatson> stgraber: hm, though I note that the md5sum you mention isn't there; I think that this is due to the gross way we handle /etc/default/grub
<cjwatson> I guess I'll have to do a test install to check
<stgraber> cjwatson: yeah, the one I mentioned is what you get when installing ubuntu 10.10 server from the CD. I was trying to do a netinstall of 10.10 desktop when the language-selector issue appeared in 10.10 breaking my install :(
<cjwatson> I would love to fix that horrible config file handling, but not for natty
<cjwatson> the defaults aren't even constant
<dobey> hey all
<dobey> if i need to upload a couple patches today, what is the probability that we will actually get them on the gold CD?
<pitti> dobey: the smaller they are, the higher the chance :)
<dobey> of course. but you know, it's ubuntuone, and we do everything big. :)
<pitti> dobey: in general the hurdle is pretty low today still
<pitti> today should be the deadline for big packages such as webkit/libo, tomorrow for small packages
<pitti> as over the Easter holidays we have little firefighting capacity
<dobey> right. was just looking at the schedule and it says release image build is tomorrow
<SpamapS> can somebody please take a look at the sync request bug 766879 .. it fixes the FTBFS bug 752164
<pitti> well, tomorrow we want buildable images, right
<ubottu> Launchpad bug 766879 in python-drizzle (Ubuntu) "Sync python-drizzle 1.0-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/766879
<ubottu> Launchpad bug 752164 in python-drizzle (Ubuntu Natty) "FTBFS with current drizzle" [High,Confirmed] https://launchpad.net/bugs/752164
<pitti> fabbione_vac: happy Easter holidays :)
<fabbione_vac> pitti: thanks dude :)
<cjwatson> SpamapS: doing a sync run now
<SpamapS> cjwatson: ty
<mvo> dpm: yeah, that looks like it, I have a look
<dpm> cool, thanks mvo :)
<pitti> SpamapS: congrats, you now have +queue access :)
<SpamapS> pitti: \o/
<soren> SpamapS: Click something!
<pitti> SpamapS: (shameless plug) want to exercise it on the postgresql update? :-)
<james_w> click /everything/
 * stgraber turns off unattended-upgrade for the time being :)
<pitti> SpamapS: in fact, I'd appreciate reviewing/accepting the maverick one, that saves me from having to upload the orig.tar.gz for lucid all over again
<SpamapS> stgraber: I <heart> u too ;-)
 * pitti hands SpamapS a â¥
 * SpamapS is reviewing the postgres sru now
<stgraber> SpamapS: that was in case you follow james_w's recommendation :)
<SpamapS> stgraber: his demos are so good, why not just blindly follow his advice?
<SpamapS> pitti: whats the hold up on the natty fix?
<pitti> SpamapS: doing it right now
<pitti> SpamapS: I thought I could do a sync, but I can't
<stgraber> SpamapS: ;)
<SpamapS> pitti: <christopher walken voice>damn</voice>
<stgraber> SpamapS: http://paste.ubuntu.com/596557/
<pitti> SpamapS: likewise, once the maverick one is accepted, I don't need to reupload the orig all over again for natty as well :)
<SpamapS> stgraber: that was for IE6
<SpamapS> it plays fast and loose with tag names
<SpamapS> pitti: well I trust you then that you'll get natty fixed soon. :)
<cnd> I'm trying to dput to ubuntu, but it's saying the gpg sig is bad
<cnd> I've never had this issue before
<pitti> SpamapS: postgresql-8.4_8.4.8-0ubuntu0.11.04_source.changes is ready to be dput :)
<cnd> is there something odd going on with lp right now?
<soren> cnd: Yeah, SpamapS just got access to a bunch of things. Brace yourself.
<soren> (jk)
<pitti> cnd: in freeze times it always costs a beer for the release team before it accepts it
<cnd> pitti, shouldn't I still be able to upload to the queue?
<pitti> cnd: LP just has liked to whine a bit in the past few weeks, but don't worry, it'll work anyway
<cnd> pitti, oh? so I can ignore the error?
<pitti> cnd: well - I can say that _so far_ it has worked for everyone else who had the bug :)
<cnd> pitti, ahh, just got the emails back
<cnd> I tried three times, so I dunno if that means there's three copies in the queue...
<pitti> cnd: yes, there will
<cnd> pitti, sorry bout that :(
<pitti> cnd: np; I just rejected two
<cnd> thanks!
<SpamapS> pitti: alright, done. :)
 * SpamapS goes to have breakfast now
<pitti> SpamapS: cheers; lucid/natty uploaded
<pitti> SpamapS: ah, did you run the sru-accept command now?
<GrueMaster> tgall_foo: pong
<tgall_foo> GrueMaster, for testing sound (in this case on arm hardware) do you have any particular recommendations ? Generally I'm just trying out things like speaker-test, aplay, xmm2 ...   sound reasonable ?
<dobey> SpamapS: are you the reason that dput is breaking for me now? :)
<GrueMaster> That's where I start.  Go with the lowest variables first.  For example, on omap (beagle, beagleXM), audio is muted by default and the pulseaudio mixer doesn't fix it.  But you can enable it through alsamixer and play sound through speaker-test
<tgall_foo> yeah we're thinking we're going to include an asound.test with the levels set correct as partof the images to avoid that problem ...   but to date adjusting the levels hasn't yielded any audio
<dobey> SpamapS: http://pastebin.ubuntu.com/596574/
<GrueMaster> tgall_foo: Which platform are you referencing?
<ogra_> omap4 sound should be fixed with next alsa-utils upload
<ogra_> omap3 likely needs the same bits in natty
<pitti> dobey: just ignore it; it'll work anyway
<tgall_foo> ogra_, yes I saw the bug update for that
<tgall_foo> ogra_, great work!
<pitti> dobey: I'll reject one of your two ubuntuone-client uploads
<tgall_foo> GrueMaster, panda, beagle xm and beagle C are the 3 I care about most
<GrueMaster> Well, for panda, we have some ucm fixes that make it work.
<dobey> pitti: ah ok. guess i checked the queue too quickly
<ogra_> kirkland, even when setting FRONTEND_BACKGROUND=legacy on the kernel cmdline i get the violet colors in screen ... should i see a difference ?
<kirkland> ogra_: screen shot?
<kirkland> ogra_: try FRONTEND_BACKGROUND=dark
<kirkland> ogra_: and FRONTEND_BACKGROUND=original
<ogra_> kirkland, trying to get you the screenshots for bug 747229 ... note that we use oem-config-debconf there, not d-i though
<ubottu> Launchpad bug 747229 in debian-installer (Ubuntu Natty) "weird color change during oem-config debconf package removal step in serial installs" [Medium,Incomplete] https://launchpad.net/bugs/747229
<GrueMaster> tgall_foo: See bug 746023.  It has fixes for panda.  As to omap (beagle, beagleXM) I am going to see if I can write a set of UCM rules for it as well.
<ubottu> Launchpad bug 746023 in alsa-utils (Ubuntu Natty) "No sound on omap4" [High,In progress] https://launchpad.net/bugs/746023
<ogra_> kirkland, doesnt change a thing, i suspect oem-config doesnt respect that var on cmdline
<chrismat> I want to create a .deb file that copies everything from a directory called texmf into /usr/local/texmf
<chrismat> how do I do that?
<kirkland> ogra_: hmm, i guess not
<kirkland> ogra_: how is it different than d-i?
<cjwatson> kirkland: oem-config uses debconf, not cdebconf
<ogra_> kirkland, though i'm pretty sure i saw the issue before the theme was changed
<cjwatson> I wonder if we need to call setvtrgb inside bterm
<Sarvatt> YokoZar: do you by any chance have any plans to update ia32-libs again? https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/755720 is a pretty major problem and already fixed on the mesa side but needs to be updated in there
<ubottu> Ubuntu bug 755720 in ia32-libs (Ubuntu) "32 bit dri drivers cannot find libdricore and libglsl" [High,Triaged]
<SpamapS> pitti: I did sru-accept for maverick, will do lucid shortly
<pitti> SpamapS: splendid, thanks
<SpamapS> pitti: accepted lucid and hardy as well now
<yofel> pitti: can we get the fix for bug 765808 into natty?
<ubottu> Launchpad bug 765808 in apport (Ubuntu) "apport doesn't use the default browser in KDE" [Medium,Triaged] https://launchpad.net/bugs/765808
<pitti> SpamapS: thanks
<pitti> yofel: yep, will look at it ASAP
<\sh> pitti: ping pygobject Gtk.Dialog and AttributeError: type object 'DialogFlags' has no attribute 'MODAL' ... do you have any clue what this error occurs on natty...
<\sh> s/what/why/
<pitti> \sh: (@phone, bbl)
<pitti> $ python -c 'from gi.repository import Gtk; print Gtk.DialogFlags.MODAL'
<pitti> <flags GTK_DIALOG_MODAL of type GtkDialogFlags>
<pitti> \sh: ? do you have a reproducer?
<\sh> pitti, http://paste.ubuntu.com/596595/ <- could be that I'm the one is wrong, but I doubt so
<\sh> it complains in  File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 358, in __init__
<\sh>     if flags & Gtk.DialogFlags.MODAL:
<pitti> \sh: sorry, I don't see "MODAL" there at all?
<\sh> pitti, see ;)
<maxb> What's a good place to ask about debian-installer preseeding ubuntu-specific issues? (I'm wondering if it's known that auto=true doesn't seem to have the desired effect in Ubuntu)
<pitti> \sh: ah -- import appindicator
<pitti> don't do that, it imports "gtk"
<pitti> \sh: you need to use GI for appindicator as well
<\sh> pitti, from gi.repository import appindicator?
<pitti> \sh: AppIndicator
<cjwatson> maxb: I think I vaguely know that I've never got round to enabling that
<cjwatson> maxb: (#ubuntu-installer, in general)
<maxb> cjwatson: Thanks. I assume it not-working is fallout from Ubuntu using console-setup, when Debian doesn't?
<stgraber> mvo: so any chance of seeing a new python-apt uploaded today (based on discussion in -meeting) ? :)
<mvo> stgraber: yes, I check it out after the meeting, thanks for your update on it
<stgraber> mvo: great thanks! I'm sure ogra_ is looking forward to finally having this bug solved ;)
<ogra_> ++
<ogra_> \o/
<cjwatson> maxb: no, auto-install was always a separate component
<cjwatson> maxb: though it's possible it's never been properly hooked into console-setup, granted
<maxb> The "Ubuntu Installation Guide" is an interesting creature. You have to read between the lines interpreting which bits are unmodified from Debian an thus may not apply :-)
<jamespage> kirkland, elmo: the version of etherpad in ppa:etherpad/ppa is prob as good as its going to get pre-UDS
<jamespage> Daviey and I have worked on pulling in a few key patches today but it looks OK.
<pitti> zul: rejecting N-1 of your many nut uploads
<SpamapS> can somebody explain why this is a "failed to build": https://launchpadlibrarian.net/70014536/buildlog_ubuntu-natty-amd64.python-drizzle_1.0-2_FAILEDTOBUILD.txt.gz
<SpamapS> Looks almost identical to the i386 build log
<doko> Spads: it deliberately rejected
<Spads> ^-- SpamapS
<doko> SpamapS: PyCObject was removed in 3.2
<jhunt> cjwatson, SpamapS: lp:ubuntu/upstart is showing as last modified "4 weeks ago"...?
<SpamapS> doko: right so how did it build on i386 and not amd64 ?
<doko> SpamapS: pretty sure that it did build, but will fail to load due to undefined symbols
<SpamapS> jhunt: http://package-import.ubuntu.com/status/upstart.html#2011-03-26 09:47:55.356196
<SpamapS> doko: interesting
<SpamapS> well I suppose the right thing to do is just disable the python3 bits then
<SpamapS> I believe swig has only *just* gotten 3.2 support
<doko> if it cannot be fixed, yes
<SpamapS> like.. 9 days ago http://sourceforge.net/tracker/?func=detail&atid=101645&aid=3057804&group_id=1645
<jhunt> SpamapS: hmm. that tag certainly isn't there, but I'm wondering how it worked for the 5 previous changes?
<jhunt> SpamapS: I really need the bzr repo to be correct as we have 1 more change to make to upstart for natty.
<SpamapS> jhunt: you can just do an apt-get source
<SpamapS> "old school" ;)
 * SpamapS has started noticing more and more udd failures that make it less and less useful. :-/
<jhunt> SpamapS: I'm guessing I should have tagged the ubuntu branch and just haven't been doing so.
<cjwatson> jhunt: if you have a branch that's closer to reality, tag it and 'bzr push --overwrite lp:ubuntu/upstart'
<cjwatson> jhunt: or, actually, you'll need to point SpamapS or me at it and have us do that
<jhunt> cjwatson: ok, I think all that reality is missing is the tag(s).
<cjwatson> jhunt: I think for the ones I sponsored, I probably set the tag
<cjwatson> maybe SpamapS didn't
<jhunt> cjwatson: ok, sorry. didn't realise I should have been tagging.
<SpamapS> I didn't actually merge into the branch
<SpamapS> I thought uploading would do so
<cjwatson> no, uploading will (at best) construct a new tree with the same contents, based on whatever was previously in lp:ubuntu/upstart
<cjwatson> you should actually merge
<SpamapS> cjwatson: *ahhh*
<cjwatson> it doesn't know where to merge from ...
<jhunt> SpamapS: can I leave you to resolve as I'm trying to get a fix for bug 767053 out kinda "now" :)
<ubottu> Launchpad bug 767053 in upstart (Ubuntu Natty) ""initctl status" no longer works as a non-privileged user" [High,In progress] https://launchpad.net/bugs/767053
<SpamapS> Ok so we can fix it by just importing the packages that aren't properly represented and then overwriting?
<cjwatson> SpamapS: is there an existing branch which is correct?  point me to it and I'll fix it up
<SpamapS> cjwatson: I don't believe there is one with the appropriate tags.
<cjwatson> I don't care about that
<jhunt> SpamapS, cjwatson: why is it looking for tag upstream-0.9.4
<cjwatson> is there an existing branch with the right content history?
<SpamapS> but the content is correct in ...
<cjwatson> jhunt: forget about that
 * SpamapS grabs it
<cjwatson> jhunt: (get james_w to explain it properly at some point, but we don't need to worry about it at the moment)
<jhunt> cjwatson: ack! :)
<SpamapS> lp:~clint-fewbar/ubuntu/natty/upstart/fix-chroot-sessions
<SpamapS> cjwatson: ^^ thats what was uploaded
<cjwatson> SpamapS: so in a checkout of that: 'bzr tag; bzr push lp:ubuntu/upstart'
<cjwatson> er, push --overwrite
<SpamapS> I did not need overwrite for some reason
<SpamapS> jhunt: check lp:ubuntu/upstart now
<cjwatson> oh, yeah, you wouldn't need --overwrite if the auto-import failed
<jhunt> SpamapS: awesome, thx!
<SpamapS> cjwatson: debcommit --release should do the tag part for me should it not?
<cjwatson> SpamapS: normally yes
<matttbe> Hello everybody,
<matttbe> I'm still looking for a sponsor in order to upload our cairo-dock packages on Ubuntu Natty.
<matttbe> Of course bzr branches have been linked to these bugs reports and I've also joined the .debian.tar.gz generated by 'debuild' command and a link the original tarball given by the upstream.
<Daviey> matttbe: is there a merge proposal?
<matttbe> Daviey: yes but it seems that cairo-dock-plug-ins bzr branch is broken
<zul> pitti: thanks i was having problems locally
<pitti> zul: LP complaining about invalid keys? :-)
<matttbe> Daviey: and the cairo-dock bzr branch has a lack of tags... but branches are there
<zul> pitti: how did you guess? :)
<matttbe> this is why I've joined other files
<matttbe> Both packages seem ready, I've tested them a lot. This version is used on our ppa and on our repository. So... we just need somebody to upload these two packages (cairo-dock and its plug-ins)
<matttbe> https://bugs.launchpad.net/bugs/723994
<ubottu> Ubuntu bug 723994 in cairo-dock (Ubuntu Natty) "FFe: Please update Cairo-Dock to 2.3.0~1 version" [Wishlist,In progress]
<matttbe> And for our plug-ins:
<matttbe> https://bugs.launchpad.net/bugs/723995
<ubottu> Ubuntu bug 723995 in cairo-dock-plug-ins (Ubuntu) "[FFe] Please update Cairo-Dock Plug-ins to 2.3.0~1 version" [Wishlist,Confirmed]
<pitti> zul: because that seems to affect half of the developers
<pitti> with "half" varying depending on the moon phase
<Daviey> matttbe: so, the debdiff on comment 4 is what you want?
<matttbe> Should I have to upload something else and/or add another comment?
<zul> pitti: hehe
<pitti> zul: it complains, but it works anyway
<zul> pitti: odd isnt it
<matttbe> Daviey: sorry, I've joined this debdiff but it was for the rc1 release
<matttbe> but I can recreate this debdiff for the final release
<cjwatson> pitti: unless you're using dupload, in which case it breaks
<cjwatson> (slightly stricter error handling, presumably)
<Daviey> matttbe: yeah, i think it's kinda confusing... there are multiple things there.. debdiff from current natty archive would help.
<matttbe> Daviey: this is why I asked here if I had to join another file because everything is there (the original tarball, a bzr branch and the debian directory)
<matttbe> Daviey: Ok, I'll do that asap!
<Daviey> matttbe: yup.. seems you've been doing all the correct things!
<cjwatson> psurbhi: oh, hm, I said in my to-do list in the meeting that I was going to look at bug 764893, but I see you just assigned it to yourself - are you already working on it?
<ubottu> Launchpad bug 764893 in os-prober (Ubuntu Natty) "os-prober: does not detect Ubuntu in btrfs subvolume" [High,Confirmed] https://launchpad.net/bugs/764893
<cjwatson> psurbhi: happy to review etc.
<Daviey> matttbe: if you debdiff from cairo-dock-plug-ins 2.2.0~4-0ubuntu4 -> what you want, that would help.
<matttbe> Daviey: ok thank you :)
<Daviey> matttbe: let me know when you have done that, and i'll have a poke.
<matttbe> Daviey: great thank you!
<pitti> yofel: merged, uploading now; thanks!
<CodeGnome> Is this the right channel to talk about non-maintainer uploads?
<cjwatson> CodeGnome: Ubuntu doesn't have that concept
<CodeGnome> cjwatson: Well, even if it's called something else, there are certainly people who maintain packages in Ubuntu, and people without commit access to them.
<cjwatson> CodeGnome: calling that a non-maintainer upload would be misleading even in Debian - all Debian developers have *technical* ability to upload anything, the restriction is just social
<cjwatson> CodeGnome: perhaps you could rephrase your question to say what you actually want, anyway
<CodeGnome> The password-gorilla packages are two years out of date. It needs to be repackaged. I'm not a committer for the package. Whatever you want to call it, what's the process?
<cjwatson> CodeGnome: https://wiki.ubuntu.com/SponsorshipProcess
<seb128> do you want to do the work or just to point that it needs an update
<cjwatson> CodeGnome: also, it would be significantly better to get the package updated in Debian first, and then we can just sync it and more people benefit
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622398 was filed last week
<ubottu> Debian bug 622398 in password-gorilla "New upstream release (1.5.3.4)" [Wishlist,Open]
<infinity> CodeGnome: What's the current upstream version?  Sid has 1.5.3.4
<infinity> CodeGnome: If Debian is in sync with upstream, this problem will be self-correcting in Ubuntu in a week or two.
<CodeGnome> seb128: I don't mind doing the work, but there are some real peculiarities to how this was originally packaged. There are the real sources, the ubuntu launchpad sources, and the debian packages.
<cjwatson> heh, Patrick forgot to close the bug with that upload
<infinity> (ie: when the next release opens and we re-sync)
<cjwatson> yeah, that'll happen automatically
<seb128> CodeGnome, so what cjwatson said
<infinity> CodeGnome: There are no "launchpad sources" in the sense that we've forked it from Debian (we haven't).
<infinity> CodeGnome: And Debian is in sync with the latest upstream.  We're just in a relese freeze right now.
<infinity> CodeGnome: So, when our next release opens, you'll have the latest version synced from Debian, no need to do anything.
<CodeGnome> Well, there sort of is. What's lp:ubuntu/password-gorilla if it isn't the launchpad fork?
<cjwatson> CodeGnome: it's an exact copy of a previous Debian version.
<cjwatson> that's not a fork by anyone's standards
<infinity> ^
<cjwatson> shortly after we open oneiric, we'll automatically sync in all changes from Debian to packages that didn't have Ubuntu modifications (and manually go through merging any that did have Ubuntu modifications)
<CodeGnome> Well, fair enough. I was told that there were issues getting the latest version packaged in Debian. I'm not a Debian maintainer, so I thought I'd handle it in Ubuntu instead. Guess it's not necessary for this particular package.
<cjwatson> CodeGnome: there may have been, but it got updated in Debian yesterday
<cjwatson> so those issues seem to be in the past
<CodeGnome> cjwatson: Ah. Well, fair enough. :)
<cjwatson> the reason we try to avoid doing that kind of thing independently is that it usually ends up resulting in more manual work in the future; although the possibility's there if there's a pressing need
<cjwatson> (i.e. Debian would likely do it at some point, and then we'd have to figure out how to merge)
<cjwatson> for a single package this isn't too hard, but it gets pretty scary when you multiply it up by the number of packages we ship
<CodeGnome> Debian is sometimes several years behind on certain packages, though. Doing NMUs for Debian is a bit of a hassle. :/
<cjwatson> right, but redirecting that effort into Ubuntu is not *necessarily* a good use of time
<CodeGnome> cjwatson: I can see your point. I'm not arguing it; I just had an itch to scratch, but it looks like someone else already scratched it. :)
<infinity> And, to be fair, if a maintainer is literally years behind on a package and can't seem to make a coherent technical argument as to why, I'd tend to consider it abandoned and fair game for NMUs in Debian.
<matttbe> Daviey: .debdiff are available! :)
<CodeGnome> infinity: You still need to get sponsored to do NMUs, though, don't you? I had a very, very frustrating experience with that a few years back, and haven't bothered with Debian upstream packaging since.
<infinity> CodeGnome: Sponsored in Debian, or sponsored in Ubuntu, causing Ubuntu to carry a painful diff (or just offloading the work on Ubuntu devs to push the change back to Debian)... The former still sounds more pleasant.
<matttbe> Daviey: LP: #723994 and LP: #723995
<infinity> CodeGnome: As Colin says, we do sometimes fork packaging for either technical reasons or "bleeding edge versions", but those occasions are few, far between, and fairly carefully considered.
<Daviey> matttbe, thanks
<CodeGnome> Alright. So, for the most part, packages need to be pushed on the Debian side. Got it.
<infinity> CodeGnome: Ideally.  Exceptions to every rule and all that, but we prefer it that way.
<CodeGnome> Thanks for the help, guys.
<bdmurray> pitti: have you uploaded apport yet?  I have a change yet
<pitti> bdmurray: uploaded yes, but not accepted yet
 * pitti needs to run now, have a good night!
<Daviey> matttbe, I'm kinda confused... the debdiff for cairo-dock upstream code differs from the upstream tarball.
<Daviey> (ignoring debian/ for the moment)
<matttbe> oh
<matttbe> Daviey: yes but if I used "bzr merge-upstream" it deletes the debian directory
<matttbe> Daviey: I don't know if it's linked
<Daviey> matttbe, no.. ignore debian/ for the moment... just the upstream code
<matttbe> Daviey: I download the old version (2.2.0) with apt-get source. And I used the .dsc generated with debuild with files from my bzr branch
<Daviey> matttbe, let me try again... maybe i made an error.
<matttbe> Daviey: do I have to add some parameters next to the debdiff command?
<Daviey> no
<matttbe> This is what I did: debdiff cairo-dock-plug-ins_2.2.0~4-0ubuntu4.dsc ../build-area/cairo-dock-plug-ins_2.3.0~1-0ubuntu1.dsc > cairo-dock-plug-ins_2.2.0~4-0ubuntu4_-_2.3.0~1-0ubuntu1.debdiff
<Daviey> matttbe, okay, give me a few mins.
<matttbe> Daviey: ok thank you!
<Daviey> matttbe, http://pb.daviey.com/mQNV/raw/  the binary files are fine... but the translations and such?
<matttbe> Daviey: this file (en.po) is now a symbolic link ;)
<Daviey> Ahh!
<Daviey> matttbe, suprised the debdiff didn't represent that
<matttbe> Daviey: oh, strange
<matttbe> Daviey: it should have a symbolic link from en_GB.po to en.po
<matttbe> Daviey: but there is this line: === target is u'en_GB.po'
<matttbe> at the end of your file
<Daviey> matttbe, Okay... happy with that... regarding debian/ it looks good.  A few comments... you've added quilt as a build depends and cdbs entries for quilt and patchsys... you have made the packge source format 3.0 (quilt).. you don't need that - as you get it for free
<Daviey> matttbe, also, you have two debian/changelog entries... two of which are both UNRELEASED.... the top one is fine, as i can change that when uploading.. but the second is odd as it was never in the archive... Do you want me merge them together.. or i am happy to?
<matttbe> Daviey: so can I remove the cdbs entries for quilt?
<Daviey> matttbe,yeah
<matttbe> Daviey: yes, you can do what you want :)
<Daviey> matttbe, infact, you can drop cdbs altogther, as the only remaining one is debhelper
<matttbe> Daviey: ok, thank you for this note :)
<matttbe> Daviey: about the debian/changelog, I didn't know what to do
<Daviey> matttbe, can you ack http://pb.daviey.com/OGwB/raw/ and i'll upload it?
<matttbe> Daviey: perfect :)
<ohsix> anyone have some pointers on how to add a media player to the indicator menu that shows controls for them? is that mpris?
<ohsix> pithos is nice, i'd like to add what i can to get it to show upthere
<Daviey> matttbe, Okay, regarding the plugins... http://pb.daviey.com/TXnW/raw/  - 2.2.0~4-0ubuntu4 changelog is edited aswell?   depends - python/valac/ruby/mono all new?
<matttbe> Daviey: about the changelog, it's strange that there is a diff for this version 2.2.0~4-0ubuntu4!
<matttbe> but I don't know why
<matttbe> it's maybe because I used the version of the my previous bzr branch, sorry for that!
<matttbe> about the debian/control file, yes, python/valac/ruby/mono all new => it's to create an interface for these languages
<Daviey> matttbe, no worries... if you can give me merged updated debian/changelog for the two versions... just pastebinit... i'll put it in.
<matttbe> Daviey: ok!
<Daviey> matttbe, I am a little nervous about all the new depends, but i'll defer that to the release team.
<matttbe> Daviey: no worry, it's just a few new depends for the build process, not for the user
<Daviey> ok
<matttbe> Daviey: this is the diff http://pastebin.com/6dScE6d9 and the file: http://pastebin.com/h7dS8GRZ
<Daviey> matttbe, uploaded both
<matttbe> Daviey: many thanks!!! :)
<cjwatson> pitti: you demoted xulrunner-2.0 yesterday morning, but http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is showing it as a promotion candidate due to a build-dependency from packagekit
<chrisccoulson> cjwatson, it's an alternative build-depend
<chrisccoulson> (ie, firefox-dev | xulrunner-dev)
<chrisccoulson> oh, actually, it is "xulrunner-dev | firefox-dev"
<cjwatson> chrisccoulson: hmm, germinate wouldn't normally pick it up in that case, and yet it is ...
<cjwatson> chrisccoulson: OK.  Can we flip that?
<cjwatson> or is that ordering appropriate?
<chrisccoulson> cjwatson, it's like that to keep the packaging in sync with debian, i think
<chrisccoulson> the debian build uses xulrunner-dev
<cjwatson> it's possible that we could fix it up with an explicit seed
<cjwatson> if you'd rather keep it that way, I can experiment ...
<chrisccoulson> cjwatson, i don't mind really. comments 43 - 46 in bug 740815 explain the current implementation though
<ubottu> Launchpad bug 740815 in xulrunner-2.0 (Ubuntu) "[FFe] Updates to enable us to drop xulrunner from main" [High,Fix released] https://launchpad.net/bugs/740815
<YokoZar> Sarvatt: ok, I'll start on an update tonight
<Ampelbein> pitti: the latest apport fails to install here with http://paste.ubuntu.com/596662/ but I can't see what is wrong. any hints on debugging that?
<smoser> what shoudl i build-depend on to use dh --with python2 ?
<Ampelbein> smoser: I think dh_python2 is integrated in the python package
<sladen> pitti: Seen this before?  1k/2k550 Changes file must be signed with a valid GPG signature: Verification failed 3 times: ["(7, 9, u'No public key')", "(7, 9, u'No public key')", "(7, 9, u'No public key')"] : Permission denied.
<sladen> pitti: (the signature is valid)
<smoser> Ampelbein, thanks.
<Laney> sladen: is that at dput time? I think that's a Launchpad issue if so
<sladen> Laney: filed as https://bugs.launchpad.net/launchpad/+bug/767595
<ubottu> Ubuntu bug 767595 in Launchpad itself "Soyuz FTP .changes signature verification complains about valid sigs" [Undecided,New]
<cjwatson> sladen: we've been having this for some days
<cjwatson> sladen: lifeless knows about it
<Laney> yeah it's definitely a known issue
<Quintasan> https://lists.ubuntu.com/archives/sounder/2004-August/000000.html
<Quintasan> :D
<sladen> Quintasan: a lesson in how First Post! might land you a job
<Quintasan> sladen: ha ha, as if :D
<cjwatson> dashua: FYI, the light-themes rejects you may get by mail were just for the duplicates in the queue (see discussion of Launchpad bug above); I'm letting somebody with more desktop experience do the actual review
<broder> hmm...would it be difficult to pre-populate natty-{security,updates} pockets on ddebs.u.c? do-release-upgrade got unhappy at me for having maverick-* in my sources.list
<stgraber> pitti: apparently apport doesn't like being disabled :)
<stgraber> pitti: its init script now fails and blocks the update. Setting it back to enabled manually unblock the update process.
<cjwatson> bug 767498
<ubottu> Launchpad bug 767498 in apport (Ubuntu Natty) "package apport 1.20.1-0ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Critical,Confirmed] https://launchpad.net/bugs/767498
 * highvoltage wonders if cjwatson knew that bug number without having to look it up
<cjwatson> no
<kees> is the change in dh_installinit expected?
<stgraber> I'm wondering if we shouldn't just make pre-start work in all cases and just do nothing if apport is disabled ? not sure what the old behavior was though
<kees> or should apport's pre-start be changed to exit 0 when ! $enabled ?
<SEJeff_work> is there a ppa with gtk3 for maverick?
<SEJeff_work> So I can build some gtk3 apps on maverick without resorting to jhbuild
<cjwatson> stgraber,kees: or perhaps --error-handler=true ...
<kees> cjwatson: yeah, that might be the better approach, since "start" really should fail if it's disabled, imo
<cjwatson> kees: IIRC, it might need to be '|| { stop; exit 0; }' or some such, if we were going for exit 0
<cjwatson> though I'd have to check - error-handler is simpler
<stgraber> yeah, I guess it makes sense for start to fail when the service is disabled as it didn't start :)
<cjwatson> does one of you want to take care of this, or should I?
<cjwatson> if somebody else does, I can accept it through the queue :-)
<stgraber> I can do it
<ScottK> pitti: Are you aware of problems with the latest apport update:
<ScottK> Setting up apport (1.20.1-0ubuntu3) ...
<ScottK> start: Job failed to start
<bdmurray> ScottK: its being fixed
<ScottK> bdmurray: Thanks.
<superm1> ScottK, for now if you enable apport in /etc/default/apport and then apt-get -f install it's fine
<ScottK> superm1: Thanks.
<barry> hi all.  is there still time, and are any sponsors available for a no-change rebuild to eliminate a mod_python error log message?
<Sweetshark> good evening! reporting in to receive a good slapping for bug 740815.
<ubottu> Launchpad bug 740815 in xulrunner-2.0 (Ubuntu) "[FFe] Updates to enable us to drop xulrunner from main" [High,Fix released] https://launchpad.net/bugs/740815
<Sweetshark> anyone having an idea why "xulrunner-dev | firefox-dev" in libreoffice/libreoffice-l10n does not get me on the component-mismatches page?
<Sweetshark> cjwatson: ^^
<cjwatson> Sweetshark: it probably depends on which seed germinate happens to encounter your package in - if it encounters it in a context where some other package has already pulled in firefox-dev, then it will use that
<cjwatson> alternative build-dependencies are unstable if they aren't consistent
<cjwatson> packagekit is a transitive build-dependency of some very low-level stuff - it gets pulled in while trying to expand the build-dependency tree of the kernel
<cjwatson> I wouldn't expect that libreoffice is in that situation
 * Sweetshark mumbles: no, its at the end of the foodchain and rather stumbles over surprise changes in packages below it ;)
<Sweetshark> cjwatson: would you say it is critical to change the build-dep order for the release?
<cjwatson> Sweetshark: not for LO, no
<Sweetshark> cjwatson: I just looked in the buildlog and it is indeed using firefox-dev ....
<Sweetshark> cjwatson: good, thanks.
<bdmurray> stgraber: there are still some apport bugs coming in with that new package version bug 767790
<ubottu> Launchpad bug 767790 in apport (Ubuntu) "package apport 1.20.1-0ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/767790
<bdmurray> kees: any ideas?
<bdmurray> oh, that's still the old one - my bad
<Andy80> hi all
#ubuntu-devel 2011-04-21
<matttbe> stgraber, kees: it seems that the apport bug is not fixed => http://pastebin.com/BXMyNmJR
<matttbe> or https://bugs.launchpad.net/ubuntu/+source/apport/+bug/767829
<ubottu> Ubuntu bug 767829 in apport (Ubuntu) "package apport 1.20.1-0ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New]
<ScottK> Apport upgrade still failing with the new one.
<ScottK> Setting up apport (1.20.1-0ubuntu4) ...
<ScottK> start: Job failed to start
<ScottK> invoke-rc.d: initscript apport, action "start" failed.
<ScottK> dpkg: error processing apport (--configure):
<ScottK>  subprocess installed post-installation script returned error exit status 1
<ScottK> (I did not manually fix the problem with ubuntu3)
<ScottK> stgraber: ^^^
<kees> hm, yeah, build log shows the wrong dh_installinit invocation
<kees> dh_installinit -papport  "true"
<cjwatson> hmph, I should have caught that
<cjwatson> getting tired
<kees> DEB_DH_INSTALLINIT_ARGS="--error-handler=true"   iiuc
<kees> (is what it should be?)
<kees> cjwatson: shall I fix it?
<cjwatson> please.  and drop the spurious quotes while you're at it
<kees> yuppers
<sladen> cjwatson: +1 for spotting the %ss <-> %sp
<cjwatson> thanks.  quite pleased with finding that. :)
<poolie> can i do anything to escalate https://bugs.launchpad.net/bugs/749817 ?
<ubottu> Ubuntu bug 749817 in xserver-xorg-video-intel (Ubuntu) "natty regression: screen goes black when external monitor is connected" [High,Confirmed]
<poolie> for people with thinkpads (and it seems to affect many of them) it's a fairly serious regression
<lifeless> raof was talking about that in #ubuntu-desktop before
<RAOF> poolie: And bryceh was organising some kernels to test.
<poolie> well, if you want testers, just ping me
<poolie> if you were still in sydney i would lend you my laptop if that helped
<stgraber> cjwatson, ScottK: doh, my bad, I did some test outside the branch, then applied manually to the branch ... Seems like I forgot --error-handler ...
<stgraber> sorry for that
<ScottK> It happens.
<ScottK> kees: Fixed apport accepted.
<ScottK> stgraber: ^^^
<bryceh> poolie, yep, I have some things for you to test.
<stgraber> ScottK: thanks
<stgraber> kees: and thanks for uploading the fix I meant to upload ;) /me should stop trusting memory and believe more in "cp" instead
<poolie> bryceh, sure just ask
<poolie> is there any current plan or forecast on when ubuntu will drop python 2.x?
<bryceh> poolie, is your system arrandale graphics?
<bryceh> yep it is
<bryceh> poolie, ok I recognize the bug
<bryceh> poolie, alright check your bug; I posted two things I'm having people with these bugs test.
<poolie> don't see anything yet...
<kees> stgraber: cool, no worries
<bdmurray> apport still doesn't seem well bug 767997
<ubottu> Launchpad bug 767997 in apport (Ubuntu) "package apport 1.20.1-0ubuntu5 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/767997
<poolie> bryceh: i'm happy to say that kernel seems to have fixed it
<ScottK> poolie: Not for a long time.
<ohsix> grr is the drag & drop problems w/compiz going to be rectified, happens sometimes, other times not
<ScottK> ohsix: #ubuntu-desktop is probably a better place to find people who would know the answer to that.
<ScottK> kees: That worked (apport).  Thanks.
<ohsix> it was mostly rhetorical, i'm amending the one bug i did report; as i've pretty much isolated it to compiz
<YokoZar> hmm, dpkg installation error of apport package...I wonder if reporting it will generate a some sort of logical black hole
<ScottK> YokoZar: Fixed. Wait for an update on a mirror near you.
<YokoZar> Indeed.  Still it does pose a logical quandry.
<ScottK> Agreed.
<ScottK> My question to my wife tonight was, "Want to hear some computer related irony?"
<ohsix> YokoZar: that was something in the post-install script about failure starting, it just moved from enabled=1 in /etc/default/apport before that update, i just enabled it again to get it to installed; but a new package has been uploaded already that properly ignores startup failure
<stgraber> YokoZar: well, I found it even funnier as the specific update was meant to turn it off :) Instead it got triggered on anyone who upgraded to that version.
<ohsix> that was cute, yea
<ohsix> how did it update my changes in /etc/default anyways; i always have it enabled, i thought that was one of the config protect directories, does one of the hooks just force change it?
<cjwatson> ohsix: if you haven't changed the conffile locally, package changes to it are applied automatically
<ohsix> cjwatson: but i had, i had enabled=1 in there before i upgraded to natty alpha
<jubei> hello :) Not sure if this is the right place to be asking. I've already asked in Eclipse to no avail. I'm trying to write C++0x on linux with Eclipse CDT. I want to use std::unique_pointer and even though gcc compiles it fine, I don't get normal auto-complete when i do std:: ... it only gives me the old std classes/templates. Any ideas on how to pursue this?
<steveire> What's the bzr equivalent of git pull ?
<lifeless> bzr pull
<steveire> thanks
<pitti> good morning
<pitti> cjwatson: xulrunner> yeah, same problem as with openjade, it's a preferred alternative build dep in universe
<RAOF> Of course, bzr pull is not a complete equivalent for git pull; git does madness on pull, wheras bzr just does what you'd expect :)
<pitti> Ampelbein: presumably this has been fixed by kees' latest upload?
<pitti> stgraber, ScottK: ^
<ScottK> Yes.
<ScottK> It fixed it for me.
<pitti> kees: thanks
<didrocks> good morning
<ohsix> RAOF: separate fast forward?
<RAOF> ohsix: Well, it'll pull other changes to other branches from the same remote (but not apply them), and it'll perform a merge if you're not careful :)
<YokoZar> so were we calling this beta 3, release candidate, or neither?
<pitti> YokoZar: we call it "natty"?
<pitti> like, in the final?
<YokoZar> I'm trying to make sense of "Release Quality Iteration" on the schedule
<YokoZar> https://wiki.ubuntu.com/NattyReleaseSchedule
<bryceh> pitti, btw when do the apport hooks get disabled?  Right at release or shortly before?
<pitti> it means that today we should have buildable images without inconsistencies, and keep it that way until final
<pitti> bryceh: crash reports got disabled with the upload from yesterday
<bryceh> pitti, ah ok
<pitti> bryceh: but that only affects signal and python crashes; I believe teh package install failures continue to happen
<bryceh> pitti, does that include the apport-gpu-freeze hook?
<pitti> bryceh: I'm not actually sure about the GPU freezes
<bryceh> pitti, ok, please flip that off whenever it's convenient
<pitti> the udev rule doesn't
<bryceh> I was still getting new ones filed today (at least, as of several hours ago)
<pitti> bryceh: ah, the hook checks
<pitti>     if not packaging.enabled():
<pitti>         return -1
<pitti> bryceh: presumably because not everyone upgraded yet?
<bryceh> oh maybe, yeah
<pitti> so it sohuld be disabled now
<bryceh> ok great
<YokoZar> slangasek: ia32-libs contains some of the packages that are in krb5, which was just updated to be a multiarch thing.  How to proceed?
<slangasek> YokoZar: how do you mean, "just updated"? krb5 was part of my initial batch
<YokoZar> oh it seems it was a security team update nm
<YokoZar> still fetch and build is complaining about an unavailable version, which it usually only does when an upload was recent and source/binary differ in the archive
<ohsix> http://blog.kevinmehall.net/2010/bringing_pin_tab_to_wnck wow that's a great idea
 * pitti revives the 6 died armel buildds; be team players!
<Sweetshark> pitti: have they been exhausted by the load?
<pitti> annonaceae keeps failing, but it seems the others are on duty again
<pitti> Sweetshark: lamont didn't feed the hamsters enough :)
<Sweetshark> pitti: ohh, thats just mean!
<ScottK> YokoZar: krb5 was uploaded to -security.
<YokoZar> ScottK: it's strange because the apt in ia32-libs fetch-and-build script is returning " E: Ignore unavailable version '1.8.3+dfsg-5ubuntu2.1' of package "  but I can apt-get source that easily
<ScottK> Does it look in all pockets?
<YokoZar> main/universe, natty natty-updates natty-security
<ScottK> OK.
<dholbach> good morning
<ScottK> No idea then.
<YokoZar> http://pastebin.ubuntu.com/596813/
<ScottK> It looks like it's fetching krb5
<ScottK> Fetching source krb5 1.8.3+dfsg-5ubuntu2 for libkrb5-3
<YokoZar> oh wait a minute
<ScottK> It claims unavailable at the end though
<ScottK> Dunno.  Need to crash.  Good luck.
<YokoZar> Thanks for thinking on it, good night
<YokoZar> ScottK: ah hah, figured it out.  Turns out the "sort" command does not think that 2.1 > 2, but apt ordering does.
<YokoZar> I think
<YokoZar> Actually nevermind we may have another edge case bug in apt...
<YokoZar> apt-get -d source krb5=1.8.3+dfsg-5ubuntu2 krb5=1.8.3+dfsg-5ubuntu2.1
<YokoZar> both commands work individually
<abhinav-> I am not able to upgrade to natty using the latest live iso, bug 768105 :-/
<ubottu> Launchpad bug 768105 in ubiquity (Ubuntu) "Not able to install using the latest Live CD" [Undecided,New] https://launchpad.net/bugs/768105
<cjwatson> abhinav-: thanks
<abhinav-> cjwatson: :)
<cjwatson> Daviey: any word on reproducing bug 728088?
<ubottu> Launchpad bug 728088 in debian-installer (Ubuntu Natty) "iscsi root with or without auth fails to boot" [High,Confirmed] https://launchpad.net/bugs/728088
 * abhinav- is puzzled on receiving an email saying that his translations have been imported for tomboy, though he didn't do any translations  
<seb128> you did an upload probably
<seb128> or got an update of your sponsored
<seb128> launchpad import translations from uploaded sources so you get those with uploads
<tjaalton> will universe freeze too? VDR is totally broken since 1.7.17 was synced from debian, since all the plugins need a rebuild, and it's best to sync them too from debian
<abhinav-> seb128: I did propose a patch for merging, pitti merged it manually
<seb128> abhinav-, your name is in the changelog for the upload that's why
<micahg> tjaalton: unseeded stuff can still be sync'd until monday I think
<abhinav-> seb128: oh thanks for clearing it up :)
<iulian> tjaalton: We still have time.  Please file some bugs and subscribe ubuntu-release.  You can also let me know when you've done that so I can take a look.
<tjaalton> micahg: good, I'll file sync requests then
<abhinav-> that's nice, I get more karma :)
<tjaalton> iulian: yeah, thanks
<micahg> tjaalton: you can use -e with requestsync if you need an ubuntu-release ACK
<Daviey> cjwatson: Sorry, missed the hilight.  I started doing this on tuesday, but seemed to have an unrelated issue with iscsi target.. I haven't dropped it, and will pick it back up today.  Sorry for the slow update.
<cjwatson> Daviey: no problem, thanks - just checking up since skaet was asking me about it
<Daviey> cjwatson: When you attempted to reproduce it, were you PXE booting or using local media?
<cjwatson> Daviey: hm, I think local
<cjwatson> only for the kernel and initrd though, which I wouldn't have expected to matter
<Daviey> It /shouldn't/ be related, but that is a difference i will explore.
<cjwatson> I think I did kvm -kernel -initrd -append
<cjwatson> (etc.)
<Daviey> ahh
<tjaalton> micahg: yeah, filing them now
<tjaalton> looks like the autosyncer didn't work properly, since some of these plugins have had releases that during the sync-period that didn't get synced
<micahg> tjaalton: does ubuntu have a diff on any of them?  that would prevent them from being sync'd (BTW, auto import ended 30 Dec)
<tjaalton> micahg: no, they were synced during maverick
<cjwatson> what packages are these?
<tjaalton> most of these only got a release for the new vdr version
<cjwatson> some packages are blacklisted from autosyncing for one reason or another
<tjaalton> cjwatson: let me check
<tjaalton> vdr-plugin-osdteletext for one
<tjaalton> _if_ the debian changelog is to be trusted
<tjaalton> it could be that they weren't actually uploaded there, but to the e-tobi.net repository
<tjaalton> hmm though they tend to use a different suffix then
<micahg> tjaalton: http://packages.qa.debian.org/v/vdr-plugin-osdteletext.html, no upload until 2011-04-11
<tjaalton> micahg: right, sorry for the noise :)
<micahg> tjaalton: no problem, better to ask to be sure :)
<tjaalton> 24 plugins in total, halfway through filing the bugs..
<chrisccoulson> jam - there?
<doko> ScottK: does boost-1.46 build with GCC-4.6?
<pitti> tjaalton: ugh, a single bug with several task would have been easier..
<ogra_> dholbach, my calendar shows i'm sponsoring next monday, shouldnt we postpone all sponsoring for that week, since the archive will be hard locked ?
<ogra_> (i know i can do stuff without uploading, but it feels kind of pointless wiht a locked down archive)
<dholbach> ogra_, we can still do SRU stuff or just review patches and upload them later or forward upstream - there's always something to do :)
<ogra_> hmm,k
<wolfe> what's SRU?
<wolfe> I don't think it means Strategic Response Unit :P
<dholbach> https://wiki.ubuntu.com/SRU
<wolfe> ah okay :) I've done one of those for ubuntu before, I thought the acronym sounded familiar
<wolfe> :( now it makes me curious, I haven't tried python-fam in the latest ubuntu, that broken code better not have reverted
 * wolfe dislikes segfaulting python interpreters
<wolfe> *scripts/programs
<wolfe> oh bloody hell
<tjaalton> pitti: yeah, well this way you get to see the changelog diffs :)
<wolfe> that maintainer never updated the code, it is an abandoned project. I bet python-fam in Ubuntu is broken in the latest release
<jam> chrisccoulson: I'm here now
<chrisccoulson> jam, i reported bug 752919 a few weeks ago, and that got marked a duplicate of a bug which is fix released (which you are assigned too)
<ubottu> Launchpad bug 752919 in bzr (Ubuntu) "bzr crashed with ErrorFromSmartServer in _translate_error(): Error received from smart server: ('error', "We are missing inventories for revisions: [StaticTuple('chrisccoulson@ubuntu.com-20110203185933-58z7mrqg0t5goswt',)]") (dup-of: 437003)" [Undecided,New] https://launchpad.net/bugs/752919
<ubottu> Launchpad bug 437003 in Bazaar "Failure to autopack because of 'missing inventories'" [Critical,Fix released] https://launchpad.net/bugs/437003
<chrisccoulson> i'm just wondering if there's anything i can do, because i'm committing a lot of stuff to this branch locally, but i can't push it launchpad :(
<jam> chrisccoulson: 2 things
<jam> 1) upgrade your bzr
<jam> 2) run 'bzr pack'
<chrisccoulson> jam, what version do i need to upgrade too?
<jam> the latter will find all the "missing" inventories and put them back together with their associated other content
<jam> (it actually puts everything into 1 file so it is always together)
<jam> chrisccoulson: according to the tracker, the fix is present in bzr-2.1.4, 2.2.5, and probably 2.0.7, 2.3.1/2 and 2.4b1. I'm not sure what has gone through final packaging.
<jam> I know 2.4b1 is available in the ppa
<jam> and probably 2.3.1
<chrisccoulson> ok, i'm running 2.3.1 currently
<jam> hmmm. Its listed as being fixed in 2.3.1, let me check
<jam> chrisccoulson: ahh!!
<jam> *launchpad* is running bzr-2.2
<jam> and doesn't have the fix
<jam> so you have to run "bzr pack lp:..."
<chrisccoulson> oh, bzr pack seemed to work :)
<jam> until Launchpad itself upgrades the server version of bzr
<chrisccoulson> yay, it worked (http://bazaar.launchpad.net/~extension-hackers/globalmenu-extension/trunk/revision/145)
<chrisccoulson> jam, thanks! :)
<\sh> micahg, ping ZF...if you want, please take care of ZF while I'm on holiday for the next 6 weeks :) thx :)
<bdrung_> doko: can you help us with an objcopy question / behaviour / bug?
<bdrung_> doko: git clone git://git.debian.org/lintian/lintian.git
<bdrung_> doko: then run debian/rules runtests onlyrun=binaries-general
<bdrung_> file debian/tests/binaries-general/binaries-general-1.0/basic returns ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
<bdrung_> the makefile calls objcopy --only-keep-debug basic $(DESTDIR)/usr/lib/debug/basic
<bdrung_> file debian/tests/binaries-general/binaries-general-1.0/debian/binaries-general/usr/lib/debug/basic returns ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
<bdrung_> doko: why does the library change from dynamically linked to statically linked?
<barry> ev, cjwatson probably too late to do anything about it right now, but someone forwarded me a ubiquity failure on samsung series 9: bug 766740
<ubottu> Launchpad bug 766740 in ubiquity (Ubuntu) "GrubInstaller failed with code 1" [Undecided,New] https://launchpad.net/bugs/766740
<cjwatson> barry: conveniently without any useful logs
<barry> yeah ;)
<cjwatson> (I've asked)
<cjwatson> barry: I notice that he's using GPT, so it's possible that he's also using EFI in which case it's bug 765270 (fixed)
<ubottu> Launchpad bug 765270 in grub-installer (Ubuntu Natty) "grub-installer fails to remove grub-pc when installing on EFI systems" [High,Fix released] https://launchpad.net/bugs/765270
<cjwatson> well, fixed in tomorrow's dailies anyway
<barry> cjwatson: thanks, i'll forward that to him
<ogra_> looking at bug 747229 ... is it even an oem-config UI i see there or is that just a debconf mode of aptd ?
<ubottu> Launchpad bug 747229 in ubiquity (Ubuntu Natty) "weird color change during oem-config debconf package removal step in serial installs" [Medium,Incomplete] https://launchpad.net/bugs/747229
<cjwatson> ogra_: it's oem-config
<ogra_> (in the graphical oem-config it looks like aptd)
<ogra_> k
<ScottK> doko: I didn't try to build it.
<mterry> jcastro, does the naming scheme for oneiric blueprints no longer prefix the track type (like appdev or whatnot)?
<jcastro> mterry: it does the tracknames are just back to normal
<jcastro> mterry: you'd be desktop-o-dejadup
<mterry> jcastro, OK.  Yeah, the deja dup one was made already, but now looking at quickly.  Quickly had a natty one too, but I assume since the -n- or -o- is part of the name, I should make new blueprint rather than rename the old one?
<jcastro> mterry: it's up to you, I prefer to just rename
<bdmurray> pitti: I wrote a bug pattern for bug 767829 and it works with test-local on the bug and a duplicate that got through (bug 768261)
<ubottu> Launchpad bug 767829 in apport (Ubuntu) "package apport 1.20.1-0ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Fix released] https://launchpad.net/bugs/767829
<ubottu> Launchpad bug 768261 in apport (Ubuntu) "package apport 1.20.1-0ubuntu4 failed to install/upgrade: el subproceso instalado el script post-installation devolviÃ³ el cÃ³digo de salida de error 1" [Undecided,New] https://launchpad.net/bugs/768261
<pitti> bdmurray: oh, thanks
<bdmurray> pitti: I'm curious why the duplicate got through even though there is a pattern
<pitti> bdmurray: oh, you mean it came through after you wrote it?
<bdmurray> pitti: yeah
<pitti> hm, it looks good from here
<pitti> it's also on people.c.c.
<bdmurray> pitti: could it be related to bug 766516?  would maverick apport check for patterns named after the package?
<ubottu> Launchpad bug 766516 in apport (Ubuntu) "no longer possible to write bug patterns on a release before Natty" [Undecided,New] https://launchpad.net/bugs/766516
<pitti> bdmurray: yes, it would
<pitti> but the bug didn't affect maverick in the first place
<bdmurray> pitti: but if they were in the process of a dist upgrade?
<pitti> bdmurray: that would work, yes
<pitti> "work" -> cause this
<ScottK> Does the desktop-file-utils in queue affect systems where software center isn't installed?
<bdmurray> he first example wasn't a dist-upgrade but bug 768125 is
<ubottu> Launchpad bug 768125 in apport (Ubuntu) "package apport 1.20.1-0ubuntu4 failed to install/upgrade: ErrorMessage: underprocess installerade post-installation-skript gav felkod 1" [Undecided,New] https://launchpad.net/bugs/768125
<bdmurray> that one wouldn't match though because the attachment name is different though
<bdmurray> pitti: I see you've cleaned up the dupes.  Is it a good idea to expand the bug pattern?
<pitti> bdmurray: I didn't really go through them all; I just duped all package failures that came in in the last 24 hours
<pitti> bdmurray: I think it'll quickly fade down now, but if we get many more, we might expand it, yes
<bdmurray> pitti: okay, thanks. maverick not using bugpatterns.xml isn't going to create that many additional bugs I think.  What do you think?
<pitti> bdmurray: right; I think bug patterns are very short-lived
<pitti> and in fact it probably would make sense to clean up patterns for bugs which were fixed more than, say, a month ago, to avoid false positives
<bdmurray> I wish patterns were automatically or semi-automatically written too
<pitti> we really need a more generic way of extracting the gist out of an apt log, then we could use the auto-duper
<abhinav-> when will ubiquity 2.6.7 make to the daily iso , today's ISO also had 2.6.6 ?
<ev> abhinav-: the next daily live will have ubiquity 2.6.7
<ev> either tonight or tomorrow morning
<cjwatson> well, 2.6.8 :)
<abhinav-> ev: oh great, I am eagerly waiting to upgrade :)
<ev> err yes, 2.6.8
<ev> :)
<smoser> anyone know how i would configure firefox's home page for a new user ?
<tumbleweed> smoser: you mean how you would configure it for all users? or just a programmatic way to change it for one user?
<smoser> either woudl be suitable for this.
<smoser> user is brand new, no .mozilla directory
<tumbleweed> smoser: add something like pref("browser.startup.homepage", "file:/etc/firefox-homepage.properties"); to /etc/firefox-$VER/pref/ubufox.js
<tumbleweed> then put browser.startup.homepage=http://foo.bar in that file
<tumbleweed> (at least that's how we did it in ff 3.x)
<LLStarks> spamaps, if i've lost VT access, would upstart be to blame?
<SpamapS> LLStarks: probably not. When you say lost it, alt-F1 doesn't give you a getty?
<SpamapS> LLStarks: I tend to blame plymouth first. ;)
<SpamapS> because I understand it less
<LLStarks> spamaps: no. and neither does recovery console.
<SpamapS> LLStarks: have you tried booting with 'quiet' removed, and '--verbose'  on the kernel cmdline ?
<LLStarks> i can try. i also have bootcharts at the ready.
<smoser> tumbleweed, hm... http://paste.ubuntu.com/597036/ like that ?
<LLStarks> brb.
<ScottK> Someone else was complaining about lost VTs recently.
<ScottK> I don't recall who.
<TeTeT> smoser: should work, I can send you a hook file for this on custom builds, if needed
<SpamapS> ScottK: I reproduced the opendkim thing *FINALLY*
<ScottK> SpamapS: Cool.
<smoser> TeTeT, doesn't seem to work for me.
<SpamapS> ScottK: had to add ssh key and sudo NOPASSWD: ALL to make it break
<ScottK> Lovely.
<SpamapS> definitely a race between the parent exitting and setsid()
<smoser> for that user i had already ran firefox, but then i did 'rm -Rf ~/.mozilla'
<SpamapS> ScottK: so I may have a tiny patch :)
<ScottK> Nice.
<ScottK> Fortunately it's Universe so we have a few days for a fix yet.
<LLStarks> yeah, still no VT. it might be related to the fact that a recovery boot will never finish. it'll just halt after loading bluetooth and usb
<LLStarks> or something like that
<SpamapS> LLStarks: try 'nosplash' too
<LLStarks> isn't nosplash inherent to recovery boot?
<LLStarks> whatever. brb again.
<cjwatson> SpamapS: what do you believe implements nosplash?
<SpamapS> cjwatson: I don't actually know. :)
<cjwatson> (hint: nothing)
<cjwatson> usplash used to ...
<SpamapS> I am mostly fishing for something I'm familiar with outside of upstart.
<SpamapS> because I don't know of anything in upstart that would cause vt's to go away... unless the getty's aren't starting for some reason
<cjwatson> recovery mode options on the kernel command line automatically cause plymouth to go into details mode, much as LLStarks suggests
<cjwatson> (src/main.c:plymouth_should_show_default_splash)
<SpamapS> but yeah I don't know *anything* about how recovery console is implemented. :-P
<LLStarks> still nothing with nosplash. i am running a custom plymouth, but also affects a fresh install.
<SpamapS> LLStarks: did this just start today?
<LLStarks> spamaps, no. this has been around since at least the start of the natty cycle.
<LLStarks> well, maybe the beginning, but at least a few months.
<LLStarks> *maybe not
<SpamapS> whats your graphics hardware?
<LLStarks> i945gm
<LLStarks> i'd file a bug, but i'm not sure what package applies
<LLStarks> os[Linux 2.6.38-8-generic i686] distro[Ubuntu "natty" 11.04] cpu[2 x Genuine Intel(R) CPU           T2050  @ 1.60GHz (GenuineIntel) @ 1.60GHz] mem[Physical: 2.0GB, 74.4% free] disk[Total: 115.2GB, 16.2% free] video[Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller] sound[HDA-Intel - HDA Intel]
<JFo> LLStarks, file against linux with the lower case L
<JFo> should send you my way
<LLStarks> jfo, i can understand the loss of vt for an X boot, but would that also explain how a recovery boot doesn't even reach the recovery menu?
<JFo> something odd afoot for sure
<LLStarks> jfo: bug 768452
<ubottu> Launchpad bug 768452 in linux (Ubuntu) "Loss of VT and recovery menu" [Undecided,New] https://launchpad.net/bugs/768452
<JFo> danke
 * JFo goes to look
<cjwatson> blueyed,mvo: this late zsh upload added a new build-dependency on yodl, which isn't in main
<cjwatson> blueyed,mvo: I'm not convinced there's time to get yodl and icmake MIRed and promoted.  Can it please be excised?
<cjwatson> (http://people.canonical.com/~ubuntu-archive/component-mismatches.txt)
<SpamapS> ScottK: so with opendkim, moving setsid() before closing/duping the FDs didn't work.. trying some more drastic things.
<ScottK> Thanks.
<SpamapS> ScottK: definitely an interesting problem. I can reproduce 100% of the time now
<ScottK> It's probably worth an email to the opendkim list saying you've reproduced it and are investigating.
<ScottK> Cool.
<ScottK> Please remember not to break BSD with your fix since that's upstream's native platform.
<SpamapS> ScottK: I'll try it out on my netbsd VM :)
<ScottK> :-)
<SpamapS> I keep one around for testing libedit's complete and utter brokenness on Linux
<pitti> cjwatson, mvo, blueyed: ok for me to just upload a reverted zsh?
<cjwatson> pitti: I don't have a problem with it, but would be good for one of the uploaders to reply
<pitti> I know, but it's getting tight
<pitti> cjwatson: I'll prepare one and upload, then we have it in the queue
 * cjwatson nods
<cjwatson> I'm away as of now, though
<pitti> cjwatson: enjoy the Easter weekend!
<cjwatson> you too :)
<mvo> pitti: sorry, sorry, I should have looked close, I have no personal attachment to this, feel free to revert
<Cas07> i have a question about backporting a pygtk patch for ubuntu
<Cas07> https://bugs.launchpad.net/bugs/708847
<ubottu> Ubuntu bug 708847 in pygtk (Ubuntu) "Unreasonable CPU usage after receiving signal" [Undecided,New]
<ScottK> !ask | Cas07
<ubottu> Cas07: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<bryceh> is there a python module to do the equivalent of apt-cache show %s | grep ^Source ?
<Cas07> ok I am wondering who can help get the recent pygtk patch http://git.gnome.org/browse/pygtk/commit/?id=4cbd3 backported to the ubuntu releases as the pygtks devs do not patch old versions. https://bugs.launchpad.net/bugs/708847
<pitti> bryceh: python-apt can do that quite nicely
<ubottu> Ubuntu bug 708847 in pygtk (Ubuntu) "Unreasonable CPU usage after receiving signal" [Undecided,New]
<bryceh> pitti, thanks
<pitti> bryceh: import apt
<pitti> apt.Cache()['mypkg'].candidate.source_name
<bryceh> nice
<pitti> you need to do some error checking of course, candidate might be None
<pitti> you can also use "installed" for the installed version (if it is installed)
<pitti> but I guess for your case candidate is better
<bryceh> yep
<micahg> SpamapS: are you available for an SRU review?
<SpamapS> micahg: Sure
<micahg> SpamapS: bug 767966, I need to know if it's ok to push with the next round of security updates
<ubottu> Launchpad bug 767966 in thunderbird (Ubuntu Natty) "globalmenu extension pollutes main window javascript scope" [High,Fix committed] https://launchpad.net/bugs/767966
<LLStarks> jfo, need any additional info about my machine?
<SpamapS> micahg: reading
<SpamapS> micahg: I'm somewhat confused by the bug statuses .. what exactly do you want me to look for?
<SpamapS> micahg: I see no test case, and I don't see it confirmed in any release.. just Fix Committed
 * SpamapS goes afk for 5-10 min
<micahg> SpamapS: ignore the statuses, I need to know if the change would be approved for an SRU and if I can include it in a security update given that I'll be running through regression tests for Firefox and Thunderbird
<maco> geser, stgraber, cody-somerville, Laney, bdrung_:  it's been a week.
<cody-somerville> maco, since last Friday? :)
<cody-somerville> oh my
<cody-somerville> Its Thursday, not Friday.
<maco> cody-somerville: the emails were sent on the 14th...it's the 21st
<stgraber> maco: I'm sitting next to cyphermox and we talked quite a bit last night so I don't have any question for him :) And I'm happy with the question that have been asked to Sylvestre, would just like to see some answers ...
<cody-somerville> maco, which e-mails? Sorry, you'll have to jot my memory. I just got my wisdom teeth removed last evening. Pain meds have me a little out of it.
<cyphermox> stgraber, you pang?
<stgraber> oh hey cyphermox, long time no see
<maco> cody-somerville: the 2 motu applications and 1 core dev application we're processing by email
<maco> cody-somerville: today's the last day to pester them with questions, then we spend the weekend thinking & voting
<stgraber> I'd also like to see RAOF answering Laney's questions (unless he did and that never made it to devel-permissions).
<stgraber> so I'm fine voting on cyphermox's application as he answered all the questions that have been asked on the ML (AFAICS) but would rather wait for the two others
<maco> RAOF: ping. answer questions on email ;-)
<maco> and sylvestre isn't an irc person, so more pinging than the 3 emails in his inbox won't help
<maco> i'm fine voting on cyphermox's too
<SpamapS> micahg: the one red flag I have is that while polluting the global namespace is evil, if we do release w/ it this way, and people depend on that, then we change it.. we break those that depend on the behavior.
<SpamapS> micahg: that said, thats in the "regression potential == LOW" category..
<SpamapS> micahg: so yeah, I think I'd approve it through to -proposed
<micahg> SpamapS: I don't think anyone would be depending on that behavior, also it's already been fixed "upstream"
<micahg> SpamapS: do you approve it for me to include in the next security update?
<SpamapS> micahg: Hrm.. I was evaluating it from the stand point of having it sit in -proposed for 7 days..
<SpamapS> micahg: but you guys do testing probably twice as rigorous as -proposed -> -updates requires
<SpamapS> micahg: so yes!
<micahg> SpamapS: thanks!, I'll make sure we start testing the global menu with natty as well :)
<micahg> SpamapS: could you please note that in the bug?
<SpamapS> micahg: done
 * SpamapS will now go for his first ever bike ride on the insane streets of Los Angeles.. wish me luck
<micahg> SpamapS: thanks!
<soren> SpamapS: It was nice knowing you.
 * SpamapS still hasn't left due to the safety precautions he's reading about last minute
<charlie-tca> Good luck and have fun, SpamapS
<lamont> why would I have 187 irqbalance processes on a machine?
<charlie-tca> I used to ride on the strip in Las Vegas
<lamont> does it just want to be REALLY REALLY balanced?
<soren> lamont: Do you have 187 cores?
<lamont> 2.  I have 2 cores.
<soren> lamont: Then I don't know.
<soren> :p
<lamont> I am a powermac running 2.6.35 on a lucid user base
<lamont> IBM XServe, to be precise
<lamont> I suspect that everytime udev gets installed in the livecd build, we get a new irqbalance process
<lamont> soren: and thanks for the laugh
 * soren tips his hat
 * slangasek grins
<soren> 187 would be a spectacular number of cores.
<soren> Much more so than e.g. 256.
<broder> now i want to start selling machines with prime numbers of cores or something, and have a bunch of marketing material that claims that makes the scheduling better or something
<soren> Like... 2?
<soren> That'd be something.
<soren> :p
<slangasek> I assume 187 processors is done as 17 tiles of 11-way cores
<slangasek> you know, so that it scales symmetrically
<maco> broder: pull some reasoning from http://designfestival.com/the-cicada-principle-and-why-it-matters-to-web-designers/ ?
<lamont> slangasek: heh
<lamont> in other news.... is it expected that after I type "reboot" on my laptop (inspiron N5010) that after ignoring it for a good long while, I finally use the "5 seconds of holding down the power switch" and another gentle push to complete that reboot?
<lamont> I seem to remember that command used to function without operator involvement
<maco> sounds like a bug to me
<lamont> maco: yeah.. my thinking follows that line too.  OTOH, sometimes my flair for the written word and such just gets the better of me
<lamont> soren: I think he means large primes
<lamont> .... like 3.
<soren> lamont: We'll know once we see the marketing material.
<lamont> but will we truly?
<lifeless> lamont: reboot -n
<lifeless> lamont: or was the -n implied?
<lamont> lifeless: sudo /sbin/reboot
<lifeless>        When called with --force or when in runlevel 0 or 6, this tool invokes the reboot(2) system call itself and directly reboots the system.  Otherwise this simply invokes the shutdown(8) tool with the appropriate arguments.
<lamont> the pretty cylon/kit-car thing continues sweeping, but no response to keyboard or other visible changes in the machine behavior
<lamont> lifeless: right
<lifeless> hmm, by my reading sudo /sbin/reboot
<lifeless> should be an error reporting 'no time' :)
<lamont> ??
<lamont> without args, reboot is equivalent to "reboot now"
<soren> Wow, that was *incredibly* annoying.
<lamont> soren: lifeless can be that way
<soren> I ran "sudo reboot -h" to get its help output thing.
<lamont> that's why we love him
<soren> ...and it rebooted instead.
<lamont> no, it halted
<lifeless> soren: doofus :)
<lamont> soren: awesome
<soren> lifeless: Yeah, not my brightest moment :)
<doctormo> Hey dpm, I'm trying to follow your devel app week guide for internationalization.
<lamont> soren: thank you so much for that.
<lifeless> lamont: man reboot doesn't mention now :)
<soren> lamont: For saving you from a similar fate?
<doctormo> So far I have almost everything, except I can't seem to generate a pot file from what I have.
<lifeless> lamont: and man shutdown doesn't mention the way in which reboot will call it
<lifeless> lamont: I'm sure you are correct [I'm not going to test :P] but the docs are stale/don't mention it
<lamont> soren: no, I know about reboot -h
<lamont> OTOH, I'm about done laughing
<soren> lamont: Well, thanks for sharing :(
<soren> :p
<doctormo> I think dpm might be out, so I throw the question out to anyone who can anwser. python/distutils/glade/i18n
<lamont> neat.  reboot's manpage also fails to mention -h
<lamont> ah.  hardy has -h and -n and a few other options described.  lucid and natty do not
<maco> haha halt is a symlink to reboot
<lamont> yep
<smoser> stgraber, ping
<Ampelbein> lamont: hardy didn't use upstart? (wild guess)
<lamont> Ampelbein: prolly
<maco> i find it funny though that "shutdown -h" and "shutdown -r" aren't just scripts calling those
<lamont> but without options, they just do what the command name seems to indicate
<stgraber> smoser: pong
<smoser> did you test bug 759545 ?
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Natty) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Fix released] https://launchpad.net/bugs/759545
<lamont> maco: used to be that reboot did just reboot(2).  then they "enhanced" it do be an alias for shutdown
<stgraber> nope, I suggested a fix but indicated I couldn't do the tests as the archive was in a bad state at the time
<stgraber> smoser: why ? still having issues with it ?
<lamont> and then there was much complaining, and reboot --force was added to get the old-n-correct behavior
<maco> lamont: its actually its own binary
<maco> lamont: i just checked, expecting a symlink and a check for the value of $0
<smoser> yeah.
<lamont> if I want to shutdown, I'll say shutdown, thank you.
<stgraber> smoser: ok, I'll have a look once my Windows XP is done installing (to test some wubi weirdness)
<smoser> stgraber, i started an instance of ubuntu-maverick-10.10-i386-server-20101225 .  Installed in the image is 1.98+20100804-5ubuntu3. then sudo update && sudo dist-upgrade.  That went fine.
<lamont> but then, I've grown tired of being pedantic about that difference
<smoser> then, sudo do-release-upgrade -d, and i got the prompt
<stgraber> smoser: can you get the md5sum and content of /etc/default/grub before the upgrade ?
<stgraber> smoser: the one I whitelisted was the one you have when you install 10.10 from the CD and then run a dist-upgrade
<smoser> yeah. http://paste.ubuntu.com/597141/ is the differences i was shown.
<stgraber> hmm, seems similar/identical to the one I whitelisted, weird ...
<tumbleweed> smoser: sorry, was out, yes looks reasonable
<smoser> didn't seem to work for me.
<stgraber> smoser: test install on its way (ubuntu 10.10 amd64 server). I'll try an upgrade from that and see if it works. If it does, then it means we have a slightly different config file on EC2 or something like that
<tumbleweed> smoser: hrm, firefox 4?
<smoser> yeah, tumbleweed
<smoser> stgraber, i'll test it again and get you md5sums of all files
<kees> slangasek: weird, I don't think "dist-upgrade" works correctly with multi-arch. I always have to do "dist-upgrade", have it fail on libgcc1, then "-f install", then "dist-upgrade" again and I'm fine.
<kees>  libgcc1:amd64 1:4.5.2-8ubuntu4 cannot be configured because libgcc1:i386 is in a different version (1:4.5.2-8ubuntu3)
<slangasek> kees: yes, it's an apt bug, let me find the ref
<kees> ah-ha, okay. already known. :)
<slangasek> kees: Debian bug #618288
<ubottu> Debian bug 618288 in apt "apt doesn't honor multiarch version requirements when configuring" [Important,Open] http://bugs.debian.org/618288
<smoser> stgraber, d44898904f347a5fad10f3b4903c4c28 is what i have.
<slangasek> kees: that's the last "I don't think I want to point users at this yet" bug
<kees> slangasek: yeah, agreed.
<kees> slangasek: I'd hit it before but I thought it was legit publisher churn (i.e. I didn't have i386 yet). during final freeze now I got suspicious. :)
<stgraber> smoser: 965e5137eff659cded3adb640357c33d  maverick_1.98+20100705-1ubuntu1
<stgraber> smoser: that's what's in the whitelist
<Cas07> how do I go about asking an ubuntu dev to create a backport of a pygtk patch to be applied to lucid, maverick and natty?
<smoser> 1.98+20100804-5ubuntu3 is what is installed, stgraber
<kees> slangasek: should that bug get added to http://wiki.debian.org/Multiarch/Bootstrapping ? it's not technically bootstrapping, but it sure seems like a sensible prereq to track somewhere.
<smoser> and what is current in maverick-updates
<stgraber> smoser: and that matches what I have on a clean ubuntu 10.10 amd64 server install
<smoser> so that i would think is more relevant
<stgraber> smoser: ok, I'm doing an upgrade now, I'll see if the file changes somehow
<smoser> ie, you're probably supposed to have dist-upgraded before do-release-upgrade, right?
<infinity> lamont: Hrm.  Does livecd-rootfs do the same "walk proc and slaughter" dance that launchpad-buildd does?
<smoser> stgraber, well it *will* change, right?
<stgraber> smoser: if it doesn't then we have some EC2 magic causing the file to have a different check sum
<infinity> lamont: If I never got around to doing that, that would probably solve your issue.
<smoser> stgraber, why would it not change when you install the newer 1.98+20100804-5ubuntu3
<stgraber> smoser: upgrade as in, going from release 10.10 to up to date 10.10
<stgraber> 965e5137eff659cded3adb640357c33d is what you have on the 10.10 CD, I'm now upgrading to an up to date 10.10 to compare, then dist-upgrading to natty
<stgraber> yeah, you're supposed to have an up to date system before dist-upgrading
<tumbleweed> smoser: looks like it's /etc/xul-ext/ubufox.js these days
<infinity> Cas07: File a bug, ideally including both the patch, and the reason(s) why you think it needs to be included in old releases.
<lamont> infinity: prolly not - I've never done it either, unless I did it early on
<Cas07> infinity: what about updating an existing bug
<infinity> lamont: Well, hooking that into the exit trap should be trivial.
<infinity> lamont: Let me go have a loot.
<infinity> lamont: Or a look.
<Cas07> infinity: oh ive found another bug that mentions something about no ubuntu-sponsors
<stgraber> smoser: ok, I still have 965e5137eff659cded3adb640357c33d with 1.98+20100804-5ubuntu3
<lamont> infinity: ta
<smoser> stgraber, yesh. it is ec2. i just realized its in the image build process.
<smoser> -GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0"
<smoser> +GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
<smoser> but i swear it didn't show me that.
<stgraber> smoser: ok, so d44898904f347a5fad10f3b4903c4c28 is what I should whitelist ?
<smoser> well that would make it better. cjwatson has never done this for me before.
<stgraber> oh, actually, no, I shouldn't whitelist that or it'll break on upgrade
<stgraber> well, not "break" but you'll loose your "console=ttyS0"
<stgraber> unless it's grub's postinst that sets that value, in which case it'd be fine to add the md5sum to the whitelist
<smoser> stgraber, no, its not grub that does it. the uec images build does it in post install modification.
<smoser> :-(
<stgraber> hmm, ok, then better not to whitelist that in grub and have the user see the diff. Or we'll get bug reports saying that they don't get their console output anymore (as grub would reset /etc/default/grub to a regular non-ec2 one)
<cjwatson> yeah, I hope to rearrange the nonsense that is that postinst after natty, but I really don't recommend trying to do it in a rush - the cure might well be worse than the disease
<smoser> cjwatson, yeah, please keep me in mind when you're doing that work.
<smoser> i know its not ideal, but i make modifications to that file in the iamge build process.
<smoser> the changes beign made currently are because I want to see a grub prompt on boot.
<smoser> -GRUB_TERMINAL=console
<smoser> +#GRUB_TERMINAL=console
<smoser> -#GRUB_HIDDEN_TIMEOUT_QUIET=true
<smoser> +GRUB_HIDDEN_TIMEOUT_QUIET=true
<infinity> lamont: Err, kay, livecd.sh has a proc walk, but it very much isn't the one I wrote for lp-buildd.  It screen-scrapes ls output with grep.
<infinity> lamont: No idea if it's working as intended and perhaps PPC is just hating you, or if it's actually broken...
<infinity> lamont: Though, given that it's meant to loop infinitely if processes remain in the chroot, my gut is that it's perhaps not working at all. :P
<smoser> stgraber, cjwatson i'm looking at diff shown to me by grub-pc right now, and it doesn't even show my console=ttyS0 change.
<infinity> lamont: I'm going to test some things here, and if the livecd.sh implementation seems completely broken (and, honestly, parsing ls output pretty much always is, even when it isn't), I'll commit some sort of shiny fix.
<lamont> infinity: heh. thanks
<lamont> hrm.. used to be that resizing  a window, I'd see lines/columns for the window... natty dropped that, and I want it back...
<Pici> iirc, theres a compiz option that does that.
<stgraber> cjwatson: for some reason I'm still getting the ucf prompt on upgrade even though my current md5sum matches the one that was added to the .md5sum ...
<stgraber> on grub upgrade that's
<stgraber> cjwatson: we apparently have an "old" md5sum in /var/lib/ucf/hashfile that's not in the .md5sum list (and I have no idea what that md5sum matches ...)
<lool> https://launchpadlibrarian.net/70111656/ubuntuone-client_1.6.1-0ubuntu3_amd64.changes shows that ubuntuone-client-gnome_1.6.1-0ubuntu3_amd64.deb was uploaded, yet I don't see it in the archive
<lool> and that was built 7 hours ago
<slangasek> lool: it's in the archive, not on the mirrors; can you poke IS?
#ubuntu-devel 2011-04-22
<stgraber> cjwatson: diagnostic so far is that the .md5sum file isn't even read by ucf, not sure why yet
 * SpamapS wipes the sweat off his brow, checks for any bleeding wounds, then returns to hacking
<micahg> stgraber: FYI, cjwatson said he was gone a few hours ago in case you're waiting for a quick answer
<stgraber> cjwatson: ok, found the issue, it's caused by the fact that we have a lastsum on the system, so the whole .md5sum file is ignored
<stgraber> micahg: nope, not really hoping for a quick answer :) I'll likely post that in the bug report anyway
<micahg> stgraber: k :)
<ohsix> am i seeing things or is python-ubuntuone-client and ubuntuone-client broke right now w/ unsatisfiable deps
<ohsix> ahhnm i know what to check, ftb for my arch
<kees> skaet: what's the best way to answer the question "is pkg Foo seeded?"
<cjwatson> kees: http://people.canonical.com/~ubuntu-archive/germinate-output/
<cjwatson> grep through that (perhaps over ssh rather than http)
<skaet> kees,  its an area I'm still learning about,  germinate is what folks use.
<kees> cjwatson: ah, yes, germinate again. how quickly I forget. :)
<cjwatson> (also: make the distinction between "explicitly seeded" and "pulled in by dependency-expansion of seeds")
<kees> well, mostly I'm trying to sort out the mess that is cyrus-sasl2-heimdal. we branched from debian at the wrong time...
<kees> currently cyrus-sasl2-heimdal is uninstallable and ftbfs. it's in universe, but people do use it.
<cjwatson> the rdepends/ directories in germinate-output can tell you why something is wanted in main
<kees> nothing seems to seed it, so that's nice. but to fix it, we need debian's -6 of cyrus-sasl2, and that gets seeded by lots. I suspect this'll need a -proposed update after release.
<cjwatson> they're the answer to many questions in that area
<cjwatson> I'd prefer to keep the term "seeded" for "there's an explicit entry in the seed files kept in bzr for it"
<kees> gotcha
<cjwatson> since that corresponds to the useful concept of "we explicitly decided we wanted this in main regardless of dependencies" (mostly)
<cjwatson> and besides the verb/noun correspondence makes more sense that way :)
<cavedon> hi, jcc binary  on natty needs to be rebuilt. what is the procedure for requesting a rebuild at this stage?
<cavedon> I guess open a bug and subscribe whom?
<sladen> cavedon: open a bug, subscribe ubuntu-release
<cavedon> sladen, thanks
<sladen> cavedon: got the bug number/package name?
<cavedon> sladen, https://bugs.launchpad.net/ubuntu/+source/jcc/+bug/768733
<ubottu> Ubuntu bug 768733 in jcc (Ubuntu) "undefined symbol JNI_GetDefaultJavaVMInitArgs (needs rebuild)" [Undecided,New]
<sladen> cavedon: python -m jcc.__main__   "/usr/bin/python: No module named _jcc"   that's a different error to what the bug report suggests?>
<sladen> cavedon: how can I test the rebuild fixes it?
<happyaron> Is there any plan about Firefox 4 for Lucid?
<micahg> happyaron: no, but maybe 5 or 6
<micahg> happyaron: you can get it now in the PPA, ppa:mozillateam/firefox-stable
<happyaron> micahg: thanks. I'm using Nighly from ftp.mozilla.org now, which get auto-update everyday.
<micahg> happyaron: we have nightlies too, ppa:ubuntu-mozilla-daily/ppa, package is firefox-trunk
<happyaron> thanks.
<didrocks> good morning
<smoser> anyone have any ideas? i've got a self signed https server . i have 2 systems running natty, that comlain about it, but will let me get the file.
<smoser> i have 2 systems running lucid (headless systems, the other 2 are desktops) that simply refuse
<smoser> wget says: Unable to establish SSL connection.
<smoser> python urllib2 gives: urllib2.URLError: <urlopen error [Errno 104] Connection reset by peer>
<lool> slangasek: apparently the u1 package issue went away by itself
<lool> or someone fixed it
<slangasek> yeah, there was IS fixing involved :)
<tseliot> Riddell: can you approve fglrx in the archive, please? It contains updates to the EULA and to the documentation
<tseliot> it won't affect the image build since the driver is not installed by default
<Quintasan> good morning
<mdeslaur> good morning
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots: mdeslaur
<ScottK> sladen: I took care of jcc.
<ScottK> tseliot: It's on the Kubuntu DVD so it does affect image building.
<tseliot> ScottK: ah, I didn't know that
<sladen> ScottK: ta
<J_Rey> Anyone know if the system requirements are going to noticably increase if using Unity?
<tomreyn> is there a universal command which can be used to check for presence of installed non-free kernel modules?
<tomreyn> i think apport and reportbug do this but i'm not sure how
<mterry> tomreyn, jockey?
<directhex> tomreyn, /proc/sys/kernel/tainted
<directhex> tomreyn, 0 means no non-free modules
<tomreyn> directhex: that's what i was looking for, thanks. How would I go about identifying which modules are tainting the kernel?
<directhex> tomreyn, that's rather more involved ;)
<tomreyn> okay, i'll leave it there for now, that's good enough for my needs.
<directhex> tomreyn, try something like for i in `lsmod | tail -n +2 | cut -f1 -d' '`; do if [ -n "$(modinfo $i | grep ^license | grep -v GPL)" ]; then echo $i; fi; done
<ScottK> i
<directhex> tomreyn, this is unsophisticated & will spit out a module which isn't really tainted (e.g. MIT only), and will miss modules which lie to fool the kernel (e.g. "not GPL; Proprietary")
<smoser> does anyone have a https server with a self signed cert running on natty ?
<smoser> i have a little python based web server, with self signed cert and I can't connect to it from lucid using python or wget (Unable to establish SSL connection.)
<smoser> i want to make sure its not a bug in the natty openssl stack
<mdeslaur> smoser: what about wget with --no-check-certificate?
<smoser> it fails.
<smoser> same command succeeds from natty to natty
<smoser> both complain about the certificate
<smoser> but it gives "Unable to establish ssl connection" when run from lucid -> natty.
<mdeslaur> smoser: hmm...interesting
<smoser> wait. i might not have been cclear
<smoser> server is natty python based self signed cert.
<smoser> when client is lucid, wget and python fail
<smoser> when client is natty, wget and python both succeed
<mdeslaur> smoser: give me a few minutes, I'll set up a natty apache with https and try it
<fta> robbiew, hi, do we know how debdelta compares with google's courgette?
<fta> robbiew, https://sites.google.com/a/chromium.org/dev/developers/design-documents/software-updates-courgette
<RoAkSoAx> mdeslaur: howdy!! Since you are piloting, could you please sponsor bug #768598 please?
<ubottu> Launchpad bug 768598 in powernap (Ubuntu) "PowerNap does not take recover action in PowerSave mode after powernap-now" [Critical,Confirmed] https://launchpad.net/bugs/768598
<robbiew> fta: I don't, and tbh  would prefer to use something shared by debian
<fta> robbiew, ok, fair enough. i just has the impression that courgette would be several orders of magnitude smaller
<fta> but i didn't test deltadeb
<mdeslaur> RoAkSoAx: sure...I'll have to ask the release team for approval first though
<mdeslaur> RoAkSoAx: actually...looks like it's too late for release, so it needs to be an SRU once natty is out
<RoAkSoAx> mdeslaur: Oh, I didn't know that we were already frozen. Thanks though!
<tumbleweed> smoser: works for me (twisted ssl server)
<smoser> tumbleweed, you have a self signed https server running on natty? and you can connect to it using wget or python from lucid ?
<tumbleweed> smoser: with --no-check-certificate yes
<smoser> ok. thank you.
<ScottK> RoAkSoAx and mdeslaur: You can upload to natty-proposed now, although (unless I screw up) it won't get accepted until release.
<ScottK> No need to wait.
<mdeslaur> ScottK: ah! cool, thanks
<mdeslaur> RoAkSoAx: I'll upload powernap as a day 0 SRU
<kirkland> mdeslaur: RoAkSoAx: thanks
<RoAkSoAx> ScottK: cool!! good to know! Thanks
<RoAkSoAx> mdeslaur: awesome! Thank you
<RoAkSoAx> kirkland: wouldn't have even noticed if you wouldn't have pointed it out :)
<kirkland> RoAkSoAx: i was working with negronjl, showing it off, and it broke for both of us
<RoAkSoAx> kirkland: yeah I don't really know what happened cause I did patch that. I guess I just forgot to commit those 3 lines when changing laptopsg
<RoAkSoAx> kirkland: btw.. how did the tests go? How much energy savings were shown?
<RoAkSoAx> kirkland: btw the issue was only seen when executing powernap-now, cause it wouldn't have come back up with activity or powerwake-now. But other than that everything was working as expected
<tomreyn> directhex: thanks for the non-free kernel module one-liner :)
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta-2 released | Archive: final freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Patch Pilots:
<hallyn> Daviey: about bug 769025, what do we do with it, target it at 'natty-updates'?
<ubottu> Launchpad bug 769025 in libcgroup (Ubuntu) "package cgroup-bin 0.37.1-1ubuntu1 failed to install/upgrade: subprocess installed pre-removal script returned error exit status 1" [Medium,Confirmed] https://launchpad.net/bugs/769025
<ohsix> hallyn: do you know offhand if cgroup-bin still makes suspend fail?
<hallyn> ohsix: nope
<hallyn> thatis, i don't know
<ohsix> i had a fun time figuring it out :] installed it to check it out a few times and thought the failures were from thekernel or something related
<ohsix> the way it bins threads, kernel and otherwise messes with the ordering of something, at least with the default configuration in cgroup-bin
<ohsix> i didn't know enough about it (that's why i wnated to mess with it) to offer a fix, and i still don't; shrug
<hallyn> ohsix: there is an open bug about it right?
<hallyn> (pretty sure i saw one before)
<hallyn> if i get through some other bugs, i may try to reproduce here
<ohsix> yea i think i filed one after i found out & closed the bug i reported for the suspend
<ohsix> one moment
<ohsix> https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/713187
<ubottu> Ubuntu bug 713187 in libcgroup (Ubuntu) "cgroup-bin default configuration breaks suspend" [Undecided,New]
<hallyn> ohsix: thanks
<ScottK> barry: I think Bug #768363 is python2.7 related.  I was wondering if you could have a look.
<ubottu> Launchpad bug 768363 in software-properties (Ubuntu) "Not able to change software origins in software-properties-kde - TypeError: coercing to Unicode: need string or buffer, NoneType found" [Medium,Confirmed] https://launchpad.net/bugs/768363
<dobey> can someone approve the lucid/maverick nominations on bug #663001 please?
<ubottu> Launchpad bug 663001 in libubuntuone trunk "My Downloads page shows incorrect status for songs with some non-English characters" [High,Fix committed] https://launchpad.net/bugs/663001
<Cas07> I updated this bug https://bugs.launchpad.net/ubuntu/+source/pygtk/+bug/664920 with ubuntu sponsors so that it can be backported but i am wondering if there is anything else i should do?
<ubottu> Ubuntu bug 664920 in pygtk (Ubuntu) "100% CPU usage when calling a child process from a python script" [Undecided,Confirmed]
<hallyn> ohsix: actually, i think libcgroup may no longer stop suspend from working.  It's not placing tasks in any child cgroups for me by default
<hallyn> ohsix: that's not to say you can't write a config to make it do so.  (nor that i'm just wrong about my conclusion)
<ohsix> did the config remove the default groupings?
<ohsix> right, the config it came with in mav was what was moving things
<hallyn> ok - we still might want to teach libcgroup explicitly not to move kthreadd, but by default maybe it won't mess people up
<Daviey> hallyn, That package is universe, and unseeded by flavours as far as i can see.  Therefore, natty pocket makes sense still.
<ohsix> it might be more than kthreadd, at least with respect to suspend, but since it's bad to do it's probably prudent
<hallyn> ohsix: right
<hallyn> Daviey: are you saying go ahead and dput?
<Daviey> hallyn, Final freeze for universe/multiverse is 26th.
<Daviey> hallyn, Yes, i would.
<hallyn> Daviey: cool, then i just have to find someone who's not on vacation who can sponsor :)
<hallyn> SpamapS: around?
<Daviey> hallyn, linky, i can
<hallyn> finding
<Daviey> hallyn, Vacation is for wuffos.
<hallyn> Daviey: the source (minus .orig.tar.gz) is at http://people.canonical.com/~serge/libcgroup_0.37.1-1ubuntu2-package.tgz.  bzr tree is linked to the bug which is https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/769025
<ubottu> Ubuntu bug 769025 in libcgroup (Ubuntu) "package cgroup-bin 0.37.1-1ubuntu1 failed to install/upgrade: subprocess installed pre-removal script returned error exit status 1" [Medium,Confirmed]
<hallyn> Daviey: i could do with a week vacation with no laptop available
<Daviey> hallyn, so bzr branch is suitable for review?
<hallyn> yup
<hallyn> want me to do merge request?
<Daviey> hallyn, I get shaky hands if i haen't checked my email for an hour.
<Daviey> hallyn, sure, go for it.
<hallyn> merge proposal sent
<hallyn> yeah i used to be that way.  i might still be.  wouldn't know, bc it hasn't happened :)
<Daviey> hallyn, what about https://code.launchpad.net/~serge-hallyn/ubuntu/natty/libcgroup/upstart ?
<hallyn> Daviey: that's merged
<hallyn> well upstart2 was
<hallyn> it was a long road :)
<Daviey> hallyn, does that mean bug 681724 is fix released?
<ubottu> Launchpad bug 681724 in libcgroup (Ubuntu) "cgroup-bin package installs with errors (failure to parse /etc/cgconfig.conf)" [High,Confirmed] https://launchpad.net/bugs/681724
<hallyn> Daviey: i forgot all about that one!  Yes, it is.  we're now mounting under /sys/fs/cgroup/
<hallyn> looks like we licked 5 or 6 bugs with the last-minute release.  and so far only created one new one :)
 * hallyn ^5s jbernard 
<Daviey> hallyn, Okay, looking at the merge proposal now.. Could you copy the debian/changelog entry that fixed that bug into a comment, and change the status to Fix Released please?
<hallyn> a comment on that bug you mean, right?
<hallyn> done
<Daviey> ta
<micahg> mdke: ubuntu-docs firefox-index still references Ubuntu 10.10, I filed a bug against ubuntu-docs a couple weeks ago
<mdke> micahg: does firefox still use that these days? I thought it was all handled internally by now
<micahg> mdke: firefox doesn't, but midori does and I think maybe others
<mdke> micahg: I can fix it now but don't know if the upload will be accepted
<ScottK> SRU material now unless you can get a fix uploaded in the next 15 minutes.
<micahg> mdke: would you rather me fix the midori home page?
<ScottK> We have a Ubiquity fix that's about to go in, so I can take a trivial fix if it's quick.
<micahg> mdke: ugh, it's seeded, I'll see if I can fix midori and the other browsers instead
<mdke> it's fairly easy SRU material though
<mdke> ScottK: I will try a gnome-user-docs upload in the next 15, as I have some help for mobile broadband that I'd like to get onto the images if at all possible
<ScottK> Hurry.  Just accepted Ubiquity.
<micahg> mdke: ok, if you want to SRU the ubuntu-docs change, that'll probably be easier, then we can fix the other browsers for oneiric
<mdke> ScottK: will depend how long it takes to build. Testing is straightforward
<ScottK> Let's see how he does with my deadline for getting it in -release first ....
<ScottK> OK
<ScottK> mdke: It looks like you've got a little longer, there's some buildd backlog and I doubt Ubiquity will make the next publisher run.
<mdke> ScottK: splendid, my laptop is a bit slow at building :)
<ScottK> So don't dawdle, but better to take a little extra time to get it right than to push it by a given moment.
<mdke> noted
<mdke> how much longer are we talking?
<mdke> ScottK: uploaded
<ScottK> Looking
<ScottK> mdke: Accepted.
<mdke> ScottK: a million thanks
<mdke> or hugs
<ScottK> You're welcome.
 * ScottK prefers thanks in whisky.
<maco> ScottK: taken Riddell's linguistic preferences to heart?
<ScottK> I figure he's in a position to be authoritative on the matter.
<mdke> ScottK: noted
<ScottK> mdke: You coming to UDS again?
<mdke> ScottK: I'm afraid not. In fact, I've never been to one
<mdke> :(
<ScottK> Ah.  Too bad then.
<mdke> difficult to get away from work
<lamont> how on earth do I get &*^_&N  to quit thinking that because the window bumps in to the top of the screen when I move it that I for some inexplicable reason want a full screen version of it?
<broder> go in ccsm and disable the grid plugin
<cjwatson> or Grid -> Edges -> Resize Actions -> Top Edge = None
<cjwatson> (also in ccsm)
#ubuntu-devel 2011-04-23
<cousteau> Qucs 0.0.16 was released in mid-March. Any chance it gets to Natty? if not, it would be nice to see it at least in Oneiric
<JanC> cousteau: Qucs 0.0.15 is in natty now, and as we are less than a week from the release...
<cousteau> ok, so Oneiric then
<JanC> is it in Debian already?
<cousteau> let me see
<cousteau> hmm... nope
<cousteau> don't know which changes will this version introduce, but after 2 years of development I'd expect some nice features...
<JanC> or a single bugfix, depending on activity  ;)
<cousteau> (then again, if they haven't released a new version in 2 years, maybe the project is a bit stalled)
<JanC> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622758
<ubottu> Debian bug 622758 in qucs "qucs: New upstream version (0.0.16) available" [Wishlist,Open]
<JanC> so you're not the first to request it  âº
<JanC> seems like the Qucs devs are somewhat "release notes, what's that?"  :P
<cousteau> well, they have a "News" section with some info
<cousteau> it's a nice and easy to use software for electronic simulations... but it gets updated each... well, 2 years
<jbernard> hallyn: nice work! thanks for all your help on that
<hallyn> jbernard: thanks for not pointing out that the last bug was my own fault :)
<hallyn> jbernard: thanks, have a good weekend
<hallyn> i'm skeedaddling
<bdrung_> hi, i have a problem with my dput upload: http://paste.debian.net/114872/
<bdrung_> it is correctly signed with my key
<BlackZ> bdrung_: I had the same problem but the package got uploaded
<bdrung_> now i get the mails.
<bambee> Hello, python-apt developers: in data/Ubuntu.info.in line 27, there is a missing description => software-properties-gtk displays "none" in updates tab, and software-properties-kde crashes (it should not, I agree, but I does because it tries to translate a None string). Add a description field solves the problem.
<bambee> (I can be wrong...)
<bambee> and all other templates have a description...
<abhinav-> bambee: see this one https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/769364
<ubottu> Ubuntu bug 769364 in software-properties (Ubuntu) "Software-sources showing repeated options" [Undecided,New]
<bambee> abhinav-: it is exactly the problem :)
<abhinav-> ah :)
<abhinav-> its strange
<bambee> see http://paste.ubuntu.com/597838/, there are two "natty-security", two "natty-proposed", two "natty-updates" with the same name and the same description, the only differences are the RepositoryType (deb-src). software-properties uses aptsources  which parses this file, then for each "Suite" it displays the name and the description => so we've duplicates options in the "updates" tab.
<bambee> :)
<mdke> I see that the Canonical Partner repository doesn't appear in software sources in natty - is it intended that users add the apt line manually or am I missing something?
<Meep> Hi, anyone here interested in chasing down the kernel power regression.
<lars_t_h> Meep, maybe you will be more lucky at #ubuntu-kernel
<lars_t_h> You should also post a link to an error report
<Meep> lars_t_h: Thanks.  Posted it to that channel with a ref to launchpad 760131
<ubottu> Launchpad bug 760131 in linux (Ubuntu) "Power consumption raised significantly in natty" [Undecided,Confirmed] https://launchpad.net/bugs/760131
<tomreyn> hi
<tomreyn> what needs to happen to have this taken on? https://bugs.launchpad.net/ubuntu/+source/bitlbee/+bug/757008
<ubottu> Ubuntu bug 757008 in bitlbee (Ubuntu) "/usr/lib/bitlbee/otr.so: undefined symbol: otrl_init" [Undecided,New]
<tomreyn> with bitlbee-otr installed, bitlbee fails to start. and this package is unusable
<tumbleweed> tomreyn: I can't reproduce that. From the Dependancies.txt it simply looks like a missing libotr2. Broken upgrade?
<tomreyn> tumbleweed: thanks for looking into it. I haven't tried it for a while. Let me try it now
<Ampelbein> looks to me like a missing Depends in bitlbee-plugin-otr
<tumbleweed> Ampelbein: lol, I was in a sid chroot my bistake
<tomreyn> tumbleweed: http://paste.ubuntu.com/598058/
<tumbleweed> tomreyn: yeah I can see it now
<tomreyn> but i agree about missing depends
<tomreyn> do youthink there's a chance to get it fixed for natty?
<tumbleweed> the plugin isn't linked again libotr2, and it should be. PRobably a result of the linker changes. Which may mean that it just needs a rebuild now (we've gone back to a conservative linker for release)
<tumbleweed> yes
<tomreyn> sweet
<tumbleweed> yup, rebuilding works
<tomreyn> what's the magic command for this again? 'apt-get -b source bitlbee-plugin-otr' or something?
<tomreyn> oh --compile
<Ampelbein> tumbleweed: are you preparing a no-change rebuild?
<tumbleweed> Ampelbein: yeah
<Ampelbein> btw, that error seems nasty as there is no way to auto-detect it at build time
<tumbleweed> I guess that's a problem with any shared library plugin
<Ampelbein> yeah, so in oneiric we must have an eye on packages with potential problems
<tumbleweed> I'm still not sure exactly what caused this
#ubuntu-devel 2011-04-24
<tomreyn> thanks for your help + bye for now
<penguin42> Ampelbein: I guess for things which take plugins you could ask that those packages have a command line --test-plugin thing that the plugin packages use during their build phase ?
<tumbleweed> oh right, argument order
<tumbleweed> -lotr -fPIC
<Ampelbein> penguin42: that would make things easier, yes.
<Ampelbein> having the actual command line instead of a "* Building plugin otr.so" would be a great help debugging, too.
 * tumbleweed is forwarding a bug to debian
<Ampelbein> anyway, objdump shows http://paste.ubuntu.com/598065/, as expected
<tumbleweed> Ampelbein: odd, no-add-needed made no difference for me (and it's the default in Debian now, anyway)
<hyperair> hmmm. to upgrade ubuntu, or not to upgrade ubuntu, that is the question.
<ohsix> only thing that annoyed me was the changes brought with compiz .8 -> .9; i got over it
<hyperair> ohsix: hmm i think i'm fine with those. i'm already running compiz git.
<hyperair> hmm
<hyperair> all my keybindings have been wiped out
<hyperair> how nice.
<m4n1sh> when checking for a version of zeitgeist in configure.ac
<m4n1sh> which one should be used?
<m4n1sh> PKG_CHECK_MODULES
<m4n1sh> or
<m4n1sh> AC_PATH_PROG
<m4n1sh> I used PKG_CHECK_MODULES and it works.
<m4n1sh> is PKG_CHECK_MODULES correct or it should be done by AC_PATH_PROG
<m4n1sh> AC_PATH_PROG is for checking the path. Right? and other for checking the existence of module
<cjwatson> if something has a pkg-config module available, you should generally use PKG_CHECK_MODULES
<m4n1sh> cjwatson: thanks :)
<joseZ33> hi everyone
<exobuzz> natty mousetweaks is gnome 3, the gnome-mouse-properties is gnome 2.32 and they are incompatible. how can i help you to notice that mousetweaks including mouse accessibility is completely broken currently in natty, before you release and get some bad press relating to it ?
<exobuzz> https://bugs.launchpad.net/unity/+bug/762806
<ubottu> Ubuntu bug 762806 in unity (Ubuntu) "simulated second click with unity" [Undecided,Confirmed]
<exobuzz> the last post points to the problem after I was unsure when posting "There's a version mismatch between mousetweaks and gnome-control-center + gnome-settings-daemon. The GNOME 3 versions of these modules use dconf for configuration and the 2.32 versions use gconf. Downgrading mousetweaks to 2.32 will fix it. (or upgrading the others)"
<jbicha> g-c-c definitely won't be upgraded to 3.0
<exobuzz> then mousetweaks should be downgraded again.
<exobuzz> wlse you are basically saying "no disabled users please"
<exobuzz> (and also no single click touchscreen users)
<exobuzz> i currently maintain a touchscreen ubuntu distribution for the o2 joggler (http://joggler.exotica.org.uk) - and that is my current solution, to use mavericks mousetweaks. however this is quite a significant bug imho, when it comes to accessibility
<exobuzz> if any dev can give this some attention, it would be most appreciated (by all the users who need it), and by yourselves from avoiding plenty of complaints ;-)
<sladen> exobuzz: /me reads the background
<exobuzz> looks like it is assigned correctly now with a priority so hopefully the bug gets fixed
<sladen> exobuzz: for bug #762806 would you be able to add a simple idiots guide for reproducing the issue (eg. a sequence of steps that works with mousetweaks version 2.XYZ and failes with mousetweaks version 3.XYZ)
<ubottu> Launchpad bug 762806 in mousetweaks (Ubuntu) "[regression] shipped mousetweaks (3.0) does not work with shipped control-center (2.32), needs downgrade" [High,Triaged] https://launchpad.net/bugs/762806
<exobuzz> sladen, done.
<exobuzz> sladen, did you mean on the bug or here? well it's on the bug now. heh
<sladen> exobuzz: on the bug is much better and stops it getting lost (IRC eventually scrolls off people's terminals)
<exobuzz> heh yeh, i wasnt sure if you were asking for yourself or in general, but anyway, quite easy to reproduce since all mouse accessibility is broken on natty
<exobuzz> let's hope the ubuntu-updates comes quickly after release.
#ubuntu-devel 2012-04-16
<Bluefoxicy> Would it be possible to separate malloc() from glibc?
<RAOF> Yes; why would you want to?
<Bluefoxicy> I'm having severe memory use issues-- 4 gigs just isn't enough for Chrome, Rhythmbox, Xchat, and Thunderbird all at once--so I've switched allocators to see if any of the others out there do better
<RAOF> I wouldn't imagine that they'd do appreciably better.  You could always try LD_PRELOAD something with a different malloc/free set.
<Bluefoxicy> Particularly in this case Hoard, although Boehm with malloc() overriding is a potential direction (that I'd like to avoid)
<Bluefoxicy> yes that's what I have going now
<Bluefoxicy> ld.so.preload
<Bluefoxicy> but preloading of course breaks wine
<Bluefoxicy> well, it breaks multilib in general
<Bluefoxicy> this is a known bug from about 47 releases ago
<Bluefoxicy> (it's #33994)
<RAOF> Oh, right.  You need a different preload per arch.
<Bluefoxicy> RAOF:  What do I do if Thunderbird keeps eating 1.8 gigs after 2-3 hours but under a different allocator it only eats 400 megs?
<RAOF> Oh, wow.  That's a big difference!
<Bluefoxicy> maybe.
<RAOF> I guess you work out what the different allocator is doing differently and file a bug at the appropriate level.
<Bluefoxicy> It could also hit the same end state just further down the line, or I haven't sufficiently loaded the application yet to cause the access patterns that bring trouble
<Bluefoxicy> But yeah
<RAOF> Oh, right.
<Bluefoxicy> thunderbird has been resident 1800 megs lately, and i've restarted it multiple times today
<Bluefoxicy> resident doesn't even count what's in swap :|
<RAOF> That's not 400MB after 2-3 hours of use under the new allocator?
<Bluefoxicy> We'll see.  It was mostly hypothetical
<RAOF> Ah.
<Bluefoxicy> I don't think a lot of experimentation happens with allocators.
<Bluefoxicy> but it's long been known to me that the entire heap model is a huge failure in design anyway.
<RAOF> Got anything better? :)
<Bluefoxicy> Hoard seems to be designed for modern systems.  That's what I'm trying to determine though.
<RAOF> I mean, there are certainly known-failings in heaps.
<Bluefoxicy> You gotta realize, with brk() heap, if you allocate 300 megs, then free all but the highest allocation, you have 1 megabyte in use and 300 megs that the system thinks are in use
<RAOF> Yeah; fragmentation is an issue.
<Bluefoxicy> fragmentation and other stupidity can land you with a huge heap.  Imagine how that pans out with threaded applications.
<Bluefoxicy> the buddy allocator in glibc was pretty fantastic when it was made, but it may be behind the times.. but that only holds true if something else significantly improves performance or memory usage, or both
<RAOF> It's a bit of a pity you can't (easily) run C code in a GC'd VM ;)
<Bluefoxicy> GC has its own issues, like touching all over memory a lot messing with the CPU cache state and of course if anything's in swap...
<Bluefoxicy> in a VM it's a little less of an issue
<Bluefoxicy> since assignments of pointers can be tracked easily
<RAOF> Right.
<Bluefoxicy> and of course there's lots of research there--Mono in fact uses a compacting GC that pauses the world, alters pointers, and defragments memory to free more back to the system
<RAOF> Right - not (yet) by default for mono, but the Microsoft CLR has used that for ages.  Presumably Java does the same.
<Bluefoxicy> Java recently stopped ref counting for a really crappy garbage collector that's much worse
<Bluefoxicy> but they may have moved to a better one since then
<lifeless> erm
<Bluefoxicy> hi lifeless
<lifeless> java has had that for decades
<lifeless> current java stuff is concurrent multi-threaded gc without stop-the-world
<Bluefoxicy> ... java's been around for decades?
<Bluefoxicy> *I* haven't been around for decades and I remember when Java first came into existence.
<Bluefoxicy> anyway it's not technically infeasible or really difficult to implement a C to CIL compiler
<lifeless> (sun/oracle) java doesn't refcount anyhow - I don't think it evcer has
<lifeless> it inherited its initial gc model from smalltalk
<Bluefoxicy> it's on the level of implementing a C to x86 compiler, plus some muckery about how to handle pointers and malloc and such
<lifeless> which is generational
<Bluefoxicy> which isn't to say that building a compiler is a child's task; just that when we're talking about how difficult a task is, it turns out building an ABWR reactor isn't "difficult" because it's a normal task in some context
<Bluefoxicy> The bigger question is do you want to run absolutely everything on top of Mono
<lifeless> Bluefoxicy: java was created in 91
<lifeless> so, > 1 decade :P
<lifeless> and it -heavily- learnt from smalltalk, which goes back to early 70s
<Bluefoxicy> (and, as an aside, if you did build C onto CIL, you could easily have Mono catch things like memcpy() more data than the total length of an array into an array and block it)
<Bluefoxicy> automatic run time analysis :D
<mwhudson> are there any known problems with wifi (intel variants thereof) in precise currently?
<lifeless> N
<mwhudson> google is freaky
<mwhudson> searching for "BUG: unable to handle kernel paging request at fffffffffffffb88" finds the bug apport filed for me about 5 minutes ago
<StevenK> My Intel card drops out in Oneiric, and then brings up a network passphrase window every 3 minutes.
<StevenK> So I will occasionally unlock my laptop and find 200 windows open all asking for the wireless password.
<mwhudson> nice
<mwhudson> this was an oops though
<RAOF> I know of no oopses.
<RAOF> I think .11n is still a little flaky, but disconnect-y flakey, rather than oopsy.
<mwhudson> RAOF: could you take a very quick look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/982738  then?
<ubottu> Launchpad bug 982738 in linux (Ubuntu) "BUG: unable to handle kernel paging request at fffffffffffffb88" [Undecided,New]
<RAOF> That seems like a bug? :)
<mwhudson> heh fair enough
<RAOF> I don't have much to say about it; I'm sure if the kernel team needs more info they'll ask.
<mwhudson> ok
<RAOF> âfffffffffffffb88â seems pretty unlikely to be a valid memory address, though ;)
<mwhudson> yeah
<mwhudson> it's not a surprising failure, on the face of it :)
<slangasek> -0x477 seems like a perfectly good place to store data, if you ask me
<pitti> good morning
<pitti> slangasek: sudo> I don't see a reason why it shouldn't invoke pam_env for itself
<slangasek> pitti: <nod>
<slangasek> pitti: though in practice, it's missing some other bits to be able to use it effectively... sudo doesn't export pam_getenvlist() to the session environment ;)
<tjaalton> is there a tool to purge obsolete kernel images?
<pitti> tjaalton: the best that we have is computer-janitor
<tjaalton> pitti: oh it's still available? thanks
<pitti> sudo dpkg -P linux-<tab><tab> works reasonably well, too (and then pick)
<pitti> but in general it's a major unsolved problem
<tjaalton> yeah, dpkg works for me, just a friend was asking/complaining about those :)
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hi pitti
<ahasenack> hi, could I interest someone into reviewing this SRU? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/978884
<ubottu> Launchpad bug 978884 in landscape-client (Ubuntu Oneiric) "SRU: release 12.04.3 for lucid, natty and oneiric" [Undecided,New]
<pitti> ahasenack: there is not much to approve, it's got a standing SRU exception anyway?
<ahasenack> pitti: yes, but some steps must be followed, I guess the approval is the first one, then I can start hunting for a sponsor and get it uploaded to proposed
<pitti> ahasenack: so, consider it approved by https://wiki.ubuntu.com/StableReleaseUpdates#Landscape
<ahasenack> pitti: don't you need to add a tag to it?
<pitti> no, we don't do that for SRUs
<pitti> we review uploads from the unapproved queue
<ahasenack> pitti: ok, thanks, so we need an uploader now :)
<pitti> ahasenack: I'll do patch piloting later today, so I'll grab them unless someone beats me to it
<ahasenack> pitti: ok, thanks
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<jibel> pitti, good morning
<pitti> bonjour jibel
<jibel> pitti, I proposed a fix for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648161 can we have it in Precise ?
<ubottu> Debian bug 648161 in autopkgtest "autopkgtest: Extracting sources with ~ or + in the version fails" [Normal,Open]
<pitti> jibel: ooh, thanks
<pitti> jibel: oh, so it was even me who reported that, sheesh
<pitti> jibel: uploaded; needs another -release member to approve the upload
<pitti> jibel: merci beaucoup for fixing this!
<jibel> pitti, thanks for uploading it !
<doko> infinity, slangasek: the new armhf linker path isn't yet in the debian eglibc repo, correct?
<infinity> doko: It will be shortly.
<infinity> doko: I needed a nap first. :P
<infinity> cd ..
<infinity> Err.
<infinity> ^-- See?
<pitti> ssh infinity cd /bed
<infinity> pitti: I did go to bed, and it lasted about 4 hours. :/
<infinity> pitti: After having been awake for about 40.
<infinity> pitti: Grr.
<pitti> infinity: does it help you sleeping if I threaten you with having to review my glib/gtk/other gnome 3.4.1 uploads? :-)
<pitti> err, "threat", I think
<infinity> Nah, I don't mind that.
<dholbach> pitti, infinity is used to pain
<dholbach> infinity, man, go to bed!
 * dholbach hugs infinity
<infinity> pitti: Check the debdiff from eglibc -0ubuntu7 and -0ubuntu9 and then get back to me on how bad you can make a GNOME review.
<infinity> From -0ubuntu7 *to* -0ubuntu9, that is.
<doko> infinity, do the gnat-4.6 bootstrap, or go to bed ;p
<infinity> doko: Considering it.
<pitti> infinity: ok, you win
<infinity> doko: And I'd be in bed if I could.  Just woke up 10 minutes ago for no good reason.
 * infinity sets about committing all of this to Debian.
<vibhav> https://bugs.launchpad.net/ubuntu/+source/amule/+bug/610385 , needs to be fixed in oneierc. Would it be right to file a sync request for oneiric?
<ubottu> Launchpad bug 610385 in amule (Ubuntu) "amule memory usage increases to 100% and makes the whole system unusable" [Undecided,Fix released]
<fhilly_> Hi all, I wonder if anyone can help me, does anyone have full documentations of Ubuntu-Core rootfs?
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, I have got a fix for bug 980673. The bug prevents N-up printing of many PDFs.
<ubottu> Launchpad bug 980673 in cups-filters (Ubuntu) "pdftopdf crashed with SIGSEGV" [Critical,In progress] https://launchpad.net/bugs/980673
<tkamppeter> pitti, how should I proceed? Probably 0-day SRU?
<pitti> tkamppeter: do you have a patch? if it's 100% risk free, you can upload to precise still
<tkamppeter> pitti, yes, I got the patch. The patch is small and simple. As I am upstream project leader I will make a new  upstream release which differs from the old one only by this patch, as I always did with cups-filters.
<fhilly_> anyone working on Ubuntu Core rootfs?
<pitti> tkamppeter: I'd say, upload it and see whether it sticks; if not, reupload to -proposed :)
<rbasak> pitti: please could you see what needs to be done on bug 947309? Is it missing from the sponsors queue because it's "Fix Released"?
<ubottu> Launchpad bug 947309 in ipsec-tools (Ubuntu) "racoon phase 2 negotiation fails with Win Vista/7" [Medium,Fix released] https://launchpad.net/bugs/947309
<pitti> rbasak: indeed; I approved the lucid task nomination
<pitti> rbasak: will look at this next
<rbasak> pitti: thanks!
<pitti> rbasak: uploaded, thanks
<rbasak> thank you!
<tkamppeter> pitti, I have uploaded the fix to precise now and it is waiting for approval.
<kerby82_> hi which is the better way to start coding for ubuntu with python? Do you have any suggestion? books, tutorial, etc..
<pitti> tkamppeter: I can upload current cups-filters to Debian, too if you want
<pitti> tkamppeter: done now
<verwilst> i'm still confused about the dlm-pcmk removal from precise
<verwilst> functionality has been removed without replacing it, or noting why it was done or how you can work around it or anything
<verwilst> sucks :(
<verwilst> roaksoax, can you spare a moment of your time? :)
<dupondje> still depressive about it verwilst  :)
<sagaci> verwilst: https://launchpad.net/ubuntu/precise/amd64/dlm-pcmk
<verwilst> sagaci, yes?
<sagaci> it says why it was done
<verwilst> myeah, ok, the why is maybe the clearest part in this story :P
<sagaci> :)
<verwilst> but tracking down the location of the module so i can maybe make my own deb or compile it from source is pretty awkward too
<verwilst> the pacemaker guys strive to make not only their configs awkward and overly complex, they do the same with versioning and branches and repositories and websites ;)
<dupondje> well the pcmk can't be build anymore it seems. Its just dlm_controld daemon.
<verwilst> myeah, so cman is required now
<verwilst> yuk
<dupondje> well seems so :)
<dupondje> building the .pcmk has been removed completely, so I guess it will not come back :)
<AlanBell> didrocks: popey suggested you might be the person to poke about bug 975029, I added a patch a while ago to enable ezoom to work by default
<ubottu> Launchpad bug 975029 in compiz-plugins-main (Ubuntu) "bindings to activate ezoom not set" [Undecided,Confirmed] https://launchpad.net/bugs/975029
<didrocks> AlanBell: hey, they are not set on purpose
<AlanBell> oh ok
<didrocks> AlanBell: people triggered them without noticying at the time and got stucked
<didrocks> AlanBell: what I proposed at UDS at the time is someone looking at activating them when a11y is enabled
<AlanBell> silly people :(
<didrocks> I think that's what will make more sense, isn't it?
<AlanBell> well not really
<AlanBell> if a11y is enabled that generally means you are using orca and have no vision
<didrocks> AlanBell: hum, there are other a11y parameters, isn't it?
<AlanBell> ezoom is full of awesome if you are just the kind of person who wears glasses, or might take a large print book out of the library
<AlanBell> or someone like me doing a presentation and wanting to zoom in on stuff
<didrocks> yeah, those options like "manifier" should be exposed in gnome-control-center I guess
<didrocks> with enable/disable
<AlanBell> that makes sense
<AlanBell> there was such an option but it is bound to gnome-shell magnifier
<didrocks> AlanBell: yeah, the right patch here is to make it working on unity, and acting differently depending on the shell running
<AlanBell> yup
<AlanBell> ok, looks like this simple patch won't get in, and the proper patch is going to be out of scope at this stage
<AlanBell> ccsm to the rescue :)
<AlanBell> I will write it up in the a11y release notes
<didrocks> AlanBell: sure! thanks ;)
<AlanBell> are you going to UDS?
<didrocks> yes, as usual, you too? :)
<AlanBell> yes, looking forward to it :)
<fhilly> Hi all, I just wonder if anyone have full documentation about Ubuntu-core rootfs
<verwilst> i have an idea, let's switch back to cluster 3.0.12 for precise! :P
<verwilst> the pacemaker resources all need dlm_controld.pcmk by default so it seems
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hrw> bdmurray: may you release new version of firefox-lp-improvements so we (poor users) will get working workitems editor?
 * dholbach hugs pitti
 * pitti hugs dholback
<bdmurray> slangasek: I'm looking at a ubiquity install bug with an update-notifier conffile prompt in it
<bdmurray> bug 982473
<ubottu> Launchpad bug 982473 in ubiquity (Ubuntu) "Installation of Pangolin Beta 2 failed." [Undecided,New] https://launchpad.net/bugs/982473
<bdmurray> mvo: looking at bug 905454 and bug 961719, how could we modify the postgresql blacklist option?
<ubottu> Launchpad bug 905454 in update-manager (Ubuntu) " 'postgresql-plperl-8.4' is marked for removal but it is in the removal blacklist" [Undecided,Confirmed] https://launchpad.net/bugs/905454
<ubottu> Launchpad bug 961719 in update-manager (Ubuntu) "Cannot calcuate upgrade on postgresql-plperl-8.4" [Undecided,New] https://launchpad.net/bugs/961719
 * SpamapS starts reviewing precise-proposed uploads
<slangasek> bdmurray: where does the conffile prompt show up/
<slangasek> bdmurray: n/m, found it
<bdmurray> slangasek: it looks like it was installing an updated update-notifier-common version 0.119ubuntu7
<bdmurray> but you know that know ;-)
<slangasek> yeah, interesting
<slangasek> bdmurray: I'd like to know why there *was* an old version of that conffile around, if he was installing beta 2
<slangasek> bdmurray: because the conffile was introduced in 0.119ubuntu2, the log shows an upgrade from 0.119ubuntu1 which is the correct version from beta-1
<slangasek> er, from beta-2
<SpamapS> is precise-proposed 0-day SRU's now?
<SpamapS> or are we still using it to stage up things?
<SpamapS> I want to know how to handle the bug statuses and such
<SpamapS> started to accept bug 982267 as an SRU but now I'm not sure..
<ubottu> Launchpad bug 982267 in apport (Ubuntu Precise) "dump_acpi_tables.py crashed with UnboundLocalError in dump_acpi_table(): local variable 'hex_str' referenced before assignment" [Medium,Fix committed] https://launchpad.net/bugs/982267
<slangasek> jibel: known issues with jenkins?  I haven't seen an upgrade test since the 12th... and I was looking forward to seeing lucid->precise server go green :)
<Streamstormer> Hello, I want to build mysql-workbench 5.2.38+dfsg-3 from Debian with pbuilder
<Streamstormer> but pbuilder fails horrible with unmet dependencies: http://pastebin.ubuntu.com/932988/
<Streamstormer> can somebody give me a hint what package the problem is?
<cyphermox> Streamstormer: "Depends: libtinyxml-dev but it is not installable"
<cyphermox> and above that it mentions that it's a virtual package, and the same for libctemplate-dev. my guess is your pbuilder might not be using universe
<Streamstormer> ah ok thanks cyphermox
<pitti> mdz, cjwatson, stgraber: so TB meeting is now or in 1 h?
<mdz> pitti, soren, kees, stgraber, I have it for now
<micahg> google calendar entry was never updated, it has been at 21:00
<mdz> could someone update the calendar or delete it? :-)
<mdz> the wiki says one time and the calendar another
<pitti> I'd very much prefer having it now, it's late enough already; but ISTR that last meeting there was a decision to keep the UTC time?
<mdz> hmm, looks like I may have permission to change it
<mdz> pitti, now is somewhat better for me as well tbh
<mdz> not least because that's what I was planning for
<soren> I thought it was now too, but I'm in San Francisco, so Imy sense of time is useless.
<mdz> that sounds like quorum to me
<mdz> stgraber, kees, any objections to having the meeting now instead of +1 hour?
<maxb> cjwatson: Re subversion FTBFS... I'm up to 12 upstream revisions backported plus a couple of local hacks, and I'm still not done making it build :-(
<jibel> slangasek, yes, there was a problem with the publication which was fixed this afternoon. I confirm that lucid server is green. result should be published when the current run finishes.
<jibel> slangasek, but last run of lucid main i386 failed with http://paste.ubuntu.com/933111/
<slangasek> hmm
<slangasek> jibel: the bug isn't in python2.7-minimal if it only happens for the 'main' upgrade; but we'll probably need to reproduce this to figure out where the bug is.  How far along in the upgrade does this happen?
<jibel> slangasek, difficult to say. I uploaded the logs http://people.canonical.com/~j-lallement/lucid_main_i386_89.zip if you want to have a look.
<slangasek> jibel: I guess by "how far along" I mean "how many hours will someone have to wait to reproduce it"
<jibel> slangasek, according to the log: 2 hours
<slangasek> bdmurray: has there been only the one report of bug #982473?  I've confirmed there's no conflicting file on the beta-2 liveCD, so I really don't know what could have caused this
<ubottu> Launchpad bug 982473 in ubiquity (Ubuntu) "Installation of Pangolin Beta 2 failed." [Undecided,New] https://launchpad.net/bugs/982473
<slangasek> except cosmic rays :P
<bdmurray> slangasek: I'll look for duplicates shortly
<slangasek> ok
<jibel> or installing over an existing installation without formating
<jibel> there is this line in the log
<jibel> Preparing to replace update-notifier 0.119ubuntu1 (using .../update-notifier_0.119ubuntu7_amd64.deb)
<slangasek> jibel: 0.119ubuntu1 is the version on the CD itself, which doesn't contain that conffile
<jibel> slangasek, yeah, I'm too much in dailies and didn't see it was a beta 2 cd sorry.
<lifeless> do we support setting up full disk encryption from the GUI installer yet ?
<slangasek> lifeless: no
<bryceh> slangasek, upstart question for you
<slangasek> yay!
<bryceh> slangasek, X needs to have the DRI device set up by the kernel (i.e. i915, nvidia, et al) before it can start
<slangasek> oh, no
<slangasek> I want a different upstart question
<slangasek> not one about hybrid graphics :P
<bryceh> heh
<bryceh> no, not hybrid
<slangasek> oh, ok :)
<bryceh> slangasek, there's cases where the system starts up really fast (or the dri driver is really slow)
<bryceh> so X comes up before the kernel is ready for it to
<bryceh> 982889 is an example on -intel; we see it more often on the blobs
<slangasek> really?
<bryceh> slangasek, it seems like we need upstart to wait until the kernel driver is "ready to go" but aren't sure a) if that's possible, or b) how to set it up
<bryceh> slangasek, I would not joke about such matters
<slangasek> bryceh: I'd like to see a /var/log/udev from an affected system
<bryceh> ok
<bryceh> slangasek, I guess my real question is, are we thinking right thoughts to be thinking about upstart here, or should we be thinking different thoughts?
<Sarvatt> i915 isn't ready until 2.76 seconds into the boot process, but X already starts at 2.44 and gives up at 2.55 on that bug :(
<Sarvatt> also i'm extremely jealous of his 3 second boot time :)
<kklimonda> hmm.. can I use dpkg to query its database on a package status (installed or not) and get a easily parsable response (or a return code)?
<bryceh> indeed
<Laney> dpkq-query
<Laney> dpkg
<kklimonda> Laney: thanks, I just found the name in man dpkg and slapped my head ;)
<slangasek> bryce: because what's supposed to happen is: kernel starts scanning everything and finds out what devices it knows about; somewhere in parallel to that the initramfs hands over to upstart; udev starts up via /etc/init/udev.conf after the virtual filesystems have been mounted; then in turn, we run 'udevadm trigger' via /etc/init/udevtrigger.conf, which cold-plugs drivers for all of the hardware seen so far by replaying the kernel events t
<slangasek> ... we call udevadm settle, and only then after everything is settled do we use /etc/init/udev-fallback-graphics.conf to load vesafb as a fallback
<lifeless> slangasek: thanks
<slangasek> so if this is a bug with the upstart jobs, it's that the video doesn't get *seen* until we're already out of the initramfs
<slangasek> if we *did* see the video (which the udev log will tell us), and this is happening, then it looks like a kernel bug to me
<slangasek> oh, in fact there's a udev log on that bug; let's see
<hallyn> bryceh: oh i believe that's teh same as my bug 969489
<ubottu> Launchpad bug 969489 in lightdm (Ubuntu) "lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489
<bryceh> hallyn, interesting, I think you might be right
<hallyn> and yes that's what i was wondering, if there's any way upstart can get an event when the driver is ready...
<hallyn> If not, perhaps long-term we should add one (a uevent...)
<slangasek> hallyn: I think the event it's already keyed on is supposed to *be* that event :)
<bryceh> apw, ^^
<slangasek> drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
<slangasek> why would the kernel claim the drm device is available before it's usable?
<hallyn> slangasek: yeah, i *did* see that... which is why threw my hands in the air and filed a bug :)
<hallyn> slangasek: i wonder if nouveau does the right thing there, and nvidia is just sticking their tongues out at us
<hallyn> slangasek: so you think the drm-device-added device might be sent too early?  interesting
<bryceh> it appears to be failing in querying the drm interface version
<slangasek> bryceh: line 4396 of the udev log shows drm card0 coming up at 1.901920 after boot; the udev doesn't start on the root filesystem until 2.244658 according to BootDmesg.txt
<slangasek> bryceh: so the drm device *was* there for coldplugging, which makes this a kernel bug
<bryceh> hallyn, can you post your /var/log/Xorg.0.log and dmesg to bug 969489?
<ubottu> Launchpad bug 969489 in lightdm (Ubuntu) "lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489
<bryceh> slangasek, ok thanks
<slangasek> fundamentally, there is still a race in how we're handling video at boot... but as my earlier surprise indicates, I think it's incredibly unlikely we'll hit it in practice
<bryceh> slangasek, I'm gathering it was there but not reporting the right version
<hallyn> bryceh: I had actually attached those to the dup, bug 964830
<ubottu> Launchpad bug 969489 in lightdm (Ubuntu) "duplicate for #964830 lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489
<bryceh> hallyn, ok thanks
<Sarvatt> odd, vesafb module isnt found but its at /lib/modules/3.2.0-23-generic/kernel/drivers/video/vesafb.ko so that modprobe vesafb in udev-fallback-graphics would never work?
<hallyn> bryceh: no, actually, i don't see it.  i remember attaching both Xorg.0 and Xorg.1, but i don't see them
<Sarvatt> sudo modprobe -b vesafb
<Sarvatt> FATAL: Module vesafb not found.
<Sarvatt> might explain why proprietary drivers have used the text splash for the past few releases
<hallyn> i'll post them the next time it boots wrongly
<slangasek> Sarvatt: I think that's a generic error
<slangasek> Sarvatt: cf. dmesg
<slangasek> (and curse you for tricking me into testing that on my running intel system :)
<slangasek> gave me a very nice kernel oops on modprobe -r :P
<slangasek> bryceh: ok, there's one more thing I'm checking here
<slangasek> it's possible upstart is getting the event itself too early
<apw> slangasek, we know that the drm driver can be opened by splash before its ready.  we had to add an 'EAGAIN' failure there
<bryceh> hallyn, ok so in your case nvidia is ready at 7.9 sec
<bryceh> [    7.915284] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  295.20  Mon Feb  6 21:07:30 PST 2012
<apw> slangasek, we may or may not cope witht aht in userspace
<slangasek> i.e., when the kernel declares the device is added instead of when udev has actually loaded the driver for it
<slangasek> apw: really?
<hallyn> molasses!
<bryceh> hallyn, but X has given up by 7.3 sec
<Sarvatt> slangasek: apologies, it really does nothing here
<apw> slangasek, really yes
<bryceh> [     7.389] (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module. Please see the
<slangasek> apw: you sure you're not thinking of the EAGAIN in the VT opening?
<bryceh> hallyn, so seems to support idea it's the same problem, although the logs differ a bit
<apw> commit 6d74feca6235b463ade4ecddd1dfdb73d30a2ff7
<apw> Author: Andy Whitcroft <apw@canonical.com>
<apw> Date:   Thu Jul 29 16:48:21 2010 +0100
<apw>     UBUNTU: SAUCE: drm -- stop early access to drm devices
<apw> slangasek, ^^
<slangasek> hmm!
<slangasek> bryceh: ^^ apw did it ;P
<bryceh> ahaa
<apw> slangasek, apw stoped the machine exploding in a heap when you opened it too early ... and we return EAGAIN to tell you to try again ... how nice are we
<slangasek> bryceh: are the timestamps in Xorg.log time since boot?
<bryceh> slangasek, I believe so, yes
<slangasek> ok
 * apw wonders if we returned ERESTARTSYS that we'd DTRT without you knowin
<bryceh> apw, is there a signal it sends when it really is ready to go, that upstart should listen for instead?
<apw> bryceh, nope not that i know of
<slangasek> apw: why does udev get the uevent at all before it's ready to go?
<apw> bryceh, its a race, we need to know the minors to tell the load method, but till its run we can't actually safely open them
<apw> w
<slangasek> that's the real question, I think
<apw> which is why we have to tell you to hang fire a sec
<slangasek> ah
<bryceh> ok, so upstart needs to catch and block and retry until it doesn't get EAGAIN?
<slangasek> no
<slangasek> upstart shouldn't do that for you
<apw> though any open can return EAGAIN and you really should damn well listen :)
<slangasek> upstart should not open the drm device at all - it's up to whatever wants to use it to handle this
<slangasek> (assuming the kernel really can't defer announcing it until it's initialized)
<apw> right, we presumably run plymouth or X and its crapping self cause the open failed
<bryceh> ok, so then _X_ should block and retry on the device until it gets something working?
<slangasek> yes
<apw> that'd be helpful if it could
<bryceh> hum
<apw> as EAGAIN really means, ooops could you try that again please
<cjwatson> jibel: even installing over an existing installation without formatting is supposed to clear out all system directories
<apw> we may be able to do it to you in the kernel, but its harder to make it safe against failure
<apw> at least you can shoot X from a shell
<bryceh> heh, was just thinking it'd be hard to make it safe against failure in X.  ;-)
<apw> bryceh, well it should only do it for open == -1 and errno == EAGAIN
 * apw looks at the time ... time for some shuteye rsn
<slangasek> bryceh: bug #969489 is going to be slightly different... binary driver, no drm, we'll *always* hit the fallback AFAIK
<ubottu> Launchpad bug 969489 in lightdm (Ubuntu) "lightdm tries (and fails) to start too early?" [Undecided,Confirmed] https://launchpad.net/bugs/969489
<slangasek> so that's a case where the events really are wrong... we just don't really have a way to fix them, because it's binary
<hallyn> slangasek: that'd be good to know, and i suppose a nice stick to force ppl like me to switch
<slangasek> hallyn: you won't have this particular issue with nouveau, for sure
<bryceh> slangasek, yeah I was just musing about that on #ubuntu-x
<roaksoax> hi guys I have a question about upgrades and dependencies. PackageA used to depend on PackageB, but now it Depends on PackageC. PackageC, however, Conflicts/Replaces on PackageB. On dist-upgrade, dpkg wants to remove packageA. However, if I install PackageC it replaces PackageB successfully. Any ideas of why would this be?
<bryceh> slangasek, so, fixing 982889 doesn't really buy us much; that case is kind of a corner case of a system with really fast hw.  the blob case is where we've seen the bulk of this type of problem, and hacking libdrm doesn't help us there.
<slangasek> well, it buys you better reliability on systems with good drivers ;P
<slangasek> but yeah, it doesn't help much if you're getting lots of complaints with nv/fglrx
<bryceh> slangasek, my guess is as more people get (faster) ssd's we may see more in general across all drivers
<bryceh> also, I need one of these SSDs :-)
<bryceh> slangasek, at least I feel like I have a better understanding of the problem, thanks.  Bummer that upstart isn't of help here though.
<slangasek> God forbid upstart should stand between X and the kernel ;)
<slangasek> if you can figure out a better way to make the kernel even reliable in the first place, that'd be something
<jtaylor> doko: is python-argparse still going to be fixed or not? its currently blocking an update of mine
<bdmurray> slangasek: so that's the only update-notifier-common conffile bug
<robert_ancell> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell
<elmo> cjwatson: would you consider a bug that asked for grub to not default to hiding when using a serial console?
<cjwatson> elmo: yes, though probably not for precise at this point (that code isn't exactly elegant and is thus delicate)
<elmo> cjwatson: sure
<elmo> cjwatson: grub-installer package, right?
<cjwatson> elmo: no, grub2
<elmo> oh, ok
<cjwatson> most probably, anyway
#ubuntu-devel 2012-04-17
<slangasek> bdmurray: ok; cosmic rays really is my best guess on that one then
<mhall119> anybody know who or what maintains this list? http://people.ubuntu.com/patches/
<Bluefoxicy> RAOF: this is so .... very strange.
<Bluefoxicy> Thunderbird hasn't bloated under hoard
<Bluefoxicy> I mean
<Bluefoxicy> Iit's running with 339MB, instead of 1.8GB which is where it got all the time while I kept restarting it.
<Bluefoxicy> after a day or so.
<Bluefoxicy> uh, guys?
 * RAOF was just googling hoard.
<Bluefoxicy> How in the heck is there a package in Main that DEPENDS ON A PACKAGE IN UNIVERSE?
<micahg> Bluefoxicy: shouldn't be, example please?
<Bluefoxicy> actually let me upgrade it to make sure
<Bluefoxicy> but my currently installed version in Precise shows gnome-session-fallback as universe
<Bluefoxicy> gnome-session is in main and depends on it
<micahg> not in precise
<micahg> the depends doesn't exist I mean
<ajmitch> it's in Suggests
<Bluefoxicy> ah
<Bluefoxicy> that explains ... most of it.
<Bluefoxicy> I was looking in Synaptic at the "Dependents" for gnome-session-fallback
<ajmitch> yeah, that likely looks at Suggests as well
<Bluefoxicy> which said that gnome-session depends on it, rather than suggests it
<ajmitch> 'reverse-depends gnome-session-fallback' is probably a bit more accurate
<micahg> apt-cache show gnome-session works also :)
<Bluefoxicy> RAOF:  man-db update in dpkg --configure seems to segfault with hoard though, be wary if you go playing with it.
<Bluefoxicy> More basically though I don't trust the behavior I'm getting.  The default allocator cannot be this bad, I'm doing something wrong somewhere.
<Bluefoxicy> ajmitch:  it says "Dependency of" in that dialog in Synaptic, maybe it should say "Suggested by" or "Recommended by" depending on if the package suggests/recommends (or is that the same thing?  I forget)
<pitti> Good morning
<micahg> hi pitti, could you please mark this proposal as merged or WIP (it's been released) https://code.launchpad.net/~jtaylor/ubuntu/oneiric/inspircd/CVE-2012-1836/+merge/102037
<ubottu> Heap-based buffer overflow in dns.cpp in InspIRCd 2.0.5 might allow remote attackers to execute arbitrary code via a crafted DNS query that uses compression. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1836)
<pitti> micahg: sure, done
<micahg> thanks
<kmc> i'm trying to build a PPA but it fails because Ubuntu's default stack-protector flags conflict with our own (more aggressive) stack-protector flags
<kmc> i tried "export DEB_BUILD_HARDENING_STACKPROTECTOR=0" in debian/rules but it seems to have no effect
<kmc> here is the PPA, the failure is on Precise: https://code.launchpad.net/~keithw/+recipe/mosh-daily
<dholbach> good morning
<kees> kmc: it's the order of flags in the build.
<kees> g++ -DHAVE_CONFIG_H -I. -I../..  -I./../util  -D_FORTIFY_SOURCE=2 -Wall -Werror -Wextra -pedantic -Wno-long-long -Weffc++ -fno-strict-overflow -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector --param ssp-buffer-size=1 -fPIE -fno-default-inline -pipe -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -c -o terminaldispatcher.o terminaldispatcher.cc
<kees> you want -fstack-protector-all to go at the end, iiuc
<kees> kmc: but if you're building with dh, you can turn it off with "export DEB_BUILD_MAINT_OPTIONS = hardening=-stackprotector"
<kees> kmc: DEB_BUILD_HARDENING_STACKPROTECTOR=0 is for the older wrapper
<kmc> okay, i will try DEB_BUILD_MAINT_OPTIONS, thanks!
<kees> kmc: btw, I think --param ssp-buffer-size=1 has no affect when using -fstack-protector-all (since the char array sizes aren't checked)
<kmc> okay
<dupondje> http://archive.canonical.com needs some more bw it seems :) its dying
<dupondje> When exactly are packages accepted into -proposed (for oneiric)
<StevenK> When an SRU team member does it, or prods an archive admin to do so.
<dupondje> ok :) cause apt needs to get in to make people can upgrade to precise without problems :)
<micahg> StevenK: did you see yada is no more?
<doko> rickspencer3, are all these multiarch assignments still targeted fot the lts?
<StevenK> micahg: \o/
<rickspencer3> doko, hi
<rickspencer3> doko, I didn't target those, no
<doko> ok, good to know :)
<rickspencer3> doko, I dropped slangasek a note about it
<StevenK> micahg: I think someone else told me it had been removed a few weeks/months ago
<rickspencer3> it was just a heads up
<rickspencer3> would have been nice to get those bug reports a bit earlier in the cycle
<micahg> StevenK: I think it was removed from Debian ~1 mo ago
<jibel> cjwatson, how can he have custom apt sources and ppa enabled during an installation ? From syslog apt.spideroak.com and ppa.launchpad.net are set.
<dholbach> hyperair, hey - how are you doing? are you still planning to fix bug 980300?
<ubottu> Launchpad bug 980300 in banshee (Ubuntu) "Amazon store checkout fails because of certificate error" [Undecided,Fix committed] https://launchpad.net/bugs/980300
<hyperair> dholbach: hey. i'm a little held up due to exams, but yeah i plan to fix that as soon as mono gets unbroken in unstable so i can upload a mono-upnp fix together with it.
<dholbach> hyperair, then all the best with the exams
<hyperair> thanks =)
<robert_ancell> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<brendand> anyone know what could be the cause behind 'unable to read python frame information' when trying to debug a python application with gdb?
<brendand> i have python-dbg installed and ran python with -d
<kmc> kees: we had to add "-include /usr/share/dpkg/buildflags.mk" after the DEB_BUILD_MAINT_OPTIONS line, but with that it works.  thanks for your help!
<apw> cjwatson, we are using -proposed a bit in precise to avoid people getting messed up, however as an upgrader who had -proposed enabled by default before update, i still do after which i think defeats the idea slightly
<apw> cjwatson, i wonder if we need to be turning it off when one updates across the stable/devel boundary
<cjwatson> mhall119: nobody maintains that list; it's a set of patches generated in the very early days of Ubuntu, which continues to be published to avoid breaking links, but which is no longer added to
<cjwatson> jibel: dunno, perhaps preseeding?
<kmc> f/part
<kmc> whoops sorry
<cjwatson> apw: *shrug* personally I think people who've opted into proposed updates have opted in :)
<apw> cjwatson, :)
<Laney> well, the release upgrader could disable proposed when upgrading to a devel release
<cjwatson> Clearly it technically could; it's not clear those are the right semantics
<cjwatson> Longer-term we're intending to use -proposed in development releases as something similar to Debian unstable, and that's certainly something that many technically-minded users and developers run directly
<cjwatson> Also if we removed -proposed only pre-release that would mean testing pre-release and post-release would have different effects, which is often a questionable thing to do - and it would lose the information that somebody's opted into post-release proposed updates
<diwic> pitti, I'm trying to trace down a crash in jackd2, but I'm having troubles getting debug symbols - the library, libjackserver.so.0.1.0, is in package jackd2 but there is no jackd2-dbgsym on ddebs.ubuntu.com. Any ideas?
<Laney> I don't know what the plans are, but it seems like currently pre-release it's used mainly to avoid skew which isn't something that people need to have in their sources.list.
<Laney> If it's used for packages that we want people to run then it is indeed different.
<cjwatson> There'll be skew in the exact same way post-release
<cjwatson> So if people have trouble dealing with that, it's a wash either way
<didrocks> could someone reject https://code.launchpad.net/~arashbm/ubuntu/precise/compizconfig-settings-manager/add_quicklist/+merge/94462 please?
<cjwatson> We've certainly discussed having things for people to test in -proposed pre-release; we've not been doing so much thus far because our tools for managing -proposed currently suck
<didrocks> same story for https://code.launchpad.net/~mniess/ubuntu/precise/compiz/fix-screenshot/+merge/100539
<didrocks> and same for https://code.launchpad.net/~nathwill/ubuntu/precise/unity/lp-972247/+merge/100927
<didrocks> dholbach: compiz/unity ones done ^
<Laney> Of course the skew issues aren't solved post-release, but there is a point to -proposed then: to test fixes. If it's just used for skew avoidance pre-release then there is no point running it and it's just pain for no gain.
<Laney> I do look forward to using it more for testing, though.
<pitti> diwic: we often lose ddebs due to various problems with the hack that ddebs.u.c. is
<pitti> diwic: if it was built less than 7 days ago, I can rescue them, otherwise they are lost, I'm afraid :/
<diwic> pitti, but that means that if I build it locally it would make ddebs?
<pitti> diwic: if you install pkg-create-dbgsym, yes
<pitti> you just won't be able to process other people's core dumps with those
<diwic> pitti, thanks, will try that.
<diwic> pitti, it's fairly reproducible here (for once...!)
<pitti> diwic: but if you can reproduce the bug, it's probably easier to just do a DEB_BUILD_OPTIONS=nostrip,noopt build
<pitti> which will also give you the non-optimized variant and thus an easier to debug one
<diwic> pitti, hum, unless the noopt changes things around that causes the sigsegv not to happen
<diwic> pitti, thanks for the tip!
<pitti> diwic: yes, that often happens unfortunately
<pitti> if so, drop the noopt
<diwic> jup
<hyperair> say, how does sponsoring involving bzr work?
<hyperair> after merging, do i push to lp:ubuntu/$pkg?
<hyperair> or do i just dput?
<Laney> both
<hyperair> oh
<hyperair> okay
<hyperair> doesn't lp:ubuntu/stuff get auto-updated anyway?
<hyperair> and should i tag it?
<Laney> if you don't push then the importer will push to the branch, but that will obviously not be the 'proper' changes you made
<hyperair> i see
<hyperair> and what about tagging?
<hyperair> does the importer handle the tagging, or do i?
<Laney> i think you do it, with bzr mark-uploaded
<Laney> but not sure about that
<jelmer> hyperair, Laney: if you push the revision contents, you should do the tagging
<Laney> jelmer: I thought I head something about mark-uploaded being handled by some other part of the process these days, but I'm too far out of the loop to know anything. :(
<hyperair> jelmer: okay. does mark-uploaded do anything special or does it just tag?
<jelmer> hyperair: it just tags - "bzr tag" (no arguments) has the same effect
<Laney> aha, that is probably what I heard
<jelmer> Laney: if you leave the creation of the revision to the importer and don't push yourself, then the importer will also take care of the tagging
<hyperair> jelmer: okay, thanks. i'm using git-bzr-ng
<hyperair> it at least makes bzr bearable to use
<Laney> is it transparent wrt branches?
<jelmer> hyperair: note that git doesn't handle some characters in tag names, not sure how that interacts with git-bzr-ng
<hyperair> jelmer: ah right, i forgot about that. well this one doesn't have ~ so i guess it's fine.
<hyperair> Laney: yeah it is
<Laney> nice
<hyperair> Laney: except it doesn't have the git-buildpackage format
<Laney> how do you do that then?
<hyperair> Laney: well, if you have tarballs lying around, you can use it without an upstream branch and without pristine-tar.
<hyperair> Laney: and if it's a native package, it works fine anyway
<Laney> maybe git-bzr-ng could learn how to expose pristine-tar. the upstream branch isn't necessary
<hyperair> Laney: did bzr ever have pristine-tar?
<Laney> it does, but I don't know how it works.
<hyperair> hmm really
<Laney> I think you can have extra data associated with a revision, which is where they store the pristine-tar data
<hyperair> well either way i don't plan to do very serious work over bzr. just a couple of random commits/merges. just today i had to wrestle with incompatible bzr repository formats
<hyperair> stupid thing.
<Laney> https://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/view/head:/upstream/pristinetar.py
<jelmer> hyperair: huh?
<hyperair> jelmer: ?
<jelmer> hyperair: everything should be in the same format these days, and has been for a long time
<hyperair> hmm is /var/crash supposed to be world-writable?
<hyperair> it looks like ubuntu-bug tries to write the .upload into /var/crash and fails
<greyback> barry: ping
<dpm> hi mvo, quick question, do you know if it's possible to get a shell script to check whether a command exists, and if it doesn't, get it to call command-not-found to get the usual message with a note about in which package it can be found and the apt-get install line?
<pitti> dpm: check whether a command exists:
<pitti> if type mycommand >/dev/null 2>&1; then ...
<pitti> dpm: in the else branch you can then echo the hint
<dpm> thanks pitti, but I was wondering if I could get command-not-found to guess the package where the command is and print the hint for me
<cjwatson> /usr/lib/command-not-found mycommand
<cjwatson> modulo all the import noise which seems like a bug
<dpm> ah, let me try that, thanks!
<dpm> although that does not give me information about the package, and it tells me the command is not found, when in fact it is installed:
<dpm> http://pastebin.ubuntu.com/933828/
<dpm> I was thinking more along the lines of (after reinstalling the package):
<dpm> http://pastebin.ubuntu.com/933829/
<dpm> which basically says that the command is not present, but that it can be installed from the given package
<dpm> I get this output by running the command on the terminal
<cjwatson> no no, you do the type test and then fall back to c-n-f
<cjwatson> of course you'd need to depend on command-not-found for this since it's not installed in minimal environments
<dpm> cjwatson, as in 'if type po4a >/dev/null 2>&1; then /usr/lib/command-not-found po4a; fi'? (sorry, I'm not good at shell programming)
<seb128> dpm, what problem do you try to solve?
<dpm> seb128, ah, it's for a script to translate the Ubuntu Code of Conduct. It requires po4a to be run, and I simply wanted to add a check to see whether it is installed, and if not, output a message showing how it can be installed, in a similar way you see when you type a command on the terminal that's not installed in the system
<cjwatson> dpm: 'if ! type po4a ...' but yes
<cjwatson> also possibly an exit or break or whatever in there depending on context
<dpm> cjwatson, ah cool, yes, that works, and I'll just need to add an exit, thanks!
 * cjwatson fixes the ImportWarning noise from cnf
<cjwatson> scan.data needs an update anyway ...
<mvo> cjwatson: thanks a bunch for your fix
<cjwatson> slangasek,dupondje: this apt oneiric-proposed upload - there was a previous oneiric-proposed upload (0.8.16~exp5ubuntu13.1) from me which fixed a different set of upgrade bugs; it was superseded by a security upload but I didn't notice at the time.  Could we perhaps merge that back in?  If we're going to be going to the effort of doing full suites of upgrade testing, I think it would be worth testing this at the same time
<ogra_> ogra@horus:~$ dpkg -L libgcc1|grep copy
<ogra_> ogra@horus:~$ LANG=C dpkg -S /usr/share/doc/libgcc1/copyright
<ogra_> dpkg-query: no path found matching pattern /usr/share/doc/libgcc1/copyright.
<ogra_> ogra@horus:~$
<ogra_> hmm
<ogra_> so where does that copyright file come from ?
<ogra_> (/usr/share/doc/libgcc1/copyright exists but doesnt seem to be shipped in the package)
<ogra_> hmm, the same goes for vim-tiny
<ogra_> (and apparently a few other packages)
<cjwatson> lrwxrwxrwx 1 root root 12 Jun  7  2011 /usr/share/doc/libgcc1 -> gcc-4.6-base
<ogra_> ah, i was searching the link
<cjwatson> $ dpkg -S /usr/share/doc/gcc-4.6-base/copyright
<cjwatson> gcc-4.6-base: /usr/share/doc/gcc-4.6-base/copyright
<ogra_> but not that high up
<ogra_> thanks
<dupondje> cjwatson: so 0.8.16~exp5ubuntu13.2 does not contain 0.8.16~exp5ubuntu13.1 ?
<cjwatson> no, as documented in its changelog
<dupondje> hmz I'll check
<saidinesh5> hey guys .. i need to get a GPLed software that we wrote packaged...  (and eventually pushed to Ubuntu software center) .. so should we have to do the packaging ourselves? or can we request someone else to do the packaging magic?
<cjwatson> depends whether you can get somebody interested :)
<saidinesh5> cjwatson: are you interested? :P
<cjwatson> you really don't want to be relying on me, I have no time
<saidinesh5> Ah :/
 * saidinesh5 finds the debian packaging process quite intimidating...
<cjwatson> mvo: any thoughts on my comments on bug 938116?
<ubottu> Launchpad bug 938116 in apt (Ubuntu Precise) "update-manager crashed with SIGSEGV in DescriptionList()" [High,Confirmed] https://launchpad.net/bugs/938116
<cjwatson> I should probably make some kind of concerted effort to reproduce that
<cjwatson> mvo: notwithstanding my comments about update-manager maybe being fixed, it does look as though software-center needs changes to create a new cache; it only seems to reload the backend, not the cache, if I'm reading it correctly
<seb128> pitti, do you know if the "no hibernate by default" and "how to re-enable" it is documented somewhere? should it be in the release notes?
<seb128> pitti, I'm looking for a pointer to give on a bug report about "hibernate is missing from the gnome-session ui"
<mvo> cjwatson: let me look at this
<mvo> cjwatson: I think you are right, I should do the store.clear() before the initCache to ensure that there is nothing in the clear that plays with the no-longer-valid references to the old mmap
<pitti> seb128: right, I'll add it to the release notes
<seb128> pitti, danke
<pitti> seb128: no other documentation aside from bug 812394
<ubottu> Launchpad bug 812394 in Ayatana Design "Disable hibernate option by default" [High,Fix released] https://launchpad.net/bugs/812394
<cjwatson> mvo: well, in update-manager there definitely isn't anything like that now (I think) because of the clearing_store thing
<mvo> cjwatson: http://paste.ubuntu.com/933923/ this should help and probably makes the self.clearing_store obsolete
<dupondje> cjwatson: https://launchpadlibrarian.net/102332070/apt3.debdiff
<cjwatson> mvo: right (though might as well leave it in for now)
<cjwatson> dupondje: looks good to me (from memory)
<cjwatson> dupondje: shall I reject the one in the queue then?
<dupondje> well its preferred to directly upload the one with your patches included also I guess
<dupondje> so fine for me :)
<mvo> cjwatson: I commited that now
<cjwatson> mvo: OK, awesome - can your team deal with the s-c case?
<dupondje> slangasek: should just upload the new one then ^^
<cjwatson> mvo: I'll see if I can reproduce the crash with an older version of u-m, to see if this is more than guesswork
<cjwatson> dupondje: done
<cjwatson> (rejected, I mean)
<dupondje> thx
<mvo> cjwatson: will do
<ahasenack> hi guys, who could upload landscape-client for lucid, natty and oneiric? https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text= is the lucid one
<ahasenack> -proposed, of course
<mvo> cjwatson: just fyi, the cache reopen in s-c is done async in the "transaction-finished" signal, so that could be covered as well
<ahasenack> greyback|lunch: ping, got you a backtrace for #936560
<mvo> Mirv: hey, I fixed the ddtp import stuff today I think so hopefully by tomorrow LP has merged the updated strings
<greyback> ahasenack: magic, can you pastebin please?
<ahasenack> greyback: https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/936560/+attachment/3083556/+files/stacktrace.txt works?
<ubottu> Launchpad bug 936560 in unity-2d (Ubuntu) "unity-2d-shell crashed with SIGSEGV" [Medium,Confirmed]
<greyback> ahasenack: is there *anything* you notice that causes this crash?
<greyback> ahasenack: it's driving us nuts
<ahasenack> greyback: since this was running for a few hours already and without a crash, I started "exercising" unity-2d
<ahasenack> greyback: so I changed background (not related), fired up some apps via the pannel, maximized and minimized them, and did a lot of exposÃ¨s
<ahasenack> greyback: eventually it crashed in a few minutes after I started doing that
<ahasenack> greyback: but nothing specific I could put my finger on
<ahasenack> greyback: and seems like I'm still missing some -dbg packages
<greyback> ahasenack: interesting, I see the onActiveWorkspaceChanged signal again. I might have fix for that
<ahasenack> I only have libqt4-dbg, libqt4-script-dbg and unity-2d-dbg
<greyback> but that's again a different bt from the original one, which depended on QDeclarativeFlickable
<ahasenack> greyback: also, i remember that a notification came up while I was in exposÃ¨
<ahasenack> but the crash wasn't right at that moment
<greyback> ahasenack: ok, thanks very much for that
<greyback> ahasenack: I'll ping you if I need anything more
<ahasenack> greyback: ok, I'll leave it running in gdb again
<greyback> ahasenack: thanks
<ahasenack> greyback: any other -dbg package I should/could install before?
<ahasenack> greyback: hm, some apps appear to have died as a result of that crash, but maybe it was a coincidence. chromium and pidgin
<greyback> ahasenack: I don't think it's necessary, I do think it's our bug
<ahasenack> ok
<Mirv> mvo: woohoo, great!
<mvo> Mirv: yeah, lets hope there are not more issues hidding, but there is definitely progress :)
<Mirv> mvo: let's see, yes :) then when they hit the archives, will they be visible on precise-changes? (they used to for some older releases at least)
<mvo> Mirv: yes, should be
<Mirv> mvo: ok
<barry> greyback: pong
<mvo> cjwatson: do you have anything else pending for update-manager? or bdmurray? if not I can upload
<greyback> barry: hey, I wanted to ask you how the Alt key is behaving for you with Unity2D
<barry> greyback: with the ppa version or stock version?
<greyback> barry: 5.10 or later (so about the last 2 weeks)
<barry> greyback: not so good unfortunately.  i tried it last week after a dist-upgrade and it still gets invoked too often.  however, i think it's been narrowed down to the vm environment.  i'll try it again right now on both a vm and native
<greyback> barry: appreciated
<tsdgeos> ahasenack: if i give you a small patch file for one of the unity2d files can you check if it fixes the crash you're experimenting?
<ahasenack> tsdgeos: more or less, since I don't have a specific way to trigger it, it just eventually happens. So if it doesn't happen for one or two days, it might have helped
<tsdgeos> well
<tsdgeos> it triggers more for you than for us
<ahasenack> :)
<tsdgeos> so i think it's worth trying
<ahasenack> sure
<tsdgeos> ahasenack: can you download https://pastebin.canonical.com/64404/
<tsdgeos> put it on a file
<tsdgeos> and then go to /usr/share/unity-2d/shell/launcher
<tsdgeos> sudo patch -p0 < /path/to/that/file
<ahasenack> ok
<tsdgeos> ahasenack: actually, can you get https://pastebin.canonical.com/64405/
<tsdgeos> it adds a logging line
<tsdgeos> so if you see it
<tsdgeos> means that something that we are not accounting for happened
<ahasenack> ok
<tsdgeos> great :-)
<tsdgeos> thanks
<barry> greyback: okay, i've done a bit of testing on both systems, after a dist-upgrade and reboot.  i have some feedback (and managed to crash u2d in the meantime :)
<barry> greyback: on the native install, alt is less prone to accidentally invoke the hud, although i've noticed a few questionable invokes while doing normal stuff in emacs.  i would need a longer session on that box to know if it's a persistent problem, so i'll try to spend a bit more time hacking on that machine today
<barry> greyback: on the vm install, the alt is still unusable.  i suspect that this has something to do with the way fusion is forwarding key events to the guest os.  note that i'm using fusion 4.1.2 which is the latest release.
<Ali> Hello :D
<barry> greyback: so, on the vm box, i rebound HUD to Alt R and then did a bunch of tapping and holding to see what happened.  bug 984012 is one fo the things that happened. ;)  one of the things that *didn't* happen though is that the HUD didn't come up
<ubottu> Error: Launchpad bug 984012 could not be found
<barry> thank you ubottu, it's a private bug
<Ali> Can anyone please tell which chapters should I study from "Operating System Concepts" if I want to understand ubuntu's source?
<maco> Ali: thatll help you understand *linux*'s source
<maco> Ali: Operating System Concepts is about kernels
<maco> though iirc, it
<maco> 's written from a solaris perspective
<Ali> I see.
<maco> i was asked to help update the next version to have a linux perspective, but... my kernel-fu not up for it :P
<barry> greyback: eot :)
<Ali> Is there anything in that book that I need to know before I (try to) jump into ubuntu dev :D
<Ali> Summers are coming up. I don't want to work on meaningless self-projects :( pls help
<maco> Ali: depends what you want to develop on... kernel hacking? read the book and get good with C.  desktop applications? check out the docs for GTK (if you want to work on ubuntu desktop apps) or Qt (if you want to work on Kubuntu desktop apps), which are usually used with C or C++ respectively, but they both have Python bindings as well
<maco> Unity is written in C I think, but Unity-2d is Qt/C++ iirc
<seb128> mdke, hey, there?
<maco> I find PyGTK and PyQt to be very nice libraries to work with
<Ali> Okay. thank you :)
<Riddell> maco: several of ubuntu desktop apps are Qt now (and Unity isn't gtk at all as far as I know)
<Ali> I'll look into PyQt. I worked with Qt under windows a couple of months back.
<maco> Riddell:  i thought unity was plain ol' C, just GLib etc.
<maco> though, it's a Compiz plugin, so idk what else gets thrown in on top of that base
<bdmurray> cjwatson: I found some more recent duplicates of bug 848915
<ubottu> Launchpad bug 848915 in update-manager (Ubuntu Precise) "$DISPLAY not set in some cases, resulting in cryptic traceback" [High,Triaged] https://launchpad.net/bugs/848915
<Riddell> maco: nux as well which is a canonical made thing
<maco> Riddell: is that the graphics library that the a11y team tends to bump its collective head on?
<Riddell> maco: could well be
<greyback> barry: sorry was away. Thanks for info. VM case is tricky alright
<greyback> barry: I can't see bug 984012
<ubottu> Error: Launchpad bug 984012 could not be found
<greyback> barry: also to clarify, in VM, with HUD bound to Alt_R, HUD never appeared?
<barry> greyback: restart after crash, now it does appear on alt-r
<greyback> barry: hmm ok
<barry> greyback: let me just look and see if there's anything obviously sensitive in the apport data, and if not, i'll flip it to public
<greyback> barry: magic thanks
<cjwatson> mvo: oho
<cjwatson> mvo: I have nothing else for update-manager, but there was a bug barry was working on
<barry> greyback: i flipped it public
<cjwatson> bdmurray: damn, things I didn't want to hear ...
<barry> cjwatson, mvo: it's bug 873468 but i'm not sure we can come up with anything that brian may will like, and slangasek bumped it down to high anyway.  mvo if you have any thoughts on the bug, could you add a comment?
<ubottu> Launchpad bug 873468 in update-manager (Ubuntu Precise) "Update to latest Release failed for overloaded mirrors with no descriptive error message" [High,In progress] https://launchpad.net/bugs/873468
<cjwatson> barry: high is still release-critical
<cjwatson> mvo: don't suppose you have any thoughts on 848915, beyond cosmic rays?
<greyback> barry: got it, thanks
<barry> cjwatson: yep, but slangasek said since it's mostly an upgrade issue he won't worry about it too much for .0
<cjwatson> well, ok
<barry> (not saying it should be fixed of course)
<barry> er, *shouldn't*
<barry> cjwatson: i think the change in language is easy.  what i'm less sure about, and what maybe mvo can comment on, is whether we can actually detect if the problem is a slow/faulty mirror or something else
<slangasek> dupondje: could you provide that as an incremental patch against the previously uploaded apt 13.3, please?  easier for me to merge that way
<mvo> right, well, that one is tricky, if the server suddently starts delievering zero size files, that could be a lot, usually its a overloaded server but it might also be misconfiguration and the like
<slangasek> barry: well, I didn't say I wouldn't worry ;)
<slangasek> I worry about a lot of things!
<barry> slangasek: fair enough ;)
<doko> micahg, ScottK, slangasek: see bug 934593, proposing for precise-proposed
<ubottu> Launchpad bug 934593 in python-defaults (Ubuntu Precise) "python-all-dev, python-dev must be Arch: any for multiarch" [Medium,Triaged] https://launchpad.net/bugs/934593
<doko> slangasek, infinity: now that gcc-4.6 is in precise, I assume it is ok to upload the two linaro regressions fixes to precise-proposed?
<slangasek> doko: should be, yes
<slangasek> doko: 934593 for SRU or for -proposed -> -release?
<doko> slangasek, both is fine with me
<bdmurray> mvo: regarding update-manager I was looking at bug 961719 and the postgresql blacklist entry
<ubottu> Launchpad bug 961719 in update-manager (Ubuntu) "Cannot calcuate upgrade on postgresql-plperl-8.4" [Undecided,New] https://launchpad.net/bugs/961719
<barry> mvo: right.  and the problem as i see it in the code at that point is that we really have no indication of the cause of the problem, just that the package isn't downloadable
<mvo> bdmurray: aha, nice. did pitti give some input on that too?
<slangasek> barry: would it be enough to add in a generic "this may be caused by [...], please try again later" at the end of the message?
<mvo> barry: right
<barry> slangasek: see my proposed text in this comment: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/873468/comments/19
<ubottu> Launchpad bug 873468 in update-manager (Ubuntu Precise) "Update to latest Release failed for overloaded mirrors with no descriptive error message" [High,In progress]
<barry> slangasek: (but a "try again later" is useful)
<dupondje> slangasek: need to check that :)
<bdmurray> mvo: no pitti did not
<mvo> bdmurray: so the current regexp is pretty broad: ^postgresql-.*[0-9]\.[0-9].* - maybe pitti can give some input what should be done about it, I don't know much about postgresql, it appears this package is no longer there, maybe we need something transitional or a less strict regexp
<ScottK> doko: Is 934593 really important enough to do during final freeze?
<slangasek> cjwatson, jodh: things we do want to hear: all but one of the plymouth crasher bugs have stopped receiving streams of duplicates since the workaround landed :)
<stgraber> wow! :)
<jodh> slangasek: nice - and we think we've found the real cause of the bug too :)
<cjwatson> mvo: I was also wondering what to do with bug 979661, but I suspect that's an apt/oneiric bug
<ubottu> Launchpad bug 979661 in update-manager (Ubuntu) "oneiric to precise: debconf: unable to initialize frontend: Gnome and falls back to Dialog" [High,Confirmed] https://launchpad.net/bugs/979661
<slangasek> jodh: sweet!
<cjwatson> slangasek: excellent.  which one hasn't?
<jodh> slangasek: ^ he beat me to that question :)
<slangasek> cjwatson: bug #733453
<ubottu> Error: Launchpad bug 733453 could not be found
<cjwatson> right, which has a quite different signature
<doko> ScottK, I don't care if it goes into -proposed for a SRU or not. but the upgrade should be safe, including the replaces
<ScottK> Why not just do it in "Q"?
<ScottK> It's lack is not an RC bug.
<doko> precise should have the python2 symlinks
<mvo> cjwatson: hm, your comments indicate its a ordering problem?
<ScottK> slangasek: I don't object to what doko wants to do, but I haven't reviewed the change. At least since it's going via proposed, it can't break the archive like it did last time.
<cjwatson> mvo: it's kind of an intractable horrible thing exacerbated by an ordering problem
<cjwatson> mvo: the ordering problem means it pops up for libc6; but in between perl-base being configured and libgtk2-perl and its deps being configured, any debconf prompt would fall back to the dialog frontend and result in this symptom
<cjwatson> how likely that actually is in practice, I'm not sure
<pitti> mvo: what's the problem with the regexp? it looks correct to me
 * pitti looks at the bug
<mvo> pitti: its fine, but it matches a package that is no longer in 12.04 afaict
<pitti> mvo: that should always be the case
<pitti> mvo: the idea is that update-manager does not remove packages like postgresql-8.4 if you upgrade to precise
<mvo> cjwatson: right, we should consider moving u-m inside the live env in the longer term :/
<mvo> pitti: right, so that is not a bug? but instead the user needs to make a decision here?
<pitti> mvo: is bug 873468 actually related to that?
<ubottu> Launchpad bug 873468 in update-manager (Ubuntu Precise) "Update to latest Release failed for overloaded mirrors with no descriptive error message" [High,In progress] https://launchpad.net/bugs/873468
<pitti> it doesn't have "postg" anywhere
<pitti> mvo: not quite a decision, but he needs to upgrade his databases; there's a debconf note and documentation what to do there
<mvo> bdmurray: https://launchpad.net/bugs/961719 seems to be the right link, sorry, too many open irc windows
<ubottu> Launchpad bug 961719 in update-manager (Ubuntu) "Cannot calcuate upgrade on postgresql-plperl-8.4" [Undecided,New]
<pitti> we can't do an in-place upgrade from 8.4 to 9.1 during dist-upgrade
<pitti> (or any major version indeed)
<pitti> so u-m must not remove postgresql-X.Y due to obsolescence
<bdmurray> the right bug is actually 905454 now
<ScottK> Someone might want to mention to sabdfl that we're running out of time if the tools in Precise are going to know the name of the "Q" release without a bunch of SRUs/backports.
<pitti> mvo: oh, that's because of the libperl transition, and it's not co-installable? erk
<pitti> ScottK: already did several times..
<ScottK> Sigh.  OK.  Thanks.
<pitti> mvo: hm, I guess in theory we could reintroduce 8.4 to universe and build it against perl 5.14?
<mvo> pitti: I don't know :) I mean, I don't know enough about this topic to have a vaguely good opinion currently  (plus it was a looong day)
<pitti> mvo: the main point is that we need a co-installable -8.4, but seems the lucid version isn't installable any more in precise due to libperl5.12 and libperl5.14 conflicting
<mvo> pitti: aha, I see
<pitti> mvo: do we want apport to report package install failures post-release?
<pitti> mvo: I think we used to do that, but now we actually have a choice
<pitti> but I think we should leave it on for a while
<dupondje> slangasek: ubuntu.dupondje.be/apt_changed.debdiff
<mvo> pitti: hm, a good question, I personally don't triage them, so bdmurray is probably a better person to anser this
<pitti> bdmurray: ^ any opinion?
<bdmurray> pitti: I think it useful to catch the long tail of uninstallable packages
<pitti> bdmurray: I agree; so I leave it on for now
<pitti> we can still disable it after 12.04.1 or so
<bdmurray> okay, that's good to know
<bdmurray> pitti: did you see that full /tmp package install failure?  I opened an apport task about it
<bdmurray> bug 979928
<ubottu> Launchpad bug 979928 in Apport "package initramfs-tools 0.99ubuntu12 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/979928
<pitti> bdmurray: I did, yes; I'll fix it soon, and we can probably SRU it
<pitti> bdmurray: oh, actually we already check for /tmp/
<bdmurray> yes, we added that and I'm wondering why it didn't work out
<pitti> bdmurray: hm, 10 MB might not be enough?
<pitti> creating an initramfs certainly needs more
<pitti> bdmurray, mvo: I followed up in #905454 to explain the situation
<SpamapS> pitti: at what point does precise-proposed become SRU's instead of release quarantined packages?
<bdmurray> Is there some archive admin who could look at my upload of update-manager in oneiric-proposed?
<slangasek> dupondje: thanks!
<slangasek> pitti: 905454> if you think it's necessary to reintroduce -8.4, I guess we can do that.  Will you take care of uploading?
<slangasek> pitti: what alternatives are there?  Could we not simply release note that the admin needs to dump their dbs before upgrade?
<cjwatson> ppisati: any chance of a fix for bug 984180 for precise, so that I don't have to track this down through multiple layers of installer code again? :)
<ubottu> Launchpad bug 984180 in linux-ti-omap4 (Ubuntu) "ext2 module missing from fs-core-modules udeb." [High,Triaged] https://launchpad.net/bugs/984180
<ppisati> cjwatson: ack, will do
<cjwatson> thanks
<ppisati> cjwatson: but i think it's too late for P
<cjwatson> #ubuntu-release doesn't
<ppisati> ok then
<cjwatson> (I discussed this there first)
<ppisati> cjwatson: ack
<cjwatson> it makes the default recipe on armhf/omap4 unusable, which may not quite be a showstopper given how arm installation works but it does seem not that far off
<pitti> SpamapS: we can basically pick any time we want; we can do that decison per-package even when it's already in -proposed
<pitti> SpamapS: my gut feeling is that the cutoff point is around this Friday
<pitti> slangasek: we could release note it, but then you'd lose all the machinery that allows you to do a safe and working upgrade; aside from the fact that not everyone reads them, and it's too late after the upgrade
<pitti> slangasek: I don't fancy reintroducing 8.4 either, but I don't know how else to do this
<slangasek> pitti: well, I'm proposing that we keep the blacklist in place
<slangasek> whether we reintroduce 8.4 or not
<pitti> slangasek: *nod*
<slangasek> and if there are steps users can follow *manually* to dump dbs before upgrade, that's fine
<slangasek> if not, well, reintroducing is an option
<slangasek> pitti: I've assigned the bug to you to do with as you wish ;)
<dupondje> slangasek: you'll upload the new apt ? :)
<pitti> slangasek: ok; I think we can keep it in universe, though
<slangasek> dupondje: yes - later today
<pitti> slangasek: ok, I'll sync it back from Debian then
 * pitti unblacklists and wonders how long it takes for syncpackage to see the updated blacklist
<pitti> oh, it's in lplib
<pitti> ah no, from http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<bdmurray> slangasek: do you have an opinion on what should happen with bug 973717?
<ubottu> Launchpad bug 973717 in update-manager (Ubuntu) "Duplicate sources.list entry after upgrade lucid to precise" [Medium,Triaged] https://launchpad.net/bugs/973717
<ppisati> cjwatson: pull req sent to the kernel ml - Ubuntu-3.2.0-1412.16
<slangasek> bdmurray: seems like something we ought to fix in update-manager
<slangasek> bdmurray: I guess the pre-requisits source needs to be removed again after dist-upgrade by u-m, since it created it?
<bdmurray> slangasek: right is that something still doable for P? or should it be release noted?
<slangasek> bdmurray: seems like it's doable provided we find the time
<slangasek> tagging rls-p-tracking
<slangasek> the work to fix that is comparable to the work to write a release note for it, so we should JFDI
<mvo> slangasek: if you are not on it already I can give it a stab
<slangasek> mvo: that'd be great, thanks :)
<slangasek> mvo: there was another bug I had a question for you on yesterday... hmm... I sent you bug mail about it
 * slangasek tries to remember now
<mvo> slangasek: uhh, a bugnumber would be awsome
<slangasek> wouldn't it though ;)
<slangasek> bug #982859
<ubottu> Launchpad bug 982859 in update-manager (Ubuntu) "Upgrade from 10.04 to 12.04 breaks if skype is installed" [High,Triaged] https://launchpad.net/bugs/982859
<slangasek> found it!
<slangasek> mvo: ^^
 * ogra_ grins seeing the recent debian-arm ML thread ...
<mvo> slangasek: thanks, let me have a look
<slangasek> mvo: I couldn't work out any way in u-m to hint that we want to give priority to holding back certain packages
<mvo> slangasek: oh, let me look at this
<mvo> slangasek: but first I need to trigger a test-run of the removal of the backports sources
<slangasek> ok :)
<mvo> slangasek: eh, why do we have "release-upgrader-libapt-pkg-dev" now in the preRequists? that does not look quite right
<slangasek> mvo: I didn't put it there
 * mvo looks further
<slangasek> bug #969182
<mvo> no worries I check it out
<ubottu> Launchpad bug 969182 in update-manager (Ubuntu) "alternate-cd-upgrade from 10.04 lts to 12.04 lts beta failed" [High,Fix released] https://launchpad.net/bugs/969182
<mvo> aha, thanks. that looks like it needs a different fix
<slangasek> jodh, cjwatson: I particularly love the timeline on bug #969667, which has dupes streaming in for two weeks and stopping exactly when the plymouth upload happened
<ubottu> Error: Launchpad bug 969667 could not be found
<slangasek> (still chasing down all the possible instances of this bug)
<mvo> slangasek: update-manager should be good now, double checking welcome, but I think this is ready to upload
<slangasek> mvo: you rock
<slangasek> mvo: you can always just upload, someone will double-check in the queue
<slangasek> mvo: hmm, "disconnect model and clear store" - I'm pretty sure bdmurray has a bug number for that
<slangasek> mvo: yep, all looks good to me.  No verdict on the skype issue yet?
<mvo> slangasek: ups, sorry, that slipped my attention while I looked at a pyhton-apt issue
<slangasek> no worries
<mvo> slangasek: yeah, we can drop it, I just added it as its so popular
<slangasek> mvo: is that the best fix here?
<mvo> slangasek: the best fix is to upgrade skype :)
<slangasek> but you can't do that until you've upgraded dpkg
<mvo> slangasek: we *could* add it to the backports if there are no incompatible issues around that
 * slangasek gibbers softly
<slangasek> mvo: we not only would have to add dpkg to backports, we would also have to configure multiarch before calculating the dist-upgrade
<slangasek> mvo: I don't think this sounds like a winning plan :)
<mvo> slangasek: well, I think that this is possible and maybe even a good idea, there is some code in u-m for this already that AFAICT is not being used right now but we could enable it
<mvo> slangasek: we can talk in more detail tomorrow and/or I can create a test branch for it that might be able to even upgrade skype, I can do a test VM and check I guess
<slangasek> mvo: it still strikes me as a big change to make a week and a half before release; all of our lucid->precise upgrade testing so far has been without multiarch enabled
<slangasek> mvo: given those options, I would prefer to just drop skype from the blacklist
<slangasek> since the user can just reinstall it after upgrade
<slangasek> cr3: hi, around?
<cr3> slangasek: sure, what's up?
<slangasek> cr3: I was wondering, does Ubuntu Friendly also know how much RAM these machines have?
<cr3> slangasek: unfortunately not, I've been meaning to add that for a while :(
<slangasek> ok
<slangasek> no worries :)
<mvo> slangasek: I agree, we have a bit of time until lts upgrades are enabled, but I still agree, its risky so not good
<cr3> slangasek: the data is there though, so I should eventually be able to mine it and retrofit reports
<slangasek> mvo: do you want to axe it from the blacklist, then/
<mvo> slangasek: already commited that ;)
<slangasek> cheers :)
<slangasek> mvo: will you upload today, or would you like me to so you can punch out? :)
<mvo> slangasek: I bzr-buildpackage now
<slangasek> ok
<barry> slangasek, mvo: https://code.launchpad.net/~barry/update-manager/bug-873468/+merge/102378
<ubottu> Launchpad bug 102378 in usplash (Ubuntu) "Not able to boot with usplash" [Undecided,Invalid]
<barry> slangasek: ignore the conflict, if the scanner hasn't yet updated the branch
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<slangasek> barry: merging that does a number on debian/changelog
<slangasek> barry: can you fix that up and resubmit? (0.156.12 has just been uploaded)
<barry> slangasek: gah.  the conflict resolved locally, but clearly the mp shows there are still problems.  fixing...
<barry> slangasek: i'm just going to revert the changelog entry.  we can always add one when it gets uploaded
<slangasek> well, since you can upload it directly, that's fair :)
<barry> slangasek: except i suppose i should merge it to trunk first ;)
<slangasek> yes please
<slangasek> barry: why "packaging information" rather than the original "package information"?
<barry> slangasek: that was *your* suggestion! :)
<slangasek> I was afraid of that ;)
<slangasek> that was a cut'n'waste on my part then
<barry> i can change that back though
<slangasek> I think the original "package" reads better
<barry> agreed
<slangasek> Looks ok to me.  You're happy with the wording otherwise?
<barry> slangasek: r2382 should do the trick
<barry> slangasek: yep
<barry> slangasek: if you're good with it, i'll merge to trunk and upload
<slangasek> barry: yep, looks good to me
<barry> slangasek: thanks!
 * barry feels the pain of pre-build.sh
<slangasek> :)
<barry> and the fact that pre-build.sh requires additional build-deps not expressed in the d/control file ;)
<slangasek> yep
<barry> getting closer tho :)
<barry> slangasek: uploaded
<slangasek> woot
<slangasek> barry: thanks
<barry> np!
<slangasek> barry: do you know why tests/data-sources-list-test/sources.list changed?
<barry> slangasek: could that be an artifact of pre-build.sh?
<slangasek> maybe
<slangasek> but it references feisty, which is what's weirding me out :)
<barry> slangasek: i see those files are 'unknown' to bzr
 * slangasek nods
<slangasek> well, accepting
<barry> that *is* odd.  i built the source package in a precise chroot because of the btrfs requirement
<barry> precise-amd64 to be, er, precise, which i use all the time so i'm fairly sure it's sane
<infinity> slangasek: Probably doesn't need to keep cluttering up #is
<infinity> adconrad@cthulhu:~$ sudo su -s /bin/sh -c 'echo $PATH' - adconrad
<infinity> /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
<infinity> adconrad@cthulhu:~$ sudo su -s /bin/sh -c 'echo $PATH' adconrad
<infinity> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
<infinity> slangasek: ^-- It's definitely the '-' versus not.
<infinity> slangasek: Maybe su doesn't actually invoke login, but rather tries to mimic it, thus parsing login.defs and being silly about it?
<slangasek> maybe, yes
<infinity> slangasek: Cause, yeah, a console login is fine.
<infinity> slangasek: That said, if we're shipping a default in /etc/environment, shouldn't login.defs match anyway?
<slangasek> wouldn't that be something?
 * infinity smirks.
<slangasek> so there seem to be four different sources for path - two in /etc/login.defs, one in /etc/sudoers, one in /etc/environment :P
<infinity> slangasek: Yeahp, and all but one of those match.
<infinity> slangasek: So, fixing the fourth would be reasonable, methinks.
<infinity> Well, I guess neither one in login.defs matches, cause it thinks root shouldn't play games.
<infinity> But we should probably just make both match the Ubuntu worldview.
<slangasek> no, root not playing games is certainly by desin
<slangasek> design
<slangasek> likewise for sudoers' secure_path
<infinity> slangasek: Okay, so we just want to update the non-su path in login.defs to match the one in /etc/environment.
<infinity> slangasek: And then we have two user paths and two su paths, both matching.
<slangasek> for a first pass, yes
<infinity> Do we consider this RC?
<slangasek> long-term, we should fix whatever's keeping su - from using /etc/environment
<slangasek> no
<infinity> Alright, so we just get elmo to puppetise that change for all his login.defs? ;)
<slangasek> not unless it's new since oneiric?
<slangasek> yeah
<infinity> It's new since something older.  No idea which older.
<infinity> New since lucid would still be a problem, I'd say.
<infinity> LTS->LTS and all.
<slangasek> that's worth pinning down
<slangasek> yes, which would make it important for .1
<dupondje> Do we have a some release notes already somewhere ? :)
<bdmurray> slangasek: I noticed mov removed my fix for bug 969182.  Do you know if there is a better solution?
<ubottu> Launchpad bug 969182 in update-manager (Ubuntu) "alternate-cd-upgrade from 10.04 lts to 12.04 lts beta failed" [High,Fix released] https://launchpad.net/bugs/969182
<infinity> slangasek: New since natty too.  We have natty buildds, and they work.
<infinity> slangasek: (All the pandas are natty)
<slangasek> bdmurray: he applied another fix
<slangasek> bdmurray: (see changelog)
<bdmurray> slangasek: I'd seen the changelog just not made the connection between the removal and lines before it ;-)
<slangasek> bdmurray: ah :)
<bdmurray> slangasek: could you take a look at bug 982140?
<ubottu> Launchpad bug 982140 in imagemagick (Ubuntu) "package perlmagick 8:6.6.9.7-5ubuntu3 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [High,New] https://launchpad.net/bugs/982140
<sbeattie> bdmurray: bug 983559 should probably go on your radar
<ubottu> Launchpad bug 983559 in update-notifier (Ubuntu) "package-data-downloader utility does not honor apt http proxy settings" [Medium,Triaged] https://launchpad.net/bugs/983559
<slangasek> bdmurray: 982140 - duplicate of the dpkg SRU bug
<slangasek> bug #902603
<ubottu> Launchpad bug 902603 in dpkg (Ubuntu Oneiric) "When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared" [High,Fix committed] https://launchpad.net/bugs/902603
<bdmurray> slangasek: it seems to me there could be a search done for those bugs â¦ 'Noting disappearnce' for an :i386 package on a amd64 system.  Does that sound about right?
<slangasek> bdmurray: yes, definitely
<slangasek> bdmurray: though I think the higher priority is for someone to verify the SRU so we get a fixed dpkg out to protect people from hitting this one
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<barry> bdmurray: can lp bugs be un-duped? and if so, do you need special permission to do so?
<bdmurray> barry: yes, no
<barry> bdmurray: i suck.  where is the magic button? ;)
<StevenK> "Unmark as duplicate" top right?
<barry> StevenK: am i smoking crack?  https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/773823
<ubottu> Launchpad bug 289952 in update-manager (Ubuntu) "duplicate for #773823 update-manager rewrites sources.list to only use official mirrors" [Medium,Triaged]
#ubuntu-devel 2012-04-18
<StevenK> barry: Hit the edit icon next to 'duplicate of ...'
<barry> StevenK: oh, *and* delete the bug number then hit the check box. :)  but thanks!
<StevenK> barry: Well, yeah, but I thought once I got you over the hurdle of *finding* the link, you could figure out the rest. :-)
<barry> StevenK: i put my 10,000 monkey-clone army on it and they shakespeare'd it in 300ms
<kees> slangasek: is there a bug open for the targoniness of booting 64-bit kernels on a 32-bit CPU?
<kees> slangasek: afaict, the kernel itself just enters a hlt loop and doesn't display _anything_.
<slangasek> kees: bug #983825?
<ubottu> Launchpad bug 983825 in gfxboot-theme-ubuntu (Ubuntu) "Present helpful message when booting 64-bit medium on 32-bit machine" [Medium,Triaged] https://launchpad.net/bugs/983825
<kees> perfecto
<pitti> Good morning
<sladen> pitti: morgen!
<dholbach> good morning
<tsdgeos> ahasenack: having any luck with the patched unity-2d i told you? Too soon to declare victory maybe?
<ahasenack> tsdgeos: yeah, too soon
<tsdgeos> oki :-)
<seb128> ev, hey, just curious but is there somewhere where we can get news about the status of your work on whoopsie, the db, etc?
<ev> seb128: actually, let me forward you an email I sent about it to my team soliciting input
<ev> would be excellent to hear your thoughts
<seb128> ev, thanks ;-)
<doko> jibel: about 983981, is this pure lucid, or lucid-updates?
<jibel> bug 983981
<ubottu> Launchpad bug 983981 in update-manager (Ubuntu) "Lucid -> Precise main failed to upgrade: ERROR: pycompile:Requested versions are not installed dpkg: error processing python2.7-minimal installed post-installation script returned error exit status 3" [High,New] https://launchpad.net/bugs/983981
<jibel> lucid updates
<jibel> doko, ^
<doko> jibel, but not for any update, correct?
<jibel> doko, correct. Only the test referenced in the report fails.
<doko> jibel, are the tarballs for the chroots available somewhere?
<mvo> Mirv: new ddtp stuff uploaded
<mterry> RAOF, heyo.  Got a moment to talk about X and keyboard layouts?
<RAOF> I'll say yes.
<mterry> RAOF, I'm seeing "key types not defined" when trying to have xkbfile X extension use the "fr oss" layout
<mterry> What does it mean for a map to not have it's key types defined?
<mterry> RAOF, (this is bug 960096)
<ubottu> Launchpad bug 960096 in ubiquity (Ubuntu) "Live session started with wrong layout" [High,Triaged] https://launchpad.net/bugs/960096
<RAOF> Hm.  I don't know at the moment.  Let me check
<mterry> but if you do look at the bug, look only at the last few comments.  Several flaws have been glommed into the same bug report
<mterry> I'm working on the most recent one
<dobey> should i not get a "Waiting for Approval" mail for something i uploaded to oneiric-proposed?
<stgraber> dobey: yes, you should
<dobey> hrmm, i haven't gotten one, and i uploaded it last night
<dobey> ubuntuone-storage-protocol_2.0.1-0ubuntu1_source.changes
<stgraber> dobey: it's not in unapproved for oneiric so it probably got lost somewhere
<stgraber> bdmurray: iso tracker updated published, bug search should be working fine now with duplicates
<dobey> stgraber: should i just rm the .upload file and try again?
<stgraber> dobey: yep
<dobey> ok
<dobey> says successfully uploaded again. hopefully it worked this time
<RAOF> Oh, wow.
<RAOF> mterry: The XKB protocol is quite impressive
<mterry> RAOF, in a good way?  :)
<RAOF> In a bloodymindedly baroque way.
<RAOF> Also, it supports keys in radio groups for some reason.
<RAOF> On the off-chance you'd like to map your keyboard such that exactly one of 'a', 'b' or 'c' is considered to be pressed at any one time.
<RAOF> The protocol specification is also a light-weight 107 page PDF, plus appendicies.
 * RAOF has thus far managed to avoid looking too closely at the direction of XKB in the hope that it'd go away if he didn't make eye contact.
<ScottK> mvo: I just noticed Bug #984906.  If you end up doing another update-manager upload, I would appreciate it if you could include the fix for it as well.
<ubottu> Launchpad bug 984906 in update-manager (Ubuntu) "update-manager-kde short description wrong" [Low,New] https://launchpad.net/bugs/984906
<RAOF> mterry: I'll take a longer gander at it tomorrow; 10pm beckons.
<mterry> RAOF, OK.  thanks!
<Mirv> mvo: ok, great! Debian itself has had apparently problems that the translations haven't been uploaded for some while, but at least now it should be up-to-date what Debian has on its servers
<Mirv> apparently some unicode problem was just now found
<doko> ScottK, do you know why pycompile in lucid still has DEFAULT_VERSION = (2, 5) ?
<ScottK> No.
<ScottK> mvo: Very quick (with the commit for the bug fix).  Thanks.
<mvo> ScottK: sure, that was a tiny one, thanks for the report and the irc ping
<ScottK> Should help the production metrics for the week....
<saidinesh5> hi guys..... just made a package for a software of ours
<saidinesh5> http://paste.kde.org/459398/
<saidinesh5> so basically are these warnings safe to ignore?
<saidinesh5> especially the ones regarding cannot find lib needed for <package>
<saidinesh5> (basically vsxu_artiste, vsxu_player, vsxu_server are all dependant on libvsxu  , and i ve specified that in the control file)
<dobey> stgraber: ugh. it's telling me the signer doesn't have upload rights now. i guess something got mucked up when we made the packageset for precise for u1 stuff, and now i can't upload to the older ubuntus?
<stgraber> dobey: that could be, ppu are for all releases but package sets are per release
<stgraber> dobey: as we created the ubuntuone packaget set in precise, you probably lost your upload rights to older releases in the process
<dobey> stgraber: ugh. any way to fix it? or will i have to just do merge proposals now for all the packages in older ubuntus?
<stgraber> dobey: launchpad doesn't let me create a copy of the package set in oneiric apparently ...
<dobey> hmm
<stgraber> dobey: I can do a temporary hack to let that one in though, what's the source package name?
<dobey> stgraber: well i have a few more packages to do as well, and was expecting to have to do a proposal for at least one. i guess i'll just do it for all. i guess this also explains why my bug nominations weren't automatically approving on a couple packages for the older ubuntus as well
<Laney> stgraber: hrm, why can't you create it?
<stgraber> stgraber@castiana:~/data/code/ubuntu-archive-tools$ python edit_acl.py create -P ubuntuone -S oneiric -p developer-membership-board
<dobey> stgraber: and i'll have to do similar SRUs for natty and probably lucid soon as well, so don't want to keep wasting time with temporary hacks
<stgraber> Package set ubuntuone already exists
<stgraber> stgraber@castiana:~/data/code/ubuntu-archive-tools$ python edit_acl.py add -P ubuntuone -S oneiric -p ubuntu-ubuntuone-dev
<stgraber> There was a 404 error:
<stgraber> No such package set (in the specified distro series): 'ubuntuone'.
<stgraber> Laney: ^
<Laney> sounds buggy
<cjwatson> edit_acl.py create IIRC
<cjwatson> oh, /me reads again
<Laney> that was in his first paste
<cjwatson> odd
<Laney> I guess you could namespace it as a workaroudn
<stgraber> I probably could but then we might end up with both in Q as LP seems to do some weird things when creating a new series...
<Laney> I recall bugs around initialising packagesets
<Laney> check with #lp?
<stgraber> well, I have a couple of "critical" bugs opened for a few months regarding the packageset table being a bit of a mess
<Laney> I would guess/hope that it only uses sets in n to initialise n+1, but â¦
<stgraber> it doesn't ;)
<stgraber> that's what caused most of our existing bugs
<ScottK> micahg: Would you or some other mozillateamish person please look at esteid-browser-plugin in the New queue and see if it's now something that's supportable from your POV?
<Laney> all I can suggest is that you seek counsel from a Launchpad developer about the best way to proceed
<cjwatson> I've been meaning to fix that initialisation bug
<cjwatson> it should be easy
<cjwatson> did you at least make sure that the data in P is clean?
<stgraber> for ubuntuone, it should be, it's a new package set
<Laney> there's some duplication
<Laney> I can't remember the details
<stgraber> for some of the other packagesets, no, we have a ton of duplicates
<cjwatson> I meant for all package sets - I knew it was broken but I haven't had a chance to go through and sanitise it
<cjwatson> we should probably try to clean that up before we open Q
<stgraber> I got a few fixed by the Launchpad guys, then they filed another bug to get that table cleaned up and nothing happened since
<stgraber> yeah, fixing the init code and cleaning up the current mess before Q would be good
<cjwatson> can't we clean it up by hand?
<stgraber> not with edit_acl
<cjwatson> how come?
<stgraber> the API does checks that the DB doesn't ;)
<cjwatson> bah
<cjwatson> but I suspect that cleaning things up requires manual attention
<stgraber> cjwatson: bug 887185
<ubottu> Launchpad bug 887185 in Launchpad itself "ArchivePermission allows duplicated rows" [Critical,Triaged] https://launchpad.net/bugs/887185
<stgraber> cjwatson: and the initial question: https://answers.launchpad.net/launchpad/+question/177449
<stgraber> so when trying to fix from the API, I get "NotOneError" so only someone with direct DB access can fix it
<cjwatson> we could relax that for removal
<cjwatson> that would probably be better than db hackery
<stgraber> that'd work, then we can cleanup the current mess with edit_acl
<cjwatson> I have to do RC stuff first though
<cjwatson> but I think I can look at this
<stgraber> ah, the packageset creation part is an edit_acl bug, I'll fix that one
<stgraber> it checks for existing packageset but without giving a distroseries
<cjwatson> ok
<cjwatson> makes sense given what I was doing when I wrote that
<stgraber> dobey: fixed for oneiric
<dobey> stgraber: thanks
<Laney> nice
<dobey> stgraber: can we get it fixed for natty and lucid as well?
<stgraber> dobey: are you uploading to these two today?
<stgraber> it takes me time to create the new packageset as I need to do it by hand depending on what packages were there (no magic copy function), so I'm happy to do it but won't spend the extra time until it's needed ;)
<dobey> stgraber: probably not today no
<Laney> implement the copy function :P
<stgraber> Laney: almost tempted to do it, then ask LP not to do any copying when creating a new series and just use edit_acl for it ;)
<Laney> heh
<Laney> I was thinking that it would be useful when we create new sets in future
<stgraber> cjwatson: actually, would that be easier? ^ :)
<stgraber> I think I can implement a new "copy" function to edit_acl that takes a packageset and two series and just re-create it
<cjwatson> hm, not sure, the init stuff was partly for derived distributions and I don't know what they wanted here
<cjwatson> I think it would be *quicker* to fix the bug at hand and then consider such a redesign afterwards
<dobey> ok. well i'll ping again when i need to upload to natty and lucid. thanks again stgraber!
<stgraber> dobey: np
<SpamapS> [160199.816023] [Hardware Error]: Machine check events logged
<SpamapS> ruh roh
<stgraber> dobey: natty and lucid done (I added a copy function quickly ;))
<stgraber> cjwatson: I just filed a merge proposal for that do_create distroseries fix and to add a basic do_copy
 * slangasek hugs didrocks for his gnome session
 * didrocks hugs slangasek back :)
<didrocks> Not sure you saw the discussion but it was hot ;)
<slangasek> didrocks: the one on #ubuntu-release, I saw :)
<didrocks> yeah ;)
<vibhav> I missed it again :(
<andreas__> tsdgeos: no backtraces yet, looking promising
<andreas__> tsdgeos: but no logging either, so that code wasn't triggered
<SpamapS> wow.. I went like, a whole week without a dist-upgrade and now I have 600 packages to update.
<tsdgeos> andreas__: ok, so the code didn't really do anything useful
 * SpamapS probably should uninstall some packages :-P
<SpamapS> ahh.. the gnome 3.4.1 bump is the source of most of it :-P
<SpamapS> need an opinion on bug 981130 ..
<ubottu> Launchpad bug 981130 in ceph (Ubuntu Precise) "python-ceph Depends on librgw1, which is no longer built" [Undecided,New] https://launchpad.net/bugs/981130
<SpamapS> its a small python library.
<SpamapS> with three modules..
<SpamapS> only one of them needs librgw1
<SpamapS> should we just not install the module that needs rgw1 .. or just drop the dep on librgw1 and ship a module that won't work?
<dobey> stgraber: cool. thanks much!
<ScottK> SpamapS: I vote for only shipping working stuff.
<doko> seb128, why did you reassign 960967 to libjpeg8?
<seb128> doko, I though it was the lib jtransform_execute_transform() and providing do_rot_270()
<seb128> doko, where the segfault happens
<seb128> doko, I guess I was wrong, where should it go?
<jtaylor> doko: sorry I have probably missed your reply to the argparse issue, will it still be fixed?
<doko> jtaylor, it is fixed
<doko> seb128, libjpeg is built from jpeg-turbo
<jtaylor> doko: oh I don't have -proposed enabled yet, thanks
<seb128> doko, oh ok, I was unsure, I picked the wrong one
<seb128> doko, I'm fixing it
<seb128> too many libjpeg* ;-)
<doko> seb128, and it appears to be a duplicate
<SpamapS> ScottK: me too.. discussing w/ upstream what the best course is
<ScottK> OK.
<seb128> doko, could well be, I didn't check for duplicates
<seb128> doko, it has a picture example included though which might be useful
<micahg> ScottK: at this point, chrisccoulson needs to review esteid-browser-plugin
<ScottK> micahg: OK.  Thanks.  chrisccoulson?
<ScottK> (it's in new again in case you missed it)
<PaoloRotolo> Hi all!
<slangasek> pitti: what do you think of bug #937249?
<ubottu> Launchpad bug 937249 in apport (Ubuntu) "apport-gtk crashed with SIGSEGV in composite_line()" [High,Confirmed] https://launchpad.net/bugs/937249
<saidinesh5> apachelogger: here?
<saidinesh5> hmm... any ubuntu packagers here?
<kklimonda> saidinesh5: well, it's a channel for ubuntu developers so it's a possibility that some ubuntu packages sit here ;)
<kklimonda> saidinesh5: it's better to ask the actual question
<saidinesh5> heheh .. well basically ..... i just created a debian/* stuff for a project that i m involved with
<saidinesh5> so basically it is split up into (libvsxu , libvsxu-dev , vsxu-artiste, vsxu-player,....)
<saidinesh5> (everything depends on libvsxu)
<saidinesh5> so 1) should i have to include the lib/*.so in the libvsxu-dev.install also ?
<saidinesh5> or just making it depend on libvsxu is enough?
<saidinesh5> ?
<cjwatson> saidinesh5: typically *.so.* should go in the runtime packages and *.so should go in the -dev packages
<cjwatson> *.so being symlinks to *.so.* in any sane upstream package
<saidinesh5> cjwatson: you mean *.so.* is like *.so.version?
<cjwatson> saidinesh5: that's what I mean, yes
 * saidinesh5 should probably edit some CMakeFiles for this now
<saidinesh5> cjwatson: could you also take a look at the ppa i ve created and the recipie i m trying to make?
<saidinesh5> cjwatson: CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE):
<saidinesh5>   Could NOT find OpenGL (missing: OPENGL_gl_LIBRARY)
<barry> slangasek, cjwatson: re bug 924079.  i've read the bug and cjwatson's post (which seems to have no follow ups?).  what needs to be done here?  are you looking for someone to verify that if the patches were sru'd that it solves the problem?  there still seems to be the issue of abi breakage though, right?
<ubottu> Launchpad bug 924079 in apt (Ubuntu Oneiric) "do-release-upgrade fails to upgrade from Oneiric to Precise" [High,Triaged] https://launchpad.net/bugs/924079
<saidinesh5> what should i include so that that builds?
<slangasek> barry: cjwatson's suggestion today was that this might be better done as a release-upgrader-specific backport, like we did for lucid
<slangasek> barry: I don't know if that's a better answer than trying to SRU patches to apt; mvo's your expert :)
<barry> slangasek: yeah, sorry mumble was so problematic today ;)
<slangasek> :)
<barry> slangasek: i'll look into it and make sure to follow up with mvo in the morning (he appears to be off-line right now)
<slangasek> barry: ack
<saidinesh5> but libgl and stuff should be installed because of libglfw-dev ...shouldnt they?
<cjwatson> saidinesh5: sorry, I'm not going to have time to look at your package (especially if it's cmake, which I don't speak at all) - just offering general advice
<saidinesh5> cjwatson: ah its okay.. basically i m just a little confused about the package dependancy...
<cjwatson> barry: I vaguely remember that mvo put together a non-ABI-breaking patch for that, too, but I don't have a record of it, so perhaps chase that up
<cjwatson> barry: it may ultimately need to be an SRU to apt - I'm just worried about timing, mostly
<saidinesh5> like it says it cant find OpenGL libs. but libglfw-dev should pull libgl and friends ...... isnt it?
<cjwatson> saidinesh5: my first guess would be that the upstream build system is buggy and can't cope with libraries installed in multiarch locations (e.g. /usr/lib/x86_64-linux-gnu/), but it may not be that
<cjwatson> you'll need to look into whatever logs it gives you (if any) in detail
<barry> cjwatson: ack
 * saidinesh5 checks 
<saidinesh5> libxrandr2 (>= 2:1.3.0-3), libc6 (>= 2.1.3), libgcc1 (>= 1:4.1.1), libglfw2 (>= 2.6), libpng12-0 (>= 1.2.0), libjpeg8 (>= 6b1-1), libglew1.6 (>=1.6.0)
<saidinesh5> bleh
<saidinesh5> they should have been -dev libs
<cjwatson> are those Depends or Build-Depends?
<saidinesh5> i put them as Build-Depends
<cjwatson> right, that would be wrong
<cjwatson> also micromanaging :) you don't need to build-dep on the C library ...
<saidinesh5> Ahh ya...
<cjwatson> in most cases you probably shouldn't version the build-deps either, unless you know you require API (not ABI) added in that version
<cjwatson> note that runtime depends don't necessarily correspond to sensible minimum versions on build-depends
<saidinesh5> Ahh cool that answers my next questioN! :D
<saidinesh5> cjwatson: if i include libglfw-dev will that install the needed headers for libglfw? (like libgl1-mesa-dev etc..) ?
<saidinesh5> (like libglfw depends on libgl)
<jibel> doko, same error on upgrade with DEFAULT_VERSION = (2, 6) I collected a bit more informations with debug enabled. I'll update the report.
<cjwatson> saidinesh5: don't know offhand, look at its dependencies and that should say
<saidinesh5> hmm.... looking into it cjwatson :)
<slangasek> bryceh: I don't suppose bug #966868 resembles the X-racing-drm bug of yours?
<ubottu> Error: Launchpad bug 966868 could not be found
<slangasek> oh hush
<bryceh> slangasek, hmm, looking
<bryceh> someone needs a name for when you're investigating one bug and notice three other unrelated bugs along the way...
<stgraber> bryceh: normal debugging?
<slangasek> bryceh: yak shaving? :)
<bryceh> there we go
<bryceh> slangasek, anyway, yeah it seems to be crashing trying to open the intel device driver.  could be same bug
<bryceh> er, same issue
<slangasek> ok
<bryceh> slangasek, i915 got initialized around 6.4-6.5 sec; if you can tell when plymouth was firing you can see if it was before or after that.  that'd be more definitive
<slangasek> bryceh: yeah, I don't have timestamps for that by default
<bryceh> slangasek, adding plymouth:debug might make some timestamps show up.  (sudo xdiagnose, first option)
<slangasek> yep
<slangasek> actually, no, even then we don't get timestamps
<bryceh> slangasek, #4 in that stack looks like libdrm code
<bryceh> dunno if its the same libdrm code as that other intel bug though.
<bryceh> slangasek, posted comment on the bug.  I think escalating to Intel would be the logical next action.
<slangasek> bryceh: if the raciness is due to an Ubuntu sauce patch?  (or is that now upstreamed?)
<bryceh> slangasek, I think so.  They actually do care about ensuring their stuff works with Ubuntu.
<slangasek> ok
<bryceh> slangasek, if nothing else they may be able to give advice
<slangasek> what's the escalation path?  do we need apw looped in?
<bryceh> I usually escalate and then bring apw in once I get some feedback from upstream
<slangasek> ok
<slangasek> I'm happy to be part of the conversation if it helps
<bryceh> slangasek, I'd expect so
<bryceh> slangasek, fwiw I do think that we'll get a flame back telling us not to run the kernel i915 this way.  but we'll see.
<slangasek> :)
<bryceh> slangasek, you'll need to manually sub yourself to https://bugs.freedesktop.org//show_bug.cgi?id=48894 because bugzilla sucks
<ubottu> Freedesktop bug 48894 in Driver/intel "plymouthd crashed with SIGABRT in __assert_fail_base()" [Major,New: ]
 * slangasek searches for the 'subscribe' button because bugzilla sucks
<bryceh> put your email addy in cc
<bryceh> you might have to register first
<slangasek> nah, am registered, just couldn't remember the next step :)
<slangasek> bryceh: how much do you know about the kernel events that we get for drm devices
<slangasek> ?
<bryceh> slangasek, not much, I generally don't play at that level too often
<bryceh> slangasek, past experiences tinkering in libdrm has left me with a general dread of this part of  the stack
<SpamapS> Ugh, I never know where to ask this
<SpamapS> UDD ...
<slangasek> bryceh: ;)
<SpamapS> what do I do when merge-upstream decides to rename .. everything
<bryceh> SpamapS, turn to drink?
<ScottK> SpamapS: dput and let the importer sort it out.
<SpamapS> ScottK: I have staged changes. :-/
<SpamapS> so my only recourse is to apply those manually w/ patch
<SpamapS> which is what I've done
<SpamapS> but.. that *sucks*
<slangasek> bryceh: so the "Best" fix is still to just have a reliable event that the upstart jobs can key off of... I'm wondering if there actually is a different event already that meets this need, or if not, how we should fix it so there is
<ScottK> What's more important: The history or the brain cells lost figuring out the right UDD way to do it?
<slangasek> SpamapS: what branch, what command?
<SpamapS> slangasek: lp:ubuntu/juju
<SpamapS> slangasek: have tried both from a tarball and from the upstream branch..
<SpamapS> it decised that the directory 'juju' is in conflict
<slangasek> heh
<SpamapS> which would be.. the entire program :-P
<slangasek> that suggests past branch divergence
<SpamapS> Possibly
<slangasek> what's the command I should run to try to reproduce this?
<SpamapS> slangasek: bzr merge-upstream lp:juju
<slangasek> hmm, revision 1.1.11 doesn't help... imported an upstream tarball without merging the branch
<slangasek> SpamapS: is there also a tarball to merge at the same time?
<slangasek> the "proper" answer is to merge both, not either/or
<bryceh> slangasek, yeah an event seems like a better solution.  the suggestion yesterday to hack a sleep loop into libdrm hasn't been sitting well with me.
<SpamapS> slangasek: bzr export from the juju trunk to a tarball produces the same result, because thats basically what merge-upstream does anyway
<slangasek> SpamapS: so there isn't a pre-existing tarball?
<slangasek> are you *creating* one as part of this upload?
<apw> bryceh, do i need to take that patch to upstream on the morrow and see waht they make of it?  perhaps they'll have some better ideas
<SpamapS> slangasek: yes
<SpamapS> slangasek: 0.5+bzr531 has never been uploaded
<slangasek> SpamapS: ok, so you should do the bzr export first to get your tarball, then reinject it with the merge-upstream
<SpamapS> slangasek: thats what I tried. *same* result.
<slangasek> ok
<SpamapS> because thats exactly what merge-upstream does IIRC
<bryceh> apw, I think so, yes.  If you have the link still handy I can post it to them now
<slangasek> SpamapS: give me a minute for my terminal to catch up with us then :)
<SpamapS> slangasek: I don't know why I seem to be the only one who runs into all the UDD weirdness. :-P
<apw> bryceh, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commitdiff;h=6d74feca6235b463ade4ecddd1dfdb73d30a2ff7;hp=e29a4668d7441aa88d8015da51674a7e8159312b
<slangasek> SpamapS: well for starters, I've never seen this message before from bzr merge:
<apw> bryceh, thats what we are using to prevent the crash
<slangasek> Exporting upstream branch revision kapil.thangavelu@canonical.com-20120415230912-d0itvlx1i2ft0c41 to create the tarball
<slangasek> so the juju branch seems special :)
<SpamapS> slangasek: haha ok
<apw> bryceh, so ... drop me an email with wherever we are at so i can follow up in the am
 * SpamapS hates being special
<hallyn> hm, so if someone reports a broken do-release-upgrade, but because they had left processes running (causing deluser to fail), do we call that invalid, or should the pkg upgrade deal with it gracefully?
<bryceh> apw, add yourself to cc on https://bugs.freedesktop.org//show_bug.cgi?id=48894
<ubottu> Freedesktop bug 48894 in Driver/intel "plymouthd crashed with SIGABRT in __assert_fail_base()" [Major,New: ]
<slangasek> SpamapS: so what's astonishing to me is not that there was a directory conflict, but that the *contents* of those directories seem to be entirely disjoint
<slangasek> $ diff -uNr docs* | diffstat
<slangasek> [...]
<slangasek>  37 files changed, 4685 insertions(+), 78 deletions(-)
<slangasek> SpamapS: why does the upstream branch look nothing like the current UDD branch?
<SpamapS> slangasek: thats about right.. lots of features landed
<bryceh> apw, added you to the cc
<SpamapS> slangasek: though thats not the same diffstat I see in the branch doing 'bzr diff -c 519..531'
<SpamapS> slangasek: would it be better to back up to 0.5+bzr504-0ubuntu1  (r10) ?
<slangasek> well, let's see
<SpamapS> slangasek: I have to step AFK for 15 minutes .. will be back ASAP
<slangasek> bryceh: someone want to tell fd.o they're not in UTC? :P
<bryceh> slangasek, OMG don't you dare
<slangasek> you like all incoming bugzilla mail being sorted 7 hours in the past? :)
<bryceh> slangasek, that's a quick path to getting flamed by mithrandir
<slangasek> heh
<bryceh> seriously, hang out on #freedesktop a while
<slangasek> I'm happy for them to use UTC for their timezone setting
<slangasek> as long as they set their friggin' clocks right
<bryceh> slangasek, I recommend raising the issue with him by pinging it (but don't mention what the ping is about).  he loves that.
<slangasek> hahaha
<slangasek> bryceh: I have to be careful; if I taunt him too much, he'll make upstart in Debian a metapackage depending on systemd
<bdmurray> slangasek: in bug 984693 update-notifier was just finishing up correct?
<ubottu> Launchpad bug 984693 in msttcorefonts (Ubuntu) "ttf-mscorefonts-installer also installs Flash" [Undecided,New] https://launchpad.net/bugs/984693
<slangasek> bdmurray: yes, apparently they had the package installed already but the trigger hadn't done its job yet
<bryceh> slangasek, o_O
<bryceh> slangasek, you're gonna get me banned off freedesktop!
<slangasek> ;)
<SpamapS> slangasek: back
<bryceh> slangasek, got a little feedback from jbarnes on the bug
<SpamapS> slangasek: so, is there some version missing from the graph in that branch?
<slangasek> SpamapS: well, the version you pointed me at failed the same way
<slangasek> looking at the history now
<slangasek> SpamapS: has this merge-upstream *ever* worked for you, when pulling from the branch?
<smoser> hey...
<smoser> how can i make my system not multiarch ?
<slangasek> because sure enough, these main directories were added separately in the two branches
<smoser> i'm looking for 'apt-get update' to not get i386 lists or show packages.
<slangasek> smoser: you can nuke /etc/dpkg/dpkg.cfg.d/multiarch; but this will make some software uninstallable for you
<SpamapS> slangasek: I think so. But its hard to recall frankly. I have a lot of merge-upstream issues
<smoser> slangasek, i'm ok with that. thank you.
<slangasek> SpamapS: 'bzr log -n0 juju' shows a completely different history for the directory on the ubuntu branch vs. the upstream branch
<slangasek> SpamapS: so you can do one of two things: 1) merge from the tarball only, which shouldn't fail like this; 2) port your local changes over on a one-time basis and nuke all of the .moved directories, which gets you in sync with the upstream branch going forward
<SpamapS> slangasek: I think at some point I did an upload w/o committing.. so the importer grabbed it instead. Perhaps thats the issue?
<slangasek> well, the first commit by you on the UDD branch is revno 7
<slangasek> before that they were auto-imported
<SpamapS> ok
<SpamapS> I like the idea of nuking and getting back on track
<slangasek> but *none* of the UDD branch history shows the history of the upstream branch... so what you're seeing now is the inevitable result of trying to merge two branches without shared history
<SpamapS> but I'm not sure what that means.. so you're saying back up to the last uploaded version, merge upstream, fix .moved dirs, then manually patch in my changes?
<slangasek> with or without the "Back up" part
<SpamapS> ok, and would just bzr rm'ing the .moved dirs suffice?
<slangasek> or maybe just 'bzr resolve *.moved'
<slangasek> (which you have to do anyway; I don't remember if the resolve also rm's in this case)
<SpamapS> it doesn't
<SpamapS> have to rm first
<SpamapS> there are issues with that approach though
<SpamapS> the 'examples' dir, for instance, has no README file now.. but the upstream version definitely does have that README file
<slangasek> ah, really?
<SpamapS> yeah, its like only things that got touched are there
<slangasek> hmmmm
<SpamapS> frankly I'm ready to just build a .dsc as I see fit, and let the importer handle it.
<slangasek> well, that's fine too
<slangasek> and approximately equivalent to doing a merge-upstream *without* referencing the upstream branch
<SpamapS> I suspect if I --overwrite with all the things after the last upload uncommitted, that would do it, right?
<slangasek> heh, the importer hates --overwrite
<SpamapS> slangasek: I get the same problem whether I merge-upstream lp:juju or an exported tarball tho.
<slangasek> if you leave it as-is, the importer will move your branch aside
<SpamapS> slangasek: it wouldn't care if I used --overwrite to get it back to a state it knows about though, right?
<slangasek> I'm not convinced that's true
<SpamapS> gah!
<slangasek> the importer wigs out on nearly any use of --overwrite I've ever done
<slangasek> maybe I'm just lucky that way
<bryceh> slangasek, posted jbarnes' comments to the bug.  Seems he's recognizing it as a core drm bug
<slangasek> bryceh: ack
<SpamapS> my understanding is that it keeps track of revids that it has seen
<SpamapS> so as long as I go back to the revid that it saw last, and no further, it should be ok
<slangasek> SpamapS: so merge-upstream from a tarball gives me 27 fewer conflicts ;)
<SpamapS> slangasek: progress
<SpamapS> slangasek: it still would be missing files that got pushed over to the .moved dirs though
<bryceh> slangasek, guessing we may have tons of dupes scattered about of this basic issue.
<slangasek> SpamapS: yeah, this is an extra-special merge failure.  I don't have any idea why it's not happy using the existing dirs
<slangasek> SpamapS: anyway, don't worry about reverting anything out of the UDD branch; just prep your upload however you'd like and upload it, and the importer will happily move your commits aside in favor of the authoritative contents of the upload
<SpamapS> ok that sounds like a plan..
<SpamapS> I do wish we had a better way to resolve this
<slangasek> well, this is very much a corner case
<SpamapS> like, at this point, I'm building a package by adding a debian dir to the tarball extracted
<slangasek> I've never seen merge-upstream wig out like this about directories, when referencing a tarball
<SpamapS> basically uupdate
<slangasek> yep
<slangasek> SpamapS: can you file a bug against udd about this, though?
<SpamapS> slangasek: yes happily
<slangasek> this is deep into "that shouldn't have happened" territory
<SpamapS> This will be my second "that should happen" UDD bug
<SpamapS> slangasek: bug 985285 FYI
<ubottu> Launchpad bug 985285 in Ubuntu Distributed Development "juju packaging branch fails using merge-upstream from tarball and upstream branch" [Undecided,New] https://launchpad.net/bugs/985285
<slangasek> cheers
<roaksoax> cjwatson: around?
<cjwatson> roaksoax: yes
<roaksoax> how can I disable multiarch on d-i? apt-setup/multiarch string false? or similar?
<cjwatson> roaksoax: d-i apt-setup/multiarch string
<cjwatson> (i.e. empty)
<slangasek> does that do any good?  /etc/dpkg/dpkg.cfg.d/multiarch is also a conffile
<cjwatson> heh
<cjwatson> it may not, now you mention it
<cjwatson> do I need to fix that?
<cjwatson> http://paste.ubuntu.com/936150/
<slangasek> cjwatson: I suppose so, if you care about this working :)
<roaksoax> cjwatson: awesome thanks
<cjwatson> slangasek: I care about not having to remember that it doesn't for five years
<slangasek> cjwatson: ack ;)
<slangasek> yeesh, can someone make sense out of https://launchpadlibrarian.net/66149842/Stacktrace.txt for me?
 * cjwatson uploads
<slangasek> somewhere between frames 5 and 4, we've lost a pointer on the stack
<slangasek> (what was passed as arg 3 shows up as arg 2)
<roaksoax> cjwatson: and would we be able to use something like d-i apt-setup/universe boolean false ?
<cjwatson> roaksoax: yes
<roaksoax> w
<roaksoax> cjwatson: awesome, thanks
<cjwatson> slangasek: I'm stumped.
<slangasek> cool
<cjwatson> I assumed it was a missing prototype, but doesn't seem to be.
<slangasek> yeah, that was my first guess
<cjwatson> Any compiler warnings?
<slangasek> none of relevance
<slangasek> (some asprintf warnings)
<slangasek> I'm doing a rebuild now with warnings++
<cjwatson> Is there any affinity between bug dups and architecture?
<cjwatson> I see that one's amd64
<slangasek> cjwatson: the first 4 and the last 2 are all amd64; I'm going to assume for the moment they all are
<cjwatson> All amd64, checked in lp-shell
<cjwatson> >>> master = lp.bugs[733453]
<cjwatson> >>> for bug in [master] + list(master.duplicates):
<cjwatson> ...  for line in bug.description.splitlines():
<cjwatson> ...   if line.startswith('Architecture:'):
<cjwatson> ...    print bug.id, line
<cjwatson> ...    break
<cjwatson> ...
<slangasek> aha
<cjwatson> that pattern saves a lot of time clicking around :)
<slangasek> I would say so :)
<slangasek> cjwatson: -Wall does not enlighten
<slangasek> I wonder if something went wrong with the retracer on that one... would be good to have a way to double-check against the current version, rather than the retracer discarding any trace
<slangasek> (why does the retracer not attach a trace when declaring it a dupe?  seems like that'd be simple enough...)
 * cjwatson tries building it locally to see if gdb says anything useful
<slangasek> well, that's the other thing... I've never seen this bug
<slangasek> so maybe it's simple memory corruption
 * slangasek afks for a bit
<cjwatson> bizarre manifestation of it though
#ubuntu-devel 2012-04-19
<smoser> anyone know how i can disable (via preseed) deb-src lines from getting into /etc/apt/sources.list
<cjwatson> You can't in general right now, short of late_command.
<smoser> cjwatson, welll...
<smoser> will anything run an apt-get update bAESD ON THAT?
<smoser> (sorry for caps)
<cjwatson> probably not but you can run your own
<smoser> i dont  (and can't get) src
<smoser> can't get the mirror of src
<cjwatson> well, it'll already automatically comment out sources it can't reach
<cjwatson> oh, except not
<cjwatson>         # Ubuntu change: network sources are always valid; apt will cope
<cjwatson>         # gracefully later, even though the network may not be available
<cjwatson>         # now.
<cjwatson> *shrug* comment them out in late_command, see if it works :)
<cjwatson> quicker than analysing
<cjwatson> specially since I have a complicated bug to fix before I can go to bed
<pitti> Good morning
<rickspencer3> good morning pitti
<rickspencer3> 1 week until release, how're things looking today?
<pitti> slangasek: the stack trace does not tell anything about which python code this came from; I'll check the duplicates if anyone has a recipe for reproducing
<pitti> hey rickspencer3
<micahg> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg
<micahg> If someone adds a large section to a man page, should they be added to authors?
<dholbach> good morning
<micahg> jamespage: did you consider an SRU for Bug #598385?
<ubottu> Launchpad bug 598385 in munin (Ubuntu) "munin plugin exim_mailqueue has incorrect graph configuration" [Low,Triaged] https://launchpad.net/bugs/598385
<micahg> stgraber: 1.299 and 1.301 are between 1.314 and 1.315 along with a lot of other commits
<StevenK> RAOF: How many rubber chickens do I have to kill to get Do working on precise?
<RAOF> StevenK: I'll get back to you in a moment :)
<stgraber> micahg: weird indeed, the tags look correct though (looking at the diffs)
<micahg> stgraber: hmm, looks like it's the importers fault ISTR cjwatson lamenting about this earlier in the week
<micahg> or it might have about something else the importer did wrong
<micahg> stgraber: seems that r1011 reverted everything back to the last import and then committed the fixes one by one
 * micahg files a UDD bug
<micahg> stgraber: bug 985465 if you're interested
<ubottu> Launchpad bug 985465 in Ubuntu Distributed Development "importer reverted casper UDD branch back until the point it needed to import and then committed all the changes back on top" [Undecided,New] https://launchpad.net/bugs/985465
<stgraber> micahg: thanks
<micahg> stgraber: also, as you TIL, do you want to have a look at https://code.launchpad.net/~roadmr/ubuntu/precise/casper/973794/+merge/100893 (as this affects the same script you touched)
<stgraber> micahg: that's the bug I fixed ;) rejecting the branch
<micahg> stgraber: great, thanks
<RAOF> StevenK: What's not working with Do on precise?
<RAOF> StevenK: Apart from unity eating anything that looks like <super> again.
<Riddell> pitti: are you ok with this change? http://paste.kde.org/459788/
<Riddell> pitti: and am I right in thinking that pkgbinarymangler has no bzr branch?
<RAOF> StevenK: (Also known as: Do Works For Meâ¢ on precise)
<pitti> Riddell: it uses the standard ubuntu:pkgbinarymangler UDD branch
<pitti> Riddell: I recommend to set NO_PKG_MANGLE=1 in calligra-l10n
<pitti> Riddell: this blacklist is somewhat hard to handle, as IS needs to manually update the conffile in all the buildd chroots
<Riddell> pitti: ah ok
<StevenK> RAOF: Yeah, that is my problem. Can I move Unity off Super?
<RAOF> StevenK: I'm not sure; you'd need to go ferreting around in ccsm.  I've caved, and set <ctrl><alt><space> as my summon keybinding.
<StevenK> RAOF: That was easy.
<Sweetshark> doko_: ping?
<Sweetshark> doko_: there is currently flameage building up on #libreoffice-dev wrt to ubuntus choice to default to --as-needed when linking, could you join and flame back responsibly.
<Sweetshark> ?
<Mirv> slangasek: should bug #540816 perhaps be marked as High, similar to the duplicate 967229 you marked as high importance?
<ubottu> Launchpad bug 540816 in plymouth (Ubuntu) "No smooth transition out of X on shutdown" [Wishlist,Triaged] https://launchpad.net/bugs/540816
<micahg> Sweetshark: Debian's planning on doing the same at some point: http://wiki.debian.org/ToolChain/DSOLinking
<Sweetshark> micahg: "debian is doing it" doesnt mean its right (which is what upstream cares about) per se, I need someone to argue the "why".
<micahg> Sweetshark: that wiki tells you why it's "right"
<micahg> quite simply, it violates encapsulation
<Sweetshark> which is why the is a --as-needed switch. however, there are scenarios where you do not want that. Using --as-needed where possible is good, mindlessly fumbling with defaults is not,
<Sweetshark> micahg: feel free to join #libreoffice-dev and discuss this with sberg
<micahg> Sweetshark: if I didn't need to go to sleep, I'd consider it :)
<micahg> Sweetshark: at the very least, you can show the wiki page as the "why"
<Sweetshark> micahg: http://nabble.documentfoundation.org/make-check-problem-in-libtest-smoketest-building-master-td3902404.html#a3905049 i did already long ago, we are way past that.
<micahg> Sweetshark: looks like fun :), doko can answer the questions much better than I in any event
<micahg> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<davmor2> hey guys is it me or has scroll stopped working for people?
<pitti> WFM
<RAOF> davmor2: Possibly - can you try running âsudo modprobe -r psmouse && sudo modprobe psmouseâ and then try scrolling again?
 * RAOF will be happy to get home, where the internet is stable enough for evolution to properly filter through the 3000-odd email backlog.
<davmor2> RAOF: that seems to of done it I think most windows now seem to scroll thanks
<RAOF> davmor2: Right.  You're running into the problem where the scroll valuator eventually gets stuck on -2,000,000ish.
<davmor2> RAOF: ah could be
<cjwatson> Is anyone in a position to test bug 969343?
<ubottu> Launchpad bug 969343 in openssl (Ubuntu Precise) "Unable to connect to WPA enterprise wireless" [High,Triaged] https://launchpad.net/bugs/969343
<cjwatson> (last comment)
<doko> Sweetshark, joined -- however no flaming. disappointed ;-/
<azeem> maybe _rene_ is on vacation
<jjardon> dobey: Hey, Is the info I put here enough ;)? https://code.launchpad.net/~jjardon/intltool/autoreconf/+merge/99802
<ogra_> nice ... http://www.heise.de/imgs/18/8/2/1/2/6/2/USB-Power-c433ad30a541bc3f.png ... use your laptop and a USB Y-Cable as a welder :)
<doko> mvo, ping
<kklimonda> on the http://wiki.debian.org/Multiarch/Implementation it's written that if you use /usr/lib subdirectories as a target for the .links file, this file has to be autogenerated in debian/rules - is there some example I could check to see how to do it?
<ogra_> jodh, your serial.conf looks good, will test it soon, what i was wondering is if we couldnt bind it to the device rather than to runlevel [23] ... (not for precise, but i think it might make sense to have somethng like a serial-device-up event or so)
<jodh> ogra_: agreed!
<jeinor> Hello. I have problems getting Ubuntu Core up and running. I try to run the 11.10 release of Ubuntu Core for armel on a Cubox (http://www.solid-run.com/), which runs a patched kernel of version 2.6.32.9. I copied the SD card included with the Cubox using dd if=/dev/sdb of=/data/somefile.img. I then restored this .img to a new SD card, mounted the second partition (there are two, one boot and one rootfs) rootfs and removed all f
<ogra_> so we dont tie to multiuser modes ;)
<jeinor> I then untared the .tar.gz to the mounted partition, and also copied the /lib/modules/* from the original rootfs to the new ubuntu core rootfs.
<jeinor> Could that possibly work? Or am I doing something terribly wrong?
<jeinor> When I boot, the kernel boots, but when I switch to the console terminal using Ctrl+Alt+F1, all I get is a black screen.
 * ogra_ invites jeinor to #ubuntu-arm :)
<jeinor> woops
<jeinor> I entered the channel mentioned at the bottom of https://wiki.ubuntu.com/Core.
<jeinor> Wrong? Should I repost my question in the ubuntu-arm channel?
<ogra_> sure, we can talk here as well ...
<ogra_> your first sentence was cut off
<ogra_> .... d one rootfs) rootfs and removed all f
<ogra_> thats how it ended
<jeinor> ok, it should have been "and removed all files."
<ogra_> note though that ubuntu core is totally unconfigured, you need to do all bits an installer would usually do manually
<jeinor> I understand. I actually got a Ubuntu Core up and running using qemu and a kernel from Ubuntu 11.04 before.
<ogra_> (its main focus is to be used as a base for building custom images (i.e. modifying it) and chroots, it is not intended to be used out of teh box as a rootfs)
<jeinor> I see. I am looking to customize it later on, but first I just want it up and running.
<jeinor> Or am I doing it wrong?
<ogra_> though i would suspect your kernel is missing parts we need in ubuntu
<jeinor> The only configuration I did was to change the password for the root user so I should be able to login.
<ogra_> like devtmpfs for example
<jeinor> aha
<jeinor> Well, I guess I can compile a kernel and try to boot using that. What version would I need for the ubuntu-core 11.10 release, do you know that?
<ogra_> (if you dont use a initrd and dont have devtmpfs i'm not sure you have /dev/console at all for example)
<jeinor> That would explain it.
 * ogra_ would have to check the -core tarball if we ship a hardcoded node for it, but i dont think so
<jeinor> However, the kernel shipped with Cubox is used (by default) to boot Ubuntu 10 or something. Perhaps that doesn't matter?
<ogra_> best to take one of our arm kernels and compare the generic config options
<ogra_> also is there any particualr reason you use armel and not armhf ?
<ogra_> *particular
<jeinor> I only found armel here: http://cdimage.ubuntu.com/ubuntu-core/releases/11.10/release/
<jeinor> What's the difference?
<ogra_> oh, yeah, 11.10
<ogra_> speed :)
<jeinor> Ah :)
<ogra_> but armhf only exists in 12.04
<jeinor> I see. Any system supporting armel should support armhl as well?
<jeinor> armhf*
<ogra_> well, all ARMv7 CPUs definitely support hf
<ogra_> cubox is an armada, it should be able to
<jeinor> "It is based  on the advanced Marvell 88AP510 SoC featuring  an ARMv7 core running up to 800MHz"
<jeinor> found in specs
<ogra_> right
<jeinor> so I guess it should work
<ogra_> well, check your kernel config first i'd say
<jeinor> hmm.. I might need more information on how to do that, do you have any good resource I could read?
<ogra_> things like having SIGNALFD ennabled are essential for example
<jeinor> that's the one read by "make cubox_defconfig" for example, right?
<jeinor> when compiling the kernel
<ogra_> that would be the default config to make the board HW work ... not sure how it sets the generic options though
<ogra_> http://paste.ubuntu.com/936755/ has a config of a well working ubuntu arm kernel
<ogra_> (ignore the arch specific stuff and compare the generic options)
<jeinor> ok
<jeinor> I'll start with that
<ogra_> and indeed, also make sure your cmdline is right (console= should have the right args to even see anything on the serial console etc)
<jeinor> where do I specify the cmdline? (you can see I'm pretty new at this... :) )
<ogra_> in the bootloader configuartion
<ogra_> no idea what cubox uses or how thats configured though
<jeinor> ok
<ogra_> (likely u-boot since its marvell...)
<jeinor> yes, it's u-boot
<jeinor> in general, it should be possible to get Ubuntu Core running on that kernel? Or might it be too old?
<jeinor> 2.6.32.9
<ogra_> well, i used a .32 kernel in oneiric with one of my arm devices ... back then it worked fine
<jeinor> ok
<jeinor> thanks a lot for your help orgra_, i'll start with comparing those configurations
<ogra_> great, good luck
<jeinor> will probably be back later :)
<ogra_> feel free :)
<ogra_> btw, if the cubox comes with an ubuntu installed, you could just use that and upgrade ;)
<jeinor> well, it's the desktop version installed now. I just want Core :)
<jeinor> I'll check back later, bye for now
<mvo> doko: pong
<jibel> mvo, ping
<mvo> jibel: pong
<DreadKnight> can someone take a look at this usability bug report I've made? https://bugs.launchpad.net/unity/+bug/985675 thanks
<ubottu> Launchpad bug 985675 in unity "Improved panel accordion effect behavior " [Undecided,New]
<seb128> DreadKnight, try #ubuntu-unity to discuss unity design
<DreadKnight> seb128, thanks!
<seb128> yw
<slangasek> Mirv: there are two different bugs: one is the lack of smooth transition (which is low-priority and intractable), the other is that there's text when X exits.  The latter is high-priority and solvable, though it requires constant vigilance against stray console messages :/
<Mirv> slangasek: ah, good point. indeed so.
<Mirv> the text is what's worrying, a plain cursor blink would not too bad
<Mirv> marking as separate again
<slangasek> thanks
<Shinobi> Where can I get the src for the ubuntu supported Banshee release?
<infinity> jodh: Around?
<jodh> infinity: yo!
<infinity> jodh: You pinged me about bug #876626
<ubottu> Launchpad bug 876626 in upstart (Ubuntu Precise) "Unlocking the second crypto disk (/home) echos password on console" [High,Confirmed] https://launchpad.net/bugs/876626
<infinity> jodh: I haven't had much time to look at it at all, so if you're looking at it, that's fine by me. :P
<jodh> infinity: gr8, thanks. I'm currently looking at it.
<slangasek> pitti: hey, would it make sense for the apport retracer to paste backtraces to each of the bugs it decides are duplicates, instead of duping them and leaving no info about the individual crashes?
<pitti> slangasek: we could, but then we would need to keep the duplicates private
<pitti> I'm not entirely sure which is worse
<slangasek> well, what good does it do to have public bugs that are duplicates of a private bug? :-)
<pitti> the master bug can be made public, but usually developers don't bother making the dupes public
<pitti> and it's a good metric for how urgent a bug is
<pitti> we have whoopsie now, of course, to tell us that
<pitti> slangasek: so, it's technically easy to do
<slangasek> pitti: right, so maybe whoopsie is the better route after all?
<seb128> slangasek, better route for what?
<seb128> slangasek, will we have full debug stacktrace with whoopsie or mozilla's like stacktrace, i.e just function names?
<slangasek> for making sure we can retain a view of the individual crashes
<slangasek> well, I hope it's meant to be full debug :)
<slangasek> ev: ^^ ?
<pitti> slangasek: is the whoopsie data accessible somehow? I thought it was meant to be kept very restricted
<slangasek> pitti: well, I'm not sure
<slangasek> I thought ubuntu devs were meant to be able to get access to it to poke around... else how would we be able to develop the kinds of hooks that would let us extract more info we need for debugging?
<pitti> slangasek: ev would know better, but I thought initially this was meant to only give statistics, not individual bugs
<slangasek> it's meant to allow us to aggregate crash info
<slangasek> but I didn't think that meant we wouldn't have access to drill down
<slangasek> but I'm speculating here :)
<jodh> slangasek: fyi - bug 985755.
<ubottu> Launchpad bug 985755 in upstart (Ubuntu) "/lib/init/upstart-job does not handle lucid->precise upgrade scenario" [Undecided,New] https://launchpad.net/bugs/985755
<cjwatson> the mockups ev's shown me permit a degree of drilling down
<slangasek> jodh: thanks
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh
<kklimonda> slangasek: hey, do you have an example of multiarch package that uses /usr/lib as a target for the .links file? according to the http://wiki.debian.org/Multiarch/Implementation this file should be generated in the install target and I'm wondering how to best do that
<slangasek> kklimonda: I don't think I have any good examples - this has been somewhat overtaken by developments in debhelper
<slangasek> kklimonda: nowadays, I would do this with an executable .links file that uses dh-exec
<slangasek> but I haven't actually done this *yet*, because all the packages I've converted were done before that was an option :)
<cjwatson> kklimonda: it's not for multiarch specifically, but groff generates .dirs and .install files, and you could use an identical approach
<kklimonda> thanks, I'll check both and see which one is less invasive :)
<FAalbers> I've been searching a doc on how to setup scons in ubunto to build QT apps. But can't find any help. Is there someone her that could help ?
<jeinor> Hello! And hello again ogra_ if you're there :)
<jeinor> I tried joining #ubuntu-arm, but it said "Cannot send to channel" when I tried to.
<jeinor> Don't know if I have to have permission to write there or something?
<jeinor> Anyway, I am still stuck on not getting Ubuntu Core to boot on the Cubox (http://www.solid-run.com/)
<jeinor> The Cubox is shipped with Ubuntu, so I figured the kernel I have from there should work for Ubuntu Core..?
<jeinor> I just copied the SD card that came with the Cubox (using dd, full disk image using dd if=/dev/sdb of=/data/cubox.img)
<jeinor> I then copied that back onto another SD card using dd if=/data/cubox.img of=/dev/sdb
<jeinor> I then mounted the second partition (the Cubox default SD card has two partitions, one boot and one for the rootfs)
<jeinor> So I mounted the rootfs, ran sudo rm -rf * on it and then copied Ubuntu Core 11.10 onto there (untared it directly to the root)
<jeinor> However, when I boot, all I get is a command prompt with only a flashing underscore on ctrl+alt+f7 and a black screen at ctrl+alt+f1
<jeinor> Anyone have any ideas? ogra_ told me to compare the kernel configuration with a known working kernel configuration, but I don't know how to that since the configuration file is 2800 lines with a lot of options
<jeinor> And I am curious though, if Ubuntu 10.04 runs on the Cubox, shouldn't Ubuntu Core run as well then?
<\sh> moins
<\sh> kklimonda, ping freeipa :)
<kklimonda> \sh: pong
<\sh> kklimonda, I just got some attention to a project you are eventually involved...bringing freeipa to debian/ubuntu ;) it happens to be that I was encountered by a core dev of freeipa here at COL
<\sh> kklimonda, just wanted to ask if you are still involved and if you need help with this
<stgraber> \sh: you may also want to read https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-freeipa-tech-preview and talk to tjaalton
<tjaalton> hmm I should mark that one finished, and postpone the last task
<\sh> I just encountered one issue while compiling the client side:
<\sh> /usr/bin/ld: warning: libkrb5.so.26, needed by /usr/lib/x86_64-linux-gnu/libgssapi.so.3, may conflict with libkrb5.so.3
<stgraber> \sh: you realize you can do "apt-get install freeipa-client" on precise, right? :)
<tjaalton> right
<tjaalton> there are a couple of issues with the ipa-client-install script that I still intend to fix for precise..
<kklimonda> \sh: we always need help :)
 * kklimonda wonders what COL is
<\sh> stgraber, yes...so this ld warning is interesting to me and eventually for you =? :)
<\sh> kklimonda, citrix online
<tjaalton> \sh: building against heimdal? don't do that
<tjaalton> don't think upstream supports it
<\sh> tjaalton, so I forget about that...now I need to backport it to 10.04 ,-)
<kklimonda> ouch
<tjaalton> uh oh
<\sh> yes yes
<tjaalton> the client?
<tjaalton> nevermind
<tjaalton> \sh: who did you meet?
<\sh> tjaalton, jr aquino
<tjaalton> ah, at citrix
<\sh> tjaalton, where else ,-)
<tjaalton> redhat? :)
<\sh> tjaalton, never...was there 2001 ,-)
<tjaalton> referred to the fact that most of the upstream is working for red hat, but anyway
<\sh> tjaalton, did you fix the uintptr_t issue in ipa-join.c?
<tjaalton> \sh: hm what?
<tjaalton> bug# ref please
<tjaalton> \sh: oh, got it..
<tjaalton> yes, it's patched
<tjaalton> included in 2.2 and later, precise has 2.1.4
<kees> hallyn: cap question for you...
<kees> ns_capable(child_cred->user->user_ns, CAP_SYS_PTRACE)    this means "does current have CAP_SYS_PTRACE in the child's namespace?" right?
<\sh> tjaalton, cool...:)
<bodhi_zazen> When making a live Ubuntu CD, how do you get the rootfs.squasfs so small ?
<bodhi_zazen> What compression options are used ?
<sladen> bodhi_zazen: lzma
<bodhi_zazen> sladen: any idea of the exact command ?
<bodhi_zazen> =)
<sladen> bodhi_zazen: apt-get install live-build
<bodhi_zazen> OK, I am familiar with live-build
<sladen> bodhi_zazen: http://lists.debian.org/debian-live/2011/06/msg00152.html
<bodhi_zazen> will look at those scripts
<arges_> micahg, hello
<micahg> hi arges
<arges_> micahg, looking at pad.lv/943502 whois backport to oneiric
<bdmurray> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray, bryceh
<arges_> micahg, i see you moved some stuff around in the bug, and was wondering how I should help? I've started to build the PPA and was going to test it
<micahg> arges_: yes, please continue, I just closed the SRU task since you decided to go the backport route and added a backport task
<arges_> micahg, ok cool. Just making sure
<arges_> micahg, also: pad.lv/968612   I was trying to backport openldap... I was able to build and install most of the packages, but wasn't sure how to test them each. Are there guidelines for this?
<micahg> arges: just install and run or build, install, and run for the reverse dependencies
<micahg> *reverse build dependencies
<micahg> whatever "run" is for the package in question (start it, use an app that exercises the library)
<arges_> micahg, ok. that one will take some time
<micahg> arges_: right, which is why requests for packages like those mostly go unanswered
<arges_> micahg, yea. i started writing some python script to take that request output and turn it into 'apt-get install' statements, so I could test
<arges_> because it became very tedious
<micahg> arges_: indeed
<micahg> slangasek: Bug #985842 (I thought we shouldn't have these issues anymore :()
<ubottu> Launchpad bug 985842 in gcc-4.4 (Ubuntu) "package gcc-4.4-base 4.4.7-1ubuntu2 failed to install/upgrade: './usr/share/doc/gcc-4.4-base/README.Debian.gz' is different from the same file on the system: removing the file fixes the issue" [Undecided,New] https://launchpad.net/bugs/985842
<slangasek> micahg: it's not a gzip issue, it's a differing-contents issue
<micahg> ah, ok, that's a relief of sorts :)
<slangasek> micahg: we never fixed that for gcc-4.4; why is someone trying to do this with gcc-4.4?
<micahg> no idea, just saw the bug come in and thought it was going to be a problem
<micahg> why should the README.Debian have different contents per arch though?
<slangasek> look and see for yourself ;)
<slangasek> (it documents the per-arch patches applied to the source)
 * micahg would think someone would want to possibly cross-compile with gcc-4.4 since it's multiarch enabled, they might have deceptively thought that they could install both :)
<slangasek> heh, ok
<micahg> I read some of the thread on debian-devel about this, so I know it's not so easy to fix
<jeinor> If I have a Ubuntu system which boots to a flashing prompt. If I go ctrl+alt+f1, the screen turns completely black. What could cause this? :)
<hallyn> kees: vacation today, afk, will be in tomorrow
<sladen> jeinor: sounds like a bug -> bug tracker please.  We need traces to get it debuggered further
<jeinor> sladen, well, it most probably is not a bug... probably me not knowing enough on kernels boot-loaders and the alike. Not exactly a standard installation I'm trying to get up and running.
<sladen> jeinor: how is it non-standard?
<jeinor> it's an Cubox arm system based on a pretty old 2.6 kernel which I am trying to get Ubuntu Core 11.10 running on
<kees> hallyn: okay, have fun!
<jeinor> I THINK I have done everything right, but apparently not
<sladen> jeinor: I don't know that I can help.  The starting place would be to find somebody else with the same hardware and compare the two setups
<jeinor> sladen: Thanks for the tip, though I have a working installation running Ubuntu 10.04 on the same hardware. I just copied that kernel and replaced the rootfs, but didn't work out.
<jeinor> sladen: the working installation was shipped with the cubox (http://www.solid-run.com)
<sladen> jeinor: I would try again, replacing the minimum at a time and bisect the point at which it explodes
<sladen> jeinor: then at that point (with minimum delta between $known_working and $known_broken) start poking to see if it's just the graphics driving dying, or the whole kernel going up in flames
<jeinor> sladen: yea, something like that. However, how do I gradually replace Ubuntu Core with Ubuntu Desktop 10.04? I guess the breaking point will be when I remove X. I think the problem is that it is trying to boot into X using tty7, but I can't get the text console on any tty
<jeinor> *the other way around, "replace Ubuntu Desktop 10.04 with Ubuntu Core"
<slangasek> jeinor: the gettys are configured with upstart using /etc/init/tty*.conf.  If you have no getty on any VT, you probably are failing to reach runlevel 2
<slangasek> jeinor: what's the kernel commandline being passed?
<jibel> during an upgrade from lucid to precise from the command line, some packages show this error/warning: dpkg-deb: file `/var/cache/apt/archives/ubuntu-docs_12.04.4_all.deb' contains ununderstood data member data.tar.xz     , giving up
<jibel> what does it mean ?
<jeinor> slangasek: 'console=ttyS0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 video=dovefb:lcd0:1920x1080-32@60-edid clcd.lcd0_enable=1 clcd.lcd1_enable=0'
<jeinor> what does "have no getty on any VT" mean? VT=virtual terminal, but getty?
<slangasek> getty is the program that gives you a login prompt
<jeinor> I see
<slangasek> jibel: it means approximately this: http://lintian.debian.org/tags/data.tar.xz-member-without-dpkg-pre-depends.html
<slangasek> jibel: however, that's supposed to be an archive-side reject rule in launchpad, so there shouldn't have been any such packages (!)
<slangasek> cjwatson: ^^
<slangasek> jibel: and indeed, ubuntu-docs has Pre-Depends: dpkg (>= 1.15.6)
<slangasek> jibel: so what's the context of the error message?  That shouldn't have happened as part of the actual upgrade
<jeinor> slangasek: there are files from tty1.conf to tty6.conf. If I press ctrl+alt+f1 at the flashing underscore, the flashing stops and the screen is just black. If I press back to ctrl+alt+f7, the flashing returns. Should I perhaps add a tty7.conf for that terminal?
<jibel> slangasek, messages are displayed the early in the upgrade, right after the new packages are downloaded and before preconfiguration
<jibel> there are 8 packages with this error in the test: cloop-utils_2.6.39.2-1ubuntu1_i386.deb libgl1-mesa-dri-dbg_8.0.2-0ubuntu3_i386.deb libgl1-mesa-glx-dbg_8.0.2-0ubuntu3_i386.deb libyaml-syck-perl_1.19-1_i386.deb python-m2crypto_0.21.1-2ubuntu2_i386.deb ttf-arphic-uming_0.2.20080216.2-4_all.deb ubuntu-docs_12.04.4_all.deb whois_5.0.15ubuntu2_i386.deb
<slangasek> jeinor: no.  your problem is that you're *not reaching runlevel 2*.  try adding --verbose to the kernel commandline; that should spew a good amount of data at you
<slangasek> jibel: aha, I thought it might be preconfiguration
<slangasek> jeinor: some of the data may even tell you where it's blocked :)
<slangasek> jibel: so the apt debconf hook tries to manually unpack the .deb files using the currently-available dpkg, so that it can extract and run the debconf .config scripts.  This will fail if dpkg doesn't yet understand the package format
<slangasek> jibel: I'm assuming there's no impact other than the error message?
<jeinor> slangasek: I see :) so I adjust my kernel command line to include --verbose. On which screen will it outut? Will I need to specify console=tty0 as well perhaps? (really grateful for your answers here, I've been stuck at this for a while now..)
<jibel> slangasek, apparently not. what kind of impact could this error produce ? package is silently kept to the old version ?
<slangasek> jibel: not at all; it just means that, if the package has any debconf questions that need to be shown, they won't be shown until much later in the install
<bryceh> slangasek, there's a couple patches in the sponsor queue for multi-arch transitions.  Are multi-arch changes permissible as SRU?
<jeinor> slangasek: I tried adding --verbose, but that didn't give me any output at all. I don't see any text at all until I see the flashing prompt.
<slangasek> jeinor: do you have the serial console hooked up?
<jibel> slangasek, ah ok. so no impact other than the error message
<slangasek> jibel: correct - it just means package *pre*configuration will fail, which is an optimization only
<slangasek> jeinor: (note that your first kernel commandline option tells everything to talk to the serial console, not the graphical console...)
<slangasek> bryceh: I discussed that with pitti earlier this week; we're agreed to allow them, provided there's due diligence on making sure they're not regressing anything
<bryceh> slangasek, thanks
<jeinor> slangasek: I have the computer connected by HDMI to a screen, but I have not connected any serial console. I actually tried changing that first command line option to console=tty0 before, but that didn't give me any output either.
<slangasek> bryceh: which one are you looking at, OOI?
<bryceh> 977952 libbonoboui and 977940 gnome-vfs
<slangasek> jeinor: Ubuntu tries to keep the console quiet by default, so that may be part of it; dropping the 'console' option entirely and adding --verbose may give you better results
<slangasek> bryceh: ok
<slangasek> bryceh: are you thinking to sponsor them?
<bryceh> slangasek, also since we're in Final Freeze, should everything that isn't a targeted bug be going through -proposed and the SRU process now?
<slangasek> yes
<slangasek> and half of what is a targeted bug, too :)
<bryceh> slangasek, well I was going to kick them out if a firm rule existed
<slangasek> yeah, it doesn't
<slangasek> if you don't sponsor them, I'll be looking at them later :)
<bryceh> there's 3-4 I'm going to look at first, and my pilot session is long in the tooth so I likely will be leaving them for you :-)
<slangasek> no problem
<bryceh> er 3-4 other patches
<jeinor> slangesek: I tried that now, still just a black screen :( not even the flashing prompt
<jeinor> slangasek: perhaps I should try connecting to that terminal console
<jeinor> slangasek: does the order of the kernel command line parameters matter? for example, the resolution and such are set after the console commands, perhaps if I put console=tty0 last it would apply that same resolution to tty0?
<bdmurray> slangasek: bug 985735 isn't really about update-manager is it?
<ubottu> Launchpad bug 985735 in update-manager (Ubuntu) "update-manager restarts KDM and interrupts update process" [Undecided,New] https://launchpad.net/bugs/985735
<slangasek> bdmurray: nope, that prompt will come from eglibc
<slangasek> because apparently we stopped restarting it from pam, but still do from eglibc?
<slangasek> bdmurray: triaged
<slangasek> Riddell: ^^ I'm not sure if kubuntu-dev gets bug mail; can I draw your attention to bug #985735, which needs input from Kubuntu ASAP?
<ubottu> Launchpad bug 985735 in eglibc (Ubuntu) "update-manager restarts KDM and interrupts update process" [High,Incomplete] https://launchpad.net/bugs/985735
<slangasek> also, how did no one run into this for upgrades to maverick or natty and report it?  did it get lost in the noise of the pam restart?
<Dr_Who> doko: ping
<Riddell> slangasek: replied
<bryceh> bdmurray, we're cutting a swath through the sponsor queue today :-)
<ScottK> slangasek: FWIW, I agree with Riddell.
<bdmurray> slangasek: maybe it has to do with bug 944876 and not knowing about updates?
<ubottu> Launchpad bug 944876 in software-properties (Ubuntu) "changed mapping of release_upgrades_policy causes software-properties-kde to set the wrong policy" [High,New] https://launchpad.net/bugs/944876
<slangasek> Riddell, ScottK: ack; will pull kdm from the service restart list
<slangasek> bdmurray: srsly?  augh
<bdmurray> I'm not positive but it could be
<slangasek> well, I guess *that* should've been noticed if it was affecting the whole Kubuntu userbase
<slangasek> Riddell, ScottK: any insight into why this has only just been reported now?
<ScottK> You mean now as in a month and a half ago?
<Riddell> I'm not sure why that software-properties bug is related to the kdm restart issue
<slangasek> ScottK: I'm talking about bug #985735 - if this really breaks kdm on upgrade, why did nobody raise it before?
<ubottu> Launchpad bug 985735 in eglibc (Ubuntu) "update-manager restarts KDM and interrupts update process" [High,Triaged] https://launchpad.net/bugs/985735
<sladen> nasty
<Riddell> it never showed up in beta 2 upgrade testing
<Riddell> and ScottK tested an upgrade today and never reported it
<ScottK> Oh.  That one.  I thought you meant the software-properties one.
<ScottK> The upgrade I did was in a chroot.  KDM wasn't actually running.
<slangasek> heh
<ScottK> I have done real upgrades and not had the problem though.
<Riddell> has it only appeared after beta 2 ?
<ScottK> I upgraded my laptop about a week and a half ago and didn't see it, but these things also come down sometimes to package update sequence and that's not deterministic.
 * ScottK has to go.
<slangasek> ScottK: I don't see any way it could be dependent on update sequence
<ScottK> OK.
<slangasek> libc6 is always going to be upgraded and always want to restart
<ScottK> True.
<slangasek> Riddell, ScottK: so there were changes to the restart code in eglibc as of Apr 12, but nothing that should have changed *whether* kdm is restarted
<slangasek> only when
<Riddell> I did plenty of upgrade testing before beta 2 so a bit of a mystery that
<Riddell> I'll probably do some more upgrade testing tomorrow so I'll check this bug to see if I should expect it to work or not
<stgraber> that's one kind of issue the daily upgrade testing won't find as it just runs do-release-upgrade from an ssh session, though I guess we could configure the VM to auto-login and ensure that the session is still alive post-upgrade...
<bryceh> anyone know offhand if apport has been turned off now?
<bryceh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray
<bdmurray> bryceh: yes
<bdmurray> bryceh: er, yes I know and yes it has
<bryceh> bdmurray, thanks
<bdmurray>   * etc/apport/crashdb.conf: Disable Launchpad crash/kernel reports for the
<bdmurray>     final release. Leave Apport running for whoopsie, though, so use the new
<bdmurray>     mechanism for selective problem types.
<slangasek> infinity, Riddell, ScottK: blast, it's my bug - sorry
<infinity> slangasek: Oh, you found where it went wrong?
<slangasek> yah
<infinity> Good, cause I hadn't gotten there yet. :P
<bdmurray> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise: Final Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<FAalbers> ly ! Got qt4 working on my Linux box with scons ! :)
<\sh> oh damn...adding a devmapper device (via multipath) prevents 12.04 from booting.
#ubuntu-devel 2012-04-20
<hyperair> any ubuntu-release members present?
<hyperair> https://bugs.launchpad.net/ubuntu/+source/glib-networking/+bug/981856 <-- i'm wondering if this deserves an Ffe
<ubottu> Launchpad bug 981856 in glib-networking (Ubuntu) "glib-pacrunner does not support file:// pac files" [Undecided,Incomplete]
<hyperair> FFe*
<RAOF> It seems a little late for a FFe?
<hyperair> RAOF: it's a bugfix, though
<RAOF> Then it doesn't need a FFe
<hyperair> RAOF: i was asking for a finalfreeze exception.
<hyperair> it's in main.
<RAOF> Ah.  Stupid overloaded initials :)
<hyperair> ;-)
<slangasek> hyperair: looks reasonable to me for an SRU, but not a freeze exception
<slangasek> (assuming there's a reason to expect a file uri to work here at all?)
<slangasek> looks like pac+file:// specified directly should work; is that what upstream recommends?
<hyperair> slangasek: i'm pretty sure it doesn't, though.
<slangasek> ah, too bad
<hyperair> there's no way to use a local pac file without running a http server.
<hyperair> not without said patch
<hyperair> glib-pacrunner checks for protocols starting with http
<hyperair> failing which it just uses wpad:// instead
<slangasek> ok
<hyperair> so this should still be an SRU then?
<slangasek> yes
<hyperair> okay then
<ScottK> slangasek: Thanks.  I'm really glad you found something.
<slangasek> it was easy to find, I just had to put my head to the bottom of the paper bag and look
<jbicha> slangasek: don't keep your head in there too long...
<slangasek> don't worry, there are air holes
<shang> hi all, I have a uefi boot related issue, I was wondering if anyone knows any kernel parameter that I could try?
<pitti> Good morning
<dholbach> good morning
<micahg> mvo: there's an apt fix in the sponsorship queue: Bug #985852
<ubottu> Launchpad bug 985852 in apt (Ubuntu) "libapt-pkg regression: infinite loop on processing certain Pre-Depends" [Undecided,New] https://launchpad.net/bugs/985852
<mvo> micahg: let me check
<jibel> doko_, lucid main upgrade pass with python 2.7.3-0ubuntu2
<pitti> jibel: \o/
<pitti> that was the only one which failed again, right?
<jibel> pitti, right
<doko_> jibel, thanks for testing. however I don't understand why it did start to fail ...
<doko_> pitti: this would require an update for python2.7...
<htorque> hi all! do the dvd images still contain more than just the language packs? in that case i was wondering if anyone could give bug 873350 a little priority upgrade?
<ubottu> Launchpad bug 873350 in ubuntu-website-content "Wrong description of DVD content" [Undecided,Confirmed] https://launchpad.net/bugs/873350
<pitti> doko_: if it's upgrade only, a 0-day SRU will do fine
<doko_> seb128, bug 960967 turned out to be a bug in eog, could you forward it, and maybe not use the internal jpeg copy?
<ubottu> Launchpad bug 960967 in eog (Ubuntu) "eog crashed with SIGSEGV in do_rot_270()" [Medium,In progress] https://launchpad.net/bugs/960967
<pitti> but it can build in -proposed either way, and then we can fold it into the release if we're going to respin
<seb128> doko_, oh, sorry about that, sure I will do!
<micahg> htorque: #ubuntu-website would probably be a better place to poke
<htorque> micahg: ah, thanks! didn't know that exists.
<doko_> seb128, he has a package in https://launchpad.net/~tom-gall/+archive/packages/+packages
<seb128> doko_, ok, I just read the comments, good work there, I will make sure it goes upstream and in the next point release (which will be SRUed to precise)
 * infinity just spent way too long trying to sort out why a documented feature in gnupg wasn't working.
<infinity> Turns out that it helps if the feature is implemented.
<mvo> infinity: haha, the command-fd ?
<infinity> mvo: No, %transient-key in batch mode.
<infinity> mvo: Only implemented in 2.1, AFAICT, but documented ALL OVER.
<mvo> aha
<infinity> mvo: I thought I was going insane until I just broke down and read the source.
<infinity> mvo: While that's touted as one of the "advantages" of FLOSS, I'm not sure I appreciate having to do it. ;)
<mvo> well, at least you can :) and I find it often a really good strategy
<Chipzz> reading the source and strace :)
<mvo> (but yeah, matching documentation is actually prefered still ;)
<infinity> Matching, or even outdated.  I was mind-numbingly confused by the documentation being AHEAD of the source.
<infinity> That just ain't right.
<micahg> infinity: in the mood for removals?
 * micahg guesses he should just file a bug
<infinity> micahg: No, I'm happy to take 'em without bugs, as long as they have justifications.
<micahg> bug #986071
<ubottu> Launchpad bug 986071 in libgtkada2 (Ubuntu) "Please remove libgtkada2 from precise " [Wishlist,Confirmed] https://launchpad.net/bugs/986071
<vibhav> Could somebody nominate https://bugs.launchpad.net/onboard/+bug/958385 for oneiric?
<ubottu> Launchpad bug 958385 in Onboard "Encoding mismatch when mousetweaks is missing" [Undecided,Fix committed]
<micahg> vibhav: why, where is it needed for oneiric?
<vibhav> affects oneiric too
<infinity> micahg: Done.
<micahg> vibhav: done
<vibhav> micahg: thanks!
<vibhav> micahg: distroseries needs to be oneiric-proposed and the version 4.1, right?
<micahg> vibhav: yes for series, no for version, grab the one from -updates
<vibhav> so the version will be +1?
<micahg> no
<micahg> oh, yes, 0.96.1-0ubuntu0.2
<vibhav> thanks
<rbasak> pitti: you sponsored/uploaded https://bugs.launchpad.net/ubuntu/+source/ipsec-tools/+bug/947309/comments/11 but it doesn't seem to have appeared anywhere. Is something stuck, or did the upload fail?
<ubottu> Launchpad bug 947309 in ipsec-tools (Ubuntu Lucid) "racoon phase 2 negotiation fails with Win Vista/7" [Undecided,Fix committed]
<pitti> rbasak: it's in https://launchpad.net/ubuntu/lucid/+queue?queue_state=1
<pitti> for ubuntu-sru review
<rbasak> Ah OK, thanks
<cjwatson> infinity: thanks for the writer2latex merge; beat me to it
<infinity> cjwatson: Yeah, I grabbed the source and started on it, and then read the "Thanks for Colin" in the changelog, and wondered if you'd be grumpy that I stole your merge.
<infinity> cjwatson: But I had momentum at that point. :P
<infinity> s/for/to/
<cjwatson> infinity: *shrug* I'd got as far as test-building my merge before I noticed you'd done it :)
<apw> bryceh, slangasek, it is looking like the race we thought we are experiencing ought to be fixed by an upstream change already in the version in precise .. do we have a reproduce by ?
<pitti> cyphermox, stgraber: hm, did we recently lose the "persistent rfkill" feature? I noticed that bluetooth is always on after booting again, even though I keep disabling it (I don't need it most of the time)
<stgraber> pitti: hmm, no, it should work... anything interesting in /var/log/upstart/rfkill*.log ?
<pitti> I don't have that file
<pitti> nor any rotated ones
<pitti> /var/lib/rfkill/saved-state is 0 bytes
<stgraber> hmm, can you try to run rfkill-store manually?
<stgraber> the script in /etc/init/rfkill-store.conf
<pitti> $ sudo start rfkill-store
<pitti> $ cat /var/lib/rfkill/saved-state
<pitti> tpacpi_bluetooth_sw 1
<pitti> phy0 0
<pitti> that seems to work
<pitti> when I enable BT in the indicator and run sudo start rfkill-restore it gets properly disabled again
<pitti> so restoring seems to work, but storing not for some reason
<pitti> stgraber: ok, thanks for the pointer; I'll have a closer look
<lool> Hey there!  It's been multiple days in a row that I get a cron.daily email that /etc/cron.daily/update-notifier-common has triggered a download for flashplugin-installer; it seems to be output of a successful job, but it keeps doing it every night
<lool> I googled the message, but I didn't find any bug for this
<lool> did anyone else see this?
<lool> Hmm now that I check closely, I see that it downloaded the same file on the 17th and the 18th, nothing on the 19th (but laptop was sleeping) and a new file on the 20th
<pitti> ooh, is that what sends me cron mail about lost+found not existing?
<lool> pitti: Not sure how it directly relates; I would think of some fsck job doing this rather than flashplayer/update-notifier
<pitti> it started a few days ago
<lool> there were a couple of update-notifier updates, but more like a week ago
<lool> that said, I didn't update daily
<lool> pitti: I actually received a flashplugin update yesterday, so that run seems legit; not sure what happened a couple of days ago; I'll see if it happens again tomorrow; it seems to be that recent update-notifier uploads might have caused output to be properly reported from the cron job, and now we might have to look at silencing it
<lool> I have a successful stamp file, so at least it shouldn't trigger daily
<lool> pitti: ah, I don't know if it relates but I think I have a bug in the timedelta handling in there; it is using os.times() which is an arbitrary base time which can also overflow and it's comparing that to a file modification time
<popey> MacSlow: just fyi, i have recording hangouts perfect here
<MacSlow> popey, good to know that it's just a magic combination of right settings... if you can write me a quick summary via email about your setup when you've some time, that would be greatly appreciated!
<popey> will do
<MacSlow> popey, sweet... thanks!
<lool> pitti: Filed as LP #986183 with a proposed approach for the timestamp checks
<ubottu> Launchpad bug 986183 in update-notifier (Ubuntu) "Triggers multiple times" [Undecided,New] https://launchpad.net/bugs/986183
<pabs3> a few days ago I got a hash sum mismatch from apt with this URL, where should I report that? http://ports.ubuntu.com/dists/precise/universe/binary-powerpc/Packages.gz
<cjwatson> Does it still mismatch?  It's probably a broken proxy.
<cjwatson> Or very unlucky timing I guess.
<pabs3> unlucky timing probably. in Debian we have a two-stage mirroring process that prevents that issue, I was surprised to see it on the official Ubuntu archive though
<infinity> lool: You might want to talk to slangasek about your update-notifier woes when he wakes up, a lot of that it shiny new code of his.
<infinity> pabs3: Two stage mirroring still allows a (small) window.
<infinity> pabs3: The only way to actually fix it is to re-work the Packages/Release concept a bit (we have a bug about this, but it's going to take some bikeshedding)
<rbasak> bug 972077
<ubottu> Launchpad bug 972077 in apt (Ubuntu) "apt repository disk format has race conditions" [Medium,Confirmed] https://launchpad.net/bugs/972077
<lool> infinity: It actually seems it was the broken flashplugin upload wiht only half the checksums updated that triggered the odd no-change redownload email; the regular behavior of update-notifier seems ok, except the failed hook time handling which is bogus (see bug)
<lool> infinity: The only remaining wonder I have is why I'm getting this as a cron notification at all?  Shouldn't this run as part of the package update?
<infinity> lool: Ahh, so it's all my fault.  Comforting! ;)
<infinity> lool: It's vorlon's shiny new crack to allow async downloading of external tarballish packages.
<infinity> lool: I'm not actually sure I understand the use-case, but people seemed to think it was important. :P
<lool> infinity: ah so it's indeed on purpose; odd, I was expecting it would at least try the download immediately during the upgrade
<infinity> lool: I think it's meant to do that too?  I dunno.
<lool> slangasek: Is it intended that updating e.g. flashplugin triggers a download + email at the next cron.daily run?  in any case the failed download timestamp handling is bogus, see #986183
<lool> infinity: maybe it does both and that's another bug
<lool> infinity, slangasek: Indeed, I checked apt term.log and it shows the download of the latest version happening yesterday, and then I download it again from cron
<infinity> lool: oops.
<cr3> hi folks, what's that library that does openid integration on the desktop? I believe it uses dbus or something...
<beuno> cr3, ubuntu-sso?
<cr3> beuno: that sounds right, I'll have a look at it. thanks!
<jibel> mvo, bug 986201 never seen it before
<ubottu> Launchpad bug 986201 in update-manager (Ubuntu) "fail to upgrade to 12.04 from 10.04" [Undecided,New] https://launchpad.net/bugs/986201
<jsjgruber> When is/was the precise archive freeze?
<cjwatson> A couple of weeks back.
<jsjgruber> Did that include the Universe archive?
<mvo> doko: can you help with 986201 ? it looks like a pycentral issue, check https://launchpadlibrarian.net/102687559/VarLogDistupgradeMainlog.txt
<cjwatson> jsjgruber: no, that freezes, err, I forget, https://lists.ubuntu.com/archives/ubuntu-release/2012-April/001083.html suggests the 24th
<jsjgruber> thanks
<Laney> jsjgruber: Depends what you mean by "freeze". It's still open for bug fixes, yes.
<jsjgruber> I've had a bug fix merge in for a while for a universe package and got word last night that it had to be a SRU.
<Laney> from a sponsor?
<jsjgruber> Right.
<jsjgruber> He asked for better test information, too, so I'll do that and resubmit it.
<doko> mvo: where can I get release-upgrader-python-apt (0.8.0ubuntu9~upgrader3) ?
<slangasek> lool: the cron job should never be downloading unless there was some failure in processing previously
<slangasek> lool: and there's a cron job because we deliberately don't fail the package install if the download fails, so we need some way to periodically retry the download so we don't just leave users with packages installed but unusable
<slangasek> doko: lucid-updates
<slangasek> apw: reproduce by> I think hallyn was seeing this one?
<lool> slangasek: But the download seems to have worked fine: http://paste.ubuntu.com/938365/
<lool> slangasek: flashplugin-installer was configured afterwards though; this was after unpacking but before configuring flashplugin-installer, but I would think that's ok?
<slangasek> lool: that's a bit weird, certainly
<slangasek> lool: oh wait, it happened *before* flashplugin-installer was configured? Haha, I fail
<slangasek> lool: I know what happened... see if you can spot the bug in the flashplugin-installer postinst :-P
<lool> slangasek: ah right, touch there
<lool> just after installing
<slangasek> not the touch... the rm
<slangasek> which I guess needs to be moved to the preinst
<lool> ah
<slangasek> since we're unconditionally removing the stamp files on the assumption that the new version needs a redownload, but the ordering of the package configuration means it's already been downloaded
<lool> yup, makes sense
<lool> slangasek: Did you work on the update-notifier failed hook handling as well?
<doko> mvo, hmm, the package does have the Python-Version attribute
<slangasek> lool: I haven't worked on it yet, but I was vaguely aware of that problem
<doko> mvo: do you know how to reproduce the issue?
<slangasek> ("vaguely" meaning "I may or may not have put a comment in the source")
<lool> slangasek: Ok; I was looking for someone able to test it properly to prepare an upload
<slangasek> apw: correction, hallyn's bug was a different one; so the reproducers for this are random bug submitters fwiw (bug #982889, bug #966868)
<ubottu> Launchpad bug 982889 in libdrm (Ubuntu) "X trying to start faster than drm driver is ready" [Medium,Triaged] https://launchpad.net/bugs/982889
<ubottu> Launchpad bug 966868 in libdrm (Ubuntu) "plymouthd crashed with SIGABRT in __assert_fail_base()" [High,Triaged] https://launchpad.net/bugs/966868
<slangasek> lool: I think those changes probably want test-suiting
<jibel> mvo, doko I could reproduce it with a cdromupgrade and no network connection. bug 986233. trace is similar
<ubottu> Launchpad bug 986233 in update-manager (Ubuntu) "lucid -> precise cdromupgrade failed without network connection" [Undecided,New] https://launchpad.net/bugs/986233
<doko> jibel, but it succeeds with network?
<jibel> doko, it seems so, it's currently downloading the upgrades
<mvo> jibel: oh, so maybe a outdated python-central? we can add "patch" support if we know what needs patching in pycentral to fix this
<doko> jibel, so to reproduce: install lucid from the alternate, upgrade to lucid-updates, then take it offline and then do the upgrade with the alternate precise CD?
<jibel> doko, correct
<doko> jibel, can you see if the new python-central is unpacked before the release-upgrader-python-apt package is configured?
<doko> mvo, jibel: we might want the fix for: +  * Fix up for multiarch dpkg: /var/lib/dpkg/info/$pkg.list is now no longer
<doko> +    guaranteed to exist, it may be /var/lib/dpkg/info/$arch/$pkg.list
<doko> +    (Steve Langasek).
<jibel> doko, here is the sequence from dpkg.log
<jibel> paste.ubuntu.com/938420
<mvo> doko: its instaled pretty much before anything else
<cjwatson> doko: well, it's $pkg:$arch.list now
<cjwatson> we don't want $arch/$pkg.list since that's not the current multiarch layout :)
<doko> mvo: is PYCENTRAL_NO_DPKG_QUERY set for the upgrade?
<cjwatson> doko: I'm fixing the pymvpa build now
<mvo> doko: yes
<doko> cjwatson: so I should check for $pkg.list and $pkg:$arch.list ?
<mvo> doko: but from the bugreport it seems like pycentral is unhappy about the missing(?) Python-version field - or is that a red-hering?
<doko> mvo: read backlog, the attribute is there
<cjwatson> doko: yes, well, if you can't use an actual published interface instead
<cjwatson> (i.e. dpkg-query -L)
<doko> cjwatson, right, used by default, unless you set PYCENTRAL_NO_DPKG_QUERY, which the installer does
<doko> mvo: do you remember why we did this?
<cjwatson> ah
<cjwatson> bizarre, speed issue or something?
<doko> I think that is a left-over for the previous lts upgrade, when we didn't have the -L option in dpkg-query
<cjwatson> that'd be a surprise, it's been there forever
<doko>   * pycentral.py:
<doko>     - if the PYCENTRAL_NO_DPKG_QUERY environment is set
<doko>       pycentral will not use dpkg-query (needed for
<doko>       dapper->hardy upgrades where dpkg-query might be
<doko>       confused about triggers information in the status
<doko>       file)
<cjwatson> ah
<doko>  -- Michael Vogt <michael.vogt@ubuntu.com>  Wed, 21 Nov 2007 15:25:03 +0100
<doko> mvo: how do you want to fix this? just not setting the env var?
<mvo> doko: if you feel like this is the right approach, that is fine with me
<doko> mvo: yes, I think so
<mvo> doko: we could add a patch to the releas-upgrader that patches pycentral before it starts too
<mvo> doko: ok, then I will upload with that disabled
<doko> mvo: no, no
<doko> mvo: where do you set the PYCENTRAL_NO_DPKG_QUERY env var?
<mvo> doko: right when it starts
<doko> mvo: so just don't set it
<mvo> ok
<doko> cjwatson, I'll fix the direct lookup anyway
 * cjwatson nods
<apw> slangasek, ok the failure in libdrm there is reporting the correct open, ie. it opened successfully so we did not hit the EAGAIN issue...
<apw> bryceh, you any idea where i'd find the code which reports the SetVer error for this bug ?
<doko> mvo, will you fix update-manager, or should I upload the fix?
<mvo> doko: I just uploaded it
<doko> ok
<dupondje> barry: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/850264 doesn't this fix your issue ?
<ubottu> Launchpad bug 850264 in apt (Ubuntu Oneiric) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Fix committed]
<pitti> slangasek: thanks for pointing out bug 937249; I tracked it down, uploading SRU now
<ubottu> Launchpad bug 937249 in apport (Ubuntu Precise) "apport-gtk crashed with SIGSEGV in composite_line()" [High,Fix committed] https://launchpad.net/bugs/937249
<slangasek> pitti: sweet, thanks
<pitti> that was a funny one
<slangasek> pitti: and yes, I'm using a non-standard icon theme here too :)
<pitti> it was really lucky to not crash with the standard ubuntu themes
<pitti> because they don't use an icon cache, being SVG only
<pitti> (or at least not a system-wide one)
<vibhav> Could somebody nominate https://bugs.launchpad.net/ubuntu/+source/pan/+bug/364732 for currently supported Ubuntu releases?
<ubottu> Launchpad bug 364732 in pan (Ubuntu) "pan: WARNING: setting an adjustment with non-zero page size is deprecated." [Undecided,Confirmed]
<slangasek> mvo: still around?  We're looking at this u-m upload right now; since it only affects LTS->LTS upgrades, using an image that we aren't going to be pressing to CD, we might ask to do this as an SRU instead of pushing it into .0.  If so, do you have time to reupload to -proposed today or would you like me to take care of it?
<vibhav> Also, is it compulsary for me to create patches for packages that have the source format '1.0'
<vibhav> OR shall I just prepare a raw debdiff?
<barry> dupondje: hmm, i'll give it a try.  maybe slangasek has an opinion (on whether the fix for bug 850264 should be expected to also fix bug 924079)
<ubottu> Launchpad bug 850264 in apt (Ubuntu Oneiric) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Fix committed] https://launchpad.net/bugs/850264
<ubottu> Launchpad bug 924079 in apt (Ubuntu Oneiric) "do-release-upgrade fails to upgrade from Oneiric to Precise" [High,Triaged] https://launchpad.net/bugs/924079
<slangasek> barry, dupondje: it is not expected to
<slangasek> 924079 is about package ordering
<slangasek> 850264 is about wrong resolution of deps
<cjwatson> vibhav: if it doesn't have some kind of patch system, you should just change the source directly rather than introducing a patch system in an Ubuntu delta
<barry> slangasek: okay cool.  note the feedback from mvo (channeled through me) in the latter bug
<SpamapS> can somebody please explain this seemingly insane patch to me: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/python-virtualenv/precise/view/head:/debian/patches/pep3147-dist-packges.patch ?
<SpamapS> tumbleweed: perhaps you can actually. ^^
<tumbleweed> SpamapS: how is that insane?
<SpamapS> tumbleweed: a giant block of uuencoded text with no explanation on how to regenerate it?
<SpamapS> also, I just say it *seems* insane to me
<tumbleweed> I sorted that out upstream :)
<SpamapS> it may be perfectly sane
<tumbleweed> basically the block of uuencoded text is the same as the readable diff around it
<tumbleweed> virtualenv embeds lots of things inside virtualenv.py
<tumbleweed> it now has everything that it embeds, and the scripts to update it, in the source tarball, so this kind of thing can be done more sanely
<SpamapS> tumbleweed: right, and it looks like its been applied in the new release. But its just that the patch itself offers no way to refresh it.
<SpamapS> tumbleweed: since I have your attention, I was going to cherry pick the fix for bug 986227 .. but then I saw that 1.7.1.2 is out and includes it...
<ubottu> Launchpad bug 986227 in python-virtualenv (Ubuntu) "virtualenv in precise has recursive symlink bug" [Undecided,New] https://launchpad.net/bugs/986227
<SpamapS> tumbleweed: If I were to update it in the DPMT svn tree, would you be up for sponsoring it? Then I can just sync
<tumbleweed> sure
 * tumbleweed seems to be a virtualenv uploader these days
<SpamapS> tumbleweed: thanks .. I'll poke you when its updated in the tree
<tumbleweed> SpamapS: bin/rebuild-script.py btw
 * tumbleweed wishes a virtualenv upstream would review https://github.com/pypa/virtualenv/pull/231
<apw> 555555555555555555555555555555555555555
 * cjwatson decrements apw
<apw> 555555555555555555555555555555555555554
<apw> damnable keyboard, never had _that_ happen before
<cjwatson> bottles of beer on the wall
<cjwatson> sounds like a kernel team night out really
<roaksoax> jdstrand: howdy!
<roaksoax> jdstrand: i've attached the apparmor profile to bug #975442
<ubottu> Launchpad bug 975442 in maas-provision (Ubuntu Precise) "add apparmor profile for cobblerd" [High,In progress] https://launchpad.net/bugs/975442
<roaksoax> jdstrand: I'd appreciate your review. Thanks! https://launchpadlibrarian.net/102704100/usr.bin.cobblerd
<jdstrand> roaksoax: thanks! why is dac_override needed?
<jdstrand> roaksoax: beyond that, it looks good :)
<jdstrand> roaksoax: I'll respong in the bug
<jdstrand> respond
<roaksoax> jdstrand: TBH, the reason why I added dac_override was becaose of this:  apparmor="DENIED" operation="capable" parent=1 profile="/usr/bin/cobblerd" pid=32110 comm="cobblerd" capability=1  capname="dac_override
<apw> hallyn, slangasek, ok i cannot _see_ any way this can occur, i have therefore shoved some debug in the drm setversion ioctl to see if we see anything ... see the bug for a link
<jdstrand> roaksoax: hmmm, I see it is calling os.setuid(100)
<slangasek> apw: so the EAGAIN is only on open?  I had inferred it was when trying to use the dev rather than open it
<apw> slangasek, only on open indeed.  after that it is out of the picture
<apw> slangasek, anyhow if we can get some testing i've added lots of dmesg cruft for it
<jdstrand> roaksoax: commented in the bug
<slangasek> apw: right - hallyn isn't likely to be able to help here, IIRC we re-triaged his issue as a binary driver problem rather than a drm one
<apw> slangasek, well if its reproducible we may find it, if not, hey ... we should not worry so much
<apw> slangasek, its very odd.  its almost like we are doing ioctls on the drm stub, which btw is impossible
<slangasek> apw: *we* can't reproduce it so far; but people with particular hardware configs can
<apw> slangasek, ok then we rely on them to test, and after a long discussion with upstream we have little clue as to the cause ... hense the debug kernels
<roaksoax> jdstrand: uhmmm adding the deny still causes the daemon to start
<roaksoax> jdstrand: uhmmm adding the deny still causes the daemon to not start
<jdstrand> roaksoax: did you see my last comment-- it's good to go :)
<bryceh> apw, you mean the -intel race condition bug? seems we traced the error message down to a routine in libdrm
<slangasek> bryceh: so there's reason to believe it's userspace-side?
<bryceh> slangasek, the code that notices the kernel driver is missing/borked/unready is userspace-side, yes.
<slangasek> bryceh: hmm, so there's already code for this and it's not working right?
<bryceh> slangasek, the code is an assert, and it's working fine (that's the problem *grin*)
<slangasek> heh
<slangasek> but if that changes... doesn't this still amount to user-side polling for the driver to be ready?
<bryceh> slangasek, how do you mean?
<slangasek> fundamentally, we don't *want* to be trying to open the drm device until the kernel's ready
<bryceh> slangasek, right
<slangasek> we *want* the kernel to tell us when it's ready, but that's not what it's doing
<bryceh> right
<slangasek> which is why we're hitting an assert... so ideally, we would still fix this on the kernel side?
<bryceh> slangasek, yes
<bryceh> slangasek, maybe context of my initial comment was missing...  apw had earlier in the scrollback asked me where I'd traced the error that we were getting.  So I said we traced it as far as libdrm.
<slangasek> ah
<slangasek> sorry, I was assuming I had full context since he'd highlighted me as well :)
<bryceh> slangasek, who's on first?
<bryceh> slangasek, are you following apw's discussion with airlied on the patch?
<slangasek> no
<slangasek> is that on the freedesktop bug or somewhere else?
<bryceh> it's not on the bug, I think it's lkml, lemme dig it up
<bryceh> linux-kernel@vger.kernel.org
<bryceh> Subject: [PATCH 0/1] [RFC] DRM locking issues during early open
<bryceh> slangasek, https://lkml.org/lkml/2012/4/19/245
<bryceh> slangasek, https://lkml.org/lkml/2012/4/19/252 is daniel vetter's reply, worth looking at
<roaksoax> jdstrand: i made two additions to the apparmor profile, which are: /var/www/cobbler/ w, and /var/log/cobbler/ r,
<jdstrand> roaksoax: ack, sounds fine :)
<roaksoax> jdstrand: quick packaging review if you like: http://paste.ubuntu.com/938830/
<apw> bryceh, i have posted some test kernels, as the issue is differnet, the hole we carried that patch for was inadvertantly closed by the BKL conversion to drm_global_mutex
 * slangasek nods
<jibel> all the upgrades from oneiric to precise failed with
<jibel> SystemError: E:This installation run will require temporarily removing the essential package python-minimal due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option., E:Internal Error, Could not early remove python-minimal
<jibel> filing a bug
<jibel> bug 986374
<ubottu> Launchpad bug 986374 in update-manager (Ubuntu) "oneiric->precise upgrade failed: E:Internal Error, Could not early remove python-minimal" [Undecided,New] https://launchpad.net/bugs/986374
 * slangasek squints
<Caesar> slangasek: I'm trying to do some archaeology on pciutils (1:3.1.8-2ubuntu1), where you moved the shared libraries to /lib
<Caesar> The bug number in the changelog looks incorrect
<slangasek> Caesar: sigh - not a wrong bug #, but a private bug
<slangasek> Caesar: and not one I can make public, sorry - but I can answer any questions you have
<Caesar> slangasek: just trying to understand the reasoning behind the change
<slangasek> Caesar: the biosdevname tool needs to be called from udev, so should be on the rootfs regardless of the admin's local partitioning choices
<slangasek> and it depends on libpci
<Caesar> slangasek: thanks
<Caesar> Sort of related, what causes ldconfig to get run after the libraries move?
<slangasek> the sort of thing we'd stop worrying about come FedoraUsrMove, I guess :)
<Caesar> :-(
<bdmurray> slangasek: looking at bug 964115 could free space in /tmp be an issue?
<ubottu> Launchpad bug 964115 in update-manager (Ubuntu) "package libcryptsetup4 2:1.4.1-2ubuntu2 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [High,Incomplete] https://launchpad.net/bugs/964115
<slangasek> Caesar: policy says each library package calls ldconfig from its postinst
<Caesar> slangasek: that's what I thought
<Caesar> libpci3 doesn't though
<slangasek> bdmurray: I suppose it could be... is that what the log points to?
<slangasek> Caesar: /var/lib/dpkg/info/libpci3:amd64.postinst shows it for me here?
<slangasek> (dh_makeshlibs goodness)
<Caesar> slangasek: *facepalm*
<Caesar> I was looking at the pre-debhelpered postinst
<slangasek> :)
<Caesar> Thanks for your time
<slangasek> n/p
<jeinor> good evening :) anyone have time to perhaps help out on a Ubuntu boot problem (ARM, kernelproblem, Ubuntu Core)?
<slangasek> jeinor: I think you're unlikely to learn anything here you haven't already learned.  Have you tried #ubuntu-arm?
<jeinor> slangasek: hi there :) thanks for all the help and answer yesterday
<jeinor> slangasek: really helpful. I actually got a bit further after your advice, but I'm stuck again now. It seems I can't say anything after joining #ubuntu-arm, you have any idea why? only registered users?
<jeinor> slangasek: "cannot send to channel #ubuntu-arm"
<slangasek> perhaps so
<slangasek> the channel mode has a bit I'm not familiar with ("c")
<slangasek> what's the next point you're stuck at?
<slangasek> (also, have you considered registering?  it's free ;)
<jeinor> slangasek: currently using the webchat.freenode.net, I should perhaps install a client..
<stgraber> IIRC 'c' is just the color/bold/... filtering mode
<slangasek> ok then
<jeinor> slangasek: I got the output we were looking for yesterday from the USB serial cable (used putty to connect to ttyS0)
 * slangasek nods
<jeinor> slangasek: it boots til the point where it should continue in rootfs (I think). It tries to mount the rootfs partition (or so I believe), but fails
<jeinor> slangasek: the error message is "cannot open root device mmcblk02p or unknown-block(0,0)
<slangasek> did your original install have an initramfs?
<slangasek> and do you still have that?
<jeinor> I'm not sure. The original install had a boot partiton and a root fs partition. Both on a SD card. It used a 2.6-kernel, which I am now replacing with kernel 3.3.1, but I'm still using the same kernel command line.
<jeinor> the original install booted Ubuntu 10.04 with X fine, and if that requires an initramfs it had one
<jeinor> I'll google what that is as we speak :)
<slangasek> and you haven't changed the contents of the boot partition at all?
<jeinor> I have replaced the /boot/uImage with a new kernel. I compiled 3.3.1 to replace the old 2.6 kernel, and then replaced that on the boot partition.
<slangasek> the initramfs is actually separate from the kernel commandline, and passed directly via the bootloader
<slangasek> ah, well
<slangasek> there's the problem
<slangasek> your new kernel doesn't have the driver for the root disk
<slangasek> so the firmware can load the kernel off the disk, but then the kernel can't see the disk
<slangasek> you should probably get 12.04 working with the vendor-provided kernel first
<jeinor> that makes sense. The reason I tried with the 3.3.1 kernel was that I got a looping error message about a "udev, function not implemented" or similar when trying to run ubuntu core using the old 2.6 kernel
<jeinor> I figured Ubuntu Core required some functionality not existing in my 2.6 kernel
<slangasek> that's possible
<slangasek> in that case, upgrading the kernel is necessary... but it's also tricky
<slangasek> you're pretty much on your own about making sure you get the right kernel config
<jeinor> ok. I actually got the kernel configuration from a forum thread where a user with the same hardware had got it running.
<slangasek> and who knows if the upstream kernel even works on this device?
<Shinobi> I'm installing 12.04 in VBox and getting guru meditation errors inconsistently.
<jeinor> That's why I thought there had to be something wrong with my kernel command line
<slangasek> you might want to poke that forum thread to see if that user had an initramfs... if so, you need to generate an initramfs to go with your kernel
<jeinor> according to him (the thread is here, if you're interested: http://www.solid-run.com/phpbb/viewtopic.php?f=9&t=493), he just replaced the /boot/uImage and he was up and running
<slangasek> hmm
<slangasek> well, I'd press *him* for details on the right kernel commandline :)
<jeinor> he doesn't mention any initramfs, but perhaps that's obvious if you know what you're doing :)
<jeinor> guess who the last person is who wrote in that thread ;)
<jeinor> I guess I'll just have to have patience (meaning I will bang my head in the wall trying everything I can think of until he answers)
<jeinor> really appreciate your answers and help here though, thanks a lot
<slangasek> sure
<slangasek> you should really register and get on #ubuntu-arm :)
<jeinor> yea, that seems like the best next step. I'll get right into that.
<jeinor> slangasek: I actually think the drivers for the SD card reader is setup correctly, it says in the log it finds /dev/mmc0 and /dev/mmc1 (that must be my boot partition and rootfs partion)
<jeinor> partition*
<jeinor> I just think the kernel loads the wrong one when it tries to mount mmcblk0p2
<slangasek> mmcblk0p2 is the root partition; the "p2" means partition 2
<slangasek> and the raw disk should be /dev/mmcblk0, not /dev/mmc0, I think
<slangasek> but I don't have anything in front of me I can check that against
<jeinor>  hmm, you're probably right. But there seems to be something wrong with the way I change the kernel command line. That's probably why it didn't work yesterday as well.
<jeinor> I just tried adding --verbose, and that makes the whole process halt when trying to find /boot/uImage. I think there's something I don't understand about u-boot
<jeinor> slangasek: aha! apparently I couldn't just change the kernel command line arguments the way I did, it had no effect. I had to regenerate the file /boot/boot.scr using mkimage.
<jeinor> slangasek: after doing that, it starts picking up my new kernel command line args. That explains why nothing happened when I added --verbose or removed console= yesterday
<jeinor> didn't help to change it to /dev/mmc1 though, still can't find the rootfs :/
<slangasek> yes, whatever /dev/mmc1 refers to, it's not your root partition
<jeinor> you're right
<jeinor> I'm starting to think you're right about the missing drivers.. when it says "here are the available partitions:" it lists none
<slangasek> bdmurray: any idea then why edward.donovan is seeing users directed to bug #628104, if there's no bug pattern?
<ubottu> Launchpad bug 628104 in Aptdaemon "update-manager crashes: AptDaemonError: org.debian.apt: Could not cancel transaction" [Undecided,Confirmed] https://launchpad.net/bugs/628104
<bdmurray> slangasek: nothing utterable
<slangasek> clearly users are seeing this error, but I think we need to get a clean backtrace
<slangasek> hmm
<bdmurray> I've tried recreating it a few times without luck
<slangasek> is there anything we've overlooked so far that would explain the users being sent to that particular bug?
<bdmurray> slangasek: maybe a bugpattern pointing a duplicate which redirects to that?  I don't see one though
<slangasek> hmm
<bdmurray> there is a pattern for similar bug 707990
<ubottu> Launchpad bug 707990 in aptdaemon (Ubuntu) "update-manager crashed with DBusException in _convert_dbus_exception(): org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." [Low,Invalid] https://launchpad.net/bugs/707990
<bdmurray> but that matches on DBusException in the title
 * slangasek nods
#ubuntu-devel 2012-04-21
<sgCoder> hi
<hyperair> huh there's a really huge multiarch breakage today in the archive
<hyperair> all my :i386 packages got removed
<hyperair> ...even nautilus got removed?!
<hyperair> oh it looks like it's fixed
<cyphermox> SpamapS: poke
<cyphermox> re bug 211631: I'm not certain your comment is true. I think the binaries that run the VPN plugins would get killed by sendsigs.
<ubottu> Launchpad bug 211631 in wpasupplicant (Ubuntu Natty) "Network is brought down before network filesystems are unmounted (CIFS timeout at shutdown)" [Undecided,New] https://launchpad.net/bugs/211631
<cyphermox> (and I should fix that ;)
<SpamapS> cyphermox: Ah so just like dnsmasq, they need to add themselves to the whitelist
<cyphermox> SpamapS: possibly. It depends at what point the stuff gets unmounted. if it's a SysVinit script, it would get unmounted before sendsigs, then the vpn plugin binary XYZ would get killed, and all is well
<cyphermox> if it's an upstart job, then all is not well; but that's easy enough to fix
<cyphermox> I just don't remember and didn't bother to look at the setup again to make sure, yet ;)
<trijntje> ping pitti: I'm trying to build a localised image using a PPA, but ubuntu-defaults-image returns "Invalid fingerprint returned by launchpad"
<cyphermox> SpamapS: I think regardless it makes sense to avoid the plugins getting killed before NM turns interfaces and VPNs off, which would get stop these processes anyway
<slangasek> cyphermox: sendsigs is run from a sysvinit script, one which deliberately runs before unmounting network filesystems
<slangasek> that's the same root issue as it's been all along, just now with a different type of network helper being killed
<cyphermox> slangasek: right, because the processes could have been started from a remote FS or depend on it
<slangasek> yes
<cyphermox> aye aye, will just need to make the processes spawned by NM be omitted for that too
<slangasek> yep - *any* process NM spawns, that it expects to keep running and reap on its own at shutdown, should be in the omit list
<cyphermox> that's a fix in each of the vpn plugin packages, there are only for.
<cyphermox> *four
<slangasek> ok
<trijntje> pitti: Nevermind, I was using the wrong name for the ppa
<rectec> How are you guys? Before I ask for help, I just want to ask how development is going along. We have only 5 days until release and currently my installation looks a bit shabby...
<rectec> anyone?
<rectec> ok, well... I have a problem in which the text inside dialog boxes is too light to read. This affects the Ambiance theme and one other theme. (The Hope theme, only 3rd-party theme I've tested.) The Radiance theme doesn't seem to have this issue.
<rectec> I don't know if this is a known issue and has/has not been solved, or if I'm the only one with this issue.
<vibhav> Ive updated a package (onboard) to 0.97-0-0ubuntu3 locally, How Do I get it into oneiric?
<jtaylor> doko_: numpy -8 merge: https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/merge-8/+merge/102970
<jtaylor> its not very important so if its to late feel free to reject it
<jeinor> slangasek: I got the Cubox up and running with kernel 3.3.1 and Ubuntu Core 12.04 beta 2 :D
<jeinor> slangasek: got some (a lot) of help from ogra_ in #ubuntu-arm, and with his directions I finally got a login console!
<jeinor> slangasek: thanks for all your help too, really helpful!
<SpamapS> vibhav: You need to file a bug, make sure that bug is fixed in the latest dev release (precise still.. soon "q"), and then choose 'Nominate for series' in launchpad and choose Oneiric.  https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<hdon-> hi all :) in many months using the latest ubuntu LTS i have noticed that all my CPU cores are rarely used. even if i am building large software packages with -j5 only 1/4 CPU cores are being fully utilized. i'm certainly not I/O bound at the hard disk. if anyone has any advice for me i would be very thankful
<penguin42> how many cores do you have?
<infinity> penguin42: I'm assuming 4.
<infinity> hdon-: How are you determining if your cores are being "used"?
<infinity> hdon-: If you make -j5, you should get 5 forks of make (assuming the Makefile can parallelize well, the kernel's always a good test).
<infinity> hdon-: That doesn't mean each CPU will get pegged at 100%, but it does mean each will get "used".
<hdon-> infinity, the system monitor application
<hdon-> infinity, it seems to my eye that only one CPU is being used fully at a time. the others all hover around 20%, and of course they switch off. one core isn't always the same one on duty
<infinity> If you make a kernel with -j4 (or higher), you should see a system load in top >= 4.
<infinity> Snapshots of system use are rarely accurate.
<infinity> (For instance, in the above kernel scenario, with -j4, you'll often see 4 instances of "cc1", but they won't necessarily all report using 100% CPU at all times)
<IntuitiveNipple> What's the procedure for requesting a freeze exception for a bug-fix at this stage? I've subscribed ubuntut-release as per one wiki recommendation (bug #927828 in sudo) ?
<ubottu> Launchpad bug 927828 in sudo (Ubuntu) "sudo: pam_mount.c:417: modify_pm_count: Assertion `user != ((void *)0)' failed." [Undecided,In progress] https://launchpad.net/bugs/927828
<cjwatson> IntuitiveNipple: that sounds like a good candidate for an SRU, I think, rather than trying to squeeze a fix in a few days before release when we don't have much time for validation or for recovering if something goes wrong
<cjwatson> I assume it only affects people with pam-mount installed (?), so perhaps it's release-note and fix for .1
<maxb> cjwatson: Oh, about the subversion FTBFS - I've been slowly slowly plodding through building a set of backported patches, but every time I think I'm done, another test randomly fails.
<IntuitiveNipple> It affects all pam modules... its just that pam_mount complains with an assert
<IntuitiveNipple> The key issue is, that the bug revealed, pam_open_session() isn't called when sudo has a valid timestamp
<IntuitiveNipple> So pam modules that are hooking the begin_session won't get triggered
<IntuitiveNipple> I suppose a work-around would be to temporarily set "timestamp 0"
<cjwatson> maxb: I know the feeling
<cjwatson> doesn't help that it's a slow build
<maxb> It builds quite quickly on my desktop; the testsuite is a bit slow, though
<cjwatson> IntuitiveNipple: well, what I mean is, this bug was reported in February, and *I* haven't been seeing the second use of every sudo ticket fail
<cjwatson> If it were doing that for everyone, this would be High or Critical and likely a showstopper - but it isn't
<IntuitiveNipple> Maybe it affects Oneiric->Precise upgrades ?
<cjwatson> Then it would affect me
<cjwatson> This is the first I've heard of this bug, in fact
<IntuitiveNipple> yeah, I was trying to figure out what it is that is causing it. For those that it affects, it occurs whenever there's a valid timestamp
<cjwatson> So it must have some kind of narrowed criteria
<IntuitiveNipple> Maybe it's something to do with PAM configuration
<cjwatson> Hence my comment about libpam-mount, if that's the only thing that fails hard
<cjwatson> And since that's an add-on not installed by default, IIRC ...
<IntuitiveNipple> Really? I didn't know anything about it until this bug then I found it installed
<IntuitiveNipple> Hmmm!
<IntuitiveNipple> Maybe it's to do with if encrypted home is in use?
<cjwatson> I don't see anything like that in its reverse-depends
<IntuitiveNipple> Interesting - I assumed it was part of the standard installation since I didn't recognise it
<cjwatson> Just sadms, which isn't by default either
<cjwatson> It's been in server-ship since hardy, but that's all I see immediately - can look a bit harder later
<IntuitiveNipple> I've just grepped all of /var/log/apt/* which goes back to Dec 5th without seeing libpam_mount ... so maybe it was installed originally by oneiric on my system, since Oneiric was a clean install
<IntuitiveNipple> OK .. so I should write up an SRU for it?
<maxb> subversion-wise, I think we just have to release precise with it FTBFS; there'll be a SRU soonish for 1.6.18, so it's not completely horrid to do so
<cjwatson> maxb: I really want to reach zero out-of-date binaries - perhaps I could help on Monday given your state so far?
<cjwatson> although it's on some images I guess, argh
<slangasek> IntuitiveNipple, cjwatson: I certainly think not opening pam sessions for authentications with an existing ticket is SRU-worthy but not a show-stopper; in fact there are several bugs in sudo session handling that I think need sorted out in SRU, and this is among them.  But yes, pam-mount isn't stock.
<IntuitiveNipple> It must be have been sadms that brought it in - I _vaguely_ recall looking at that package for some reason last year
<IntuitiveNipple> slangasek: Well it looks like the sudo author accepts there is an issue now, despite initially saying my analysis was wrong, so maybe now's the time to push bugs upstream
<slangasek> IntuitiveNipple: where is the upstream discussion happening?  bug tracker / list / private email?
<IntuitiveNipple> Well I found the sudo bugzilla and there were only a handful of bugs in it, so it looks like folks rarely use it. It's linked to the launchpad sudo project though, and I've linked it on the bug itself
<slangasek> which bug is that?
<IntuitiveNipple> bug #927828
<ubottu> Launchpad bug 927828 in sudo (Ubuntu) "sudo: pam_mount.c:417: modify_pm_count: Assertion `user != ((void *)0)' failed." [Undecided,New] https://launchpad.net/bugs/927828
<slangasek> ok
<IntuitiveNipple> Rich Miller _is_ the upstream author, was very quick and precise in responding
<slangasek> pitti: so we've worked out with some difficulty that a client-side apport dupe check is causing update-manager crash reports to be treated as duplicates of a closed bug (bug #628104) and we want to have them *not* treated that way so we can get full clean backtraces from bug submitters.  How do we do that?
<ubottu> Launchpad bug 628104 in Aptdaemon "update-manager crashes: AptDaemonError: org.debian.apt: Could not cancel transaction" [Undecided,Confirmed] https://launchpad.net/bugs/628104
<slangasek> well, a bug that /was/ closed
<slangasek> pitti: I don't have confidence here that the duplicate signature is accurate and would like to see a recent backtrace
<slangasek> pitti: or at least get a better understanding of the duplication algorithm :)
<maxb> cjwatson: Sorry, was away; yeah, I figured it was already too late what with it being seeded
#ubuntu-devel 2012-04-22
<Logan_> When I'm patching a package, do I need to update the series file in debian/patches, or will the package maintainer do that after merging?
<jelmer> hi Logan_ ; if you're adding a file in debian/patches it's usually a good idea to update the series file too
<Logan_> Aw, okay. :-P I already proposed it for merging. :-(
 * Logan_ fixes.
<Logan_> My first patch, so I have no idea what I'm doing. :-P
<Logan_> (Well, hopefully some idea.)
<jelmer> Logan_: it's not the end of the world, I'm sure whoever reviews it knows how to update the series file too :)
<penguin42> I'd love to know why flash pauses when I boot a vm
<clausen> how can I figure out the CFLAGS used to build a .deb?
<hyperair> hmmmm how is this multiarch arch:all dependency supposed to work?
<hyperair> i tried to install acroread:i386, but it's trying to pull in acroread-common:i386 which doesn't exist because acroread-common is arch:all.
<hyperair> so i rebuilt it setting Multi-Arch: allowed as mentioned in the multiarch spec...
<hyperair> but that doesn't seem to satisfy dpkg.
<imbrandon> arch:all and arch:any are not the same i think you may want the other
<ScottK> Try installing acroread-common acroread:i386
<hyperair> ScottK: aha, i see it. it's supposed to be Multi-Arch: foreign, not Multi-Arch: allowed.
<hyperair> Multi-Arch: allowed merely permits Depends acroread-common:i386
<hyperair> or something
<hyperair> ScottK: and you need Multi-Arch: to be defined on arch:all packages now.
<hyperair> https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages
<ScottK> Oh.
<hyperair> which.... i haven't defined on my multiarch library packages =
<hyperair> =\
<hyperair> we should have an MBF for this or something..
<vibhav> Shall I cereate a patch or sync python-scipy? https://bugs.launchpad.net/ubuntu/+source/python-scipy/+bug/655192
<ubottu> Launchpad bug 655192 in python-scipy (Ubuntu) "scipy.weave.inline requires python-dev to be installed" [Low,Confirmed]
<vibhav> create*
<vibhav> FYI, the package is unseeded
<Laney> what else would be in the sync?
<micahg> tons of rdeps
<vibhav> http://pastebin.ubuntu.com/940778/
<micahg> well, not tons, but quite a few :)
<vibhav> yes
<Laney> very informative changelog there
<vibhav> why?
<Laney> it doesn't say why any of the changes were made
<vibhav> ah, sarcasn :)
<vibhav> sarcasm*
<Laney> :P
<vibhav> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651760 might help you
<ubottu> Debian bug 651760 in src:python-scipy "python-scipy: should recommend python-dev" [Minor,Fixed]
<Laney> oh, it's got a new upstream too
<vibhav> But isnt the bug a problem with the debian packaging files?
<Laney> if you sync you get everything
<Laney> i'm trying to answer your question
<vibhav> ah
<vibhav> Lets get a sync then
<vibhav> thanks
<Laney> i didn't say that. looks like at least the Ubuntu diff would still be required (so, a merge)
<vibhav> why would a ubuntu diff be required?
<Laney> have a look at our changelog and you can see what it is
<Laney> I think doing the minimal change is going to be safer
<vibhav> you mean adding the python3 packages?
<Laney> adding the new recommends
<Laney> but jtaylor didn't just upload it (instead forwarded the bug) so perhaps it isn't worthwhile
<vibhav> fine
<vibhav> Ill do the minimal change
<vibhav> Also, should I add it as a build-depend or a recommended package?
<vibhav> could anybody nominate https://bugs.launchpad.net/bugs/655192 for supported Ubuntu releases?
<ubottu> Launchpad bug 655192 in python-scipy (Ubuntu) "scipy.weave.inline requires python-dev to be installed" [Low,Confirmed]
<jtaylor> I don't think its really SRU worthy
<vibhav> jtaylor: why?
<jtaylor> its a minor bug easily fixed by the user
<vibhav> since we are fixing it for precise, might as well get the fix in other versions
<jtaylor> SRU's are considerably more work than fixes in precise
<vibhav> ah
<vibhav> Then what about a backport?
<jtaylor> also not really enough for a backport, though backporting 0.10.1 from Q might be a good idea
<jtaylor> its a bit late to add that to precise now
<vibhav> ah
<vibhav> Well, Ill keep it for U+1 then
<vibhav> jtaylor: Is that fine?
<jtaylor> vibhav: we could fix it for precise, if my numpy branch gets merged we could add dh_numpy3 usage too
<vibhav> jtaylor: Could you give me the link to your branch?
<jtaylor> https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/merge-8/+merge/102970
<Laney> it's seeded. I'm not sure that it will get in.
<jtaylor> yeah I guess its to late, but then we merge it in Q
<jtaylor> its on no image though
<Laney> yeah it is
<Laney> ask seeded-in-ubunbut
<Laney> or a correctly spelled variant thereof
<jtaylor> oh it got on the dvd :O
<raffa50> hello. what is the command for rebuilding source. i want to upload it on launchpad
<hyperair> hmm why do we have gccgo from gcc 4.7, but not gcc 4.7? =(
<raffa50> hello. what is the command for rebuilding source. i want to upload it on launchpad
<cjwatson> what exactly do you mean?  Launchpad PPAs will build a source package into a binary package for you ...
<cjwatson> could you clarify?
<cjwatson> hyperair: probably because introducing all of gcc 4.7 would involve an updated libgcc1
<hyperair> cjwatson: ah, that sucks.
<cjwatson> raffa50: perhaps https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage will help you
<clausen> I think Ubuntu 11.04 has a miscompiled ssh
<clausen> it is giving me failed MAC codes, and the openssh source code states that this is a well-known problem
<clausen> when compiling with gcc optimizations enabled (-O2)
<clausen> so it's important to compile the MAC bit without optimizations
<clausen> I only just started getting problems, so I guess I'd like to trace the build history of the package
<clausen> is there a good way to do thsi?
<clausen> (can I see how each package was built, the history of packages uploaded, etc.?)
<ScottK> clausen: https://launchpad.net/ubuntu/+source/openssh/+publishinghistory
<clausen> ScottK, thanks!
<clausen> ScottK, so how can I see the CFLAGS?
<ScottK> Should be in the build logs.
<clausen> aha
<clausen> it is indeed compiled with -O2
<clausen> although the source only complained about -O3 and higher...
<clausen> looks like I'm going to have to do some more digging!
<clausen> is it possible to get the object files from the build?
<cjwatson> clausen: I see no such claim in the openssh source code.  Where do you see it?
<cjwatson> It says you sometimes get incorrect results with -O3, not with -O2.
<cjwatson> And we don't use -O3.
<cjwatson> (I guess you mean the header comment in umac.c)
<clausen> cjwatson, yes, you are right
<clausen> nevertheless, the code doesn't work for me
<clausen> yes, umac.c
<clausen> I regularly get corruption messages
<clausen> so perhaps something else changed (eg: gcc moved some items from -O3 to -O2)
<cjwatson> I don't remember ever seeing those when I was running 11.04
<clausen> it only just started recently
<clausen> (I'm still using 11.04 on my machine...
<cjwatson> Are you sure it isn't a problem on the server side?
<clausen> it started getting regular corruption about 2 weeks ago)
<clausen> yes, I have no trouble if I use dropbear instead of openssh
<clausen> (on the client side)
<cjwatson> After all, it's warning about a transport problem
<cjwatson> That might not signify
<clausen> I agree, it's not 100% evidence
<cjwatson> They're sufficiently different in other ways that they might not tickle the same server bugs
<clausen> but I would like to get to the bottom of this...
<clausen> (the way umac's are used shouldn't make a difference though...
<cjwatson> I suppose you could try building 12.04's openssh as a starting point for comparison
<clausen> ... it's a very simple interface)
<clausen> cjwatson, well, I could recompile myself (11.04) to see if it works :)
<clausen> I will do that
<cjwatson> Yes, though I'd be surprised if that changed anything
<clausen> different gcc?
<cjwatson> Will it in fact be?
<clausen> you would know better than me :)  i don't know how the build machines are configured
<cjwatson> Last openssh upload to natty was 1 April 2011, not that far from release
<clausen> oh
<clausen> that's odd
<clausen> good point
<cjwatson> There were a few gcc-4.5 changes since then, but I wouldn't have expected major code gen fixes, though it would depend on your architecture
<clausen> ok, that's a puzzle then, why I am suddenly getting MAC corruption
<clausen> since the binary didn't change for a year
<clausen> I guess I jumped to conclusions when I saw the comment in umac.c
<cjwatson> Well, that's why I'm suggesting it might not be a problem in that binary :-)
<cjwatson> Nightmare to track down, though, I'm not experienced in that particular part of openssh
<cjwatson> What architecture is this, anyway?
<clausen> come to think of it, it might be the server side
<clausen> x86
<clausen> (intel)
<cjwatson> OK, so shouldn't have been any relevant compiler changes
<clausen> the time-frame is similar to when I upgrade the server from 10.10 to 12.04 beta
<cjwatson> You could try winding back recent library upgrades if you still think it might be a client bug
<cjwatson> There was an eglibc update in natty a month and a half ago or so
<clausen> hmmm
<cjwatson> Or an openssl update a few days ago
<cjwatson> Bit tenuous
<clausen> I'm wary about winding back, because this particular machine is a "secure" machine
<clausen> (I guess I could clone it, and work off the clone...)
<clausen> (but that's a lot of work!)
<cjwatson> Another thing you could try is building 10.10 and 12.04 chroots on the server and starting sshd instances there on spare ports
<clausen> yes
<cjwatson> So that you can compare a bit more accurately
<clausen> that's a good idea
<cjwatson> Then possibly bisect at least at the level of uploads
<clausen> in fact, I still have 10.10 on another partition, so I can chroot to that ;)
<clausen> yes
<cjwatson> debootstrap's easy enough if not
<clausen> very good suggestion
<clausen> thanks
<cjwatson> good luck ...
<clausen> thankyou :)
<cjwatson> To answer your earlier question, the object files from the build are discarded, although you might find some debug symbols on ddebs.ubuntu.com if it happens to have a matching version
<cjwatson> (That service isn't desperately robust and it does sometimes not have matching versions)
<dupondje> Still allowed to do bugfix uploads?
<cjwatson> to unseeded packages in universe, yes
<cjwatson> otherwise ask the release team
<dupondje> https://launchpad.net/ubuntu/+source/remmina => scrolling is broken in rdp connections. Because of GDK_SCROLL_SMOOTH.
<cjwatson> that's on the desktop CD (among others) and it doesn't sound like a showstopper - I'd recommend an SRU
<dupondje> I'll prepare an SRU then :)
<dupondje> Good to have it fixed still. Quite annoying issue (for me at least ;))
<raffa50> hello. what is the command for build the package of debian? i need to upload my software on launchpad
<astraljava> raffa50: Did you not understand the previous instructions? You don't need to build locally in order to use a PPA.
<astraljava> raffa50: https://help.launchpad.net/Packaging/PPA
<vibhav> Since only 5 days are left for 12.04 , should we fix https://bugs.launchpad.net/ubuntu/+source/sivp/+bug/879097 in Ubuntu directly?
<ubottu> Launchpad bug 879097 in sivp (Ubuntu) "libraries are not properly loaded in etc/SIVP.start " [Undecided,Confirmed]
<vibhav> instead of getting it first into Debian?
<raffa50> uhm i found
<jtaylor> vibhav: do you have a working patch?
<ScottK> vibhav: Yes.
<nigelb> Do we have a name for Q yet?
<arand> nigelb: Don't think so, but it's generally around this time it gets announced iirc
<nigelb> arand: It's far far later than normal. :)
<nigelb> I wonder if sabdfl is saving it for the UDS opening keynote ;)
<micahg> cjwatson: what do you think of removing packages that FTBFS in the rebuild on all archs that have been removed from testing?
<micahg> cjwatson: oh and have no rdeps
<arand> nigelb: Might just be very hard to find positive adjectives on Q...
<nigelb> arand: HA. lol.
<penguin42> arand: Quintessential Quetzalcoatlus, obvious really
<nigelb> penguin42: haha
<penguin42> nigelb: I know Mark always likes things that are easy to spell and type
<nigelb> penguin42: yeah. he does care for us developers
<nigelb> who have to type it out many times ;-)
 * penguin42 is still just bitter that PP isn't penguin
<penguin42> oh, nested KVM seems to work nicely on PP; I've just booted a OO VM on a PP server running on a PP host
<penguin42> and given the number of impossible things I've done this weekend I should give up now :-)
<ScottK> oneiric was not easy to type at first.
 * tumbleweed is hoping for a quirky quagga - quirky is a great name for a post-LTS release :)
<jtaylor> well it falls into debian freeze
<jtaylor> so it won't be so bad
<ScottK> I'm sure we'll invent plenty of crack on our own.
<ScottK> Qwality Quail
<ScottK> http://dilbert.com/strips/comic/1996-06-11/ comes to mind.
<jtaylor> ^^
<tumbleweed> :)
<cjwatson> micahg: I'm gradually fixing or removing anything that has out-of-date binaries as a result of build failures.  I expect most of the packages in your category would be sane to remove, but I'd like to apply some case-by-case judgement all the same
<cjwatson> out-of-date binaries are more urgent IMO
 * ScottK doesn't understand why all the axiom binaries on the the outofdate list.
<cjwatson> YM from architectures that built?
<micahg> powerpc is behind
<cjwatson> They're probably arch all.  LP nowadays keeps arch all around until there are no arch-specific binaries from the same version, to try to reduce skew-induced damage.
<Laney> it's the arch:all binaries being held because of the FTBFS
<cjwatson> Fix or remove the arch-specific ones, and the arch all binaries will be dominated away on the next publisher run.
<micahg> where's this out of date list?
<Laney> http://people.canonical.com/~ubuntu-archive/testing/precise_outdate_all.txt
<Laney> and s/testing/testing-ports/
<micahg> meh, I've added 2 to the list apparently
<cjwatson> it's about half the length it was on Friday :)
<cjwatson> it does fluctuate a bit
<cjwatson> one of these days I must add a currently-building indication to it
<ScottK> It definitely looks much better than the last time I looked at it.
#ubuntu-devel 2013-04-15
<mwhudson> RAOF: ayt?
<RAOF> mwhudson: EUNKNACRONYM
<RAOF> Oh, are you there.
<RAOF> I guess I've also answered, then :)
<mwhudson> RAOF: i'm doing that terrible thing were i bug a person who i think knows about X
<mwhudson> RAOF: but i'm getting lots of "soft" gpu crashes with sandybridge on recent quantal
<mwhudson> RAOF: do you know anything about that?
<RAOF> By "soft gpu crashes" what you mean is "apport pops up saying the GPU has crashed, but you haven't noticed anything wrong", right?
<mwhudson> more or less
<mwhudson> it freezes for a second or two, so i know something has happened
<mwhudson> but i don't have to restart
<mwhudson> and there are messages like "[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung" in syslog
<mwhudson> WARNING: at /build/buildd/linux-3.5.0/drivers/gpu/drm/i915/intel_pm.c:2505 gen6_enable_rps+0x706/0x710 [i915]()
<infinity> mwhudson: That's probably old crashes all being reported in a batch since your last reboot.
<infinity> mwhudson: Check timestamps in /var/crash.  If they're all old, just wipe 'em out and try fresh.
<infinity> Oh, if you're seeing new hangs in the kernel rungbuffer, ignore me.
<infinity> ringbuffer, even.
<mwhudson> infinity: xserver-xorg-video-intel.2013-04-15_12:25:14.100714.crash
<mwhudson> that's about 5 minutes old
<infinity> Kay, nevermind.  We just had a case of "I rebooted quantal and apport went insane and I'm blaming it on the new kernel" a few days ago.
<infinity> So, that's my go-to. :P
<mwhudson> :)
<RAOF> Sorry s baby attack
<RAOF> mwhudson: I don't know anything specific about that - have we updated mesa in quantal recently? You say it only recently started?
<mwhudson> RAOF: yeah, it only started a week or so ago
<mwhudson> RAOF: oldest thing in /var/crash is from apr 9, but i don't know if that gets auto-pruned
 * mwhudson times out launchpad a few times
<mwhudson> RAOF: https://launchpad.net/ubuntu/+source/mesa/+publishinghistory does show things from around that time
<RAOF> Yeah, we would seem to have pulled in the 9.0.3 mesa point release.
<RAOF> Which would be a plausible cause.
<RAOF> I don't suppose you'd feel like downgrading to the previous mesa package and seeing if the hangs still occur?
<mwhudson> sure
<mwhudson> ... if i can still download the previous package from somewhere?
<RAOF> Yeah, launchpad. Let me slurp you up a link.
<RAOF> mwhudson: https://launchpad.net/ubuntu/+source/mesa/9.0.2-0ubuntu0.1 has links to all the various builds; presuming you're after amd64 packages you can get them from https://launchpad.net/ubuntu/+source/mesa/9.0.2-0ubuntu0.1/+build/4312581
<mwhudson> that's a lot of packages :/
<mwhudson> i guess i don't need -dev or -dbg?
<RAOF> No.
<RAOF> Nor any of the swx11 ones.
<RAOF> In fact, you only need the ones that you've currently got installed, which is not likely to be *too* much more than libgl1-mesa-glx and libgl1-mesa-dri
<mwhudson> oh god i have 32 bit mesa installed too it seems
<mwhudson> (probably because of steam?)
<RAOF> Yeah, that'd be right.
<RAOF> So, you'll need to grab the i386 versions, too :)
 * mwhudson runs sudo dpkg -i *mesa*9.0.2* in a loop while downloading more and more things
<RAOF> Yeah, that's about the shape of it.
<mwhudson> sigh
<mwhudson> ok, i think i have that working again :)
<mwhudson> can't restart now but will get back to you later ,,,
<RAOF> mwhudson: Ta
<hyperair> any archive admins around? (bug #1069292)
<ubottu> bug 1069292 in Ubuntu "[needs-packaging] New package tegaki-zinnia-traditional-chinese" [Wishlist,In progress] https://launchpad.net/bugs/1069292
<Mirv> slangasek: you may be right. the thing that pointed towards it was that the skype crasher is very popular and happens right when the program starts, while none of the other packages have any recent crash or "doesn't start" reports
<dholbach> good morning
<ion> good ****ing
<apachelogger> chrisccoulson: bug 1168152
<ubottu> bug 1168152 in firefox (Ubuntu) "package kubuntu-firefox-installer 12.04ubuntu1 [modified: usr/share/applications/firefox.desktop] failed to install/upgrade: Versuch, Â»/usr/share/applications/firefox.desktopÂ« zu Ã¼berschreiben, welches auch in Paket firefox 20.0+build1-0ubuntu1 ist" [Undecided,Confirmed] https://launchpad.net/bugs/1168152
<trijntje> pign cjwatson: will there be another translations export of ubiquity-debconf before the 13.04 release?
<chrisccoulson> apachelogger, http://bazaar.launchpad.net/~mozillateam/firefox/firefox-trunk.head/revision/1668
<RAOF> Hm. How do we get out-of-date packaging branches dealt with, again?
<apachelogger> chrisccoulson: ah sweet
<seb128> RAOF, open a bug against UDD?
<seb128> RAOF, https://bugs.launchpad.net/udd
<RAOF> seb128: Ta
<seb128> yw
<trijntje> cjwatson: the reason I ask is that the dutch team recently (yesterday) fixed some very visible errors in the installer, and we would like to see those fixes show up in 13.04 if possible
<cjwatson> trijntje: import, you mean?  we usually do one between now and release, yes
<cjwatson> oh, well, export from LP's point of view, import from ours :)
<mpt> ev, any progress with the weighting recalculation?
<ev> mpt: good timing (for certain definitions)
<ev> the test of it just timed out while repopulating
<ev> it did 12.9 million reports over the weekend out of some 45 million
<ev> but since we were calculating a new denominator at the same time, I should be able to generate a test graph with the data we have
<mpt> What period, do you know?
<ev> period?
<ev> reports are not stored by date
<mpt> So, scattered across the whole time since tracking began?
<ev> (technical: cassandra arranges row keys based on a selected partitioner. We use the random partitioner, since the order-preserving partitioner brings serious performance concerns with it)
<ev> mpt: correct
<mpt> nice
<ev> if you come over here I can tell you more
<mpt> My curiosity is assuaged for now :-)
<ev> :D
<stgraber> robert_ancell: hey, I took a quick look at lightdm in the raring upload queue and was wondering why we need those changes in raring.
<Laney> rejecting libcolumbus (commented on the mp)
<seb128> stgraber, you would prefer raring to stay on an unstable lightdm version?
<seb128> Laney, :-(
<Laney> seb128: it wasn't for raring
<stgraber> seb128: no but there's no indication in the changelog that the current version is unstable
<stgraber> seb128: it just says that the new one is a bugfix release even though one of the so called bugfixes is actually a new feature
<seb128> stgraber, it's 1.5.n (odd numbering = dev serie, a la GNOME)
<Laney> huh, thought this was -release
<seb128> Laney, k, I though it would be the fix for https://code.launchpad.net/~jpakkane/libcolumbus/lessfuzz-test/+merge/158595
<Laney> no :-)
<stgraber> seb128: ok. I'll let it through then. I don't think I agree with upstream's definition of "bugfix" but well, it's not causing any actual change in behaviour for the user.
<seb128> stgraber, is that because of the vnc option?
<stgraber> robert_ancell: It'd be great if in the future you could put something in the changelog when moving from an unstable to a stable release. Here all I saw was 1.5.3 => 1.6.0 both of which were referred to as "New upstream bugfix release".
<seb128> stgraber, but I guess you could try arguing with robert_ancell over it
<stgraber> seb128: yeah, the Qt change looks like a bugfix
<stgraber> seb128: I usually see adding config options (including change to the default/example conffile) as a feature change
<stgraber> anyway, accepting
<seb128> yeah, I agree this one is a bit borderline
<seb128> thanks
<robert_ancell> stgraber, ok, I'll note that the releases are switching from unstable to stable in the future
<cjwatson> BenC: your new linux-ppc has belatedly landed
<mitya57> pitti: I've assigned you to bug 1162931, but I'm happy to work on it myself if you say where I should look
<ubottu> bug 1162931 in Ubuntu Translations "Calculator app UI is not translated" [Medium,Triaged] https://launchpad.net/bugs/1162931
<mitya57> (looks like there is some list of packages that needs to be updated)
<seb128> mitya57, dpm just approved the new templates last week
<seb128> not sure if they made it to langpacks yet
<mitya57> seb128: thanks, I'll mark it as fix committed then
<mitya57> (the current langpacks were built earlier)
<seb128> check that those have the translation or maybe check with dpm
<dpm> mitya57, I approved the gnome-calculator last week after I noticed the name had changed. That one and others where that rename happened should appear in the next full language pack
<dpm> seb128, ^
<seb128> dpm, hey, when is the next "full" planned?
<mitya57> dpm: did you approve new GNOME games?
<dpm> mitya57, I remember approving gnome-mahjongg and gnome-mines. Was there any other one?
<dpm> seb128, we haven't got any one planned, but the LP export is next Wednesday, so it might be worth making that one a full lp
<seb128> dpm, well, hard freeze for raring is this week, so that would be good
<mitya57> dpm: gnome-chess gnome-nibbles iagno quadrapassel gnome-tetravex gnome-robots gnome-klotski five-or-more
<dpm> mitya57, thanks. Have all these been uploaded?
<seb128> some of those are in universe
<mitya57> dpm: yes, but $(whatSeb128Says)
<dpm> mitya57, seb128, looking at gnome-chess, it seems no translation template has been uploaded: https://translations.launchpad.net/ubuntu/raring/+source/gnome-chess/+imports
<seb128_> dpm, it's in universe
<dpm> same for gnome-nibbles
<dpm> ok
<mitya57> dpm: looks like everything I named is in universe :)
<dpm> mitya57, ok, so it seems we're all sorted
<dpm> thanks
<seb128_> dpm, mitya57: thanks
<mitya57> dpm: while you are here: do you have any plans to look at bug 861455 / bug 886968 / bug 886971 / bug 1134393?
<ubottu> bug 861455 in Ubuntu App Developer site "Fix Qt documentation links" [Low,Triaged] https://launchpad.net/bugs/861455
<ubottu> bug 886968 in Ubuntu App Developer site "Very old Qt tutorial" [Undecided,New] https://launchpad.net/bugs/886968
<ubottu> bug 886971 in Ubuntu App Developer site "Qt Creator tutorial is not the most recent one" [Undecided,New] https://launchpad.net/bugs/886971
<ubottu> bug 861455 in Ubuntu App Developer site "duplicate for #1134393 Fix Qt documentation links" [Low,Triaged] https://launchpad.net/bugs/861455
<mitya57> (or is there any branch I can file a MP against?)
<dpm> mitya57, wow, that's a quite a few bugs in a row. Give me a few minutes to look at them one by one :)
<mitya57> dpm: probably some/all of these are duplicates
<celso> people, someone knows a kernel bug ? i am still getting an annoyign bug that leaves me with a black screen after the updates. i thought it was because my intel hd3000 but happens after the updates even with my  ati card.
<celso> people, someone knows a kernel bug recently that guives black screen ? i am still getting an annoyign bug that leaves me with a black screen after the updates. i thought it was because my intel hd3000 but happens after the updates even with my  ati card.
<infinity> tseliot: Hrm.
<tseliot> infinity: yes?
<infinity> tseliot: That move to xorg-driver-binary is shiny, but it doesn't mean you can drop the conflict and/or replaces on all the old ones that you have file conflicts with.
<infinity> tseliot: Otherwise, upgrades from previous releases will asplode.
<infinity> (Or, potentially will)
<tseliot> infinity: I think I removed conflicts from initial debian releases
<tseliot> infinity: the rest should be pretty useless too
<infinity> You might need to expand that sentence to tell me what it means.
<cjwatson> [also file conflicts should be expressed with breaks/replaces, not conflicts/replaces]
<tseliot> cjwatson: is it really necessary?
<infinity> A hard conflict and nothing else isn't world-ending either.  But none of the broken provides/conflicts/replaces madness, since fglrx never actually should have PROVIDED nvidia-foo, etc.
<infinity> tseliot: It's absolutely necessary to provide smooth upgrades if there are file overlaps.
<tseliot> infinity: right, and xfree86-driver-fglrx, xorg-driver-fglrx, fglrx-kernel-source, libamdxvba1, fglrx-modaliases come from very old releases
<cjwatson> tseliot: Normally, keeping the Breaks/Replaces is way cheaper for everyone than trying to figure out whether they're strictly needed.
<infinity> tseliot: Since you can't go back in time and make the precise packages provide xorg-driver-binary, you still need to deal with that.
<cjwatson> tseliot: The failure mode is pain for users and results in hard-to-decipher upgrade failures; what's the point in inviting that?
<infinity> (You can drop all of that after 14.04, though, and just use the new method)
<tseliot> infinity: right, they all conflict/replace/provide with fglrx-driver, same as in previous releases
<tseliot> cjwatson: I'm trying to understand what kind of failure a missing Breaks can cause. This wasn't the case with Nvidia, at least according to my tests
<infinity> tseliot: But fglrx and nvidia don't conflict.  Is there actually a file overlap between them?
<infinity> tseliot: Or was that conflict just poorly-expressed?
<cjwatson> tseliot: see policy for why Breaks in addition to Replaces
<infinity> tseliot: As in, precise's nvidia-* and raring's fglrx.
<cjwatson> It's a corner case that's cheap to avoid, so why not avoid it ...
<cjwatson> (Assuming this is actually a case of file overlaps)
<infinity> cjwatson: I think it's actually a conflict in this case anyway, they should never be installed together.
<tseliot> infinity: nope. It was a poor attempt at saying that one package could be replaced by the other instead of making apt complain about having to remove either of them manually
<infinity> (Or, that's what I gathered from all the hackish relationships)
<cjwatson> tseliot: If you mean why Breaks instead of Conflicts for file overlaps (in cases where there isn't a real conflict), there's an extensive discussion in the policy manual about that
<infinity> tseliot: So, what's preventing me from having precise's nvidia-foo and raring's fglrx installed together now?
<infinity> tseliot: And isn't that a Very Bad Thing to let happen, hence all those conflicts in the first place?
<tseliot> infinity: they conflict/replace/provide one another
<infinity> tseliot: But they don't, as of this upload.
<infinity> tseliot: See my point?
<tseliot> infinity: they all conflict/replace/provide xorg-driver-binary
<tseliot> cjwatson: they don't really overlap
<infinity> tseliot: Not in precise...
<infinity> tseliot: I'd just keep a conflicts line that lists all the binary drivers that shipped in precise-release and quantal-release (don't worry about updates, since you can make those provide xorg-driver-binary), and leave it be.
<tseliot> tools such as jockey or its successor, don't remove any other installed driver before installing a different graphics driver, so, if, for example, nvidia-310 is already installed, and you want to install nvidia-304, apt will complain unless they all conflict/replace/provide the same thing
<tseliot> infinity: I'm planning to update the drivers in Precise too (I forwarded the email to both of you)
<infinity> tseliot: Yes, but you can't update the ones shipped in the release pocket.
<infinity> tseliot: And while we *technically* don't "support" upgrades from the release pocket only, there's no point in making them gratuitously more difficult.
<tseliot> infinity: in Precise all the drivers can be installed at the same time without problems. Thanks to the alternatives system only one will be used
<infinity> tseliot: Erm, you mean none of those conflicts are in the precise packaging?
<tseliot> infinity: no, just in quantal and raring
<infinity> tseliot: Or, you mean that if they weren't there, they'd be coinstallable and it would sort of work? :)
<tseliot> infinity: so, they conflict only in quantal and in raring but, even without that, things wouldn't explode
<tseliot> each driver lives in its own set of directories and the files in common are handled using alternatives
<infinity> Hrm.  Kay.  Then maybe my concern is unfounded.
<infinity> (Does jockey/ubuntu-drivers-common manually twiddly alternatives?  Ew)
<infinity> s/twiddly/twiddle/
<tseliot> infinity: jockey certainly does, ubuntu-drivers-common does not
<infinity> Okay, so in the post-jockey world, you really can't install two together.
<ogra_> we really have to many  ...
<infinity> I mean, you can install them, but the one you want won't necessarily work. :P
<tseliot> infinity: nope
 * ogra_ wonders if mtp has seen the UI in a recent raring with nvidia card 
<ogra_> *mpt even
<ogra_> definitely not something my mother would get along with
<tseliot> infinity: well, it's either one driver or the other...
<infinity> Anyhow.  If they all conflict in raring, that'll work fine.  And I think you've satisfied me on the upgrade front.  Ish.
<tseliot> ogra_: I didn't really work on the UI
<infinity> This is all such a mess.
<ogra_> tseliot, yeah i wonder if thats solvable at all
<tseliot> infinity: welcome to my world ;)
<mpt> ogra_, let me guess, the description of the driver is hundreds of characters long?
<ogra_> but we definitely have to much choice there
<infinity> Why doesn't someone just write an nvidia shim driver that checks your PCI ID and dlopens the right one, and you can ship them all in one?
<infinity> That's what the ATI driver does...
<infinity> (The free one, not the binary one)
<ogra_> mpt, well, no, but you have an nvidia-1-* mvidia-2-* nvidia-1-updates nvidia-2-updates nvidia-5-experimanetal etc
<ogra_> mpt, (example numbers indeed)
<tseliot> infinity: I guess they simply want you to pick a driver version and use that. This is entirely our problem
 * mpt reads scrollback
<infinity> tseliot: Nonsense.  You can't just pick one as a distribution, since we have to support multiple cards and they keep bumping them out of support.
<mitya57> dpm: any progress?
<tseliot> cjwatson: I'm doing what "7.6.2 Replacing whole packages, forcing their removal" says, and I think it should be fine
<cjwatson> If it's a case of a true conflict and not just a file overlap, sure
<cjwatson> (I didn't check, just triggered on the "conflicts/replaces for file overlaps" notion
<cjwatson> )
<ogra_> mpt, http://img6.imageshack.us/img6/6692/screenshotfrom201303140.png thats what i mean
<tseliot> infinity: I've never said it would make sense ;)
<infinity> cjwatson: It's a real conflict, thanks to how well they don't work when installed together.  There's apparently no file overlap at all. :P
<tseliot> heh
<cjwatson> Gotcha
 * mpt wonders why it's "Using" rather than "Use"
 * infinity wonders why those lines start with the same redundant verb at all.
<ogra_> mpt, well, i dont really care about the wording, but the amount of choice (and actually understanding what they mean) seems awful
<ogra_> my mom would definitely not get along with it
<mpt> infinity, good question ... Because normally there's only two or three of them, and repeating the verb is less waste than having a whole extra "Use:" intro line
<cjwatson> And with that amount of choice they badly need to be sorted
<ogra_> there wqere three of them in the far past :)
<ogra_> thats long gone i think
<mpt> infinity, AIUI in code this is called "inlining" :-)
<infinity> mpt: This is a funrolled loop, clearly.
<mpt> But when it gets to six, it starts looking silly
<infinity> mpt: Gentoo dialog.
<ogra_> (what the heck is VDPAU ?!?)
<mpt> This reminds me of when we used to show kernels going back years in Grub
<mpt> Now we have just "Ubuntu" and "Ubuntu (other options)", or something like that, right?
<infinity> Yeah.
<infinity> 1) Free, 2) Proprietary and tested, ** divider ** 3..inf) other crap?
<infinity> Assuming that one I slotted in (2) isn't a case that exists twice, which it might for some PCI IDs.
<infinity> But I guess then you just pick the highest version one. :/
<infinity> In conclusion: Eff you, nvidia.
<ogra_> which might or might nort work on your card depending on how the nvdidia dev slept last night
<ogra_> otr only have half baked support for exactly that card etc
<infinity> I miss the good old days when their drivers supported everything from the TNT to the latest and shiniest GeForces.
<ogra_> yeah
<mpt> infinity, after five years, today I finally understand that the "funroll loops" in <http://funroll-loops.info/> is an actual thing. Thank you.
<infinity> Though, I can sympathize with their urge to drop compatibility code for shader emulation and other madness.
<infinity> mpt: It's a compiler switch. :)
<ogra_> you could still ship different binaries in one tarball
<infinity> mpt: -funroll-loops does what you'd expect.
<mpt> All this time, I thought it was dried fruit leather.
<infinity> Hah.
<mpt> ogra_, so I can tell you that fewer choices would probably be better, but I am clueless as to which choices to hide or de-emphasize
<ogra_> mpt, heh, yeah
<mpt> More consistently structured titles would be nice, too
<infinity> Well, in that screen shot, the only two I would expect people to select are the first one, and the free driver.
<infinity> "Regular" users, that is.
<mpt> Also, it's not shown in the mockup, but in <https://wiki.ubuntu.com/SoftwareAndUpdatesSettings#drivers> I suggest that the branch should start by labelling the hardware we're talking about, in this case "Graphics card:"
<mpt> (e.g. "Graphics card: NVIDIA G86 (GeForce 8500 GT)")
<ogra_> infinity, how about steam users ? :)
<infinity> ogra_: If we screw it up really badly, they'll end up replacing our dialog with their own. :P
<infinity> ogra_: (Steam on Windows has builtin driver updaters for nvidia and ATI)
<ogra_> haha
<ogra_> so we should just not change it and wait for the contribution then :)
<cyphermox> mpt: I think initially the "Graphics card: " prefix was there
<cyphermox> not sure why it's not, now
<mpt> cyphermox, could you find out? :-)
<cyphermox> mpt: sure. should just be a matter of digging through the branch history
<mpt> ta
<doko> jibel, thanks for the autopkg updates. had some of those done. did you see any other test failures?
<victorp> mdz, ping
<smb> infinity, I got two Xen packages in the sru queues for q and p which I would like to see getting accepted for proposed rather sooner that later. Would you be able to work some "magic"?
<infinity> smb: Tomorrow, I can.
<smb> infinity, Ok, that would be soon enough for me
<ev> mpt: so much for that theory: http://jsfiddle.net/Ra4xT/4/ (see "Precise (again)")
<ev> it might be a lack of data, but I think I should look for the problem elsewhere before I commit webops to a full run
<mpt> ev, are any of those "(original)" lines actually plotted?
<ev> if you click on them they are
<mpt> aha
<ev> all the items in the key can be toggled
<ev> unchecking raring makes things much more readable ;)
<mpt> ev, is October 11 the date of the first Raring reports?
<mpt> (or at least, the first ones included in this sample)
<ev> yeah
<jibel> doko, not with 2.7 but there are 4 failures with 3.3 and 3.3dm http://paste.ubuntu.com/5710791/
<ev> mpt: perhaps it would be interesting to see what this looks like with the weighted data we have, but unweighted
<ev> to see if it's missing data that's proving to be the problem
<ev> that is, taking the the number of instances from the weighted CF and just not weighting them
<ev> I'll do that nowish
<mpt> ev, okay, so if the formula was working, then weightedRaring(2012-10-11) = 1/90 * Raring(2012-10-11) = 1/90 * 0.81 = 0.009.
<mpt> And it isn't.
<ev> I haven't adjusted raring yet for the second run
<ev> sorry, I've only done precise
<mpt> oh.
<ev> probs should've mentioned that
<mpt> ev, that would be the easiest way of telling whether the formula was working, though. Because that's the only date on which all the machines you're seeing for a particular series are brand new.
<ev> ah, I'll run through raring as well.
<ev> and check that date
<mpt> (I'm distinguishing here between "the formula working" and "the formula being correct". We know it isn't correct, but it'll be a lot closer than what we have now.:-)
<ev> :)
<ev> mpt: you do realise we're going to have to give this a fancy marketing name if it gets too far away from "average errors per calendar day"
<doko> jibel, hmm, I didn't see the test_shutil failure
<doko> jibel, is this some kind of summary? note that the failed tests are re-run at the end for details
<ev> hm, no data on systems running raring in this set until 2012-10-23, and even then only 5
<ev> perhaps I really do need to just bug webops to run the full thing.
<ev> (which would take 2-3 days)
<cjwatson> ev: raring wasn't created until about then.
<ev> oh, strange
<ev> I wonder why we have data from the 11th then
<cjwatson> ev: Any report on raring from 11 October is a misconfigured clock.
<cjwatson> Or something.
<ev> it would imply our clock
<ev> hm
<ev> I'll have to investigate that
<cjwatson> It may have been in existence a bit before the 23rd - would need to check full logs to make sure.  But definitely not the 11th, which was a week before quantal release.
<ev> mpt: http://jsfiddle.net/Ra4xT/8/ - added 'Raring (again)'
<ev> I'll get the full data set building (in production) tomorrow
<mpt> ev, no need really
<ev> hm?
<mpt> ev, November 10th was the 17th day you got reports for Raring. On that day originalRaring = 0.89, so weightedRaring would have to be 17/90 * 0.89 = 0.168 at most, and would probably be much less. But on that graph, it's 0.49.
<mpt> ev, whoops, replace "0.89" with "0.81" everywhere above, so weightedRaring would have to be 0.153 at most. The point stands.
<ev> I do worry that the early days of raring are just noise from so few people using it
<arges> slangasek: fyi. bug 1157678 seems to be fixed with a later xserver-xorg-video-intel patch, is this something that should be an FFE for raring, or should wait until the first updates? I know its _really_ late at this point.
<ubottu> bug 1157678 in xserver-xorg-video-intel (Ubuntu) "unplugging an external monitor from laptop results in corrupted screen. Logging out fixes it." [Medium,In progress] https://launchpad.net/bugs/1157678
<slangasek> arges: so the patch applies against the X driver, not against the kernel?
<slangasek> arges: have you tested cherry-picking this onto current raring?
<arges> slangasek: Yes its X driver. And yes I'm cherry-picking the fix now
<ev> mpt: so something is clearly wrong in the code then
<mpt> yep
<ev> okay, I'll have a dig at it tomorrow
<ev> thanks for the math :)
<slangasek> arges: so it's basically a two-line fix; and there's no FFe needed, this is a bugfix not a feature; if the X folks are ok with it (bryce, tjaalton, mlankhorst?), then we should just take it now
<arges> slangasek: so actually its 9dae6f9f1f169c228929185a8bd94e82afe92574 that fixes the issue (according to Chris Wilson) and that's a pretty large patch. I'm going to test that cherry-picked into the current raring versuion
<slangasek> arges: ah, ok
<slangasek> yeah, much bigger change
<slangasek> most of it's code reorg though
 * bryce looks
<bryce> there's some code refactoring there that may be making the patch bigger than it actually is
<arges> bryce: it not a completely clean cherry-pick, but it applies only after a one line move in src/sna/kgem.h
<bryce> mm
<infinity> arges: Oh, hey, I just ran into that bug this weekend.  Yay for it having a fix.
<infinity> arges: Anyhow, if you're fixing that, you might also need to fix the driver to not FTBFS. :P
<infinity> (Or back out the valgrind changes)
<arges> infinity: : ) yup upstream really helped.
<bryce> so essentially it's a) changing from calling sna_mode_has_pending_events() once to "until no events remain" in sna_mode_close(), and b) adding event checking (and a cache cleaning) to sna_mode_resize().
<arges> infinity:  yea looking at that too cause i was going to test the xorg edgers package.
<bryce> infinity, what broke exactly?  :-/
<bryce> infinity, does removing the added --enable-valgrind in rules fix it?  It built fine for me locally.
<arges> bryce: https://launchpad.net/~xorg-edgers/+archive/ppa/+build/4488414 do we need enable-valgrind?
<infinity> bryce: Dunno, looks like it's just missing a -I/usr/include/valgrind or something.
<arges> its listed as a dependency
<infinity> bryce: I didn't look hard at it, was going to fix tomorrow if no one beat me to it.
<bryce> infinity, I'll take care of it.
<arges> bryce: so i'm building a test xserver-xorg-video-intel with that cherry-picked patch. How do you guys track patches in this package btw?
<bryce> arges, in git
<arges> oooo wheres the git tree?
<bryce> https://wiki.ubuntu.com/X/GitUsage
<bryce> arges, ^ everything you'd like to know and more
<arges> cool i'll provide a patch that if that makes sense
<arges> bryce: also i have to fix the valgrind.h to backport this patch anyway
<bryce> great
<bryce> arges, I was just going to revert the --enable-valgrind
<arges> ok either way, just have to use something to get it to build : )
<bryce> (it just slipped it because it was hanging around in the unreleased debian experimental branch)
<infinity> bryce: With the current patches applied (which you could revert to the version in the release pocket, I guess), you'll need an explicit --disable-valgrind, since enable is the new default.
<bryce> infinity, hmm!
<bryce> yep looks like you're right.
<bryce> ok in that case, arges go ahead with your fix, that's probably the least invasive solution.
<infinity> bryce: Well, that's how I read configure.ac ... But I'm now confused because none of that changed between ubuntu1 and ubuntu2
<arges> ok its building
<infinity> Anyhow, --disable-valgrind is probably less hassle than working up a proper fix for not finding the headers.
<bryce> my concern is mainly stability - this is a new feature and if there is one bug somewhere however minor, experience says there's bound to be another...
<infinity> bryce: Yeah, but the debdiff between -release and -proposed has no code changes.
<infinity> bryce: So changing code now seems like probably not the way forward.
<bryce> infinity, you mean because there's nothing aside from the --enable-valgrind in the rules?
<infinity> bryce: Yeah...
<bryce> well, I'm fine with reverting just that change if that's the cleanest solution, but I'd like to see what arges comes up with first.
<infinity> bryce: So, I suspect I misread configure and it defaults to off, since it's clearly not enabled in the previous build.
<infinity> bryce: Disabling valgrind is certainly the more tested solution, since we've never successfully built with it enabled.
<infinity> bryce: And final freeze is in a few days.
<bryce>               AS_HELP_STRING([--enable-valgrind],
<bryce>                              [Enables valgrindified ioctls for debugging [default=no]]),
<bryce> sounds like, default=no
<arges> bryce: well i just built it with --disable-valgrind, but i'm just trying to test teh cherry-pick for now
<jibel> doko, it was a grep FAIL in the logs, here with the traceback http://paste.ubuntu.com/5710948/ , I'll have a look tomorrow morning to eliminate any error that could be introduced by the testing env.
<infinity> Yeah, I misread something later in configure.ac ... It was a late night.
<bryce> arges, aha alright.
<doko> jibel, thanks! delaying uploads then
<infinity> (Not that it's a bad idea to use enable/disable explicitly anyway, so upstream changes don't cause surprises)
<arges> bryce: but i haven't put anything in git, so I can change it accordingly
<bryce> infinity, ok good point about final freeze.
<bryce> I'll go ahead and revert it.
<arges> ok test build here http://people.canonical.com/~arges/lp1157678.1/ I'll work on the git patch now, since it seems to work for me.
<arges> bryce: is this the tree i need to clone btw: git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video-intel
<slangasek> arges: yep
<arges> cool
<bryce> arges, yes and use the 'ubuntu' branch
<bryce> alright, uploading the --enable-valgrind revert.
<jtaylor> doko: numpy merge I mentioned last week, bug 1168652
<ubottu> bug 1168652 in python-numpy (Ubuntu) "merge python-numpy 1.7.1-1 from debian experimental" [Undecided,New] https://launchpad.net/bugs/1168652
<mlankhorst> bryce: boo valgrind is good :(
<bryce> mlankhorst, totally agreed.  But since this is sort of new functionality, I'm thinking we probably should have done an FFe on it anyway, with some docco for how to use it, what it does, etc.
<bryce> mlankhorst, if you think it's worth having it in raring, and the build breakage is simple to fix, you might write up an FFe for it and we can try again.
<mlankhorst> meh it was meant to be enabled way early
<mlankhorst> however due to a bug it never was
<mlankhorst> valgrind has been a build-depend on intel for ages
<mlankhorst> and on uxa it already works (through libdrm)
<bryce> mlankhorst, so I take it this makes it run during package build?  how's it detect if there's a problem - does it block the build from completing?
<mlankhorst> valgrind just adds a bunch of special assembly ops that does nothing if valgrind is not running :)
<mlankhorst> see /usr/include/valgrind/valgrind.h
<mlankhorst> it does a 2 rolls for a total of 64, causing edi to be the same as it was before, then does a xchgl, with %eax set to the op
<mlankhorst> so all you have is a bunch of fancy nops if valgrind is not enabled :)
<arges> bryce: ok patch posted here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1157678/comments/56
<ubottu> Launchpad bug 1157678 in xserver-xorg-video-intel (Ubuntu) "unplugging an external monitor from laptop results in corrupted screen. Logging out fixes it." [Medium,In progress]
<arges> after using the correct branch the cherry-pick was easy save a small conflict. this patch matches what I've already tested and have installed on my laptop
<sepisoad> ow to capture input devices events/intrrupts?
<bryce> arges, ok
<mlankhorst> bryce: anyway i dont think enabling valgrind is worth the paperwork for a ffe, I'll enable it in s
<mlankhorst> and lts-raring I suppose :P
<bryce> mlankhorst, sounds good
<bryce> mlankhorst, guessing it's already on in xorg-edgers?
<mlankhorst> dno, it's mostly nops if valgrind is not found at runtime, so if it builds it works
<mlankhorst> that nexus 7 touch corruption bug is annoying btw, xserver adds so much obfuscation through the keyboard/mouse emulation layer
<bryce> mlankhorst, referring to 1002788?
<bryce> mlankhorst, anyway yeah can't tell whether we need to pull the patch in that bug, or if it is indeed just the nautilus bug mentioned in the last comment.
<stgraber> pitti, cjwatson: ping (TB meeting in 4min)
<pitti> stgraber: hello
<mlankhorst> bryce: hm actually i should bisect the series tomorrow just in case I can find what is causing the corruption that way, maybe I'll get more lucky this time
<mlankhorst> with the other things fixed
<bryce> mlankhorst, alright.  want to take the bug for now then?
<mlankhorst> https://bugs.freedesktop.org/show_bug.cgi?id=56578 btw
<ubottu> Freedesktop bug 56578 in Server/Input/Core "race condition with active/passive grabs when opening menus with touch" [Normal,Assigned]
<cjwatson> stgraber: ack
<stgraber> cjwatson: meeting notes (as short as they are) are in ubuntu-devel-announce's queue
<cjwatson> stgraber: processed
<mwhudson> RAOF: huh
<mwhudson> RAOF: so i just had another gpu hang (not restarted yet) and font rendering in ff has gone _very_ funky
<mwhudson> http://people.canonical.com/~mwh/funky_rendering.png
<mwhudson> anyway, i think i will now restart...
<sarnold> that'd be cool effect if you wanted it..
#ubuntu-devel 2013-04-16
<bkerensa> Needs Sponsor Love: https://code.launchpad.net/~bkerensa/ubuntu/raring/ubuntu-docs/13.04/+merge/159058
<ScottK> kirkland: Looks like you last testdrive upload lost a debian/changelog entry.  Please reupload - http://launchpadlibrarian.net/137515417/testdrive_3.17-0ubuntu3_3.18-0ubuntu1.diff.gz
<ScottK> or two
<pitti> Good morning
<dholbach> good morning
<jibel> doko_, test_shutil only fails when run under adt-run. The 3 others (code_module and subprocess tests ) fail even when run directly.
<jibel> doko_, TestWhich.test_non_matching_mode fails because adt-run executes it as root and the file is always writable.
<jibel> doko_, Possible solutions could be to search for a file with execute bit set instead of writable, or set the file immutable or skip the test if executed as root.
<pitti> or not running the tests as root perhaps?
<pitti> it currently specifies "Restrictions: needs-root"
<smartboyhw> kirkland, ping
<smartboyhw> roaksoax, ^
<xnox> smartboyhw: what's up?
<seb128> http://package-import.ubuntu.com/status/accountsservice.html
<seb128> is there a way to ask for a retry for udd imports?
<smartboyhw> xnox, about Testdrive:)
<xnox> seb128: I supposedly have access to trigger that =)
<seb128> xnox, can you try? ;-)
<xnox> seb128: well, it will not work.... as "$ pull-debian-source accountsservice 0.6.21-4" fails as well. That upload is clearly bogus =)
<xnox> as dpkg-source cannot unpack that upload.
<seb128> xnox, it's not really buggy
<seb128> it has a sources and a sources.ubuntu
<seb128> that works fine with quilt
<seb128> but not with dpkg source v3
<seb128> xnox, or, yes, that upload is buggy on Ubuntu in some way, the debian maintainer didn't make the ubuntu patches to apply
<doko> pitti, but then, how would I turn off apport without running as root?
<seb128> xnox, it would unpack fine on debian
<pitti> doko: ah right, for that
<pitti> doko: the test could run "su -c 'python ...' nobody" if that helps for that permission test?
<xnox> seb128: arghhhh..... DEB_VENDOR and ./debian/patches/ubuntu.series strikes again...... sigh.
<seb128> xnox, right...
<xnox> seb128: I don't know what is the correct way to solve this. I notice something similar with another package long time ago and proposed to unpack lp:debian/package with DEB_VENDOR=Debian, but that means rewritting history.
<doko> pitti: yes, but another patch requires writeable locations ...
<seb128> xnox, ok, don't bother, I didn't realize we needed to un pack the debian source to have the ubuntu vcs
<xnox> seb128: bug 911496
<ubottu> bug 911496 in Ubuntu Distributed Development "Needs to set DEB_VENDOR when unpacking source packages" [Undecided,Confirmed] https://launchpad.net/bugs/911496
<xnox> seb128: yeah, udd tries to do complete history with proper recollection that ubuntu packages are usually have lp:debian/package as ancestor.
<pitti> jibel: would you know why in "run-adt-test -sl" "modprobe mac80211_hwsim" works fine, but it fails with run-adt-test -s network-manager"?
<cjwatson> xnox: merge-o-matic takes care to unpack Ubuntu packages with DEB_VENDOR=ubuntu and Debian packages with DEB_VENDOR=debian - udd probably needs to do the same.  And yeah, it'd be a history rewrite
<pitti> jibel: that module is in linux-..-extra, but I don't see that being treated in any special way in the scripts
<xnox> cjwatson: thanks for pointer where to steal code for UDD =)
<cjwatson> Only if you're very lucky :)
<cjwatson> Ah, heh, I pointed that out to James according to that bug
 * cjwatson reads Max's comment.  Messy :-(
<pitti> jibel: unping, pebcak
<xnox> cjwatson: and well, MoM simply gives a tarball on errors, here the "ubuntu" series patches were not refreshed and hence it would fail to unpack....
<jibel> pitti, ack : )
<xnox> (when unpacked the second time for the ubuntu branch)
<xnox> seb128: my recommendation is to start ~ubuntu-desktop-team or ~ubuntu-core-devs branch where bzr import-dsc is used or such like on packages that are known to work.
<cjwatson> xnox: Actually in the case at hand it crashed MoM
<cjwatson> xnox: So I cared a little more than that :)
<xnox> ouch.
<xnox> =)))))
<cjwatson> MoM fails if dpkg-source exits non-zero
<xnox> hmm... true that is sensible.
<xnox> cjwatson: should it fallback to unpacking ./debian/patches/series at all?
<cjwatson> xnox: MoM or UDD?
<xnox> cjwatson: either/both?
<cjwatson> MoM's current behaviour is fine I think
 * xnox really dislikes split personality source package, where it may or may not unpack depending on which $derivative one is using and whether the patches for refreshed or not.
<cjwatson> I certainly don't think MoM should be peering at debian/patches/series* by hand (except in the generate-dpatches bit)
<cjwatson> yes, I'm not a fan either.  I think it's normally more sensible, if you really need conditional behaviour, to have patches that make the behaviour be built conditional on a configure flag or environment variable or similar
<xnox> doko: http://paste.ubuntu.com/5712837/ is python2.7's sysconfig a bit confused, or am I not passing correct optional args to it? It's reporting that everything is in /usr/local/*
<cjwatson> doko: any chance you could look at the polyorb build failure at some point?  It sort of looks like -lgnarl isn't being added, which I *think* is meant to be done automatically by something in the gnatmake/gnatlink chain
<cjwatson> But I don't know Ada at all, really
<doko> xnox, see the FIXME in sysconfig._get_default_scheme ...
<doko> cjwatson, heh, you did learn haskell too =)
<doko> I'll look
<cjwatson> doko: one exotic language per month, is my rule ;-)
<cjwatson> thanks
<doko> xnox, $ python -c "import sysconfig; print(sysconfig.get_paths(scheme='deb_system'))"
<xnox> doko: ack, thanks.
<xnox> cjwatson: is MQL4 on your list of exotic language to learn?
<cjwatson> no
<cjwatson> not least because I've never heard of it :)
<doko> jibel, did you see these? http://paste.ubuntu.com/5712858/
<xnox> cjwatson: it's to automatically script algorithmic forex trading. windows/wine only.
<cjwatson> xnox: yeah, not exactly in my interest zone :)
<jibel> doko, yes and this too http://paste.ubuntu.com/5712878/
<pitti> cjwatson: I have some larger autopkgtest additions/changes for network-manager; I guess they are still ok at this time of the freeze?
<pitti> i. e. debian/tests/* is not regarded as "features", as they don't impact the installed system
<cjwatson> pitti: yes, should be fine
<doko> jibel, http://bugs.python.org/issue17750 should now have all the depending issues
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<doko> barry, ahh, you did find the installed testsuite issues ;)
<barry> doko: no, but i just wanted to follow it.  i see other test suite failures building from the hg branches on 13.04
<barry> doko: have you run the default or 3.3 branch test suite from hg source recently?
<doko> barry, yes. well, this is 3.3.1, won't update anymore before the release
<barry> doko: the ubuntu buildbots are red for 3.3 and 3.4 unfortunately.
<doko> barry, well they are offline ...
<barry> doko: i doubt they'd be green if they were online :)
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<tseliot> pitti: do you still have the python script to reproduce bug #804662 ?
<ubottu> bug 804662 in nvidia-common (Ubuntu Precise) "jockey-gtk crashed with TypeError in _execute_child(): execv() arg 2 must contain only strings" [High,Triaged] https://launchpad.net/bugs/804662
<pitti> tseliot: no, sorry; should have attached it
<tseliot> pitti: too bad. I'll try to figure it out from the bug report
<pitti> tseliot: I guess it just called a few functions from NvidiaDetector and printed its results
<tseliot> pitti: yes, I can see that the script printed something about an NvidiaDetector.alternatives.Alternatives object, the question is why this proved that the library is passing the wrong arguments
<gQuigs> is recommending 64 bit (on website) only going to change for a LTS release?
<smartboyhw> gQuigs, what do you mean?
<gQuigs> guess I'm wondering if this [1] has been revisited for Raring
<gQuigs> [1] https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035054.html
<gQuigs> 64 bit desktop by default
<smartboyhw> gQuigs, well I think it would be changing for everybody...
<gQuigs> everybody means both 12.04 and Raring?
<cjwatson> Fairly sure we're not changing that quite yet
<cjwatson> Though it still needs to happen at some point
<cjwatson> It's not necessarily tied to the LTS cycle, though, no
<gQuigs> thanks cjwatson
<gQuigs> do we know what is currently blocking it?
<ogra_> a TB decision i would guess
<ogra_> (or was there one ?)
<cjwatson> Er, no
<cjwatson> IIRC last we checked the resource consumption of 64-bit systems wasn't favourable
<xnox> gQuigs: cjwatson: the website team is thinking to add a label to the 64-bit to say "(recommended for newer machines)" or something along the lines.
<xnox> but to still keep 32-bit as the default option for raring.
<gQuigs> xnox: right partly due to EUFI I'm guessing
<gQuigs> the big reason it didn't go forward with 12.04 (from Ubuntu-devel) was because a significant number of people submit to ubuntu friendly with 32 bit only machines, with EUFI that might start going the other way
<xnox> having 64-bit UEFI-only machines & significantly more than 4GB by default, even on budget machines will help to towards making 64-bit image by default.
<bdmurray> mpt: now that update-manager tells you to reboot after installing updates do you think that update-notifier still should?  (It doesn't it most cases because the update-notifier tray is hidden.)
<gQuigs> I guess what I'm really asking is how can I push 64 bit along :)   I can redo the power/memory tests to see what kind of impact it has...  or will it just come about when UEFI machines outnumber 32 bit only machines?
<jdstrand> slangasek: hi! it seems that atd is no longer on the server cd. my interpretation of the list was that we still wanted it. was this intentional?
<jdstrand> Daviey: ^
<mpt> bdmurray, no, I don't think it ever should have. The first paragraph of <https://wiki.ubuntu.com/SoftwareUpdates#alert> goes into a bit more detail. :-)
<jdstrand> Daviey: and hi to you too :)
<slangasek> jdstrand: hmm, not intentional on my part; looking
<slangasek> jdstrand: I did put 'at' in the server-ship seed, which I thought was correct
<slangasek> jdstrand: perhaps it was meant to be in 'server' rather than 'server-ship'
<jdstrand> slangasek: hmm, it doesn't end up installed though
<jdstrand> slangasek: you did that some time ago, right? my server install is from 20130410
<bdmurray> mpt: great, thanks!
<cjwatson> If you want it installed by default on server it'd need to be in the server seed
<jdstrand> s/install/iso/
<jdstrand> ah
<psusi> ubiquity is not supposed to let you install grub to the usb flash drive you are booting from right?  even if it is detected as sda?
<xnox> psusi: not supposed to, but it currently does for me when trying to install '/' on a fakeraid device.
<xnox> psusi: bug 1167366
<ubottu> bug 1167366 in grub-installer (Ubuntu) "Precise/Raring does not detect proper device (/dev/mapper/isw_<something>_Volume0p1) during preseed install" [High,Confirmed] https://launchpad.net/bugs/1167366
<psusi> xnox: that's where it wants to install to an individual disk instead of the raid array isn't it?  I'm talking /dev/sda happens to come up as the usb flash drive you are installing from, and /dev/sdb is the hd
<xnox> psusi: well, I'm booting installer off usb-disk /dev/sda and grub-installer puts the bootloader on to /dev/sda instead of the target device. So my situation is closer to yours, apart from instead of /dev/sdb it's /dev/dm-0.
<xnox> psusi: "everything works fine" when booting in UEFI mode though. Try that, if possible on the target machines.
<psusi> ahh
<psusi> not happening to me, just triaged a bug report of install failure that looked to be caused by trying to install grub to the flash drive instead of the hd because they were detected in the reverse order
<psusi> and I thought ubiquity supposedly handled that
<xnox> psusi: it does handle it mostly correct, but not always.
<gQuigs> (my last question, repeated from above):  will 64 bit by default just come about when UEFI machines outnumber 32 bit only machines?  or should I redo power/memory tests to see if it has less impact now?
<smartboyhw> !patience | gQuigs
<ubottu> gQuigs: Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com/ or http://ubuntuforums.org/ or http://askubuntu.com/
<cjwatson> slangasek might have the most context on this ^-
<cjwatson> or cking
<stokachu> bdmurray: do i need to set verified-done and remove -done-{precise,quantal} from bug 1013798
<ubottu> bug 1013798 in libgcrypt11 (Ubuntu Oneiric) "Blink SIP client segfaults with libgcrypt11 1.5.0-3ubuntu0.1" [Critical,In progress] https://launchpad.net/bugs/1013798
<stokachu> now that both series are verified
<bdmurray> stokachu: if you look at the pending SRU report you'll see that the bug is green so no it doesn't look like it
<stokachu> bdmurray: ok cool
<stokachu> thanks
<doko> jibel, python3.3 now waiting for approval
<jibel> doko, good. there'll be another issue with autopkgtest and python3.3dm because it outputs ref counts to stderr
<doko> jibel, honestly this seems to be a bad assumption in autopkgtest
<smb> infinity, Has tomorrow still a chance to be today or will it be today's tomorrow? 3:)
<kirkland> smartboyhw: howdy
<kirkland> smartboyhw: here now, what's up?
<infinity> smb: That was a convoluted sentence, but I think today is tomorrow.
<ev> mpt: all the difference an order of magnitude makes. I think I found the bug. http://paste.ubuntu.com/5713799/
<ev> going to do some more testing though
<ev> mpt: false alarm
<xnox> jibel: we could add a "stderr-no-fail" constraint.....
<slangasek> jdstrand: yes, I adjusted the server seed at the same time that I adjusted the base seed; sorry, my point was that I think I put it in the *wrong* seed and that it should have been in server, not server-ship - I think you'll find it's still on the server *CD*, but not installed by default.
<Daviey> aaaaa
<jdstrand> slangasek: right, I gathered that after I read your and colin's comments. are you adjusting the seed or shall I?
<slangasek> gQuigs: there shouldn't be any need to rerun the power/memory tests as there's unlikely to be much change there; it now mostly comes down to the numbers of users that are going to find each of the two options incompatible with their hardware.  With the UEFI question now, 64-bit will certainly figure more prominently on the website
<gQuigs> slangasek: thanks...  are the current numbers public?
<slangasek> gQuigs: hmm, I don't think so; I've had to ask various people with access to run queries to get information about the range of user systems we've seen in the wild
<jdstrand> slangasek: ok, r2131 does it, so cool. thanks :)
<slangasek> gQuigs: I mean, "the numbers" they came up with were posted to the discussion on ubuntu-devel last time we looked, which was a year ago; but sourcing new numbers requires access to data sources
<slangasek> jdstrand: ok, great
<slangasek> jdstrand: so you're the one user of at, eh? :)
<infinity> I use it...
<slangasek> weirdos
<infinity> It's handy.
<jdstrand> hoestly, I haven't used it for years, but that doesn't mean that other server admins don't :)
<infinity> Depends on how far out my needs are.
<infinity> If I want to do something in an hour, I just sleep 3600 and keep a session open, but if I want to do something sometime tomorrow, at makes more sense.
<jdstrand> yeah
<mcantor> Is there a channel devoted to developing *ON* Ubuntu?
<jdstrand> imo, a server is a place where you expect to have certain things like at
<gQuigs> slangasek: right, but that wouldn't have many UEFI hits and I was also curious if those numbers included derivatives (lubuntu/xubuntu likely would want to keep 32 bit more prominent for longer)
<infinity> mcantor: The topic claims #ubuntu-app-devel
<gQuigs> guess I should just ping ubuntu friendly?
<mcantor> infinity: Haha, thanks; I saw "Devel of Ubuntu (not support or app devel)" and stopped reading... <.<
<infinity> gQuigs: lubuntu/xubuntu aren't derivatives, they're flavours (which matters in this case, since we're probably talking about archive and/or whoopsie statistics)
<slangasek> gQuigs: well, we were only considering the question for www.ubuntu.com, not for flavors; and while it's true there wouldn't have been many UEFI hits yet at that point, it at least gives info on the ratio of 64-bit to 32-bit-only machines
<infinity> gQuigs: Actual derivatives (like Mint, for instance) wouldn't be counted in any stats we keep.
<mcantor> Hmm. You guys might be able to help me out here anyway.
<mcantor> When I link my application with -m32 and run gcc with -v, I see that /usr/lib/x86_64-gnu-linux is still the first directory in the LIBRARY_PATH. Am I doing something wrong?
<gQuigs> infinity: right, sorry I misspoke (typed..)
<slangasek> mcantor: what exactly is the gcc command you're running?
<infinity> It's a bit of a chicken and egg, of course.  The longer we promote i386 as the default image, the higher our i386 stats on package downloads and whoopsie reports will be.
<gQuigs> slangasek: but wouldn't Ubuntu Friendly have included information from lubuntu/xubuntu ?
<infinity> Not that they'll go up, but you know what I mean.  They could go drastically down if that wasn't the default ISO. :P
<slangasek> gQuigs: yes, but it wouldn't call it out separately
<infinity> If this is purely about actual hardware stats (cpuinfo, etc), ignore me.
<slangasek> infinity: no, the stats we're looking at for this is whether the machines *support* 64-bit.
<infinity> But we have a lot less of those.
<infinity> slangasek: Right, see above.
<mcantor> slangasek: /usr/bin/c++ [my object files] -m32 `/opt/pym32/python-config --ldflags` -lboost_system -lboost_python -llog4cplus -lfreetype -o executable
<slangasek> mcantor: and where are you seeing /usr/lib/x86_64-gnu-linux?
<mcantor> slangasek: It complains that it cannot find the symbol 'dlopen@@GLIBC_2.1', but tells me that it is defined in DSO /usr/lib/i386-gnu-linux, and I should add it to my compiler command line
<mcantor> slangasek: when I add /usr/lib/i386-gnu-linux/libdl.so to the command line, it works fine. I see /usr/lib/x86_64-gnu-linux when I add "-v" to the prior command line
<mcantor> slangasek: it's the first directory in LIBRARY_PATH, which seems wrong to me, and I have a hunch that it's why the linker is complaining... perhaps it's finding the 64-bit libdl.so first.
<infinity> mcantor: But your command line is lacking '-ldl'
<mcantor> infinity: Sorry--"-ldl" is in the output of `/opt/pym32/bin/python-config --ldflags`.
<mcantor> infinity: the full output of that command is '-L/opt/pym32/lib/python2.7/config -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic'.
<jtaylor> is that after the object files? libraries before them are dropped due to ubuntus use of ld --as-needed
<jtaylor> also if you get that message you should not rely on getting ldl form python-config
<infinity> jtaylor: According to his paste, it is.
<jtaylor> as you need it directly
<mcantor> jtaylor: Pasting the output of python-config directly into my Makefile has the same results
<mcantor> jtaylor: I don't see why it would be different, to be honest--Make tends to complete a subshell and insert its output just to avoid that kind of weirdness.
<mcantor> jtaylor: It is after the object files, though.
<jtaylor> hm it might need to be after boost
<jtaylor> I recall some weirdness with boost_system
<jtaylor> try adding a -ldl after the -lboost_system
<mcantor> jtaylor: I've heard furtive whisperings and conspiracies that the linker is very sensitive to the order of link flags... I'll give that a shot
<jtaylor> it is
<mcantor> jtaylor: No dice
<slangasek> mcantor: and you have the g++-multilib package installed?
<mcantor> jtaylor: infinity: Here's the exact error I'm getting: http://pastebin.com/ZgBj4fUi
<mcantor> slangasek: Indeed.
<jtaylor> oh static libpython
<mcantor> slangasek: Should I specifically *NOT* have ia32-libs installed?
<jtaylor> then --ldflags output is wrong
<jtaylor> the -ldl must be behind the -lpython2.7
<mcantor> jtaylor: You're kidding--python-config itself is giving me bad output?
<jtaylor> seems so
<mcantor> jtaylor: I'll try it, but fwiw, adding /usr/lib/i386-gnu-linux/libdl.so to the *END* of the command line worked before
<jtaylor> that should work, but the linker works in mysterious ways
<mcantor> jtaylor: wait a tick... -ldl is already before -lpython2.7
<jtaylor> behind lpython2.7
<jtaylor> worst case add -Wl,--add-nedded
<jtaylor> that will shut this warning up
<mlankhorst> isn't it -Wl,-as-needed?
<mcantor> jtaylor: By "behind" do you mean "after"?
<slangasek> yes
<jtaylor> this warning is ld --no-copy-dt-needed (or --no-add-needed)
<slangasek> -ldl needs to be listed after libpython2.7 on the commandline; you shouldn't have to specify it as /usr/lib/i386-gnu-linux/libdl.so, -ldl should Just Work
<jtaylor> -lpython2.7 -ldl
<mcantor> trying that now
<mcantor> Perhaps I should file a bug with Python since it is providing a bad command line
<GunnarHj> slangasek: Sorry to be a pain, but you didn't change your mind about the Skype thing, did you? Suppose it's not directly related to the ISO builds, but I think sooner is better than later. ;-)
<mcantor> I'll be damned. It worked.
<jtaylor> its only bad with static python
<jtaylor> if libpython is shared it works in wrong order too
<jtaylor> but yes file a bug please
<slangasek> if libpython is shared, the -ldl is unnecessary and redundant on Linux
<mcantor> jtaylor: slangasek: why is the order significant? (I recognize that this is likely a Tip of the Iceberg question, but if you can direct me to further reading other than man gcc, I'd be delighted)
<jtaylor> if you don't need it directly yourself
<jtaylor> its a side effect of ld --as-needed
<jtaylor> it sees libdl, nothing needs it, it forgets about it
<mlankhorst> it matters mostly for static libs
<jtaylor> then it seens libpython, its needed and now you are screwed
<jtaylor> libpython.a
<mcantor> ahhhh, ok
<slangasek> GunnarHj: haven't changed my mind, but I did decide I want to do a local test to see if I can get a better backtrace proving the problem is with QtWebkit, not skype
<jtaylor> its a ubuntu/mandriva specific problem
<jtaylor> other distributions don't enable as-needed by default
<GunnarHj> slangasek: Ok, thanks for letting me know.
<mcantor> jtaylor: I see, thanks so much for the explanation and help!
<cjwatson> and opensuse
<jtaylor> really? I think I haven't seen it on 12.1
<cjwatson> well, so said http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries anyway
<jtaylor> on the other hand my makefiles are all well behaved ;)
<mcantor> jtaylor: so why does this behavior screw up with a static library? can ld "not see" the required symbols?
<jtaylor> ld goes through them from left to right, it can't go back to elements it has already checked
<jtaylor> (unless you tell it to with -start-group)
<mlankhorst> even that screws up, though
<mcantor> jtaylor: wouldn't it have the same problem if python was a dynamic library, though?
<mcantor> at the time it saw -ldl, it would still think "Nope, I have nothing that needs this"
<jtaylor> that somehow works different, don't ask me why :)
<mcantor> hahaha, ok, that's what I was specifically wondering about. XD
<jtaylor> I never udnerstood why order on the commandline matters
<mlankhorst> because computers are dumb
<jtaylor> but I'm sure there are good reasons
<jtaylor> makes it slow on old Z3 machines or so :)
<mcantor> hahahaha
<mcantor> great reasons, of course
<slangasek> mcantor: with a shared library, there's nothing that needs relinking against libdl; you don't need to tell ld about a library that libpython is already linked against
<mcantor> slangasek: Ah, that makes sense. It just goes and finds it at runtime like usual.
<cjwatson> the order-insensitive behaviour of --no-as-needed also causes objects to end up with extra linkage that they don't need, because the linker doesn't go through at the end and trim out the ones that turned out not to be used
<cjwatson> --as-needed is more efficient at runtime and makes library transitions less complex in cases of indirect linkage
<cjwatson> (--no-copy-dt-needed-entries also contributes to this)
<jtaylor> its clear the flag is good, but why does it make it order dependent instead of just adding a cleaning phase when it checked everything?
<jtaylor> I could guess memory issues?
<cjwatson> well, order-dependent is the traditional Unix behaviour, and indeed there are cases where linker memory use is a serious problem
<cjwatson> I'm not certain that a cleaning phase could be implemented correctly, but I'm also not a linker expert :)
<mcantor> I filed a bug with python here btw, for any interested http://bugs.python.org/issue17769
<mcantor> cjwatson: The order-dependence does make more sense given slangasek's point. It's apples and oranges when it comes to being concerned with symbol usage.
<cjwatson> Well, sure
<cjwatson> I agree python-config --ldflags looks backwards
<jtaylor> it also shouldn'T be ldflags :/
<mcantor> jtaylor: Why not..?
<jtaylor> then people put it into autotools LDFLAGS and you have the same problem for your own object files
<mcantor> ah, I don't know autotools
<jtaylor> autotools LDFLAGS is placed before your object files, so it forgets all the libraries listed in them
<cjwatson> FWIW, all traditional Unix linkers have the behaviour where later entries on the link line supply symbols used by earlier entries.  It's just that some linkers are more permissive and people have incorrectly got used to that behaviour.
<jtaylor> the right variable is LIBS
<mcantor> jtaylor: python-config has a --libs flag, too, but the output is different
<cjwatson> I believe the NT linker is the other way round, and AIX is similar.
<cjwatson> (As in, AIX is the other way round too.)
<mcantor> cjwatson: that makes sense.
<cjwatson> jtaylor: It's not just autotools; make's implicit rules treat LDFLAGS and LDLIBS separately in much the same way
<mcantor> I didn't know LDLIBS was another automatic variable used by Make
<cjwatson> (CC) $(LDFLAGS) N.o $(LOADLIBES) $(LDLIBS)
<cjwatson> with a $ at the start too
<jtaylor> also LDADD and LIBADD, for libtool based autotools ._.
<mcantor> What is LOADLIBS?
<cjwatson> LDADD is automake
<cjwatson> mcantor: thread starting https://lists.gnu.org/archive/html/help-make/2005-01/msg00062.html
<mcantor> thanks
<cjwatson> (LOADLIBES is not a typo, or at least if it is it's not mine ...)
<mcantor> Oh. Hahaha
<cjwatson> (tl;dr: ignore it and just use LDLIBS)
<zyga-phone> Hew: thnx
<zyga-phone> DziÄki
<zyga-phone> Grr
<cseder> Wow! What a user count for a developers group!
<cseder> Active community for sure.
<cseder> Guess I should introduce myselfâ¦ I work as a full-time developer, but I've used Linux for about ten years, and Ubuntu since its first release. So now I thought I should maybe contribute something back.
<cjwatson> cseder: welcome :-)  https://wiki.ubuntu.com/ContributeToUbuntu if you haven't seen it
<cseder> So I'll be doing some development on my spare time...
<cseder> I guess I'll just SVN the source tree?
<cseder> Or maybe just read the Wiki firstâ¦ ;-)
<cjwatson> There isn't a single source tree
<cseder> the source tree for my parts of interest was what I meant.
<cjwatson> Ah, yeah
<cjwatson> If you already have an idea what you want to work on, then sure
<cseder> Well, I've done a bit of this and that, so I'll just check out what's needed and pick from that
<cseder> Mainly C, C++ and C#, but a tiny bit of Python also
<cseder> Most administrative scripts in Python, so I won't do that in the first round...
<cseder> Hahaâ¦ Now my Ubuntu installer just crashed. Maybe start there! ;-) kidding
<cseder> Apport!
 * infinity is still trying to find someone to talk into porting apport from Python to C/C++.
<cseder> Probably a good idea
<cseder> I'm not very fond of using python for main programming tasks. It's ok as a glue.
<cseder> But I guess Ubuntu uses a lot of Pythonâ¦
<cjwatson> You can find lots of almost any language you care to name, really
<doko> jibel, so for printing the reference counts in the debug interpreter. so why specify a filter in the control file, which filters these out to clear your stderr log file?
<cjwatson> Most low-level system code is C or C++; a considerable amount of glue code is Python (especially that written specifically for Ubuntu) or Perl; GUI code is C/GObject, Vala, C++/Qt, etc.
<cseder> cjwatson: guess it depends on the variations of Ubuntu as wellâ¦ kUbuntu xUbuntu and the ilkes
<cseder> That's what I'll miss from FreeBSD. One distribution. But then again there are other things I won't miss...
<cjwatson> It's still all one archive
<cjwatson> At a technical level, Kubuntu and Xubuntu are essentially just different sets of packages (and associated images) within the Ubuntu archive
<cseder> aha.
#ubuntu-devel 2013-04-17
<mwhudson> RAOF: i'm still getting those hangs with mesa 9.0.2 :(
<RAOF> mwhudson: Boo. You've got two options here, then. One: move further back in Mesa history. Two: try an older kernel.
 * mwhudson stares at https://launchpad.net/ubuntu/+source/mesa/+publishinghistory
<mwhudson> RAOF: i don't see from that when 9.0.2 hit quantal(-updates)
<mwhudson> although i do notice that 9.0.3 hit just _after_ I started seeing the problems
<mwhudson> bah
<mwhudson> RAOF: i don't see from that when 9.0.2 hit quantal(-updates)
<mwhudson> although i do notice that 9.0.3 hit just _after_ I started seeing the problems
<mwhudson> (that == https://launchpad.net/ubuntu/+source/mesa/+publishinghistory)
<RAOF> mwhudson: Just after? ie: it's unlikely to be the culprit?
<mwhudson> yeah
<RAOF> That firms the kernel as being a suspect.
<mwhudson> i don't understand the kernel's publishing history on lp at all :)
<mwhudson> mwhudson@narsil:failover-scripts$ uname -r
<mwhudson> 3.5.0-27-generic
<mwhudson> mwhudson@narsil:failover-scripts$ dpkg -l | grep linux-image-generic
<mwhudson> ii  linux-image-generic                       3.5.0.27.43                                amd64        Generic Linux kernel image
<mwhudson> that version doesn't appear on https://launchpad.net/ubuntu/quantal/+source/linux at all
<StevenK> linux 3.5.0-27.46 shows in updates on that page
<StevenK> mwhudson: It probably came from proposed a while ago?
<Sarvatt> mwhudson: do you have a sandybridge GPU? hd2000 or hd3000
<mwhudson> Sarvatt: sandybridge, yes
<Sarvatt> there's been a regression in the last few kernel updates, bug 1140716
<ubottu> bug 1140716 in linux-lts-quantal (Ubuntu Precise) "[regression] 3.5.0-26-generic and 3.2.0-39-generic GPU hangs on Sandybridge" [Critical,Confirmed] https://launchpad.net/bugs/1140716
<Sarvatt> you want either 3.5.0-25 or 3.5.0-28
<mwhudson> oh yes, that looks like it
<mwhudson> thanks
<mwhudson> is 3.5.0-28 in proposed?
<Sarvatt> yeah
<Sarvatt> the fix in -28 may not actually fix it for you, instead of reverting the broken stable update they tried to backport fixes and some people are saying they are still broken when reverting the commit worked
<Sarvatt> but it'd be good to mention that in the bug if it doesn't, -28 should be better
<mwhudson> ok
<mwhudson> sudo apt-get install linux-image/quantal-proposed ?
<mwhudson> assuming the "usual" pinning
<mwhudson> ah, linux-image-generic i think
<Sarvatt> not sure if pinning the metapackage works instead of the actual package, sorry
<Sarvatt> it should :)
<mwhudson> the latter certainly is doing more than the former
<mwhudson> hee, i certainly have a lot of kernels installed currently
 * mwhudson restarts
<george_e> I'm writing Debian packaging for an application and need to apply some Debian-specific patches. The problem is that the patches should only be applied to specific series (Quantal and Raring but not Precise).
<george_e> I've got quilt patches properly set up in the patches/ directory.
<george_e> ...but I need only _certain_ patches to be applied on Precise.
<george_e> Is this possible?\
<geofft> Is this for the Ubuntu archive, for a PPA, for a local archive...?
<geofft> If it's for the Ubuntu archive, having a different source package go into precise-backports is totally normal
<geofft> It's convenient when a package doesn't need to be modified to be backported, but it's by no means required.
<george_e> geofft: It's for a PPA.
<george_e> Actually, it's for a recipe.
<george_e> So it would be nice if I could use the same Debian packaging for each series.
<george_e> In my specific case, the "node" executable in Precise was renamed to "nodejs" in Quantal - hence my package doesn't need to be patched on Precise (since it references the "node" executable) but needs to be patched on Quantal and Raring (which do not have the "node" executable).
<RAOF> george_e: You can't have the same binary package version with different content, which means you'll at the very least need to change the changelog
<george_e> Yes but this is for different series.
<george_e> ...or does that not matter?
<mwhudson> Sarvatt: so far so good with the kernel from -proposed...
<Sarvatt> mwhudson: good to hear
<Sarvatt> x-x-v-intel from -proposed made it stop reporting bugs also if you upgraded to that..
<mwhudson> nope
<Sarvatt> it'll just silently do gpu hangs until it freezes
<Sarvatt> ah good so that fix worked
<mwhudson> yeah, i think so
<mwhudson> i wasn't getting the hangs all that frequently so i'll give it about 24h before commenting
<Sarvatt> good to hear, thanks for the heads up
<Sarvatt> some people upgraded x-x-v-intel from proposed and said it fixed it but it really just stopped reporting crashes by removing the apport hook
<mwhudson> heh
<mwhudson> would you still get stuff in /var/crash without the hook?
<Sarvatt> still crashing all the time in the background
<Sarvatt> nope but you'd see it in dmesg
<mwhudson> ah right
<mwhudson> Apr 17 13:01:47 narsil kernel: [14665.887564] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
<RAOF> george_e: Yeah, it doesn't matter.
<mwhudson> (that's before my restart )
<RAOF> george_e: The contents of a given binary package version have to be unique across all series.
<Sarvatt> yeah if the proposed kernel didnt work you'd see that in dmesg
<Sarvatt> and it'd eventually just hang completely after a bunch of those :)
<RAOF> george_e: For a quick reason why - think what happens on a preciseâquantal upgrade: it won't upgrade the package because you've already got the same version installed, but you won't have the quantal package. Which is a problem :)
<george_e> Ah, okay. That makes sense.
<george_e> Thanks for the explanation. Perhaps what I really need is some sort of "meta-package" that provides a "node" => "nodejs" symlink for Precise.
<george_e> I know that Quantal and Raring include a package "nodejs-legacy" that does the opposite.
<RAOF> Yeah, that might be the ticket.
<george_e> Which one?
<george_e> Using "nodejs-legacy"?
<RAOF> The general approach - a package which does nothing but provide the expected symlink.
<george_e> Okay.
<george_e> RAOF: What would be an appropriate name for the package that provides the "nodejs" => "node" symlink?
<RAOF> node-unlegacy? :)
<george_e> :)
<pitti> Good morning
<siretart> morning
<siretart> pitti: you're up early :-)
<pitti> hey siretart
<siretart> robru: do you happen to be still awake?
<robru> siretart, yes! not even 10PM here ;-)
<siretart> robru: :-)
<siretart> robru: thanks for contacting me and your interest in ~ubuntu-elisp, I've just made you admin in that team
<robru> siretart, ah, thank you!
<robru> siretart, I'm actually just working on the packaging right now... enabling a certain distropatch so that the snapshot will have support for the existing emacsen-common package.
<siretart> robru: please do take care for our daily recipe and restore that team PPA to sanity. It is currently really in a desperate state
<siretart> robru: I've been busy lately myself, but now that I've handed in my disseration this week, I think I should be able to catch up with foss stuff really soon.
<robru> siretart, do you know if there are a lot of users who are subscribed to this PPA? (ie, people who potentially haven't yet noticed how long it's been since the last update)
<siretart> robru: I have to admit that I totally lost track of that team, so no idea ATM
<robru> siretart, ok, no worries. I'm hoping to shake things up a bit, so there might be some growing pain during the transition.
<siretart> go ahead :-)
<robru> siretart, but so far I've had a few people testing my existing packaging and the response has been positive.
<robru> siretart, great ;-)
<stokachu> could i get a patch pilot to review nominations for bug 1169740?
<ubottu> bug 1169740 in rsyslog (Ubuntu) "rsyslog hangs loading modules" [Undecided,Confirmed] https://launchpad.net/bugs/1169740
<dholbach> good morning
<smb> infinity, Likely too convoluted. Hm, seems tomorrow was not the day before yesterday's tomorrow. At least lp tells me the xen packages are still in the unapproved queue for p and q.
<diwic> TheMuso, pitti, I'm looking at bug 1167192, and I wonder, is the xdg_runtime_directory deleted at some point?
<ubottu> bug 1167192 in pulseaudio (Ubuntu) "A second pulseaudio daemon is spawned after logging out and back in even though one is already running for the user." [Undecided,Confirmed] https://launchpad.net/bugs/1167192
<diwic> TheMuso, yep, it's deleted on logout, and PulseAudio only quits ~30 seconds after idle
<diwic> TheMuso, so if you then login immediately again, PulseAudio can't find that it's already running, because the file used for that purpose has been deleted
<seb128> diwic, not sure if that's revelant there, but the dmesg log has "[   58.622779] systemd-logind[2257]: New seat seat0."
<seb128> diwic, logind and libpam-xdg-support are likely to behave differently
<diwic> seb128, I'm reading the xdg spec now. It seems like we're doing the right thing by deleting the directory.
<diwic> seb128, i e it's PulseAudio that needs fixing
<seb128> ok
<seb128> that makes sense to clean behind
<pitti> diwic: it gets deleted once that user closes her last session, yes
<diwic> pitti, I think the correct course of action would be to monitor the relevant file/directory and quit Pulseaudio if deleted. Would that make sense to you too?
<pitti> diwic: usually such daemons listen to the D-BUS "lost connection" signal and quit themselves
<pitti> diwic: i. e. when the user's session dbus goes away, everything hanging off it should quit itself, too
<pitti> diwic: in raring+1 we'll also switch to logind, and we could discuss whether quitting a session should also kill all of its processes
<pitti> (but that might not be desirable, i. e. screen sessions started in the sessions should stay)
<diwic> pitti, is there a session dbus on VT sessions too?
<pitti> diwic: ah no, not usually
<pitti> diwic: but there is a CK (or logind) session, so listening to that signal should also work
<pitti> diwic: monitoring $XDG_RUNTIME_DIR sounds okay as well, but it might not always be present
<pitti> but then, if it isn't, just don't do it I guess
<diwic> pitti, what would be the use case for not setting xdg_runtime_dir?
<pitti> diwic: older distributions mostly
<pitti> diwic: but for current ubuntu it really should be there
<pitti> OTP, bbl
<cjwatson> stokachu: done
<infinity> smb: Look again.
<smb> infinity, Amazingly, gone. :-P
<doko> jibel, pitti: I assume https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/ doesn't show a build of the recent upload yet?
<pitti> doko: no, last build from 16.04.2013 22:40:30
<pitti> it's also not running in the "real" jenkins yet, hmm
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<jibel> doko, https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/3/ is the test for python3.3 3.3.1-1ubuntu3
<jibel> I didn't push the modification for fsync yet.
<jibel> that's the 2 tests that fail for python3.3 and for python3.3dm this is the output to stderr we talked yesterday
<pitti> jibel: do you know why the new python3.3 upload didn't trigger a new test run? is that because of the machine which went out over night?
<jibel> pitti, it did, the last upload of python3.3 is 3.3.1-1ubuntu3 published to -proposed 11hours ago and the version tested in run #3 of python3.3
<pitti> jibel: oh right, I just saw the "4 hours ago", but that was raring migration; sorry
<henrix> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix, Laney
<OdyX> tkamppeter: cups + cups-browsed and printer queues that don't disappear, does that ring a bell?
<infinity> doko: Why did you upload python-default/precise with a bizarre dpkg-genchanges -v invocation that included the whole changelog in .changes? :)
<infinity> doko: (I'd poke more fun, but I did exactly the same thing with something last year...)
<infinity> doko: Anyhow, want to reupload that to avoid sending a 13k email to precise-changes?
<tkamppeter> OdyX, what exactly happened?
<OdyX> tkamppeter: I'm moving between offices, without shutting down. Now I see printers for offices I left 10 days ago.
<doko> infinity, I have to look at this anyway, so for now only the python3 stuff seems to be ready
<infinity> doko: I'm going to reject that just because of the giant .changes file.  The rest of the upload was fine, so go ahead and bounce it back whenever.
<tkamppeter> OdyX, seems that cups-browsed needs to get a removal signal from Avahi to remove a queue while running. Workaround is restarting cups-browsed.
<tkamppeter> OdyX, probably cups-browsed needs to detect somehow when the network environment changes, to mark all queues unconfirmed them and if Avahi does not report their presence, they go away after some secs. But how can cups-browsed detect the change of the network environment?
<OdyX> tkamppeter: indeed, cups-browsed restart does the trick.
<OdyX> tkamppeter: don't know; doesn't avahi have such triggers ?
<tkamppeter> OdyX, the local machine reports itself as workstation in avahi-discover. This record contains the MAC address and the IP for the local network. Perhaps one has to track this avahi report and if the IP changes to unconfirm all queues.
<OdyX> that could work. I'm surprised you haven't gotten such a report yet though.
<tkamppeter> OdyX, seems that most people shut down their boxes when they move between environments, or they have only something like 2 environments with few print queues and so the extra queues are no problem for them.
<OdyX> well, it's not a problem per se, it's just noise.
<tkamppeter> OdyX, another thing: cups-browsed is only included in Raring, Ubuntu's development branch, and there we get a new kernel twice a week, so who reboots after every kernel update will probably not have the problem.
<OdyX> ah yeah, good point.
<OdyX> tkamppeter: good you have me then :)
<Laney> Can someone reject https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/clamav/quantal-security/+merge/156911 ?
<pitti> Laney: done
<Laney> danke!
<jibel> doko, I re-ran autopkgtest for python3.3 with the fsync fix, the tests that failed previously pass now but there is this failure that I haven't seen before http://paste.ubuntu.com/5715517/
<doko> jibel, no, never did see this one
<doko> jibel, and it doesn't fail on the buildd either: https://launchpadlibrarian.net/137578622/buildlog_ubuntu-raring-amd64.python3.3_3.3.1-1ubuntu3_UPLOADING.txt.gz
<mlankhorst> do we have someone to look at https://bugs.launchpad.net/ubuntu/+source/xorg-lts-quantal/+bug/1134492 ?
<ubottu> Launchpad bug 1134492 in apt (Ubuntu) "xserver-xorg-lts-quantal breaks Kubuntu" [High,New]
<jibel> doko, the refs count to stderr comes from running script.py with python3.3dm. If you use python3 instead of python3.3dm in testsuite-dbg to execute script.py the testsuite pass in autopkgtest.
<jibel> doko, also I cannot reproduce the uuid failure, could it be due to a lack of entropy on the test system?
<doko> jibel, but the whole point of the exercise is to use the dbg interpreter ...
<jibel> doko, to execute the testsuite not script.py
<doko> jibel, entropy, maybe try it on a virtulized buildd too? if that matches your autopkgtest setup better
<jibel> doko, okay, I'll try that. re ref counts that'll give a command like : python3 /tmp/tmp.pASFAYfBf4/ubtree0-ubtree/debian/script.py "/dev/null" "python3.3dm  ...
<jibel> which is fine since it still use the dbg interpreter to run the testsuite.
<doko> ok, but I better use python3.3
<Laney> pitti: Could you do https://code.launchpad.net/~fcole90/ubuntu/precise/python-reportlab/fix-for-1005187/+merge/158774 too? :-)
<pitti> Laney: where "do" == ?
<Laney> reject
<Laney> or Merged, or whatever
<Laney> I merged it, but not into the target branch there
<pitti> Laney: ah, set to merged then
<xnox> Laney: pitti: http://youtu.be/8vJthZst5tQ "down with whatever" =)))))
<Laney> what is this hideous row?
<Laney> </middle aged>
<pitti> xnox: what's that? I can't watch that in Germany
<ogra_> pitti, well, talk to gema :P
<xnox> pitti: kelly rowland singing "I'm down with whatever" w.r.t. to merge request status.
<Laney> I'm Kelly Rowland and I approve of this MP.
<ogra_> haha
<tkamppeter> mlankhorst, I am trying to offer my patched xorg-server to the people which suffer the touch-click bug via PPA but it seems that when building it in the PPA xorg-server falls into an infinite loop in the test suite. See https://launchpad.net/~till-kamppeter/+archive/ppa/+build/4499041
<mlankhorst> tkamppeter: just retry
<mlankhorst> it happens randomly
<tkamppeter> mlankhorst, strange is also that i386 and amd64 are bult by an "arm ppa builder" and there is no armhf built at all.
<cjwatson> That's normal
<mlankhorst> virtual armhf builder right?
<cjwatson> The builder is ARM-capable (via qemu), but can build any of i386/amd64/armhf
<mlankhorst> tkamppeter: just retry, that failure is not an infinite loop, it just does nothing
<mlankhorst> presumably some race
<cjwatson> And PPAs only get armhf on explicit request
<tkamppeter> mlankhorst, I have canceled and rescheduled the builds now.
<tkamppeter> cjwatson, so it is a fast Intel processor and not a slow ARM?
<cjwatson> Yes
<cjwatson> A Xen guest, actually
<mlankhorst> tkamppeter: anyway until the corruption gets fixed I'm not going to bother
<tkamppeter> mlankhorst, I have also successfully built my patch on the Nexus 7 and my Nexus 7 works reliably with it. Right before installing it the screen got stuck on the first click.
<tkamppeter> mlankhorst, so then let it come as SRU as soon as the corruption get fixed.
<mlankhorst> I'm running on nexus7 with valgrind and my nexus7 xserver dies on it rather soon
<Laney> freeflying: Gentle poke to remember to upload with -v when there's more than one version covered in an upload (it causes bugs to be closed, amongst other things)
<freeflying> Laney: acked, thanks
<mlankhorst> Laney: hah, I fixed my lts rename scripts to do it for me, now I can forget all about it :-D
<Laney> don't forget too much :P
<mlankhorst> forget what? ;-)
<Laney> donk
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix
<doko> Sweetshark, should libreoffice-emailmerge be demoted?
<apachelogger> pitti: are you still handling langpack creation?
<pitti> apachelogger: I twiddle the cronjobs from time to time, yes
<apachelogger> pitti: who would I talk to to get new templates into a langpack and that langpack created? (i.e. they are on launchpad but not in any langpack yet)
<pitti> apachelogger: if they were imported recently (i. e. in the last few days), they should be in the next automatic export and upload
<apachelogger> pitti: they have been imported for 2 weeks or more, so I am getting a bit anxious :)
<pitti> apachelogger: what's an example domain name?
<apachelogger> pitti: kubuntu-patched-l10n
<pitti> from which package is taht?
<apachelogger> same package
<doko> pitti, jibel: both python2.7 and python3.3 uploaded. please fix everything else in autopkgtest ;-)
<pitti> WARNING: unknown translation domain: kubuntu-patched-l10n
<apachelogger> hum, try kubuntu-firefox-installer
<apachelogger> albeit that's a bit strange... https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-patched-l10n
<pitti> apachelogger: it's due to that LP bug that it doesn't add universe packages to the domain -> package map
<pitti> bug 1048556
<ubottu> bug 1048556 in Ubuntu Translations "Language pack translations export needs to add universe packages to domain map" [High,Triaged] https://launchpad.net/bugs/1048556
<mlankhorst> mvo: hm, any thoughts on https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1134492 ? I posted what I know there, should be straightforward to reproduce with pbuilder
<ubottu> Launchpad bug 1134492 in apt (Ubuntu) "xserver-xorg-lts-quantal breaks Kubuntu" [High,New]
<pitti> apachelogger: but we stopped having kde langpacks a long time ago; should these just appear in the main packs?
<apachelogger> pitti: yeah, we only have like 5 packages which go through launchpad and each has 10 strings or so, so dpm and I agreed that simply putting them in the main packs should be good enough
<apachelogger> pitti: the affected packages are: https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-patched-l10n | https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-debug-installer | https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-web-shortcuts | https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-firefox-installer | https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-notification-helper
<pitti> apachelogger: I added manual workaround mappings for kubuntu-patched-l10n, kubuntu-firefox-installer, kubuntu-notification-helper
<pitti> ah
<stokachu> cjwatson: re: nominations, thanks :)
<pitti> apachelogger: ok, workaround table updated: http://paste.ubuntu.com/5715858/
<apachelogger> pitti: missing notificationhelper = kubuntu-notification-helper and kcm_notificationhelper = kubuntu-notification-helper
<pitti> apachelogger: added
<apachelogger> pitti: yay, thank you very much :)
<highvoltage> is it just me or are these instructions actually harmful? http://helpx.adobe.com/air/kb/install-air-2-64-bit.html#main_Install_AIR_2_on_64_bit_Ubuntu_9_04
<ogra_> highvoltage, dont worry, we wont have to support broken ubuntu 9.04 installs anymore :P
<highvoltage> :)
<highvoltage> ogra_: the worse thing is that adobe recommends that as the current way to install air on ubuntu :-/
<ogra_> well, dont install air or get support at adobe for the broken thing afterwards
<highvoltage> *nod*
<highvoltage> I just despise them a little bit more for pasting instructions that will damage user's systems
<shadeslayer> lol air
<smartboyhw> xnox, er I thought Wubi was not going out for 13.04. Why did you merge my fix?:O
<xnox> smartboyhw: what happens in the upstream wubi project does not affect what gets released or not by upstream ubuntu project.
<smartboyhw> xnox, ah:O
<Sweetshark> doko: yep, -emailmerge isnt needed in main anymore.
<wgrant> pitti: From which file are the domains you reference in bug #1048556 missing?
<ubottu> bug 1048556 in Ubuntu Translations "Language pack translations export needs to add universe packages to domain map" [High,Triaged] https://launchpad.net/bugs/1048556
<pitti> wgrant: they should be in ./rosetta-*/mapping.txt
<pitti> bbl
<wgrant> pitti: Yes, but which language pack tarball?
<pitti> wgrant: teh current raring ones
<wgrant> Ah, raring
<henrix> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<wgrant> pitti: I don't see that template in the langpack tarball at all. Are you sure the langpack inclusion flag was set at that point?
<dobey> how do i tell what requires nullmailer (or mail-transport-agent) on my system? apt-get remove --purge nullmailer just wants to install exim4 instead, to replace it
<dobey> and apt-cache rdepends isn't helpful
<wgrant> pitti: All three templates were created just a few days before the export, and I don't see any of their pofiles in the tarball.
<bdmurray> ev: its rather hard to see the functions here https://errors.ubuntu.com/?user=foundations-bugs&period=month
<ev> bdmurray: *shrugs* suggestions welcome. I think trying to show enough of the functions to make them legible is a near impossible task
<ev> bdmurray: not sure why 4.0-0ubuntu20.2+elementary5~precise1 is showing up in there, given that we're filtering out distributions
<bdmurray> ev: well I used to be able to see it when I moused over the link in Firefox now with the hash url ...
<ev> bdmurray: we could have alt text or a floating div that displayed the full thing on mouse over
<ev> bdmurray: feel free to file a bug for that
<bdmurray> ev: okay, I think that would help as its easier for me mentally to keep track of the funciton than the bug numbers (which don't always exist)
<ev> bdmurray: I very much agree
<pitti> wgrant: what is a "langpack inclusion flag"?
<jibel> doko, python3.3 autopkgtest is green https://jenkins.qa.ubuntu.com/job/raring-adt-python3.3/7/   \o/
<doko> jibel, and 2.7?
<jibel> doko, red test_tempnam failed with a permission denied probably because adt set TMPDIR to a readonly directory
<doko> jibel, so is this a adt issue?
<doko> I accidentally left the pgo and lto optimizations disabled, so I'll have to do one more upload
<wgrant> pitti: There's a flag on the +admin form for Ubuntu templates that determines whether the template will be included in langpacks.
<jibel> pitti, ^^ you fix that by executing the testsuite with env -u TMPDIR, correct ?
<pitti> apachelogger: ^ do you know about this? (wgrant's comment)
<pitti> jibel: why would $TMPDIR be readonly?
<pitti> jibel: I do that for processes which change user, i. e. run stuff as non-root
<xnox> jibel: pitti: doko: I thought one should be using $ADT_TMP which should be writtable location.....
<pitti> xnox: yes, if you don't use su
<pitti> xnox: but if you start a test as root, and then su to another user, that other user won't be able to access $ADTTMP or its $TMPDIR
<pitti> as these are still owned by root
<xnox> hmm...
<apachelogger> pitti: nope, also I don't think I have access to +admin ^^
<pitti> wgrant: hm, I thought we already had that X-Ubuntu-Langpacks: header for that; I never heard about that flag
<seb128> pitti, didn't we stop using that until bug #1048556 is fixed?
<ubottu> bug 1048556 in Ubuntu Translations "Language pack translations export needs to add universe packages to domain map" [High,Triaged] https://launchpad.net/bugs/1048556
<pitti> seb128: maybe, I don't know
<seb128> pitti, oh, you just commented on that bug
<pitti> who can access these +admin pages?
<seb128> pitti, what's the url?
<seb128> dpm can I guess
<happyaron> pitti: guess I can. U-T-C team.
<pitti> I don't know that either
<seb128> if that's a translator thing
<doko> jibel, pitti: so it looks like the control file needs another attribute to specify the user the tests are run with?
<pitti> doko: isn't the default "user" or "root" (Restrictions: needs-root) sufficient?
<xnox> doko: /me thought we specify that when launching adt tester already to match the adt testing environment. E.g. packages themself shouldn't fiddle with that.
<pitti> we probably need to take a second look at this
<xnox> doko: we can give the username currently used by our setup and/or check for it.
<doko> pitti, I need to turn off apport, the rest can be done as a normal user
<pitti> if we run the entire test suite as user, and just start out as root to disable apport, it's probably better to put the apport disabling into a test before the "main" one, and only run that one as root
<pitti> doko: ah, then we could have "Tests: disable-apport\nRestrictions: needs-root\n\nTests: testsuite" perhaps?
<dpm> pitti, seb128, wgrant, that's the regular flag we use to mark templates as exported in language packs. Anyone in the ubuntu-translations-coordinators can set it. Which packages are we talking about? I can check if the flag is set
<wgrant> dpm, pitti: The flag is set now, at least on one of the templates. But I can't tell if it was set for the last langpack export.
<seb128> dpm, does that work for universe packages?
<wgrant> (except that I read the code, and it makes no sense that the template wouldn't be there if the flag was set)
<pitti> or, if you want to keep it together, we need to unset ADTTMP/TMPFILE or chown them before the su
<pitti> jibel: ^ WDYT?
<dpm> wgrant, which package?
<dpm> sorry, which template?
<wgrant> dpm: https://translations.launchpad.net/ubuntu/raring/+source/kubuntu-firefox-installer/+pots/desktop-kubuntu-firefox-installer/+admin
 * pitti wishes we could just drop that ADTTMP/TMPFILE nonsense; it's creating nothing but trouble
<dpm> wgrant, recently it's been me only setting that flag, so if it's set now, it certainly was set before the last export
<dpm> seb128, it does, except for the issue mentioned in that bug
<wgrant> Note that the last export was on March 22
<wgrant> And that template was created on March 18
<wgrant> Or later
<jibel> pitti, I think unsetting TMPDIR before running the test is better than creating a fake test just to disable apport
<doko> pitti, so ADTTMP/TMPFILE are always set?
<doko> I don't like the faketest either
<pitti> doko: yes, and they point to a directory owned by 'ubuntu', or 'root' if Restrictions: needs-root is set
<pitti> ADTTMP certainly doesn't get in the way, but TMPFILE will
<pitti> err, TMPDIR
<doko> so chown -R $SUDO_USER should work?
<pitti> yes
<jibel> it does that's what was done for software-center IIRC
<dpm> wgrant, I think we might be talking about different things. The latest export happened yesterday: https://translations.launchpad.net/ubuntu/raring/+language-packs
<wgrant> Oh
<wgrant> I thought I saw that one crash
<wgrant> Apparently that was for another series
<dpm> wgrant, I haven't checked if that export is ok, but in any case, there was another previous export last week, which is the one we're currently using in the language pack packages
<wgrant> Yeah, that was quantal
<wgrant> Oops
<wgrant> ./mapping.txt:kubuntu-firefox-installer desktop_kubuntu-firefox-installer
<wgrant> pitti: It's in mapping.txt
<pitti> wgrant: hm, odd; did these appear very recently?
<pitti> so, it should be okay in the next build
<ev> bdmurray: I'm piecing together https://wiki.ubuntu.com/ErrorTracker/DailyTasks as a one stop shop for error tracker misbehaviour :)
<ev> for what it's worth
<wgrant> pitti: Nothing's changed here in a long time, so I don't think there's ever been a problem on our end.
<bdmurray> ev: I saw, thanks
<ev> cool
<cjwatson> jodh: I notice that the filesystem event finishes before static-network-up starts
<dpm> pitti, wgrant, I'm a bit confused by this issue. wgrant, you mean that the templates are present in the mapping.txt file of the latest full export (i.e. the one from yesterday), but pitti was mentioning on the bug report that the mapping.txt file of that export didn't list the templates?
<pitti> dpm: right, I was wrong about that
<doko> jibel, pitti : http://paste.ubuntu.com/5716277/
<dpm> pitti, ah, gotcha, that makes it clear
<pitti> doko: not sure whether we need to chang ADTTMP, but it can't hurt at least
<pitti> 10 if [ -n "$SUDO_USER" ]; then
<pitti> doko: ^ should that be $su_user ?
<doko> no, don't want to change anything when running as nobody
<pitti> ah, ok
<doko> pitti, does every test case has its own TMPDIR?
<pitti> yes
<jibel> doko, also,  "stop apport 2>dev/null || true" otherwise the test will fail if apport is not running
<cjwatson> jodh: I *think* I may see the general structure of what's going on here
<cjwatson> jodh: This debugging should make it about as clear to you as it is to me so far, I think
<cjwatson> <7>init: conf_load_path_with_override: Loading configuration file /etc/init/rc-sysinit.conf
<cjwatson> ...
<cjwatson> <7>init: conf_file_destroy: Destroyed unused job rc-sysinit
<cjwatson> <7>init: event_unblock: name: 'filesystem', new blockers: 3^
<cjwatson> jodh: When we tear down the old job, we end up unreferencing and destroying the event operators it refers to, at least enough to cause them to decrement various event->blockers
<cjwatson> jodh: So the 'filesystem' event ends up entering the finished state far too early because it's been wrongly unblocked
<tvoss> slangasek, ping
<slangasek> tvoss: otp pong
<jodh> cjwatson: gotcha - that is indeed subtle. Could be an interesting one to fix too ;)
<cjwatson> jodh: My feeling is that the nih_free in conf_file_destroy needs to be something more careful involving keeping references
<cjwatson> jodh: But that also perhaps job_class_reconsider shouldn't replace a job that has events that are blocking some other event?  I'm not quite sure, I don't know the structures quite well enough
<cjwatson> jodh: Is that enough to get you going for now though?
<jodh> cjwatson: sure is - thanks!!
<bdmurray> doko: could you have a look at bug 1084935?
<ubottu> bug 1084935 in java-common (Ubuntu) "/usr/lib/jvm/java-6-openjdk â java-1.7.0-openjdk-amd64 symlink confuses ca-certificates-java" [Undecided,Confirmed] https://launchpad.net/bugs/1084935
<infinity> BenC: New linux just landed, if you'd like to rebase -ppc.
<BenC> infinity: ok, couple hours...
<infinity> BenC: Cool.
<doko> jtaylor,
<doko> dpkg-source: info: local changes detected, the modified files are:
<doko>  python-numpy-1.7.1/doc/source/conf.py
<doko>  python-numpy-1.7.1/doc/sphinxext/tests/test_docscrape.py
<doko> dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/python-numpy_1.7.1-1ubuntu1.diff.UwGgRh
<jtaylor> doko: did you pop the patches before applying the debdiff?
<jtaylor> also barry already sponsored it
<barry> hmm. it built locally
<barry> for me
<jtaylor> it works if I pop the patches
<jtaylor> if I leave it applied and then change series quilt gets confused
<doko> ohh, if barry sponsored, fine
<nemo> say. just a minor idea
<nemo> if usb-creator-gtk is an ubuntu project. maybe you could have it check md5 sums for isos w/ standard names?
<nemo> or have it return better error messages.  took me quite a while to figure out that "[Errno 5] Input/output error" was its way of saying the ISO was bad
<nemo> (network here sucks - downloaded ISO 3 times, got 3 different checksums)
<TheMuso> diwic: Ok thanks, that makes sense.
<doko> tjaalton, ping
<nemo> Oh. One more thing
<nemo> Some people were irritated, but, 'grats to you on your new donation screen
<nemo> frankly, I liked it and tossed some cash your way.  The voting thing was fun idea.
<nemo> I guess it had just not been convenient enough or in my face enough to do it before ;)
<BenC> infinity: upload away...
<nemo> I don't care for the lil skull face after tho
<nemo> (when I went to reattempt downloads due to failed ISO due to sucky network here)
<nemo> was like.  seriously stupid page. don't you know I already gave you cash?
<infinity> BenC: Cheers.
#ubuntu-devel 2013-04-18
<cjwatson> stokachu: are you planning to get the fix for bug 1169740 into raring, as well as SRU?
<ubottu> bug 1169740 in rsyslog (Ubuntu Raring) "rsyslog hangs loading modules" [Undecided,Confirmed] https://launchpad.net/bugs/1169740
<nemo> oh. one more thing for you guys. I think this UEFI nonsense is going to be a big stumbling block
<nemo> there's no way around it anymore
<nemo> so, some clearer guides, online and in installer, on what to do, would be nice
<cjwatson> we've put a great deal of effort into UEFI already; it would be best if you could file bugs about specific things you feel are missing, rather than a general comment ...
<nemo> cjwatson: heh. was just typing something longer :)
<nemo> cjwatson: but. specifically, the installer was aware Windows 8 was there
<cjwatson> (also, distinguish plain UEFI from UEFI Secure Boot, as the issues are quite different)
<nemo> but did not warn me I was not in EFI mode
<cjwatson> hey, I'm not going to try to understand anything UEFI-related at 1am local
<nemo> only my own paranoia made me halt before blowing away existing setup
<cjwatson> that's why I suggested filing bugs :)
<nemo> also. none of the docs explain how to get to EFI boot from Windows 8 - which was what I had to do. BIOS failed horribly in this regard
<cjwatson> (I'll have forgotten this conversation by the morning ...)
<nemo> oh well
<cjwatson> these are useful comments and I heartily encourage you to file them as bugs so they don't get lost
<nemo> Oh. Also, getting this information to someone who is in Windows 8 and just plugged in USB drive or CD. 'cause booting straight off it sure didn't work.
<nemo> relative to where they are at that moment.  that's similar to (2) I guess
<nemo> And. Man, is it hard to get into the BIOS screen on one of these fast-booting UEFI setups these days :(
<cjwatson> Booting to UEFI from USB is certainly meant to work, and has in the past
<nemo> cjwatson: well. Depends on BIOS setup possibly
<cjwatson> Perhaps
<cjwatson> Lots of room for intersection of our bugs and firmware bugs
<nemo> thise was a lenovo g780
<cjwatson> No idea about the specifics of that
<nemo> when I finally got into BIOS screen there were options for boot order. I made sure USB was on top
<nemo> there was also, under UEFI, windows boot loader and some USB boot loader
<nemo> I put the USB one on top.  Unfortunately, that still sent me straight to windows.
 * cjwatson -> overdue sleep
<nemo> When I went to bios, the boot sequence was right, but windows was back on top
<nemo> setting boot to USB from the windows 8 options was the only way to get it to work
<nemo> well. actually legacy mode worked too, but that's how I got to a point in the installer that would have completely screwed everything up
<nemo> oh well. g'nite
<stokachu> cjwatson: i have debdiffs ready for precise, quantal and raring
<stokachu> cjwatson: do you want me to attach raring, quantal? i was waiting on the OP to return with his testing
<stokachu> and i see he updated
<stokachu> cjwatson: if you see this and im not here i went ahead and filled out most of the SRU, waiting on OP to send me his test case and ill submit it up
<stokachu> cjwatson: and to answer your original question (sorry its late) precise is my main concern as raring can be after release
<pitti> Good morning
<tjaalton> doko_: pong
<dholbach> good morning
<ev> apw: interestingly, we've only ever received 23 KernelOops reports with an OopsText field in them.
<ev> It doesn't include 12.04, which doesn't have the version of whoopsie that sends the OopsText field, but I wonder if we're failing to correctly process these crashes at an earlier stage.
<ev> apw: http://paste.ubuntu.com/5718063/ - you can look those up individually by going to https://errors.ubuntu.com/oops/$the_oops_id
<apw> ev, indeed they mostly look reasonable, a couple seem truncated to the left ... and 23, i have had more than 23 this cycle i would think
<ev> apw: truncated to the left?
<apw> ('d4ae7486-568d-11e2-a835-2c768aafd08c', OrderedDict([(u'OopsText', u'ence at 00000004\nIP
<ev> and yeah, I have no doubt that we're missing a lot, but I'm not sure why. The daisy.ubuntu.com frontend is very liberal in the reports it'll insert into the database.
<ev> oh interesting
<apw> i don't know of any bugs or oopses which start that way
<ev> right
<apw> in fact i think they probabally all start bug or oops
<ev> so I'm wondering if this is some corner case in apport / whoopsie. (why we have so few)
<ev> right
<apw> you should be able to trigger them i think, isn't there a sysrq for that
<apw> no it always forces a complete reboot.  we could so with a mechanism in our kernel to allow you to trigger them for testing me thinks
<StevenK> apw: I think there is a magic sysrq for it, but I can't remember what it is either.
<apw> StevenK, sadly it sets panic_on_oops before it oopses, which is a hard fatal reboot jobbie
<apw> i cannot sensibly find one to trigger them quietly
<StevenK> That isn't playing fair
<doko> tjaalton, any reason not to merge the JITEmitter.patch in llvm-3.2?
<tjaalton> doko: is it from debian?
<doko> tjaalton, yes
<tjaalton> doko: hmm can't find it on 3.2-4?
<doko> tjaalton, because it's in -5?
<tjaalton> ah
<tjaalton> packages.d.o is lagging behind..
<doko> tjaalton, or #1160587. note that Sylvestre mostly complains about stuff not being in Debian, but he's not caring much for the other way around :-/
<tjaalton> right..
<tjaalton> I guess it's fine
<tjaalton> doko: are you merging it with -5?
<tjaalton> getting the r600 updates would be nice too
<tjaalton> although we didn't get radeonsi support included in raring, glamor-egl isn't uploaded yet and I doubt it would make it in main on such short notice :/
<tjaalton> then a couple of commits to x-x-v-radeon to use these
<doko> tjaalton, well, I can apply the jitemitter patch
<tjaalton> tkamppeter: did you pull the whole touch-grab branch from whot, or just that one commit?
<tjaalton> tkamppeter: I can still crash it easily by changing between the dash icon and indicator menus
<tkamppeter> tjaalton, I only picked that one commit.
<tjaalton> ok
<tkamppeter> tjaalton, what sequence of finger clicks I have to do exactly? I clicked the dash icon (Ubuntu symbol at the upper left) and after that one of the indicator icons (Network Manager) and again the dash icon and nothing crashed for me (on the Lenovo Thinkpad Twist).
<tjaalton> tkamppeter: doing that a few times crashes it here with the branch
<tjaalton> i'll try without
<doko> tjaalton, llvm-3.2 waiting in the queue
<didrocks> diwic: I'm seeing quite some people complaining about pulseaudio taking 99% of their CPU since last update. I wonder if inotify doesn't go crazy if /run isn't there or something is tweaked. Heard about it?
<diwic> didrocks, no, not yet
<tkamppeter> tjaalton, I cannot reproduce the crash, I tried on both the Nexus 7 and the Thinkpad Twist.
<diwic> didrocks, do you have a bug or person affected that I can work with?
<seb128> diwic, seems like ricotz has it
<seb128> ricotz, ^
<didrocks> diwic: do you speak french? ;) (a lot of people on the unstable part of the french forum are complaining, so not just one isolated case)
<didrocks> diwic: I can get them opening a bug report, is there anything I should add in addition to what ubuntu-bug will bring to them?
<didrocks> if ricotz can do live debugging, that's even better
<didrocks> ricotz: diwic: FYI, people report that if they kill pulseaudio in their session, then it works fine
<tjaalton> tkamppeter: i'm building with your patch now
<didrocks> I wonder if it's a race before /run is set for the user or anothingâ¦
<diwic> didrocks, I guess attaching to the process and seeing where it's stuck would be the first thing
<didrocks> diwic: yeah, they are not *that* technical :p
<ricotz> didrocks, diwic, i killed pulseaudio several times and it constantly uses 100% of one cpu again
<didrocks> ricotz: ah, at least, it's more reliable for you, mind helping diwic? ^
<diwic> ricotz, can you attach to it with gdb?
<ricotz> didrocks, already downgraded :\, to be able to use my laptop
<tkamppeter> tjaalton, you do not need to build. For Intel I have packages on my PPA and for Nexus 7 there is the tarball attached to the bug. To try without patch, go back to the official packages.
<ricotz> diwic, i will give it a try in a moment
<tjaalton> tkamppeter: building already
<diwic> ricotz, or run sysprof on it could work too, if that easier
<ricotz> diwic, although i am running an older kernel here
<darkxst> I am not seeing the cpu issue, but why would pulseaudio be using 3GB of ram ....
<ricotz> diwic, http://paste.debian.net/plain/250235
<diwic> ricotz, all threads appear sleeping in that post
<ricotz> diwic, seems like attaching to it released the "loop"
<diwic> ricotz, oh.
<diwic> ricotz, maybe you can try sysprof instead? Have you used it?
<tjaalton> tkamppeter: it's trivial to get the grab hang with it
<tjaalton> tkamppeter: just hit the indicators with two fingers a few times
<ricotz> diwic, not yet
<tkamppeter> tjaalton, you mean, clicking two indicators at the same time?
<ogra_> stgraber, i forwarded your mail to the ubuntu phone list
<ricotz> diwic, http://people.ubuntu.com/~ricotz/pulseaudio/
<ricotz> diwic, not sure how to interpret it
<stgraber> ogra_: thanks. I guess I probably should subscribe to some of those lists...
<diwic> ricotz, hmm, what does the screenshot look like?
<ricotz> didrocks, http://people.ubuntu.com/~ricotz/pulseaudio/sysprof.png
<didrocks> I think this is for diwic ^
<ricotz> ah sorry
<diwic> ricotz, hmm, I loaded your log in my sysprof. It seems to point at e1000e_poll_eerd_eewr_done, but isn't that some kind of network related thing?
<ricotz> diwic, actually yes, does pulseaudio probe those for something
<ricotz> like discovering bluetooth adapters
<tjaalton> tkamppeter: no, but rapidly change between two or more indicators by tapping on them with two fingers
<diwic> ricotz, you haven't mounted /run/user on a network drive or something?
<ricotz> diwic, no
<ricotz> diwic, maybe you missed some prerequisite for the cherry-picked patch
<diwic> ricotz, I wrote the inotify patch yesterday myself
<ricotz> diwic, ah i see, alright
<ricotz> +-        valid_pid_file = TRUE;
<ricotz> ++        valid_pid_file = true;
<diwic> ricotz, yeah, I changed pa_bool_t to bool too
<diwic> ricotz, argh, I don't get it. Why would adding an inotify watch cause the e1000 driver to eat cpu?
<tkamppeter> tjaalton, https://blueprints.launchpad.net/ubuntu/+spec/client-1305-convertibles-and-touch-desktop
<tkamppeter> mlankhorst, bryc: ^^
<diwic> ricotz, if you do "sudo fuser -v /run/user/ricotz/pulse/pid" a few times, does anything show up?
<tkamppeter> bryce, ^^
<diwic> ricotz, (assuming your logged in user is "ricotz")
<ricotz> diwic, nothing shows up
<ricotz> diwic, /run/user/*/pulse/pid contains the correct pid
<mlankhorst> tkamppeter: we're aware of the touch problem, if it was easy to fix, or even not that hard to fix by the upstream maintainer it would already have been fixed
<diwic> ricotz, hah! I reproduced it here: If I edit the pid file manually (with gedit), PulseAudio starts taking up 100% CPU
<diwic> ricotz, probably there is some software on your machine that accesses it in some way
<mlankhorst> Anyway I have a fix for bug 1170074, it seems nobody tests on x86 these days but it would be unsurprising if x86 was completely broken for nouveau/radeon because of it. :s
<ubottu> bug 1170074 in mesa (Ubuntu) "mesa 9.1 regressed Tibia on nouveau" [High,Fix committed] https://launchpad.net/bugs/1170074
<diwic> ricotz, and that triggers the loop
<ricotz> diwic, hmm, i see, running gdm/gnome-shell here
<diwic> ricotz, anyway, if I can reproduce it here, I can hopefully come up with a fix too with some analysis
<diwic> ricotz, thanks so far!
<ricotz> diwic, yeah, touching the file triggers it too while running in gdb
<ricotz> diwic, ok, yq
<ricotz> yw
<rbasak> jodh: seen the LWN article on upstart?
<rbasak> (just FYI, in case you're interested)
<jodh> rbasak: not yet :)
<zyga> is there a way to select apt-proxy via ubiquity somehow?
<xnox> zyga: i'm considering to seed squid-deb-proxy-client package to desktop CDs....
<diwic> didrocks, ricotz, ok, I believe I have fixed it now. Since this is last minute, what precautions do you suggest I take before pressing the "upload" button?
<ricotz> diwic, i guess you can put it in a ppa and let someone test it
<diwic> ricotz, are you volunteering? :-)
<diwic> ricotz, I don't know exactly when Final Freeze is, but some time today I believe
<didrocks> diwic: is there any risk of things going worse?
<ricotz> didrocks, ^
<ricotz> diwic, just put the source package somewhere
<didrocks> diwic: I can get some people testing from a ppa if you want
<diwic> didrocks, ricotz uploaded to ppa:diwic/pulseaudio-testing
<ricotz> diwic, alright
<diwic> build starts in 2 hours
<didrocks> pitti: can we have a small bump on https://launchpad.net/~diwic/+archive/pulseaudio-testing/+build/4501878?
<didrocks> diwic: forum updated, they will install it once it's available, will keep you posted
<diwic> didrocks, thanks, I'll go for lunch in the mean time
<didrocks> diwic: enjoy, thanks! :)
<pitti> didrocks: done, it's now next in line
<didrocks> thanks pitti :)
<diwic> didrocks, as for risks for things going worse, I guess the risks are 1) PA crashing or 2) bringing back the original bug (stale PA processes after logout/login)
<didrocks> diwic: ok
<ricotz> diwic, looks good, can't reproduce it so far
<didrocks> diwic: one confirmation on the forum as well :)
<Kalidarn> not sure if this is the place, i'm currently testing raring ringtail and have had some problems getting it to boot.
<Kalidarn> while it is kubuntu (i think its actually pre to any distro stuff)
<Pici> Kalidarn: #ubuntu+1 is probably a better place if you're looking for support/
<Kalidarn> basically comes up with grub menu, and then when you select "Start Kubuntu" it says you need to load the kernel first.
<Kalidarn> yeah i think it might be a bug actually.
<Kalidarn> unfortunately the error doesn't really tell me that much, the media is fine, already checked that.
<Kalidarn> the error i get is:
<Kalidarn> error: failure reading sector 0x6d500 from `cd0'.
<Kalidarn> error: you need to load the kernel first.
<Kalidarn> i might actually try with standard ubuntu media not kubuntu to test that as well
<Kalidarn> i think it probably affects all variants
<diwic> didrocks, ricotz, ok, I'm uploading it now then
<didrocks> diwic: \o/ thanks a lot :)
<Kalidarn> Pici: would it be recommended to get the latest beta or current daily?
<didrocks> diwic: 3 people confirmed on the forum now :)
<cjwatson> you should certainly try a current daily, although I don't know how much difference it'll make
<cjwatson> "you need to load the kernel first" is a consequent error and not the real cause - you should generally look at the first error not the last
<diwic> didrocks, thanks for organising the testing!
<didrocks> yw ;)
<diwic> didrocks, uploaded, fingers crossed
<didrocks> heh ;)
<Kalidarn> yeah cjwatson i wonder why its failing to read that particular sector though :) the drive works fine and the media burnt fine hmm.
<cjwatson> evidently the boot loader is having genuine trouble with one or the other
<cjwatson> it tried asking the BIOS to read that sector three times, and it failed every time
<cjwatson> it's a fairly straight INT 13h Function 42h, and I doubt that that was the first sector it tried to read, so my money would be on a drive and/or media failure that your tests didn't pick up, with a backup option of some problem in your BIOS
<cjwatson> the error here is close enough to the firmware call that I don't think it's likely that this is our bug
<Kalidarn> cjwatson: yeah that's rather odd because ive burnt it twice (two dvds) and the drive does work as other distros have no issue
<Kalidarn> so ill try booting off a usb stick
<cjwatson> Kalidarn: well, it could be that other distros just happen to miss the problematic bit, or maybe Linux tries harder to read it than your BIOS does and the other distros have no need to read that sector with raw firmware calls
<cjwatson> Kalidarn: sadly, experiment does not actually rule out faulty drive/media
<Kalidarn> this includes previous versions of kubuntu such as quantal or ubuntu so yeah
<cjwatson> Kalidarn: sure, but it could depend on exact position of data on the disk
<Kalidarn> ill try a different type of media entirely and see if it occurs, the debian wheezy bug (pre RC1) happened the same to me on both optical and usb drive
<cjwatson> Kalidarn: drive cleaning kits are IME worth a shot as well, but yes, you probably stand a better chance with USB
<Kalidarn> yeah, i doubt the drive has anything wrong with it. but i guess ill know soon enough
<Kalidarn> it's just rather odd i only seem to be having that issue with raring ringtail
<cjwatson> the boot loader code in question hasn't changed for a year or more (I did go and read it before replying to you).  Random chance can produce odd things sometimes
<Kalidarn> i guess :) time for more experimentation! :D
<cjwatson> the boot loader code *is* Ubuntu's responsibility, but I think in this case whatever the bug actually is is out of our hands
<Kalidarn> i figured at that point it wouldn't matter what variant of buntu was being used.
<dholbach> lool, ready?
<cjwatson> Kalidarn: the boot loader code is identical, but the different flavours of Ubuntu might happen to have the kernel in a different position on the disk
<cjwatson> which in this case could make a difference
<lool> dholbach: eh was just joining #ubuntu-on-air and just moved the invite 5 mn earlier to make sure people join on time
<Kalidarn> thanks for your time cjwatson.
<dholbach> cool
<stokachu> cjwatson: hey did you see my messages from last night? (not sure if you logged off to sleep by then)
<cjwatson> Oh, I did but hadn't quite got round to them yet - I'll look shortly, thanks
<stokachu> cjwatson: ok no problem just making sure they made it to you
<cjwatson> stokachu: We're before final freeze (just), so I'd like to get the raring fix in if possible
<cjwatson> Since it ought to be there before precise
<stokachu> cjwatson: ah ok, ive got everything attaached to the bug and sru template done
<stokachu> cjwatson: so not sure if you want to just pull that raring one in before freeze
<cjwatson> Right, I see.  I will stare at it a bit
<cjwatson> mlankhorst: http://paste.ubuntu.com/5718775/ is a rather bigger diff than the changelog suggests - is that intentional?
<cjwatson> 14:37 <seb128> tjaalton, slangasek, Laney: the libgl1-mesa-dri update makes unity segfault on start in vms
<cjwatson> mlankhorst: ^- and is it likely to fix that?
<mlankhorst> are they i386 vms?
<seb128> mlankhorst, yes
<cjwatson> the one I tried was
<mlankhorst> cjwatson: it was a result of a merge back to ubuntu branch from ubuntu+1, the patches that were dropped were already no longer applied.
<mlankhorst> hm I think it might
<mlankhorst> I have it on my ppa anyway
<seb128> mlankhorst, do you have a deb handy ?
<mlankhorst> https://launchpad.net/~mlankhorst/+archive/ppa?field.series_filter=raring
<rbasak> Would it be worth sorting the rebuild failure reports in popcon order? I'm still struggling to prioritise what to look at.
<Laney> popcon doesn't get updated any more
<rbasak> :-(
<rbasak> How about Debian popcon?
<seb128> cjwatson, mlankhorst: libgl1-mesa-dri_9.1.1-0ubuntu3~ppa1_i386.deb from that ppa fixes it
<mlankhorst> good
<mlankhorst> and what I expected
<seb128> mlankhorst, still a bit annoying that this slept through, we should have at least one people running unity under a vm on i386 and amd64 before upload
<seb128> mlankhorst, thanks for the fix ;-)
<mlankhorst> seb128: it was a case of conflicting symbols specifically for i386
<seb128> mlankhorst, well, it means nobody tested on i386...
<mlankhorst> and only happened specifically on nouveau < nvc0, or llvmpipe i386
<freeflying> wonderding do we have latest kde ppa for 12.04?
<freeflying> sorry, wrong channel
<mitya57> freeflying: ppa:kubuntu-ppa/backports
<freeflying> mitya57: thanks, typed in errors here, meant to ask in kubuntu-devel :)
<Sweetsha1k> achiang: ping?
<achiang> Sweetsha1k: hey, in a hangout-on-air now, but what's up?
<slangasek> mlankhorst: so what's the plan for getting the fixed mesa uploaded?
<mlankhorst> erm it's already been uploaded before everyone was panicking about it ?
<mlankhorst> :P
<mlankhorst> so I guess poking you until you accept it
<mlankhorst> oh was already accepted 7 minutes ago
<mlankhorst> no plans, then..
<Laney> the plan is to kick back with a nice jug of sangria
<mlankhorst> mmm I think I'll go biking
<mlankhorst> while the weather is nice
<Laney> so dutch
<mlankhorst> and the storm hasn't calmed down yet
<mitya57> running ReText under qt5 makes gnome-session crash... interesting
<mitya57> s/gnome-session/Xorg/g, which is even more interesting
 * mitya57 installs Xorg dbg symbols, fastens seat bells and tries again
<bdmurray> slangasek: could you have a look at bug 1169621?
<ubottu> bug 1169621 in plymouth (Ubuntu) "encrypted LVM desktop does not boot with cirrus driver (no password prompt)" [High,New] https://launchpad.net/bugs/1169621
<xnox> bdmurray: i can test it again. there have been updates to kernel and/or qemu as e.g. background is now colorful.
<slangasek> bdmurray: that's been a problem for a couple of cycles, IIRC there was a change in the kernel that triggered this... it's not going to get fixed for r
<bdmurray> slangasek: got it, thanks
<mitya57> FWIW I've found the issue: it's bug 1005677, for which we have a patch only in Qt 4, not in Qt 5.
<ubottu> bug 1005677 in overlay-scrollbar (Ubuntu Quantal) "Re-emergence of "Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)'" Makes vlc and other Qt apps crashing crashing" [High,Fix released] https://launchpad.net/bugs/1005677
<GunnarHj> cjwatson: ping?
<cjwatson> GunnarHj: pong
<GunnarHj> cjwatson: Hi Colin. I just posted a comment on bug 1160441. I do disagree on that change.
<ubottu> bug 1160441 in ubiquity (Ubuntu Raring) "Calendar is still in English despite French is selected as the Language during the installation" [Medium,Fix committed] https://launchpad.net/bugs/1160441
<cjwatson> Sigh, "not discussed with you" != "without discussion"
<GunnarHj> cjwatson: Ok, true, but...
<cjwatson> I can't wait indefinitely for feedback about every change
<cjwatson> You haven't actually refuted my point about LC_TIME being a conflation of language-dependent and language-independent data
<cjwatson> glib and indicator-datetime notwithstanding, anything that does even just something as simple as ctime() will have day/month abbreviations from the wrong language
<cjwatson> "wrong", anyway
<GunnarHj> cjwatson: It's true, no doubt. But given that we won't change the fundamentals easily, such as splitting LC_TIME into two locale categories, we need to do our best to meet user expectations.
<cjwatson> I think day/month from "wrong" language is more likely to break those expectations than other parts of the format
<GunnarHj> cjwatson: Possibly. But the conflict typically gets visible in the calendar, and I have an idea - admittedly hackish - how to deal with that.
<cjwatson> I really profoundly disagree with the notion of hacking around locale categories in individual applications
<cjwatson> All it will do is introduce inconsistency among applications
<cjwatson> psivaa: ^- since this was your bug
<cjwatson> bdmurray: ^- and you were investigating it
<cjwatson> If I revert this for raring, I'm not sure how anything will change in future releases; we will still have the fundamental issue of a conflated locale category
<GunnarHj> cjwatson: Well, it's better IMO than doing nothing. At the same time I think that doing nothing is better than preventing the users from controlling the date and time format, which is what LC_TIME primarily is about.
<cjwatson> I'm not preventing users from doing anything!
<cjwatson> They can change the categories themselves if our guess (and it can be no better than a guess) was wrong
<GunnarHj> cjwatson: Well, currently they will do so automatically if they use language-selector to set the region. So it's inconsistent.
<cjwatson> If we start changing individual applications then we're just going to have a succession of bugs like the one psivaa reported; the system will get more complex as we add more and more and more manual workarounds
<cjwatson> This is how things get to the point where nobody understands them
<bdmurray> cjwatson: I believe the change makes sense
<cjwatson> I agree that we have an inconsistency here
<cjwatson> That's the only reason I'm considering reverting
<cjwatson> If I reverted for raring, I haven't seen any reason yet why I wouldn't put the change back in the first upload for S
<cjwatson> And I'm not at all convinced that I would consider that indicator-datetime change acceptable for raring
<GunnarHj> cjwatson: At least it would give us a possibility to consider the issue more carefully.
<cjwatson> Unfortunately we have already changed something from quantal, namely the mixed-locale improvements in ubiquity, and the handling of LC_TIME was one of them
<cjwatson> So we don't get to say "let's just leave it how it was in quantal and consider more carefully later"
<GunnarHj> cjwatson: But language-selector has considered LC_TIME a region thing for many, many cycles.
<cjwatson> And we probably only didn't notice that was a problem because relatively few people set their language through language-selector rather than setting it once in the installer and leaving it there.
<cjwatson> So it didn't come up in this kind of test.
<GunnarHj> cjwatson: Those who distinguish between language and region have typically used language-selector, I think, considering that the installer only lately has made a similar distinction.
<xnox> GunnarHj: i live in the uk, but on many machines want Russian UI, and that means my calendar should say Ð§ÐµÑÐ²ÐµÑÐ³ and not Thursday. Just because my current timezone is here, doesn't magically make me understand that language.
<cjwatson> Perhaps.  Some of them have probably set the locale categories manually ...
<GunnarHj> cjwatson: That too.
<xnox> GunnarHj: Or are you proposing that we print time in German, when the timezone is set to Berlin? even if the rest of the UI is French?!
<cjwatson> xnox: Gunnar is proposing that we do the language parts of this at the application level, I believe
<GunnarHj> https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/159214
<cjwatson> Which I think is really dangerously wrong
<cjwatson> For reasons given above
<xnox> cjwatson: I mean the ultimate incornation of this bug is how currencies are displayed by default in Libreoffice calc. Cause when a Russian UI in the UK one would want Â£ currency & Ð§ÐµÑÐ²ÐµÑÐ³ as name of the day.
<cjwatson> No, don't drag currencies into this
<cjwatson> Those are LC_MONETARY which is different
<cjwatson> I don't believe anyone disagrees that LC_MONETARY should be location-dependent
<cjwatson> And it is, with current installer and language-selector code
<xnox> ok, good.
<GunnarHj> cjwatson, xnox: Personally I think I won the debate at https://bugzilla.gnome.org/687945, but Matthias had access to the button...
<ubottu> Gnome bug 687945 in i18n "Display names of days and months using the current language" [Normal,Resolved: wontfix]
<cjwatson> GunnarHj: Exactly the same argument applies to glib as to applications - it's the wrong place, fixing this belongs at the standards / C library level
<cjwatson> Which is certainly harder, but ...
<GunnarHj> cjwatson: So the question is what's the best thing to do until the standards are changed.
<xnox> GunnarHj: the questions is did you raise it for standards to consider fixing yet?
<Kalidarn> cjwatson: works off USB ;)
<cjwatson> Kalidarn: excellent
<Kalidarn> i should try another cd drive actually.
<Kalidarn> cos i don't believe the media is bad.
<Kalidarn> i don't like problems that go away by themselves.
<Kalidarn> (especially as two seperate discs had exactly the same issue)
<Kalidarn> i wouldn't mind betting though cjwatson it's probably my dodgy BIOS
<GunnarHj> cjwatson: I have discussed the issue quite a lot the past few months. Winows and Apple are said to fix the distinction in accordance with the users' expectation, i.e. despite of the standards.
<Kalidarn> i've had nothing but trouble with this GA-X58A-UD3R
<GunnarHj> xnox: No, I haven't. Isn't that a 'mission impossible'? ;-)
<xnox> GunnarHj: i haven't pushed anything into C std library, but e.g. ubuntu community did push a few things into other standards and languages.
<cjwatson> GunnarHj: I really don't see how Windows or Apple are relevant to a discussion of POSIX standards :-)
<cjwatson> Sure, they're big OSes, but they're not exactly well-known for POSIX compliance in general
<Kalidarn> isn't OSX more posix compliant than linux?
<cjwatson> GunnarHj: If we don't try then *certainly* nothing will happen
<xnox> GunnarHj: it's a valid problem, and needs a solution that works =) standards committees are suppose to be good at resolving such things, or at least defining/clarifying the expected when mixed LC_* locales are set.
<xnox> s/expected/expected behaviour/
<GunnarHj> cjwatson: Their success is probably partly because they set user expectation before bad standards.
<cjwatson> GunnarHj: Sigh, I guess this discussion is useless if we're going there
<cjwatson> False dichotomies 'r' us
<GunnarHj> cjwatson: For now, can't you please take a step back and revert?
<cjwatson> GunnarHj: I'll revert this change in the installer for raring, but only because it has additional interactions I hadn't thought of which are now too late for 13.04.  I intend to reinstate it as soon as raring is out.
<cjwatson> Unless there is a better option, and I don't count application-level changes ...
<GunnarHj> cjwatson: Good, then I can sleep well tonight, at least. ;-)
<psivaa> cjwatson: sorry was still trying to understand the conflict and the inconsistency. i like the correct language to be displayed but if that's going to change the timezone, then i dont have a preferance :)
<cjwatson> psivaa: It's not about changing the timezone
<jtaylor> barry, doko: ubuntu python now has native access to the multiarch tuple right?
<jtaylor> where was i again?
<jtaylor> sys._multiarch is only py2 :/
<doko> jtaylor, depends on what you want to use it for
<jtaylor> to find tk/tcl
<doko> if you can, use sysconfig.get_config_var('MULTIARCH')
<jtaylor> ok seems to work, thx
<psivaa> cjwatson: ok, I think its safe for me to leave the decision to you guys then :)
<jtaylor> or is there a compat package one can use for tk/tcl build dependencies?
<cjwatson> GunnarHj: Reverted. :-(  Now I really do have to go.
<cjwatson> Oh blast, I have to wait until localechooser is approved before reuploading ubiquity.
<cjwatson> So that will probably miss final freeze now.
<nemo> Hrm. I wish ubuntu software centre offered a way for devs to get in contact w/ users who give bad reviews
<GunnarHj> cjwatson: Thanks. :)
<stgraber> cjwatson: I can review it now if you want
<nemo> I mean. I don't *care* that much, I just feel sorry for poor "John" who was having trouble starting the game which was almost certainly due to bad gfx driver
<nemo> and could probably have been fixed w/ application of jockey-gtk
<nemo> and might be having bad exp w/ other games too
<xnox> nemo: wrong channel =)
<stgraber> cjwatson: accepted (confirmed that diff from ubuntu2 to ubuntu4 is only removal of .gitignore)
<nemo> xnox: oh?
<xnox> nemo: i'm not sure where you can discuss apps published in the software center. Wait is that about a review on a package from Ubuntu OS or about an app you published in Software Center as a developer?
<nemo> Hedgewars. 2nd FOSS game in Games category :)
<nemo> xnox: but. it wasn't really about the game itself
<nemo> was more about ubuntu software centre - I wish it offered a way for me to somehow help john is all
<nemo> every time I go to the game, his review is there, and I feel bad
<xnox> nemo: hmmm...
<nemo> I know what is happening. hwengine is crashing.  which is usually due to opengl probs, thus need for another driver. well, it sometimes is 'cause people screwed w/ sound system or pulseaudio is crashing
<nemo> but john doesn't seem like the type to screw w/ sound system, and pulseaudio is better behaved these days
<nemo> if john had linked to a launchpad issue, I would have commented there :)
<nemo> but given cjwatson's complaints yesterday, I guess I shouldn't talk about filing issues :-p
<stokachu> cjwatson: that version change you made in rsyslog was that the only thing I should be aware of? i couldnt find versioning schemes for development in the wiki anywhere
<nemo> xnox: and. I can't just write another review rebutting him, since I already did that once for the guy who said we work better on windows machines :D :D
<nemo> er. s/rebutting/replying/  - my first review was a rebuttal./
<cjwatson> stokachu: Yeah
<cjwatson> stokachu: dch -i usually does the right thing for development releases
<stokachu> cjwatson: ah ok, yea it did do that but i manually altered it :X
<sabdfl>  let me know which is the best image version to demo on N4 and N10?
<sabdfl> gack
<weasel> please excuse my intrusion, but does ubuntu/canonical have porting machines that give developers various chroots to interactively debug stuff?
<roadmr> weasel: not to my knowledge :/ I may be wrong though...
<weasel> what a shame.  I wondered how they were maintained :)
<infinity> weasel: We do internally, yes.
<weasel> ISTR elmo mentioning many years ago some tool that gives otherwise unprivileged developers the means to install packages from the archive in a reasonably secure way
<weasel> but I can't find that email anywhere
<infinity> weasel: chapt-get
<infinity> Or, no.  What did I name that project?
<infinity> Bah.
 * infinity goes hunting.
<weasel> hah
<infinity> rapt.  That's it.
<infinity> Failing old brain.
<infinity> weasel: https://launchpad.net/rapt
<weasel> not packages for debian.  what a shame
<weasel> thanks
<infinity> weasel: It ain't pretty.  Just a quickie hack by mvo and I over a few days/weeks.
<infinity> weasel: But it basically does the job.
<weasel> yeah, we're mostly worried about tty/stdin interaction during the install process
<infinity> weasel: The idea is to install it as /usr/local/bin/apt-get and then provide sudo access to it.
<weasel> or at least that was one obvious attack vector
<infinity> Which is sketchy.
<infinity> But less sketchy than giving someone apt-get raw.
<infinity> Though, it might not meet your use-case.
<infinity> Our use case was "we don't want people removing packages", basically.
<infinity> Not so much about security as developers not stomping on each other.
<weasel> hmm.  might not be a perfect fit then
<weasel> not too different from the apt-in-chroot wrapper we already have for porters
<infinity> Possibly not, no.
<weasel> I'm just glancing over the code, but there's nothing stopping me from say installing a pager, apt-listchanges, and then execing a shell from the pager while apt-listchanges shows me stuff, right?
<weasel> ah.  there's a pty.fork()
<weasel> that's good
<weasel> thanks
<hallyn> infinity: bug 1170489 , does that suggest we should always have group admin in /etc/group?
<ubottu> bug 1170489 in libvirt (Ubuntu) "libvirt-bin postinst can try to add non-system group members to libvirtd group" [Undecided,New] https://launchpad.net/bugs/1170489
<stgraber> ubuntu@lxc-testing01:~$ grep admin /etc/group
<stgraber> ubuntu@lxc-testing01:~$
<stgraber> hallyn: ^ clean raring system
<hallyn> right
<stgraber> my guess is that you probably want to look at the sudo group instead
<stgraber> assuming you want the list of people who are able to become root on a standard ubuntu system
<hallyn> stgraber: the problem is the system may have been installed with lucid and upgraded
<hallyn> so libvirt postinst does both groups admin and sudo
<hallyn> (i originally switched to only sudo, but mdeslaur pointed out the problem with that)
<stgraber> hallyn: hmm, then it depends what you want to get, if you just want the local users and ignore network sources, just parse /etc/group directly. If you don't care about network group membership but want to check that the group exists locally, then use grep -q + getent group
<hallyn> was pinging infinity bc he originally did the switch from grep to getent, so he might have thought about it already and know of a reason why it's a non-issue
<hallyn> i haven't used NIS since 1998 on an iris box...
<hallyn> can't quite decide if, if you give yourself an NIS group called 'admin', how that's supposed to be handled
<stgraber> ah, actually, I thought NSS would aggregate when the group is provided by more than one backend, but it's not, it just returns the first one, so if you have the group in /etc/group + NIS, it'll just return the members listed in /etc/group
<hallyn> what if you list NIS before files?
<hallyn> course, then, again, it's what you wanted...
<stgraber> so if you want to fix what's described in this bug, you can get away with "grep -q admin /etc/group && getent group admin" (and same for sudo)
<hallyn> but do i want to :)
<stgraber> yeah, if you list NIS before files, then if the group exists in NIS only those members will be returned, even if you have some extra in /etc/group locally
<infinity> hallyn: I'm puzzled as to what the bug is.
<hallyn> so if you do have an nis group called admin, why shouldn't those users be added to group libvirtd?
<infinity> hallyn: I've never seen someone complain before about NIS working exactly as advertised.
<hallyn> that's bc it's been 15 years since anyone used it, working or not
<stgraber> so usually people don't really like postinst scripts adding possibly hundreds of network users directly to the local /etc/group
<stgraber> and I think that's what the reporter is complaining about
<infinity> It's only a complain because it's an ambiguously vague group name.
<hallyn> stgraber: but won't adduser use NIS to add the users to (NIS) group libvirtd
<infinity> hallyn: It can, depending on how you've set it up.
<infinity> By default though, no.
<stgraber> if you have a company with a NIS (or LDAP or whatever) group called "admin" with users in there and don't have the group locally (because it's a clean raring system), then all those users will end up being hardcoded in /etc/group
<stgraber> so yeah, I guess the grep + getent change would be reasonable. It won't cause any change for standard systems and for systems using network auth, it won't give extra rights to "random" users.
<hallyn> well if we do want to undo this, i'd say falling back to 'grep "^admin:"' makes more sense than using both grep and getent
<hallyn> IF we want to undo it
<pedahzur> I am trying to use a latest mainline kernel to debug an issue.  The 3.9-rc6 has a linux-image-extra package, but 3.9-rc7 does not.  Has everything in the extra package been integrated into the main kernel package?
<gotwig> Does anyone know something about GeoClue?
<gotwig> its death, isnt it? No maintainer, no new code, no bug fixes for several months
<gotwig> tvoss, hey there
<tvoss> gotwig, about to leave :) how can I help, though?
<gotwig> tvoss, hallo erstmal ;D
<gotwig> tvoss, I saw your blueprint about geoclue2
<gotwig> tvoss, do you work on it, or is it deathÂ²?
<tvoss> gotwig, the blueprint itself is alive, geoclue2 as presented on the bp is quite unlikely at this point
#ubuntu-devel 2013-04-19
<stokachu> stgraber: ping
<pitti> Good morning
<dholbach> good morning
<stgraber> stokachu: pong
<stgraber> roaksoax, Daviey: So MAAS was uploaded after final freeze. How critical is it that you have it on media for 13.04?
<infinity> pitti: Methinks it's probably final langpack time?
<infinity> pitti: (Unless that happened when I wasn't looking, it's been a weird week for me)
<pitti> stgraber, infinity: I'm about to upload a new network-manager with more tests, and resurrecting the dnsmasq autopkgtest; no changes to the actual code, is that okay?
<pitti> infinity: ah, good point; requesting full export now
<infinity> pitti: More tests are fine, if they pass. :P
<pitti> infinity: yes, I'm pre-testing in a jenkins-like VM
<pitti> and they now cover WPA and WPA2 as well
<pitti> infinity: actually, we got a full export yesterday, so unless we are heading for an even fresher one I'll take that one
<infinity> pitti: Also, I've lost track through all the apport/whoopsie iterations what the new and improved "we're about to release" workflow is for stuff.  Do we still do some bit twiddle on apport, or is that a thing of the past?
<pitti> infinity: we still have to twiddle, but that already happened for raring
<infinity> pitti: Yesterday should probably be fine.
<infinity> pitti: Okay, cool beans.
<infinity> pitti: Did your langpack chroot ever get upgraded, or are you still fudging it on a porter?
<pitti> infinity: it was, all working fine on macquarie now
<pitti> the cron'ed ones also come from there
<infinity> \o/
<infinity> Hrm, I wonder if I should try to fast-track Marc's apt-ftparchive change in precise to get it on pepo before we generate raring's final Sources.gz
<pitti> infinity: the only thing left to do there is to figure out how I can copy/rsync the precise ones from the porter box to macquarie
<pitti> I haven't yet found a suitable route through ssh/firewalls/etc (except through my box, which would take ages)
<infinity> pitti: netcat ftw?
<infinity> pitti: Or just ask a GSA to do it for you.
<pitti> infinity: yeah, probably an RT
<pitti> infinity: I tried that back then, can't directly ping/cat from macquarie to osageorange
<pitti> (or the other way round)
 * pitti turns the crank for building packs
<pitti> as we currently have four amd64 and four i386 buildds, I guess one should be permanently reassigned back to i386?
<pitti> allspice?
<infinity> pitti: Oh, we should toss more than one back when we accept this mess anyway.
<infinity> pitti: Like, all but one. :P
<pitti> right, but only temporarily
<infinity> Yeah.
<pitti> but I thought we permanently have 5 i386 and 3 amd64
<infinity> Usually, yeah.  I rebalanced cause we had a bunch of heavy arch:any jobs on the go.
<infinity> Making that a shared pool is on my TODO for the next cycle.
<infinity> pitti: Anyhow, crank away.  You have 7 i386 builders now.
<infinity> pitti: Once you verify those source packages are building right and looking sane or whatever, feel free to self-accept the lot.
<pitti> infinity: it'll take some two or three hours to build the (source) packages on macquarie and then I want to test them first
<pitti> infinity: ack, will do
<cjwatson> infinity: pepo's on lucid, not precise, FWIW
<infinity> cjwatson: Oh, right.  Derp.
<infinity> cjwatson: I can backport his patch for IS.
<cjwatson> I thought that's what barry had done
<infinity> Oh, did someone already get there? :P
<cjwatson> Did that not happen?  He was certainly talking about it in foundations meetings ...
<infinity> I've been missing those meetings of late.
<cjwatson> Yeah, it's on pepo
<infinity> Yeahp, so it is.
<infinity> Shiny.
<cjwatson> http://paste.ubuntu.com/5720945/ - head of /usr/share/doc/apt-utils/changelog.gz
<infinity> He says to the man staring at that in a terminal.
<cjwatson> Heh
<infinity> Was there a plan to also push that to lucid-updates, so it doesn't get lost after a security update?
<cjwatson> Not sure.  barry?
<infinity> I mean, ideally, pepo will be precise some day.  But, I don't know when that day it.
<infinity> s/it/is/
 * cjwatson fixes up the bug metadata
 * infinity gives the i386 chroot a quick refresh before pitti goes all langpacky.
<pitti> infinity: ah, thanks
<infinity> Actually, I guess I'll do them all.  It's not like I can sleep anyway.
<stgraber> infinity: are you trying to shift to the Australian timezone right before flying to Europe? you really like jetlag that much? :)
 * infinity wonders why his Panda thinks it's 2012...
<infinity> stgraber: I've only slept about 8 hours since Sunday.  It's not by choice, I assure you.
<pitti> urgh
<stgraber> infinity: ouch
<seb128> xnox, hey
<xnox> seb128: heya.
<seb128> xnox, https://bugs.launchpad.net/ubuntu-geonames/+bug/1150109 ... is "fix commited", what is needed for it to be "fix released"? #is to deploy the update?
<ubottu> Launchpad bug 1150109 in Ubuntu Geonames "Ubuntu's geonames only knows about Hong Kong in Guyana, not in China" [Undecided,Fix committed]
<xnox> seb128: pending RT ticket I believe.
<seb128> xnox, ok, thanks
<seb128> xnox, do you have the rt number by any chance? ;-)
<seb128> xnox, 60594 I guess
<xnox> seb128: correct. =) you are quick with RT
<seb128> xnox, :p
<xnox> seb128: /me was waiting on thunderbird to launch and find the emails.
<seb128> I went on the site and typed "geoname" in the query field
<seb128> that listed only 2 tickets
<seb128> so easy enough ;-)
<xnox> 2...? interesting.....
<seb128> xnox, the other one is "Make geonames a fully webops managed service"
<xnox> seb128: interesting =) maybe I should look into that.
<cjwatson> infinity: Think I should flip base-files now, for the sake of minimal obstacles to release candidate being true candidate?
<infinity> cjwatson: Go nuts.
<infinity> cjwatson: We really need to rewrite these checklists as we go.  They're a bit stale.
<cjwatson> Yeah
<cjwatson> Fighting the last battle
<infinity> cjwatson: Twiddling CONF.sh early isn't an awful plan either, IMO.
<cjwatson> Indeed
<cjwatson> Hm, I've not done os-release before.  Any objections to me setting PRETTY_NAME to "Ubuntu 13.04", rather than something in the style of "Ubuntu quantal (12.10)" as was used for 12.10?
<infinity> cjwatson: How's it look in Debian?  I'm not too picky, since we've not really done much with os-release...
<infinity> PRETTY_NAME="Debian GNU/Linux 7.0 (wheezy)"
<infinity> So, seems to match vaguely the format of issue.net
<stgraber> cjwatson: I think it makes sense not to use the codename for the released version.
<cjwatson> OK, I'll go for "Ubuntu 13.04"; people can reupload if they object
<seb128> the upstream definition is "A pretty operating system name in a format suitable for presentation to the user. May or may not contain a release code name or OS version of some kind, as suitable."
<seb128> "Ubuntu 13.04" seems fine to me
<infinity> cjwatson: That sounds good to me.
<infinity> Oh, wait, that means you're stealing base-files TILM from me.  Grr. :)
<infinity> I geuss I'll resync in a week. :P
<cjwatson> Heh
<cjwatson> Feel free
<ev> mpt: current theory: code is sound, we just need to run build_errors_by_release twice.
<mpt> ev, you've unit-tested?
<ev> mpt: I have for the case of one system that reports an error a week ago, then a day later, then a day later
<ev> mpt: feel free to suggest more test cases
<ev> but I realised that the work of build_errors_by_release would be inaccurate after the first run. FirstError will not be correct until we've seen all the data, and so ErrorsByRelease will not be correct until a second run.
<ev> We're not processing the error reports in time order. We can't.
<ev> So for one system, if we see a report from a day ago and write it into FirstError and ErrorsByRelease, then we see a report from a week ago and write it into FirstError and ErrorsByRelease, the data in FirstError will be correct, but that first error report value in ErrorsByRelease will be inaccurate, because it was based on a report from a week ago being the first error report seen for the given release.
<cjwatson> base-files uploaded, CONF.sh twiddled
<ev> I have no idea why this didn't occur to me straight away
<ev> mpt: I'll be posting a merge proposal for you and bdmurray to review today. I'll try to make the unit test as readable as possible.
<infinity> cjwatson: Cheers.
<infinity> pitti: chroots are all updates, BTW.  Should be good to go when you're ready.
<infinity> s/updates/updated/
<pitti> infinity: thanks
<pitti> sources finished building, I'll give them a smoke test and binary debdiff now
<infinity> pitti: If you have buildd admin, feel free to give amd64 a few machines back when you're done.
<pitti> infinity: I have, will do
 * infinity goes to see if he can get a couple hours of sleep...
<infinity> Maybe I'll get lucky tonight.
<cjwatson> Good luck
<pitti> infinity: sleep well!
<pitti> new langpacks look good, and have a lot of previously missing domains
 * pitti uploads; buildds, brace for impact
<seb128> pitti, do you want/need testers?
<pitti> seb128: if you wish; hang on, I'll build French ones
<pitti> I checked English and German
<pitti> there's no particular reason to believe anything is broken, but it can't hurt of course
<pitti> seb128: les paquets de language sont ici: http://people.canonical.com/~pitti/tmp/langpack/
<pitti> "de lange"
<pitti> "de langue"
<pitti> didrocks, cjwatson, stgraber: perhaps for the final freeze we should disable the daily autolanding?
<didrocks> pitti: it's in manual mode
<seb128> pitti, what daily autolanding?
<seb128> what didrocks said
<pitti> didrocks: ah, because I just see builds
<didrocks> pitti: yeah, it's building everyday
<didrocks> trying tests
<didrocks> but doesn't publish
<pitti> oh, that's just for the PPA, ignore me
<didrocks> yep :)
<infinity> didrocks: Disabling even those PPA builds next week might be nice, in case they happen to clog the buildds at Just The Wrong Time and we need to get someone to kill them.
<didrocks> infinity: we can do that temporarly, however, we are preparing SRU0
<didrocks> infinity: so yeah, if you see anything critical, we can kill them. however, right now, what's building is more the touch stacks for S that we bootstrap than stuff in daily release
<didrocks> infinity: meaning, like, this morning, only 2 source packages built for raring (in indicators stack)
<didrocks> nothing else on the daily release "r"
<infinity> didrocks: Well, for release minus 48h, it might be nice to not have a panic conflict, but I also know which shoulders to tap if I need a buildd Right Now too.
<didrocks> infinity: agreed, can be disabled by then, we need to have mterry, cyphermox, robru and kenvandine do the "disable bits" for it (it's not a global switch)
<infinity> didrocks: Ahh, well.  I'll talk to you next week about it when we're in the same timezone.
<didrocks> infinity: sounds good :)
<seb128> pitti, language-pack works fine for me, gnome-calculator is in french, all good ;-)
<pitti> so much for sleeping :(
<infinity> pitti: I'm asleep right now, can't you tell?
<pitti> seb128: ah, most important app ever!
<pitti> seb128: merci
<seb128> pitti, lol
<seb128> pitti, that's the one that I know about which was missing its template ;-)
<seb128> pitti, de rien
<pitti> infinity: your IRC proxy clearly passes the Turing test!
<infinity> pitti: Can you elaborate on that?
<pitti> Eliza, how are you today?
<infinity> :)
<infinity> And here I was, afraid you wouldn't get the reference.
<pitti> the most important emacs feature missing in vim!
<highvolt1ge> in a very poor school district in south africa, I migrated a few schools form Fedora to Ubuntu a few years ago
<highvolt1ge> and received a bunch of faxes begging to bring back emacs because the kids wanted it back badly
<highvolt1ge> I was a bit confused as to why the kids wanted emacs so badly. turned out it was for the psychologist :)
<infinity> Heh.
<infinity> Damn you, Launchpad, for not instantly knowing about new Debian uploads.
<infinity> http://packages.qa.debian.org/l/lolcat/news/20130419T100008Z.html
<infinity> ^-- Inclusion thereof is clearly RC for raring.
<StevenK> infinity: You have to wait for gina
<infinity> StevenK: DON'T WANNA.
<xnox> infinity: veto, unless is also ships a loldog symlink.
 * StevenK overrules xnox, since he is an archive admin
 * xnox :`(
 * infinity removes emacs from the archive to spite xnox.
<xnox>  /msg doko please blacklist lolcat
<xnox> infinity: please do, everyone should be using emacs24 by now ;-)
<infinity> xnox: I meant all emacsen. :P
<xnox>  /o\
<StevenK> infinity: Some way to track Debian uploads without having to have a mirror on iron (and probably somewhere else in the DC) and gina would be awesome
<StevenK> Oh, no, it's the debbugs mirror that is bounced twice, iron is not
<infinity> StevenK: You'd think we could get near instant turnaround by tracking a changes list and pulling from incoming.
<StevenK> Hmm
<infinity> Though, incoming suffers the problem that there's no signed index, so we're blindly trusting the signatures on the .dsc files.
<infinity> Which is likely bad. :P
<cjwatson> Which is pretty much why we wait for a mirror, yeah
<StevenK> And at this point, we stuck until katie runs and ftp.uk is pulsed
<infinity> Of course, incoming DOES have a signed index at /buildd/
<infinity> Shame it's no accessible to the public.
<StevenK> infinity: Not even a DD?
<infinity> Weeeell.
<xnox> not _all_ DD
<infinity> All buildd admins have access to the buildd bits.
<StevenK> Right
<xnox> legal issues prevents access to incomming?!
<infinity> Maybe we could get someone to agree that allowing us to pull from there would be cool.
<StevenK> Back in my day, you couldn't build from incoming
<StevenK> xnox: Yup
<StevenK> xnox: It's a fun legal issue
<infinity> Hrm?  There are no legal issues with incoming.
<infinity> incoming.debian.org is poorly named, it should be accepted.debian.org. :P
<xnox> infinity: if it's new and ftp-master hasn't reviewed it yet..... oh incoming is not NEW?!
<infinity> The only technical issue with us pulling from incoming is that it has no trust path.
<StevenK> incoming is not NEW, no
<infinity> xnox: incoming.debian.org is queue/accepted.  Not to be confused with queue/incoming, which is the precursor to new/by-hand/etc.
<StevenK> NEW is locked down, due to some US acroymn and having to announce packages to the US government because they may contain crypto, but my knowledge might be years out of date
<infinity> Serious terminology overload.
<StevenK> I thought BYHAND was mostly dead?
<xnox> StevenK: right, which debian was requested to stop mailing, but simply keep a record & produce it upon request.
<xnox> aren't docs and d-i bits still BYHAND?
<StevenK> xnox: I was around when BenC produced the first list, which was 8,000 pages
<xnox> wow =)
<infinity> And one wonders why DPLs burn out and disappear.
 * xnox is very young ;-)
<StevenK> I've been a DD for 12 years
<infinity> And you've still not fully repented for linda.
<StevenK> Linda had her uses. And a fan club.
<infinity> Charles Manson has a fan club.
<infinity> Just sayin'.
<StevenK> infinity: Here, I have something for you. It's called 'ether'
<infinity> Yes, please.
 * xnox ponders how to check when one became a DD
 * infinity takes the hint and goes to stare at the ceiling some more.
<StevenK> xnox: nm.debian.org
<StevenK> But only those who went through the new NM process
<Laney> https://nm.debian.org/public/process/13678
<xnox> meh just a year.
 * xnox just under 2 years from start to finish.
<Laney> I think that might be a relative definition of "new"
<StevenK> https://nm.debian.org/public/process/13201 is me
<infinity> Sweet.  Sledge has been a DD since the UNIX epoch.
<StevenK> Haha
<infinity> https://nm.debian.org/public/people/dd_u <-- Might have accuracy issues for people who predate the NM database...
<StevenK> Maybe just a bit
<xnox> StevenK: hmm... 5 days that's swift.
<StevenK> xnox: Yup
<StevenK> xnox: I didn't hear about the "NM problems" until after I became a DD and I was "What problems?"
<xnox> StevenK: I also had something like 7m+ hunting down for someone to sign my key.
<infinity> StevenK: My AM was a slacker compared to yours.
<StevenK> I've been accused by others of having my dates changed by the klecker fire, and by one person that "I must have gotten access to the NM system and changed my own dates"
<StevenK> infinity: Who was your AM?
<infinity> opal
<highvolt1ge> n/win 12
<StevenK> infinity: tbm talked to joeyh about me, joeyh said "Yeah, Steve knows what he's doing", and tbm went "Right, there's T&S done."
<mpt> ev, the simplest test case would be one machine that reported one error today producing a weighted error rate of 1/90
<StevenK> xnox: Ah, I had no issues with that, Sydney has a large number of DDs
<infinity> I didn't have any DDs nearby, but I had some kernel devs that were considered strongly connected enough.
<StevenK> I think I had four or five DD signatures by the time I applied
<ev> mpt: if a machine reported one error today and it was their only error for the release, wouldn't that be 0, not 1/90?
<ev> it's been 0 days since their first error.
<StevenK> bod, wildfire, gus spring to mind
<infinity> pasc, csmall?
<StevenK> Indeed
<infinity> Man, I haven't seen pasc in ages.
<StevenK> I pre-date pasc being a DD
<infinity> Right.  Sleep.  No reminiscing.
<mpt> ev, yep, you're right :-)
<mpt> (off-by-one error!)
<ev> I feel like balloons should be falling from the ceiling right now and someone should be approaching my desk with an award
<ev> maybe a cake
 * katie runs for StevenK 
<ev> bdmurray: happy to report that the only OOPS reports in https://errors.ubuntu.com/oops-local/2013-04-18/ yesterday were caused by me
<StevenK> Haha
<StevenK> katie: The *other* katie
<ev> (I have a branch to fix the bug, I'm just a bit stuck on the YUI DataSource.Get code for catching a 404 raised by the API when the user cannot be found)
<cjwatson> tjaalton: bug 1169071 - are they superseded by some other packages?  just trying to work out what to write in the removal comment
<ubottu> bug 1169071 in nvidia-settings-experimental-304 (Ubuntu) "please remove from the archive" [Wishlist,Confirmed] https://launchpad.net/bugs/1169071
<tjaalton> cjwatson: yes, we have nvidia-304/310 already
<tjaalton> tseliot knows the right answer I think :)
<tjaalton> why we had both
<DktrKranz> cjwatson: wrt bug #1083091, I can't do it right now in Debian because of its rdep gtg. It's on my radar, and it'll be gone as soon as Wheezy is released :)
<ubottu> bug 1083091 in liblarch-gtk (Ubuntu) "Remove liblarch-gtk from the archive" [Wishlist,Fix released] https://launchpad.net/bugs/1083091
<obounaim> What is the lowest level packaging command that is called by all the other packaging tools like pbuilder, sbuild..?
<tumbleweed> dpkg-buildpackage -b
<tumbleweed> which essentially calls debian/rules build; fakeroot debian/rules binary
<obounaim> ok thanks
<obounaim> I am looking for to integrate scan-build int the packaging system, any ideas how to do that?
<obounaim> for a way
<tumbleweed> scan-build?
<pitti> infinity: FTR, roseapple and allspice sent back to amd64 duty
<obounaim> yes a static analyzer for C/C++ programs
<xnox> jibel: how would you like installer bugs tagged that affect ubuntu-gnome images? "ubuntu-gnome" tag? Are you ubuntu-gnome team monitor those?
<xnox> (e.g. in ubiquity package we use kubuntu, xubuntu, lubuntu tags when it only affects those images)
<lool> cjwatson: Hmm ISTR that ffmpeg was in a germinate blacklist, but I can't find it anymore; did the situation change or is this something that we were checking manually?
<lool> I see it in supported-desktop-extra now
<lool> cjwatson: ah!  found libavcodec in ubuntu.raring/usb-ship-live, nm
<lool> seb128: ^
<jibel> xnox, your question is for jbicha?
<xnox> jibel: correct.
<xnox> jibel: he is not here =) hmm... will catch him some other time.
<ScottK> Sweetsha1k: There's a bug asking for lo-menubar to be removed from raring.  Is that correct?
<seb128> ScottK, yes, that got replaced by an upstream implementation in libreoffice itself, but that was for quantal, I'm surprised we still have the old source in the archive
<seb128> hum
<seb128> so indicator-weather is just broken
<ScottK> Thanks.
<seb128> is anyone working on it/upstream for it?
<seb128> or should we just drop it from raring?
<tseliot> cjwatson: nvidia-310-updates has transitional packages for experimental-310 and 304->updates for experimental-304
<mpt> Could someone please answer my questions in bug 1166230 about why there are ever updates to "transitional dummy packages"? Thanks kindly.
<ubottu> bug 1166230 in update-manager (Ubuntu) "Updater lists many transitional dummy packages" [Medium,Confirmed] https://launchpad.net/bugs/1166230
<seb128> mpt, they are updated because they are typically built from the same source as the real package
<seb128> mpt, like gcalctool -> gnome-calculator
<seb128> mpt, so they have the source version
<mitya57> hey seb128, do you think we can backport https://bug691040.bugzilla-attachments.gnome.org/attachment.cgi?id=238204 for raring gtk2?
<mitya57> (bug 1125260)
<ubottu> bug 1125260 in gtk+2.0 (Ubuntu) "gtk_file_chooser_get_current_folder() function is broken in 2.24.10 < GTK+ < 2.24.15" [Undecided,Confirmed] https://launchpad.net/bugs/1125260
<seb128> mitya57, (sorry, otp, seems reasonable but maybe check with Laney/the release team)
<mitya57> it'll be nice to have it at least as a sru
<geser> mpt: at your 2nd questions: it's not always possible to remove those transitional packages yet as the transition isn't complete (e.g. ubuntu-minimal -> module-init-tools which is a transitional package to kmod)
<doko> jibel, pitti: everything green now with the python autopkg tests?
<pitti> no, still not :(
<pitti> https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python3.3/10/ARCH=i386,label=adt/
<pitti> https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-python2.7/6/ARCH=i386,label=adt/
<pitti> python2.7: can't open file '/usr/lib//test/regrtest.py': [Errno 2] No such file or directory
<jibel> doko, it wasn't last time I checked, dbm test failed
<xnox> mpt: furthermore, we support LTS->LTS upgrades thus when we renamed gcalctool -> gnome-calculator, we kept a dummy empty package gcalctool which simply depends and installs gnome-calculator, such that a Precise user upgrades to 14.04 his "gcalctool" upgraded package installs "gnome-calculator". Then in 14.10 we can remove gcalctool transitional package.
<xnox> thus most of transitional packages stick around for 2 years or less.
<jibel> doko, for 3.3
<pitti> jibel, doko: right, for 3.3 there are three failures in dbm
<Sweetsha1k> ScottK: we can do that yeah. its a transitional by now.
<Sweetsha1k> ScottK: /me in call
<rbasak> rsalveti: I'm just looking at the avogadro FTBFS. It's another example of the GLdouble declaration conflict. https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=gldouble+previous+declaration has nine others. Would it be an idea to collapse these into a single bug with multiple tasks? Is there a simple fix that will fix them all, or does each package need individual treatment?
<doko> jibel, pitti: crap about 2.7/testsuite. can't see the test_io failure here with 2.7/testsuite-dbg
<doko> jibel, doko: hmm, the test_dbm failure isn't reproducible here either
<cjwatson> rbasak: Each package needs individual treatment, so it should remain separate bugs rather than being collapsed into a single bug with multiple tasks.  See https://wiki.ubuntu.com/ARM/FTBFS#OpenGL_and_Qt_combination
<cjwatson> DktrKranz: Oh, I hadn't noticed that the liblarch that builds python-liblarch-gtk is still only in experimental.
<tseliot> pitti: is it possible that jockey is trying to set the alternative in enable() before XorgDriverHandler.enable() finishes. This would explain our problem
<barry> cjwatson, infinity yes, it's probably a good idea to backport the patch to lucid.  i can do that
<tseliot> ?
<tseliot> pitti: also maybe in a separate thread?
<pitti> tseliot: jockey doesn't use threads
<pitti> tseliot: so unless the nvidia.py handler calls them in the wrong order, no
<tseliot> pitti: could it be that apt/dpkg does though?
<tseliot> pitti: if so, as  a workaround, I can make sure that the alternatives are set in enabled() instead of enable()
<pitti> tseliot: no, enabled() must not change anything
<tseliot> pitti: hmm... I guess I'm out of ideas on bug 804662 (on the nvidia-common side)
<ubottu> bug 804662 in nvidia-common (Ubuntu Precise) "jockey-gtk crashed with TypeError in _execute_child(): execv() arg 2 must contain only strings" [High,Triaged] https://launchpad.net/bugs/804662
<pitti> need to run out for a bit, back in 45 ins
<tjaalton> slangasek: looks like I've come up with a fix for the plymouth race bug http://pastebin.com/2bZu24yG (+ 'and plymouth-ready' to *dm.conf)
<tjaalton> on another note, can someone explain why 'pkg-config --libs nss' doesn't show -lpthread, while it's linked against it?
<diwic> tjaalton, are you sure that it should, as long as the host software doesn't need -lpthread ?
<tjaalton> -ldl is also missing, these both caused build issues with sssd
<cjwatson> tjaalton: it's only linked against it indirectly
<tjaalton> diwic: I don't know
<tjaalton> cjwatson: ahh, ok
<cjwatson> use 'objdump foo.so | grep NEEDED' rather than ldd
<cjwatson> sorry, objdump -p
<tjaalton> gotcha, thanks
<cjwatson> so sssd must either be linked against something else that fails to specify that you need -lpthread; or it's using pthread directly and erroneously not specifying it
<tjaalton> nah the build-issues have been fixed, but upstream (or fedora) is complaining why these fixes are proposed there :)
<cjwatson> libnssutil3 and libnspr4 are both directly linked against -lpthread
<tjaalton> or something, pinging me about it anyway
<cjwatson> hm, and  pkg-config --libs nss  says -lnssutil3
<cjwatson> well; -lpthread should not be necessary in sssd unless it uses pthread functions directly, should it?
<tjaalton> there are some components that do use it
<cjwatson> which it does
<cjwatson> so it's sssd's fault then.  use directly, link directly.
<cjwatson> and don't use directly, don't link directly.  should be very simple :)
<seb128> lool, we are discussing the gettext issue on #ubuntu-hardened
<cjwatson> lool: ubuntu.raring/ship-live is generally the governing one, but yes
<tjaalton> cjwatson: ok, but shouldn't nss.pc have -lpthread then if libnssutil3 links to it?
<cjwatson> tjaalton: only if the mere fact of using the nssutil API causes the program using it to have *direct* references to symbols in libpthread
<cjwatson> tjaalton: for example if an nssutil header file had macros that expanded to pthread_*
<tjaalton> cjwatson: alright.. think I got it this time
<cjwatson> programs shouldn't overlink by re-specifying all the indirect linkage of the libraries they use
<cjwatson> at least not on Linux
<tjaalton> what changed it for raring?
<cjwatson> it actually causes some subtle problems if they do
<cjwatson> not aware of any toolchain-level changes here for raring
<cjwatson> maybe something changed in nss, dunno
<Laney> mitya57: is the patch reviewed/committed upstream?
<tjaalton> maybe it's nss/nspr then
<tjaalton> right
<tjaalton> ok, case closed anyway
<mitya57> Laney: looks like a different set of patches was committed, I didn't yet figure out which of them actually fixes the bug
<Laney> mitya57: sounds like SRU would be better then
<mitya57> there are *lots* of gtkfilechooserbutton fixes @ https://git.gnome.org/browse/gtk+/log/?h=gtk-2-24
<Laney> even since .17?
<mitya57> yes
 * mitya57 wonders whether it'll be better to backport the whole set of fixes
<Laney> so there are
<Laney> maybe there will be another release
<mitya57> Laney: is "another release" OK for SRU?
<Laney> GNOME micro releases are
<mitya57> Laney: OK, so let's wait for the new release, I'll prepare a SRU then
<Laney> might be good to find out if/when that is planned for
<mitya57> I don't think there is any schedule
<mitya57> xnox: do you know why your reply is shown at http://www.riverbankcomputing.com/pipermail/pyqt/2013-April/thread.html, but my original mail isn't?
<xnox> mitya57: are you subscribed to the mailing list? as far as I remember it's moderated list.
<mitya57> xnox: is it auto-moderated for those who are subscribed? I am not (yet)
<xnox> mitya57: yeah. rather not moderated at all if posted by subscribers, kind of like launchpad mailing lists.
<mitya57> ok, let's hope they will read my mail via yours :)
<mitya57> xnox: by the way, did you already test if phablet toolkit works with PyQt?
<xnox> mitya57: it could be me building it wrong though =/ I am surprised it build at all =))))
<xnox> mitya57: nope. I have only tried simple standard show a QApplication with a label =)
<mitya57> but the target is the toolkit, right? or why do you need it?
<xnox> mitya57: my initial target is getting a non-trivial gui app working (e.g. ubiquity) or something QML based.
<mitya57> xnox: fwiw, apart from QFont constructor and Xserver crashes, I am able to run ReText under Qt 5
<xnox> mitya57: the target is to get oem-config (ubiquity) frontend in python with ubuntu-touch Qml components.
<xnox> mitya57: but we'd want pyqt4 (with qt5.... and eventually pyqt5) regardless of anything.
<mitya57> yes, let's hope PyQt5 will be available soon
<mitya57> and thanks for the work you have done!
<xnox> mitya57: i would not hold my breath waiting for PyQt5 release
<ogra_> well, probably if you are a professional diver ...
<xnox> ogra_: i'm no Linus ;-)
<ogra_> hehe
<mitya57> seb128: I think https://plus.google.com/u/0/106010143685041042333/posts/XeygQ6A9dEk indicates that the author is not going to continue i-w development
<rbasak> cjwatson: thanks, and for the wiki link - I had googled but not found it.
<cjwatson> Might be a plan to grab the UbuntuKylin people and point them at that post - hard
<mitya57> (Vadim is here, and his nick is roignac)
<seb128> mitya57, oh ok, thanks for pointing it, shame that he got offended just because those guys forked some code, they are pretty new to opensource communities and are learning...
<seb128> mitya57, well, from what I see that yahoo service has been discontinued for a while .... in any case if nobody is wanting to fix it, just drop the source from raring, that's a shame though :/
<mitya57> yes, let's drop it
 * mitya57 has to leave
<slangasek> tjaalton: 'start on filesystem' is very late, I don't think that's what you want - that's going to unnecessarily slow the boot down in some cases
<tjaalton> slangasek: 'startup' didn't work
<slangasek> tjaalton: I think you instead want 'start on startup or started plymouth-splash'
<tjaalton> hmm let me try again
<slangasek> tjaalton: 'startup' didn't work for the plymouth-in-initramfs case?
<tjaalton> I think so, hang on
<tjaalton> got some ideas from #upstart too, added sleep 0.1 and dropped console-output
<tjaalton> oh now it worked, heh
<Riddell> ogra_: I've come to the conclusion that the kubuntu nexus images you made don't work
<ogra_> haha, thats a prompt reply
<Riddell> ogra_: flashing them to the nexus just stops indefinately
<Riddell> ogra_: http://paste.kde.org/728402/
<Riddell> ogra_: that's quite reproducable on two nexus 7s
<ogra_> erm
<ogra_> when do you flash boot ?
<ogra_> oh i see ...
<Riddell> ogra_: when it's in firmware mode
<ogra_> your images are to big
<Riddell> hum
<ogra_> you can try using the -S option for fastboot
<ogra_> but thats sadly unreliable and doesnt work on all models
<ogra_> try with -S 512M
<ogra_> that will cut the img in little chunks while transferring
<cjwatson> Daviey: Could you or somebody on your team confirm bug 1017609?
<ubottu> bug 1017609 in python-melangeclient (Ubuntu) "Please remove melange from ubuntu archive" [Undecided,New] https://launchpad.net/bugs/1017609
<slangasek> tjaalton: also, I think you want to drop the 'stop' rule, add an 'instance $UPSTART_EVENTS', and lose the while loop
<tjaalton> slangasek: ok..
<Riddell> ogra_: well that seems to successfully copy over but then on reboot it drops me to an initramfs command line
<Riddell> saying "mounting /dev/mmcblk0p9 on /root failed: invalid argument"
<slangasek> tjaalton: e.g., (untested): http://paste.ubuntu.com/5721802/
<ogra_> Riddell, thats with the matching bootimg file in place ?
<Riddell> ogra_: yep
<slangasek> tjaalton: caveat: for the plymouth-in-initramfs case, this will emit the event twice
<slangasek> tjaalton: which means, actually, that the initctl emit should be --no-wai
<slangasek> t
<ogra_> Riddell, what kind of n7 is that (what size)
<ogra_> just the 8G one or something bigger ?
<slangasek> Laney: indicator-weather upstart respawn> haha, +1
<ogra_> uuuh !
<Riddell> ogra_: Google Nexus 7 Tablet PC (Android 4.1 Jellybean) - 16 GB
<ogra_> as someone who had his disk eaten by indicator-weather i strongly disagree !
<slangasek> ogra_: oh, but you had your disk eaten by it because it was writing to .xsession-errors... as an upstart job you're safe from that ;)
<ogra_> Riddell, hmm, might be that mmcblk0p9 isnt the userdata partition on that device
<slangasek> ogra_: you can even just remove .cache/upstart/indicator-weather.log, and upstart will automatically re-open the logfile automatically ;)
<ogra_> slangasek, haha, so upstart doesnt log ?
<ogra_> heh
<ogra_> great
<slangasek> it *does* log - /properly/
<ogra_> i could write an upstart job to remove it once it hits a certain size !
<Riddell> ogra_: ubuntu images work fine on it
<slangasek> tjaalton: so does my counterproposal make sense?
<Laney> slangasek: :-)
<slangasek> (happy to explain it if not - also happy to take the discussion to #upstart, now that I've noticed I had fallen off the channel)
<tjaalton> slangasek: yeah, I'll test it in a bit
<slangasek> tjaalton: ok, cool
<tjaalton> I had --no-wait there first since I copied the idea from somewhere
<ogra_> Riddell, hmm, try with a more recent bootimg then
<cjwatson> How often is the rdepends data on qa.ubuntuwire.com updated?
<tjaalton> duh, forgot that modemmanager doesn't work with my old laptop (3g builtin). it hangs in shutdown and timeouts after some minutes, not a nice machine for quick testing
<tjaalton> then again, power button
<slangasek> tjaalton: modemmanager> hmmm please escalate that to cyphermox
<cyphermox> err what?
<slangasek> modemmanager is supposed to be shutdown cleanly by NM
<cyphermox> yes
<slangasek> if it's still hanging on shutdown, that's a pretty serious bug
<tjaalton> cyphermox: I'll update the machine and get back to you later :)
<cyphermox> it wasn't, but I'll take a look
<tjaalton> slangasek: seems to work on the non-initrd (=normal) case
<tjaalton> next the odd one
<tjaalton> slangasek: hmm, works without --no-wait
<tjaalton> slangasek: the non-initrd case
<tjaalton> slangasek: same thing with initrd case
<tjaalton> that's probably why it suddenly started working for me, when I dropped it :)
<tjaalton> slangasek: actually the initrd-case isn't working with your version
<tim`> hrmm - there appears to be a libqwt6 package but no libqwt6-qw4-dev package
<tim`> how are you supposed to get qwt6 dev headers?
<cjwatson> tim`: libqwt-dev
<roaksoax> stgraber: howdy!! there are critical fixes that I think *need* to be fixed because it truly affects how it behaves in distributed environments and could potenttially break deployments. As far as the media side, i think I would be fine to accept it as a 0-day sru, as long as it hits the archives as part of raring
<roaksoax> stgraber: Daviey would be a better person to discuss this with :).
<tim`> cjwatson: thx is 6 default now then ?
<roaksoax> stgraber: but idk whether he is back in the UK or whether he is flying now.
<cjwatson> tim`: no idea, I just looked at the package structure ...
<tjaalton> slangasek: 'status plymouth-splash' should never return 'started' for the initrd case
<stgraber> roaksoax: ok. We haven't technically started spinning RC media at this point, so if you're 100% sure this won't cause regressions, I think I'm fine to accept it (as 0 day SRUs for main pieces of software is always a bit annoying)
<tjaalton> slangasek: adding " || plymouth --ping" fixed it :)
<cjwatson> tseliot: I don't see a transitional package for nvidia-settings-experimental-304 - is it OK to remove anyway?
<Riddell> ogra_: curiouser, on my other nexus it mounts fine (same boot image) and shows plymouth then goes to a blank screen
<cjwatson> tseliot: ah, it's provided by nvidia-settings-304/nvidia-settings-304-updates I see; so would "superseded by nvidia-settings-304/nvidia-settings-304-updates" be a suitable removal message?
<Riddell> ogra_: Serial Debug Shell doesn't work
<tseliot> cjwatson: oh, good point. I guess it will be ok, since the new drivers will pull in the relevant nvidia-settings flavour anyway
<cjwatson> tseliot: The Conflicts/Replaces/Provides are probably sufficient, if those are the correct replacement packages
<tseliot> cjwatson: I guess a number of packages provide that though
<cjwatson> tseliot: Yep - well, decide quickly whether you want me to remove it now or whether you want some further packaging change
<tseliot> cjwatson: ok then please leave the nvidia-settings-* there for now, I'll make sure I come up with some proper transitional packages
<smb> stgraber, So with that unpleasant UEFI experience there is something that probably should go into the release notes. Problem is that the kernel driver for efivars now refuses to add the ubuntu boot key when the space is already filled up to a certain degree. However the installer does not realize this a just shows the "reboot now" dialogue. Which then does not find anything to boot.
<stgraber> smb: yep, not sure about what to put in the release notes though... "If you install on UEFI and don't see an Ubuntu entry post-reboot, your system is broken, turn BIOS mode back on and use that."? :)
<slangasek> smb: oh, is *that* what's happening!
<slangasek> (bug #1170183)
<smb> Unfortunately (maybe again AMI) a GPT partition with something in does not count as bootable. Most seem to only look for EFI/BOOT/BOOTxxx.EFI.
<ubottu> bug 1170183 in grub2 (Ubuntu) "can not boot up in uefi secure boot mode unbuntu 13.04, can run in a live from cd uefi secure mode. will boot non secure boot mode" [Undecided,New] https://launchpad.net/bugs/1170183
<stgraber> or actually "reboot your system twice and try again" (as it's the AMI way of triggering the garbage collector and hopefully save some space)
<smb> stgraber, Did not seem to help on that board... hence caused me to issue the command of doom
<stgraber> but yeah, I've had that specific issue on one of my UEFI machines and ended up going with a factory reset of the firmware which wiped enough stuff to let me write a new boot entry
<stgraber> smb: how long had you been using that board with UEFI on raring?
<stgraber> smb: I'm wondering whether you may have had some kernel panic dumps in pstore/nvram back when we still had that enabled in our kernel which would have caused your nvram to be pretty full and prevent any extra write (that was the cause for the broken efibootmgr on my other UEFI machine)
<smb> stgraber, Not really long. That board is maybe 1 or two months old. And from that time I only did a UEFI install of 12.04.2 and kept that running. And then had some non-efi installs for other tings. Raring I probably only had tried the one or two weeks
<smb> The dumpstore output of all variables did not seem to contains anything like dumps
<stgraber> smb: hmm, ok, so that's not it. 12.04.2 doesn't have pstore efi nvram IIRC and if you only had raring for a couple of weeks you never had that in your kernel (sforshee turned that off after I bricked my laptop for the second time, so 1-2 months ago)
<smb> But maybe hidden through compression or so. Who knows. Yesterday I still was able to get the ubuntu entry written after I booted through efi shell and re-issued dpkg-reconfigure grub-efi-amd64
<smb> Not anymore today
<stgraber> though I have no idea what kind of crap the firmware may end up storing in there causing it to grow slowly and eventually reach the 50% threshold
<smb> Yeah, I could not really tell
<smb> Just hope that not too many people install aside a win8 and secure boot requiring the efi bios...
<cjwatson> ogra_: I think bug 1153313 may need your attention before the archive team can do anything with it
<ubottu> bug 1153313 in usb-imagewriter (Ubuntu) "Please port usb-imagewriter to modern APIs, or remove it" [Undecided,New] https://launchpad.net/bugs/1153313
<stgraber> well, that's just every single machine you currently find in stores... (and apparently they all have some flavour of the broken AMI firmware, haven't heard of anything shipping with a non-AMI UEFI firmware yet)
<roaksoax> stgraber: yeah I have been testing this the past week and have not found any regressions.
<stgraber> roaksoax: ok, good enough for me. I'll let it in now. I can't remember seeing anything horribly wrong when reviewing the diff the other day
<stgraber> s/other day/this morning/
<ogra_> cjwatson,  do you need any attention from me to remove it from the archive ?
<ogra_> cjwatson, updated the title :)
<cjwatson> ogra_: comment in the bug ...
<smb> stgraber, Yeah, if one would not have missed the good old bios already... anyway, the brick is packed to be sent msi's way.
<roaksoax> stgraber: i'd like to do a quick run now though? or at what time do you have to release this?
<roaksoax> stgraber: i think I spotted a tiny issue that I would like to get tested
<cjwatson> ogra_: https://bugs.launchpad.net/ubuntu/+source/usb-imagewriter/+bug/1153313/comments/1
<ubottu> Launchpad bug 1153313 in usb-imagewriter (Ubuntu) "Please remove usb-imagewriter from the archive" [Undecided,New]
<ogra_> yeah, just saw it
<ogra_> if SSO wouldnt constantly time out on me i could fix that wiki ...
<stgraber> roaksoax: well, too late, it's already been accepted into the archive... if that issue is problematic enough, just upload again and I'll review the new one
<ogra_> cjwatson, added a note that this is only supported until 12.10
<ogra_> feel free to remove it
<tjaalton> cyphermox: turns out it was caused by (ahem) buggy sssd upstart job which leaves upstart thinking it's running when in fact it failed to start.. so my fault :P
<tjaalton> "sssd stop/killed, process 1239" -> shutdown waits for 5min until it proceeds
<tjaalton> but modemmanager at least used to segfault all the time on this machine, I need to revisit that issue..
<slangasek> zyga: hi, did you end up filing any bug reports for your efivars/pstore issues?
<slangasek> zyga: cf. bug #1170183, another user who I've asked to run 'grub-install --uefi-secure-boot' whose boot config failed to be updated
<ubottu> bug 1170183 in grub2 (Ubuntu) "can not boot up in uefi secure boot mode unbuntu 13.04, can run in a live from cd uefi secure mode. will boot non secure boot mode" [Undecided,New] https://launchpad.net/bugs/1170183
<zyga> slangasek: hi
<zyga> slangasek: actually no, I only sent an email to the ubuntu-devel ML
<zyga> slangasek: let's see
<zyga> slangasek: interesting
<zyga> slangasek: the symptopms are similar, I wonder if the cause is as well
<roaksoax> stgraber: alright. Uploaded a new package, is a really tiny change to one of the patches. SOrry about that
<slangasek> zyga: since this seems to be a new install, it seems unlikely to be caused by the kernel filling the nvram
<zyga> slangasek: indeed
<zyga> slangasek: but if you recall, there were two oddities in my casae
<zyga> case
<zyga> slangasek: nvram going dry _and_ the incorrect image being loaded
<hallyn> slangasek: ok, so after going through some more links and edk2/ovmf code:  indeed you can NOT currently save efi nvram to a file from qemu.  david woodhouse was working on a patch in january toward this (http://permalink.gmane.org/gmane.comp.bios.tianocore.devel/1706), and others talk about using qemu's flash fs support.  i'll keep looking, and perhaps jump in on the patch to support that.
<slangasek> hallyn: ah, alrighty
<hallyn> (see for instance http://blog.hansenpartnership.com/uefi-secure-boot and http://sourceforge.net/mailarchive/forum.php?thread_name=CAFe8ug_dnTdU0OWR_LiGAzmcLgUDvumQJ%3DYgT9jZQmd14BNwHQ%40mail.gmail.com&forum_name=edk2-devel for more confirmation that you can't right now)
<xnox> bdmurray: are you uploading ndiswrapper to raring? as far as i can see we want it into precise as well due to linux-lts-raring
<xnox> or do you want me to upload?
<bdmurray> xnox: I uploaded it to raring, you could do precise
<xnox> bdmurray: ack. adding to my todo list for some time later e.g. by 12.04.3 i'm guessing.
<slangasek> smb, cking: so regarding pstore... why should we not just patch out pstore writing to uefi nvram?
<slangasek> smb, cking: it seems to be causing us no end of problems, and pre-3.9 there isn't even a "good" way to get at the data to maintain it, AIUI
<cking> sforshee, ^^ didn't pstore uefi get disabled in raring?
<stgraber> slangasek: we did actually
<slangasek> oh
<stgraber> cking, slangasek: Ubuntu carries an extra patch that disables UEFI nvram storage as a pstore backend
<slangasek> so we're not pstoring in efi at all anymore?
<slangasek> cool
<slangasek> ok, then I guess zyga's problem was just because he managed to fill nvram before that
<slangasek> and this patch will go (or has gone) into 12.04 enablement kernel, right?
<stgraber> sforshee wrote that one after we discovered the whole "thinkpad turn into brick on panic" bug
<stgraber> slangasek: I guess so
<cking> but also there was a patch to limit uefi vars from filling > 50% or so of space to avoid bricking issues too
<stgraber> slangasek: I think that in theory we could remove mjg59 change to restrict nvram writes when > 50% of space used as without the pstore use case, it should be relatively safe to do so
<cking> one issue is that now we may not have enough free space to set the boot vars and hence installs fail if we run low
<stgraber> cking: right, both try to address the same problem in different ways. mjg59's patch simply rejects any write done when we're past 50% of used space and that's what actually prevents efibootmgr from doing its job on some systems. sforshee's patch is specific to the use of nvram for pstore and essentially disables the biggest source of nvram writes
<cking> stgraber, yep, i concur with that
<stgraber> so it "should" be safe to turn off the 50% one on Ubuntu, though this may still lead to some bricks if for example you have too many secureboot keys being added or any similar thing
<cking> stgraber, we just need to make sure users now don't tidy up their uefi vars by deleting them all and bricking their machines :-/
<stgraber> (it's a case where all solution sucks... the real solution is to get a fixed firmware on those machine that does proper garbage collection and doesn't blow up when the nvram is empty or full)
<cking> stgraber, indeed.  firmware sucks
<slangasek> other issues: - efibootmgr doesn't output any error messages on failure; - grub-install doesn't capture the error code from efibootmgr
<cking> slangasek, yes, the silent fail is a big fail
<stgraber> slangasek: right, I saw that on a machine and didn't even realize it was caused by the 50% thing... I (wrongly) assumed it was a bad firmware, I updated to the new one which fixed it (likely because it forced the garbage collector or freeed some nvram variables)
<stgraber> cking: does the kernel at least log something when it refuses a write because of the 50% stuff? A dmesg entry would be kind of nice (on top of having the userspace tools return an error message)
<cking> stgraber, ideally the failed update should return an error code so apps can react to that, not sure about the kernel messages
<cking> sforshee, any ideas ^^
 * sforshee tries to catch up after returning from lunch
<sforshee> stgraber, if writes are done via the raw_var sysfs attribute then there should be an error code and something in dmesg
<cking> something like efivars: set_variable() failed: status=.... ?
<sforshee> yes
<cking> I think if it ends in 9 then you've run out of free spafe
<cking> *space
<cking> ..and you get -EIO on a failed write I believe
<sforshee> some other paths don't print to dmesg, but they all ought to return errors
<stgraber> sforshee: is there an easy way to special case the boot order variable?
<stgraber> All of ^Boot* actually
<sforshee> stgraber, with the way the driver is today there are multiple paths by which the variable could be written
<sforshee> stgraber, there are probably only a couple that matter though
<cking> ultimately one is at the mercy of the firmware run time service to update the vars though
<stgraber> yeah, my guess is that we always want BootOrder and BootXXXX so that we can setup the boot entry
<slangasek> hmm, I think I've spotted a simpler explanation for bug #1170183; we'll see what the submitter comes back wiht.
<ubottu> bug 1170183 in grub2 (Ubuntu) "can not boot up in uefi secure boot mode unbuntu 13.04, can run in a live from cd uefi secure mode. will boot non secure boot mode" [Undecided,New] https://launchpad.net/bugs/1170183
<slangasek> stgraber: "special case" them how?  excluding them from the 50% restriction?
<stgraber> slangasek: yep
<cking> and then risking bricking some machines?
<slangasek> right - the machines that are affected won't care how much over 50% you are
<slangasek> the failsafe is there because we don't have a saner option
<slangasek> so I think it's more important instead to fix efibootmgr+grub-install wrt error reporting
 * cking got kids to sort out - sorry, need to go
<stgraber> and say what? sorry you can't use UEFI on that box because your firmware is crap, switch back to BIOS and try again? (I rechecked the post by Matthew and yeah, I agree we shouldn't write past the 50%. I had the hope it'd only apply to new variables but apparently not)
<cking> stgraber, essentially, yes, firmware is the limiting factor
<stgraber> would be nice if we could somehow detect that before wiping the user's harddisk...
<cking> either it bricks (v bad) or won't install (annoying)
<slangasek> stgraber: not "sorry your firmware is crap", but "sorry your nvram is full, here's some helpful advice on how to clean it up safely"
<sforshee> slangasek, do we have advice on how to clean it up safely other than "try rebooting a couple of times and see if that helps"?
<stgraber> hmm, yeah, I guess we could recommend doing a firmware factory reset and reboot twice, that "may" help freeing up nvram space
<slangasek> sforshee: well, what I had zyga do was "rm /sys/firmware/efi/efivars/dump*"
<sforshee> that's only going to help people who were running raring during development though
<slangasek> that's the only confirmed cause of too-full nvram so far
<slangasek> and no, it's not raring-only... this problem was seen in quantal too
<slangasek> maybe raring's kernel is the only one with the 50% guard, but you could have already filled your nvram up by running quantal
<sforshee> ah, that's right
<stgraber> ah, we had nvram backend pstore in quantal?
<stgraber> if we did, I was extremely lucky not to brick my machine before the 3.8 kernel
<slangasek> stgraber: yes, that's basically what was bricking the samsung machines
<zyga> hmm
<zyga> slangasek: did my email start any internal discussion about how to use nvram?
<slangasek> zyga: no
<slangasek> zyga: I asked you to file bugs :)
<slangasek> zyga: but it sounds like the kernel team was already on the ball and patched out nvram pstore in raring... you just already had a too-full nvram by that point
<zyga> slangasek: you are right, I should have filed them right away
 * zyga sometimes feels that with the swarm of bugs, a message to a mailing list works better to start a conversation about a diffucult topic 
<tjaalton> slangasek: i've pushed plymouth to ubuntu-x-swat/x-staging ppa
<tjaalton> with the job
<slangasek> tjaalton: ok.  care to raise a branch mp to go with it?
<tjaalton> slangasek: I'd need to use bzr, that takes time :)
<slangasek> pff
<tjaalton> checking out
<slangasek> actually, looks like the branch is out of date because infinity and the package importer both failed to update it
<slangasek> let me fix that
<tjaalton> yeah looks like it
<tjaalton> added plymouth.plymouth-ready.upstart and dh_installinit line to rules
<slangasek> branch updated
<mlankhorst> ogasawara: what happens with armel for the enablement stack, is it explicitly unsupported?
<bdmurray> where is the python-apt upstream? lp:python-apt is behind ubuntu raring
<ogasawara> mlankhorst: it's not supported
<slangasek> (well, modulo race condition with my shell not having returned yet from 'bzr push')
<slangasek> bdmurray: 'debcheckout -a python-apt' should DTRT here I think
<tjaalton> hmm, bzr pull didn't do what I wanted?
<mlankhorst> ok good, I'll fix up mesa-lts-raring to not fail to build on armel, but I'm 90% sure it won't actually run
<slangasek> tjaalton: did you hit the race with me telling you it was done before it was (sorry)? :)
<tjaalton> slangasek: no, pulled afterwards
<slangasek> tjaalton: ok.  if it didn't do what you wanted, what /did/ it do?
<tjaalton> I'll just clone it again
<tjaalton> not sure what happened, bzr diff looks messy
<tjaalton> ooh, managed to push it too
<tjaalton> slangasek: so how to do the mp?
<tjaalton> oh there it is
<tjaalton> https://code.launchpad.net/~tjaalton/plymouth/race-fix
<slangasek> tjaalton: ta
<bdmurray> stgraber: there is a crash on errors that is only about isc-dhcp version 4.2.4-1ubuntu10.2 from quantal-proposed
<bdmurray> https://errors.ubuntu.com/bucket/?id=/sbin/dhclient%3A11%3Aoption_state_reference%3Apacket_to_lease%3Adhcpoffer%3Abootp%3Aassemble_hw_header
<stgraber> bdmurray: odd, the only actual source change in that SRU is the UDP checksum offload, but it's been taken as-is from RedHat and is used in all RedHat derivatives and in raring, so I'm quite surprised it only shows up in quantal-proposed
<bdmurray> Well it could be that the bucketing is too specific.
<bdmurray> ah maybe its bug 1048403
<ubottu> Error: Launchpad bug 1048403 could not be found
<stgraber> the stacktrace also doesn't show anything that's been touched by the extra patch
<bdmurray> https://errors.ubuntu.com/bucket/?id=/sbin/dhclient%3A11%3Aoption_state_reference%3Apacket_to_lease%3Adhcpoffer%3Abootp%3Ado_packet
<stgraber> if it was a bug introduced by the SRU, I'd have expected to see decode_udp_ip_header in the trace
<stgraber> bdmurray: ah yeah, that looks pretty similar.
<stgraber> bdmurray: it's actually the same guy that triggered both entries (look at the IPs in the trace, they're the same)
<bdmurray> thanks for looking
<stgraber> so yeah, I don't think we should worry too much about this. Typically isc-dhcp issues are a pain to figure out from coredump, as they're almost impossible to replicate.
<stgraber> If they guy ever gets around to reporting it on Launchpad and is technical enough, I'll ask him for a pcap of the DHCP traffic, with that it's then trivial to reproduce
<slangasek> Mirv: hey, so bug #1131636 (which should probably be duped to #1155327) has a claim now that QtWebkit 2.3.1 fixes the skype/nvidia/webkit regression... is there something here that you could maybe cherry-pick for us?
<ubottu> bug 1131636 in skype (Ubuntu) "After QtWebkit update Skype is not launching" [Undecided,Confirmed] https://launchpad.net/bugs/1131636
<hallyn> is there a 'proper' command-line way to detect http proxies specified in apt.conf?
<slangasek> hallyn: interesting question.  Why do you want them?
<slangasek> hallyn: last time I tried to use "http proxy specified in apt.conf" for something that wasn't apt, google yelled at me ;)
<hallyn> slangasek: I'm looking for an intelligent deafult for containers
<slangasek> hallyn: so you want to extract the setting from the host for provisioning the guest?
<hallyn> right now we support a MIRROR variable in lxc.conf, but it has been suggested that the /etc/apt/apt.conf/70-procy or wahtever is the way to go
<hallyn> right
<slangasek> hallyn: 'apt-config shell'; cf. /etc/cron.daily/apt
<hallyn> (thanks, looking)
<infinity> hallyn:
<infinity> (base)adconrad@cthulhu:~$ apt-config shell APT_PROXY Acquire::http::Proxy
<infinity> APT_PROXY='http://127.0.0.1:3142/'
<infinity> ^-- For example.
<infinity> (And then just eval that)
<hallyn> thanks
<hallyn> of course, if people commonly do localhost (like you did), then that won't work.  but i guess i can autodetect that
<infinity> It's a pretty common setup for people with apt caches.
<dtchen> yeah, it helps heaps with these test-rebuilds
<hallyn> right.  i do it - but i wasn't sure that meant others would :)
<hallyn> all right well i can just ignore it if its 127.anything
<hallyn> (and still let MIRROR override it)
<hallyn> thanks again
<infinity> dtchen: Oh, I didn't want to go rejecting things because an FTBFS patch that works is better than none at all.
<infinity> dtchen: But you should try to avoid the layering violation of injecting DEB_HOST_MULTIARCH into upstream configure checks, etc.
<infinity> dtchen: And instead push patches upstream to actually use the compiler to find things instead of fighting against it by guessing at paths.
<dtchen> infinity: noted
<mhough> can anyone help me with the removal of libgoogle-glog-dev?
<mhough> the launchpad info just doesn't make sense
<mhough> said removed for qa reason but the bug listed is for a different package/language
<ScottK> mhough: Link
<mhough> thanks
<mhough> https://launchpad.net/ubuntu/precise/amd64/libgoogle-glog-dev
<mhough> if you follow the bug link does that make sense?
<cjwatson> mhough: Launchpad renders the link wrongly
<cjwatson> mhough: Try http://bugs.debian.org/662137
<ubottu> Debian bug 662137 in ftp.debian.org "RM: google-glog -- RoQA; FTBFS, unackowledged" [Normal,Open]
<cjwatson> mhough: FWIW that was a largely automatic removal - we tend to track packages that have been removed from Debian unless there's some special reason not to (substantial Ubuntu modifications, remaining reverse-dependencies, present on one of the images we build, etc.)
<mhough> I see. Thanks for all the help
<sarnold> why was it only removed from precise and not oneiric, quantal, or raring?
<cjwatson> Well it clearly couldn't have been removed from quantal or raring since they didn't exist yet
<mhough> what is an RC bug?
<cjwatson> And we don't remove packages from existing stable releases
<cjwatson> release-critical (Debian term)
<sarnold> cjwatson: ah :) thanks
<cjwatson> Looks like it was later reintroduced
<cjwatson> Somebody picked it up and fixed the RC bugs
<cjwatson> But nevertheless I think it's right to err on the side of not shipping packages that we may not be able to stand behind
<cjwatson> https://launchpad.net/ubuntu/+source/google-glog/+publishinghistory shows the sequence of events
<jbicha> bug 1151844 is interesting then
<ubottu> bug 1151844 in google-glog (Ubuntu) "[MIR] google-glog" [Undecided,Fix committed] https://launchpad.net/bugs/1151844
<mhough> does that mean the package be readded?
<cjwatson> mhough: Yes, in >=12.10
<cjwatson> jbicha: Well, as I say, the package was fixed up and reintroduced in quantal
<jbicha> oh never mind then :)
<mhough> the maintainer of another package is asking me the best way for people to read the package to build his package on precise
<mhough> sorry re-add
<cjwatson> Probably easiest to put it in a PPA
<mhough> the 12.10 version?
<cjwatson> If that works
<mhough> gotcha
<mhough> thanks
<cjwatson> It would be extremely rare and exceptional for us to introduce (effectively) new packages in stable updates
<mhough> no I see that
<cjwatson> It does happen but there'd have to be a driving reason
<mhough> sure
<mhough> probably not for obscure DICOM package
<cjwatson> That might be a tough sell
<ScottK> It could be added in backports.
<cjwatson> True
<mhough> well I don't mind adding it to a launchpad PPA to learn how to do that
<ScottK> !backports | mhough
<ubottu> mhough: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<mhough> but if you think its worth adding it to
<ScottK> updated can also mean doesn't exist.
<mhough> ok
<ScottK> You're call.
<ScottK> your
<mhough> hopefully his package will be in neurodebian or med debian
<mhough> is orthanc there yet?
<cjwatson> http://packages.qa.debian.org/o/orthanc.html ?
<mhough> yeah I see in unstable sid
<cjwatson> It's in raring too.  https://launchpad.net/ubuntu/+source/orthanc/+publishinghistory
<cjwatson> We try to keep track of new packages as well as removals ;-)
<cjwatson> (Actually rather better - that side is more fully automated)
<mhough> so would that justify libgoogle-glog-dev for a backport?
<cjwatson> If you were backporting orthanc too, yes
<mhough> I see
<mhough> let me see how it goes with them on my ppa first I guess right?
<cjwatson> Sure
 * cjwatson gets the archive admin to-do list down to three long-term items (one in progress) and one removal pending verification by the server team
<cjwatson> Phew
#ubuntu-devel 2013-04-20
<slangasek> Laney: hi, do you know how /usr/lib/x86_64-linux-gnu/libproxy/0.4.7/pxgsettings gets launched?  I happened to be looking at my process list and found 13 instances of this thing running... and the package doesn't seem to ship any dbus service definition?
<cjwatson> I have three of them, which 'ps xf' show to be descended from unity-scope-video-remote, unity-shopping-daemon, and unity-lens-photos
<cjwatson> also paired "sh -c" processes indicating that the parent processes are lazily using some equivalent of system() rather than a direct execve
<cjwatson> but I guess that's some library interpreting a configuration file or similar ...
<stokachu> just to verify, https://wiki.ubuntu.com/Releases should quantal be EOL April 2013 and not 2014
<slangasek> cjwatson: ah right, I overlooked that ~half the processes were actually sh -c.... but in my case, ps f doesn't show any parents for them, they've apparently been left behind :-P
<slangasek> stokachu: it should not
<slangasek> stokachu: 12.10 + 18mo -> Apr 2014
<stokachu> oh then raring is off right?
<stokachu> or will that change when its made stable
<slangasek> stokachu: raring will AIUI be supported until Jan 2014
<stokachu> slangasek: ah b/c of rolling release i assume?
<slangasek> well, because of the discussion about shortening the support cycle
<slangasek> we aren't actually having a rolling release :)
<stokachu> :P sounds good to me
<stokachu> i should probably catch up on my emails in the non fire group
<tjaalton> slangasek: does the plymouth mp look good? :)
<tjaalton> oh bah
<tjaalton> wrong version number, took the ppa upload as-is
<tjaalton> fixed
<smartboyhw> kirkland, roaksoax ping. I'm having problems adding a flavour to Testdrive code.
<smartboyhw> ^ please ignore, I think I found the problem.
<doko> jtaylor, https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4440877 numpy related?
<purezen> Hey guys..!! I wanted to know if the updates enabling Hardware Video Acceleration via UVD on ATI Radeon HD 4000 through MESA have arrived on Ubuntu 12.10 x64 yet..?
<jtaylor> doko: numpy related but probably not 1.7.0 -> 1.7.1 related, the headers have not changed
<jtaylor> I'll have a look
<jtaylor> doko: pytiff sets NPY_NO_DEPRECATED_API but does not set the api version
<jtaylor> though there is probably an additional inconsistency in numpy I'll check with upstream
<jtaylor> no numpy is fine, just pytiff doing wrong stuff
<jtaylor> doko: http://paste.ubuntu.com/5724729/ should fix it
<jtaylor> it uses 1.6 API so it can'T disable deprecated api
<jtaylor> specifically PyArray_CORDER instead of NPY_CORDER
<doko> jtaylor, can you upload?
<jtaylor> yes
<jtaylor> done
<slangasek> bdmurray: is bug #1036081 something we've seen before?  Users are trying to install the 'sysvutils' binary package on 12.04, when that package was last available in lucid
<ubottu> bug 1036081 in sysvinit (Ubuntu) "package sysvutils (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/mesg.1.gz', which is also in package sysvinit-utils 2.88dsf-13.10ubuntu11.1" [Undecided,Confirmed] https://launchpad.net/bugs/1036081
<nonickname2> could someone with casper or plymouth knowledge maybe look at bug #1170421 and/or is this bug something for the release notes? only tested on/with kubuntu though, so maybe someone could try to reproduce it on another *buntu (taking the testing results in the bug report into account)?
<ubottu> bug 1170421 in plymouth (Ubuntu) "Live session shutdown "hangs" (not showing "Please remove media ..." message)" [Undecided,Confirmed] https://launchpad.net/bugs/1170421
<slangasek> bdmurray: ok, having looked closer I see that this is an issue we've discussed before; but I don't know if there was a master bug for it somewhere?
<sreich> i've got uhm..a bit of a concern with clang 3.2
<sreich> as in, there's a 100% of the time crash on anything that uses C++11's std::thread with 3.2, from what i can tell.
<sreich> the bug is here http://llvm.org/bugs/show_bug.cgi?id=12730
<ubottu> llvm.org bug 12730 in C++11 "libstdc++ std::thread, when compiled with clang, "pure virtual method called"" [Normal,Resolved: fixed]
<sreich> they fixed it in r178816 (a couple weeks ago)
<sreich> thing is i don't think llvm itself backports fixes..is it possible for ubuntu to squeeze that in?
<sreich> because that's a pretty serious bug imho
<sreich> or should i be contacting llvm to have them backport it (maybe i am wrong and they do push bugfix releases?)
<jtaylor> sraue: depending on the invasivness of the fix we can fix it for raring
<jtaylor> sreich: ^
<jtaylor> though probably via an stable release update at this stage
<jtaylor> sreich: forwarding it to debian would also help, llvm is maintained there
<sreich> ok
<jtaylor> clang 3.0 is not affected?
<sreich> no idea
<sreich> don't think 3.0 even had std::thread support
<jtaylor> probably not I'll try
<sreich> but to check you can just run the source file there
<jtaylor> hm it doesn'T compile unless you remove a static assert and then it crashes :/
<sreich> yeah it's a bit on the edge i guess http://clang.llvm.org/cxx_status.html
<sreich> could be 3.1..or 3.2, don't really know
<jtaylor> the fix looks quite simple
<jtaylor> bit I'd like the debian maintainers opinion on it first
<sreich> jtaylor: where can i get them?
<sreich> is there a #debian-devel  ?
<bdmurray> slangasek: bug 1001904
<ubottu> bug 1001904 in sysvinit (Ubuntu Precise) "package sysvutils (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/mesg.1.gz', which is also in package sysvinit-utils 2.88dsf-13.10ubuntu11" [Low,Triaged] https://launchpad.net/bugs/1001904
<jtaylor> sreich: by filing a bug
<sreich> k
<jtaylor> sreich: debian experimental has pretty much the same clang version
<jtaylor> sreich: you can use reportbug -B debian clang
<sreich> wow, reporting a debian bug on a non-debian system is fun
<sreich> they use emails to create bug reports. like..seriously?
<sreich> what is this, 1980?
<jtaylor> I think its great
<jtaylor> the debian bug tracking system is the best I yet encountered
<sreich> seriously?
<sreich> why? to report a bug..you need to send an email?
<jtaylor> everybody has email
<sreich> everybody has bugzilla
<jtaylor> you usually need to register for that
<jtaylor> which requires email
<jtaylor> bts just skips this step
<sreich> yeah, but it's got a sane interface
<sreich> email is error prone
<sreich> and as mentioned, reportbug isn't on non-debian systems
<jtaylor> reportbug is just for convinience
<sreich> yeah, which you don't get on non-debian systems apparently ;)
<jtaylor> I usually just write an email with, Package: ... VErsion: .. bugtext
<sreich> hence my point about not using a bug management system seems silly
<sreich> i could understand having both, but just one?
<jtaylor> it is occasionally discussed to add a webinterface
<jtaylor> its usually rejected because its to easy to use :)
<sreich> heh
<jtaylor> "if someone is not able to write an email, the bug report will not be useful anyway"
<mlankhorst> but what if its a bug about thunderbird? ;)
<dtchen> is there another archive rebuild test running? I just attempted to reload a build log from the 0329 test, and it had disappeared. :)
<jtaylor> which package?
<dtchen> mysql-workbench, amd64
<sreich> jtaylor: not finding clang 3.2 in debian at all
<sreich> http://packages.debian.org/unstable/devel/
<jtaylor> dtchen: strange, the i386 log is still there though
<dtchen> sreich: looks like it's in experimental
<sreich> where can i view experimental?
<dtchen> jtaylor: yeah, I ended up using that one as a starting point. Thanks.
<jtaylor> sreich: the package trackign system has all information: http://packages.qa.debian.org/c/clang.html
<xnox> Anyone have any pointers as to where is the code that generates https://patches.ubuntu.com ?
<slangasek> bdmurray: right, thanks
<cjwatson> xnox: lp:merge-o-matic
<xnox> cjwatson: ok, didn't know it's the same =)
<stgraber> fauxww
<stgraber> chvt 7
<stgraber> chvt 8
<stgraber> 0~0~/valogXcd ..
<stgraber> cd ..
<stgraber> cd vanhoof Logan_
<stgraber> ls
<stgraber> cat xnox 0 | less
<xnox> stgraber: ?????
<stgraber> qconso
<stgraber> ubuntu
<stgraber> ubuntu
<stgraber> sudo -i
<stgraber> ubuntu
<stgraber> ps fauxww
<xnox> "Ctrl-Alt-t" | stgraber
<stgraber> cat /var/log/upstart/li
<stgraber> restart lightdm
<xnox> I take it stgraber is trying to recover his machine blind =)
<ogra_> lol, yeah, good guess
<xnox> ogra_: let's just wait for the sudo password =)
<ogra_> he obviously uses ubuntu/ubuntu :)
<xnox> ogra_: ha, true.
<Logan_> hahaha
<Logan_> this is quite amusing
<stgraber> oops ;)
<Logan_> btw, you need a stronger password
<xnox> stgraber: or is it focus-failing-to-follow-eyesight-error ?
<stgraber> xnox: nope, I'm reinstalling my laptop, running a bare Ubuntu server on it and running Ubuntu desktop inside an LXC container
<stgraber> I was at the setting up input devices step ;)
<ogra_> it worked !
<ogra_> :)
<stgraber> which apparently ended up working a bit too well as the X server running in a non-focused VT was still getting the keyboard input (apparently)
<stgraber> looks like a reboot fixed it though ;)
<xnox> stgraber: i can get a mouse pointer working on a VT sometimes......
 * xnox praises Intel graphics
<xnox> like a tty1 that is.
<stgraber> xnox: yeah, I had that and it's when that happens that you can get in the situation where what you type in tty1 ends up in both the tty and in your focused X window (in my case, irssi)
<stgraber> anyway, sorry for the spam, it hopefully won't happen again (will try to keep something else focused when doing my tests ;))
#ubuntu-devel 2013-04-21
<m4n1sh> can anyone sponsor this bugfix SRU https://code.launchpad.net/~zeitgeist/activity-log-manager/fix-bug-1058037/+merge/159896?
<ScottK> pitti: I would appreciate it if you could look at Bug #1171048 and tell me where I should re-assign it.
<ubottu> bug 1171048 in jockey (Ubuntu Raring) "Segfault during Broadcom STA wireless driver install in Kubuntu live session" [High,New] https://launchpad.net/bugs/1171048
<frodo_jeb> hi
<frodo_jeb> i want to customize ubuntu server iso (installation media) so i can installe some pakage by default so is there some tool i can use
<frodo_jeb> besides online distro maker
<siretart> frodo_jeb: the installation manual has a chapter for this. look for the appendix "preseeding"
<frodo_jeb> thanks but it seems like a kickstart installation
<tjaalton> frodo_jeb: drop a preseed file on the media
<tjaalton> uh, my raring laptop now forcibly shuts down instead of suspeding
<tjaalton> *suspending
<tjaalton> works fine on another laptop
<tjaalton> huh, had to remove the batteries.. works now
#ubuntu-devel 2014-04-14
<hallyn> infinity: debian-experimental has 2.0-rc1.  i'll do either -rc2 or final on monday, whatever is available.  (hoping for final, but not optimistic)
<pitti> Good morning
<hallyn> stgraber: for bug 1307008, i was wondering, should cgmanager/cgproxy stop on starting rcS, or on runlevel [06]?  Or something later yet than rcS?  Some services might want it around to shut down...
<ubottu> bug 1307008 in cgmanager (Ubuntu) "cgmanager doesn't stop on shutdown" [High,Confirmed] https://launchpad.net/bugs/1307008
 * hallyn leaves for the night on that note
<infinity> pitti: I know you don't work on this anymore, in theory, but you seem like the sort of person who would know.
<pitti> infinity: what's up?
<infinity> pitti: Any idea who/what is responsible for brightness keys working these days, and why the ones on my Thinkpad might have suddenly stopped working in the last few days?
<infinity> ... he says, testing and they now work...
<infinity> WTF. :(
<infinity> pitti: So, last night, brightness keys and (worse) lid-close didn't work.
<infinity> pitti: Seems that after manually suspending, it's "fixed".  That's not comforting.
<pitti> infinity: in general, those are both (gnome|unity)-settings-daemon
<pitti> infinity: for the brightness keys, X.org translates the evdev keys into XF* events, and (g|u)-s-d listens to them and calls xrandr to set the brightness
<infinity> pitti: And lid close?
<pitti> infinity: for suspend, -settings-daemon usually controls that as well; unless it's crashed, then logind takes over
<pitti> i. e. logind usually listens to the power button and lid close, so that this stuff works on a VT or in the DM; but settings-daemon tells it not to, and listens to those events by itself
<pitti> infinity: so it might be that settings-daemon has crashed for you, or got stuck somehow?
<infinity> So, lid-close and brightness working (and not) definitely seem to be tied together here, so I guess I get to hunt down what was broken last night and magically fixed after a suspend/resume...
<infinity> pitti: More disconcerting, it was after a fresh reboot, so it's not like I'd crashed g-s-d over weeks of hard use or something.
<infinity> Oh well.  Will experiment today, if I get a chance.
<pitti> infinity: if you are able to reproduce the behaviour, the first interesting question is whether it starts working again after re-starting u-s-d
<pitti> if so, we at least know the component (but then, harder to debug)
<infinity> lid-close not working is one of my least favourite failure modes... So many burned out motherboards and burned-through LCD panels. :/
<pitti> if it still fails after restarting, then we can restart it in the foreground with debugging enabled and see what's going on
<pitti> *ack*
<pitti> I don't test it very often, only when I'm travelling or working elsewhere
<pitti> but I had zero problems with it during last weeks' sprint or in Oakland in March, etc.
<pitti> infinity: the main big change that landed fairly recently is that logind now uses cgmanager for cgroup management
<infinity> pitti: Yeah, it's been working for me non-stop for a long time, until just last night.  So, colour me confused.
<infinity> I'll see if I can reproduce or if it was a one-off.
<pitti> infinity: that has caused a few crashes, hangs, and high CPU usage before it stabilized
<infinity> Not that the latter is any more reassuring, but... Meh.
<pitti> otherwise I'm not aware of big changes in the stack; I haven't followed the ubuntu-settings-daemon story, though
<pitti> infinity: err, unity-settings-daemon
<pitti> infinity: hm, I don't see something obvious at https://launchpad.net/ubuntu/+source/unity-settings-daemon/+changelog which could be the cause
<infinity> pitti: My unity-settings-daemon also seems to be the same age as the rest of my session (ie: no indication that it crashed and restarted)
<infinity> pitti: So, why I had to manually suspend last night, and it works this morning (under the same session) is a wonderful mystery.
<pitti> infinity: indeed; it's not like suspend ought to magically restart services or so
 * infinity needs to eat before caring more about this.
<infinity> pitti: Well, suspend invokes gnome-screensaver and other things, so could accidentally trigger restarting problematic helper services.
<infinity> pitti: But I don't see any evidence of that at first glance.  PIDs all look to be from yesterday.
<dholbach> good morning
<pitti> hey dholbach, wie gehts?
<dholbach> hey pitti - sehr gut - und dir?
<dholbach> pitti, HAPPY BIRTHDAY! :)
<pitti> dholbach: prima, danke!
<pitti> dholbach: yay, thanks!
 * pitti is munching a wonderful rhubarb cake that my wife made me *yummy*
<mvo> pitti: good morning! I got a bugreport that gdebi has no translations in 14.04, is it possible that they are still stripped out even though they are no longer part of the language pack?
<pitti> mvo: hm, that's a bit odd; the source is in main, the binaries are in universe; I need to check more closely
<mvo> pitti: gdebi-core is a dependency of packagekit (aptcc) iirc
<pitti> mvo: indeed, no trace of gdebi in the current LP export; I wouldn't know why that is
<mvo> pitti: oh, so its supposed to be there but it is not? should I file a bug? aganst LP ?
<pitti> so https://launchpadlibrarian.net/172212731/buildlog_ubuntu-trusty-i386.gdebi_0.9.5.3_UPLOADING.txt.gz does build a translation tarball
<pitti> 328949 bytes, so it's not empty or so
<pitti> mvo: but https://translations.launchpad.net/ubuntu/trusty/+source/gdebi is empty
<pitti> mvo: it's odd that this never got imported -- it's an old package; or did you just recently add i18n?
<mvo> pitti: it has i18n since ~2005 or so :)
<pitti> mvo: so someone with the necessary privs (dpm, wgrant?) needs to do some clickery on https://translations.launchpad.net/ubuntu/trusty/+source/gdebi/+imports
<mvo> pitti: but it recently got moved some main to universe or something
<mvo> pitti: oh, so that is whats missing? a approval?
<pitti> yeah; but I can't do that
<mvo> pitti: ok, thanks a lot for finding the root cause - I guess its too late for -final, but we can get updates in the first update?
<pitti> mvo: yes, indeed; they'll show up in the autogenerated update packs in teh langpack PPA too, and I expect we'll do an "official" update for .1 at the latest (maybe before if there's enough interest in testing them)
<zyga> pitti, mvo: good morning :-)
<mvo> hey zyga
<zyga> mvo: hey, it's somewhat a sad story, ever since you left I let c-n-f bitrot as I didn't know how to upload it nor wanted to maintain @home infrastructure to scan the archive all the time
<zyga> mvo: but with some new debian proposals (not debtags, the other thing) it might be possible to rewrite c-n-f to be 100% accurate by 14.10
<zyga> mvo: could you help me througout the cycle to understand how to be able to upload a package to ubuntu?
<mvo> zyga: no worries - the important one we need to solve is commands that get generated via update-alternatives in the postinst, if that could be marked via some meta-data we should be good
<zyga> mvo: (or alternatively, cnf could move to debian, which I already know how to work with)
<zyga> mvo: right, and exactly that meta-data can now be expressed and will be processed by the archive system (so the user needs to download one per-archive file and it's good to go)
 * zyga googles for that DEP
<mvo> zyga: yeah, totally. I scriped it on one of the ubuntu servers now (the data extraction) and we should simply make this a proper public service - unless we can simply use this DEP which would just be perfect :)
<Noskcaj> Can i merge (or SRU) ball, since it will fix the ftbfs
<zyga> mvo: DEP-11
<zyga> mvo: https://wiki.debian.org/DEP-11
<zyga> mvo: 'Type-Name: exec', packages could then have meta-data like exec<nano>, exec<vim>, ec
<zyga> mvo: I think that a hybrid approach would be best, for packages that have DEP-11 annotation it takes over entirely (for the source whole package), otherwise the guesstractor is used as today
<mvo> zyga: yeah
<zyga> mvo: if you look at "Location in the Archive" part you will see a standardized location where compressed component (e.g. exec) indices are to be made available
<mlankhorst> infinity: hey can I pull the fix for https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1306897 into the mesa package too?
<ubottu> Launchpad bug 1306897 in mesa (Ubuntu) "xbmc with vdpau crashes on stop" [Undecided,Confirmed]
<infinity> mlankhorst: Is it reviewed/committed upstream, or just a random patch floating on a mailing list?
<wgrant> xnox: https://pastebin.canonical.com/108412/
<mlankhorst> it's committed upstream
<mlankhorst> and cc'd stable
<infinity> mlankhorst: Shiny.
<infinity> mlankhorst: In thta case, go for it.  Be quick like a bunny.
<mlankhorst> already copied to the 10.1 branch it seems
<mlankhorst> http://cgit.freedesktop.org/mesa/mesa/commit/?h=10.1&id=48fe4c80b356c9d3ca77ec170414ee8df80e6f60
<seb128> do we have anyone looking to libav issues in Ubuntu?
<Laney> siretart?
<seb128> bug #1288206 could do with somebody looking at it
<ubottu> bug 1288206 in libav (Ubuntu) "vlc crashed with SIGSEGV in memcpy()" [High,Confirmed] https://launchpad.net/bugs/1288206
<seb128> the Debian bug is closed saying it's a libav issue happening with libav9 only (and not 8 or 10)
<seb128> siretart, ^ is there any chance you could look if there is a bugfix we can backport there?
<seb128> that's one of the most reported issues on e.u.c
<infinity> Weird, I never see that.  I must be lucky.
<infinity> I'm okay with being lucky for once.
<seb128> infinity, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741240#40
<ubottu> Debian bug 741240 in libavcodec54 "vlc segfaults while playing MKV files" [Important,Open]
<seb128> infinity, you maybe use that option?
<seb128> infinity, or maybe you don't play mkv files (those seem to be the ones hitting the bug (or most often doing at least)
<infinity> seb128: Well, I don't use vlc, but I do use libav...
<seb128> oh ok
<seb128> well maybe you don't exerce the codepaths in it that have that issue
<infinity> mlankhorst: No mesa for me?
<bdrung_work> hi, which package is responsible for bringing up the network on boot?
<pitti> bdrung_work: ifupdown (for /etc/network/interfaces), and NetworkManager for everything else
<bdrung_work> it's a server, so no network-manager
<pitti> ifupdown then
<bdrung_work> pitti, on a new install, i get 'waiting up to 60 more seconds for network configuration' message from plymouth
<bdrung_work> i get the same message on an old install, but it just continues to boot
<bdrung_work> (both 12.04 systems)
<pitti> well, everything which triggers on net-device-up or similar won't start; everything which doesn't need network should start
<bdrung_work> /etc/network/interfaces have the same content and both system have one network device
<pitti> that is, if your /e/n/i defines an interface which doesn't come up (not connected or so)
<bdrung_work> one devices comes up, but not additionally defined ones
<bdrung_work> on the old install, the boot continues (including showing the tty for log in), but not on a new installation
<bdrung_work> but maybe the real problem is that auto-hotplug does not work at all (neither on 12.04, 13.10, nor 14.04)
<bdrung_work> ups, i meant allow-hotplug
<pitti> yes, /etc/init.d/networking seems to handle this, but not our upstart jobs
<pitti> but this should only do additional things, so that still doesn't explain the hang
<pitti> ifup -a ought to ignore these
<mlankhorst> infinity: hm tjaalton did an upload I think, I'll wait with the fix for 10.1.1 sru :P
<tjaalton> I didn't upload this patch
<kdeuser56_> pitti: are dbgsym for http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<pitti> kdeuser56_: apparently not
<kdeuser56_> pitti: why do some dbgsym depend on dbg?
<pitti> the kernel source itself should build these, but apparently not for the mainline ones
<pitti> kdeuser56_: for those src packages which already build a -dbg we just generate empty -dbgsym packages that depend on these, to avoid duplicating the symbols
<kdeuser56_> pitti: thats pretty bad in some cases as some -dbg install unnecessary packages ...
<pitti> kdeuser56_: i. e. we only really build -dbgsyms for sources which don't have a -dbg, but for getting one consistent workflow folks asked for these empty "pointer" -dbgsyms
<pitti> if these deps are required for debugging, it seems fine; if they are unnecessary, that shoudl be fixed of course
<pitti> we don't really notice, as it's certainly not recommended to install many -dbgsym on a "real" system
<kdeuser56_> pitti: so generally I could simply install -dbgsym as they will install dbg anyway
<infinity> mlankhorst: If you'd prefer to wait for an SRU, that works for me.
<kdeuser56_> pitti: muon-dbg and muon-dbgsym should conflict right?
<pitti> kdeuser56_: not "Conflicts:" in the dpkg sense; myon-dbgsym should just Depends: muon-dbg and otherwise be empty
<pitti> (except changelog etc.)
<kdeuser56_> pitti: ah then the wiki should be updated as it says dbg and dbgsym cannot be installed at the same time
<mlankhorst> infinity: yeah should be ok, no need to push it 3 days before a release :P
<kdeuser56_> pitti: which is what it used to be right?
<pitti> kdeuser56_: yes, indeed; that got changed perhaps a year or so ago
<kdeuser56_> pitti: libmagickcore5-extra-dbgsym installs imagemagick-dbg which installs imagemagick which I do not want to be installed, as I only need the library.
<kdeuser56_> pitti: if dbgsym would be as they used to be in the old times it would work much better in many cases
<bdrung_work> pitti, Debian does this in their init script: "if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose"
<kdeuser56_> pitti: or for example: plasma-dataengines-addons-dbgsym installs "plasma-runners-addons plasma-wallpapers-addons plasma-widget-lancelot kde-wallpapers"
<pitti> bdrung_work: right, that led me to believe that ifup -a should ignore the auto-hotplug ones
<bdrung_work> pitti, where is ifup -a called?
<pitti> bdrung_work: in /etc/init/networking.conf
<kdeuser56_> pitti: kde-wallpapers are just wallpapers,  they are not needed for debugging ... if dbgsym would be generated independently from dbg those issues would not arise
<pitti> kdeuser56_: yes, I know; that's what we did in the past, but they take an awful lot of space, so this was a way to reduce that quite a bit
<kdeuser56_> pitti: why not going away from -dbg and only create automatic dbgsym?
<pitti> kdeuser56_: that's a good plan, but as long as we inherit all those -dbg from Debian we need to deal with them
<kdeuser56_> pitti: why is it difficult to not inherit the -dbg packages?
<bdrung_work> pitti, yes, the hotplugged ones probably should come up when they are plugged in
<bdrung_work> but they do not
<bdrung_work> /etc/init/network-interface.conf does not bring them up
<pitti> kdeuser56_: we could probably mangle our dpkg tools to ignore them unless they are python-* ones or so, but that'd be quite an ugly hack; it hasn't really been discussed so far
<kdeuser56_> pitti: but the current situation is not pretty either if you ask me
<pitti> kdeuser56_: certainly not pretty, but good enough; at least nobody has complained in a long time :)
<kdeuser56_> pitti: dbg often contain stuff not needed to debug only the package you installed the dbgsym of
<pitti> apport-retrace surely unpacks more stuff than it needs to into its sandboxes
<kdeuser56_> pitti: and the dbg packages pull in so much unencessary stuff
<pitti> the wallpaper one is really more like the exception; most -dbg packages are just fine
<pitti> of course many/all pull in the corresponding application, but that's fine
<kdeuser56_> pitti: not if you only need a tiny library and it pulls in big programmes
<kdeuser56_> pitti: call me crazy but I installed dbgsym for all installed packages and encountered many packages which were installed despite being not needed for debugging
<kdeuser56_> pitti: I know its NOT recommended :-)
<pitti> heh yes, they are certainly not designed with that in mind
<kdeuser56_> pitti: okay lets keep it short: do you think something will change with that in the near future?
<pitti> kdeuser56_: I doubt it TBH; if we'll change it in any way, then probably by going the full route to build IDs and stop having -dbg or -dbgsym packages altogether
<pitti> but that's quite a lot of work, and for relatively little gain, so someone who wants to do it and has time for it needs to pick that up
<pitti> (i. e. I probably won't soon)
<kdeuser56_> pitti: thanks for your support!
<kdeuser56_> pitti: btw: you said if someone wants to work on it: is there really opportunity for a non-canonical employee to change something in this regard?
<pitti> it doesn't need anything canonical specific (except for putting into production and running it on ddebs.u.c.)
<pitti> but designing and implementing a new system doesn't need any particular privileges
<kdeuser56_> pitti: https://bugs.launchpad.net/software-properties/+bug/1307170 look at  #7-#10 despite having all dbgsym of all packages installed gdb reports missing info
<ubottu> Launchpad bug 1307170 in Software Properties "/usr/bin/software-properties-kde crashed when triggering mirror selection and clicking ok quickly" [Undecided,New]
<kdeuser56_> pitti: any idea how this can be?
<pitti> kdeuser56_: python*-dbg are special; I think you need to run them with the corresponding e. g. python3.4-dbg interpreter to make full use of them
<pitti> python-*-dbg isn't just gdb debug symbols, it's also extensions built in a "debug way" (I don't know the details)
<shadeslayer> chrisccoulson: can you upload the patch mentioned in bug 1294666
<ubottu> bug 1294666 in xserver-xorg-video-intel (Ubuntu) "[HSW mesa kde needs Xorg-1.15.1] Multiple tiling-esque artifacts in KDE" [High,Fix committed] https://launchpad.net/bugs/1294666
<shadeslayer> i.e. patch the package and upload it
<kdeuser56_> pitti: I have installed all dbg packages too
<shadeslayer> I most certainly don't have upload rights for xserver-xorg-video-intel :P
<kdeuser56_> pitti: it did not change anything ... right now the siutation looks like this: of all packages name-dbg is installed and name-dbgsym is installed
<kdeuser56_> pitti: in theory that should be enough right?
<pitti> kdeuser56_: yes; however, that's just a theory; I still often see situations where gdb isn't able to figure out symbols for everything
<pitti> it's the nature of crashes -- corrupted/invalid pointers, corrupted stack, etc.
<pitti> or, more importantly, optimization
<kdeuser56_> pitti: this crash can be reproduced every time
<kdeuser56_> pitti: *almost
<shadeslayer> oh
<shadeslayer> chrisccoulson: sorry, wrong ping :(
<cjwatson> I dealt with a crash just on Friday that was reproducible every time but resulted in a consistently corrupted stack.  It happens.
<cjwatson> Corrupted-stack isn't necessarily an unreliable symptom.
<kdeuser56_> oh okay
<kdeuser56_> thanks very much for your great support!
<bdrung_work> pitti, i filed bug #1307429
<ubottu> bug 1307429 in ifupdown (Ubuntu) "Existing allow-hotplug devices do not come up" [Undecided,New] https://launchpad.net/bugs/1307429
<rbasak> cjwatson: could you take a look at bug 1306877 please?
<ubottu> bug 1306877 in openssh (Ubuntu) "sshd stops accepting new connections after configuration reload" [Critical,Triaged] https://launchpad.net/bugs/1306877
<rbasak> It seems to me that this should be a regular pattern for "expect stop" if this is what upstart expects.
<rbasak> (I've attached a patch)
<cjwatson> Thanks, I'll look shortly
<cjwatson> rbasak: looks good thanks, building a Debian upload
<om26er_> Hi! whenever I login I see apport crash window on my screen, why don't we disable that for the release ?
<pitti> om26er_: it seems we want crash reports for stables to go to errors.ubuntu.com
<pitti> om26er_: so we only disable submission to LP, not to errors
<om26er_> pitti, I see a stack of atleast 3 apport windows one above the other every boot, I have cleared /var/crash and now rebooting to report bugs from the new crashers
<om26er_> brb
<seb128> I though we had put code in place to avoid greeting users at login with apport prompts
 * seb128 looks through apport changelog entries, not sure I remember correctly
<seb128> we should do that if we didn't ;-)
<pitti> we actually do
<pitti> seb128: well, we have code to suppress crashes which happen at session logout and from previous sessions
<pitti> it could still be that stuff actually crashes during login
<seb128> pitti, I wonder if not prompting for "<n> minutes" after login would helps in the user perception
<seb128> pitti, I find it myself annoying to have prompt open on screen before unity is ever loaded
<seb128> it's like first thing you see in those case is a system error dialog
<om26er> pitti seb128 , interestingly now that I cleared /var/crash the dialog never appeared, I have been seeing that dialog for a long time on every boot
<pitti> yeah, indeed; I haven't had these in a long time, so didn't notice either
<om26er> and would always cancel it
<seb128> om26er, that's because you always cancel that they never cleared
<seb128> om26er, if you had reported them they would have been flagged as handled and it would have stopped nagging you
<om26er> seb128, as a user I would expect it to not keep bugging me till I report it, i'll report a bug for that.
<seb128> I would be surprised if there were not reports about that already
<seb128> could somebody build retry https://launchpad.net/~ci-train-ppa-service/+archive/landing-008/+build/5908000
<seb128> ?
<cjwatson> seb128: done
<seb128> cjwatson, thanks
<stgraber> hallyn: "stop on runlevel [06]" should do it I guess
<hallyn> stgraber: so long as noone puts cgm commands in post-stop jobs
<hallyn> jodh: ^ you haven't suggested that anywhere?
<jodh> hallyn: missing context - irlogs is 3 hours out of date :)
<jodh> hallyn: *irclogs
<stgraber> jodh: cgmanager currently doesn't have a stop on stanza
<stgraber> jodh: we need one but we're not sure what's appropriate as anything can use cgmanager...
<stgraber> jodh: we need to have it happen after lxc and systemd-logind are done but before we reach the umount
<hallyn> infinity: ok i guess we expect 2.0.0-rc3 today, but not a -final.
<smb> xnox, cjwatson Just to check, do you know about "error: diskfilter writes are not supported"? I am getting that message after a 64bit server install from this mornings iso. Although it says enter to continue it seems to proceed without that and boot seems to go on ok.
<cjwatson> smb: Yes, that happens if your /boot is on something GRUB can't write to directly, like LVM or RAID.  Well-known.
<cjwatson> smb: As for the message glitch, see https://lists.gnu.org/archive/html/grub-devel/2014-04/msg00028.html and thread.
<smb> cjwatson, Ok, so lvm in my case. Hm, thought I had that setup before...
<smb> Oh, actually no... for those I end up using bad blocklists but real (extended) partitions. So it would not happen there
<infinity> hallyn: Alright, then probably not rush to try to shove something in pre-release.
<hallyn> infinity: 2.0 *should* be this week,
<hallyn> so i'll push that for a 0-day sru?
<infinity> hallyn: Right, and as much as I'd love that in release, if 2.0 doesn't get in the release pocket, I don't care which RC is there. :P
<hallyn> ok
<infinity> hallyn: I fully expect us to SRU to 2.0 final regardless.
<smb> infinity, So what do you think of Xen + arm64? Unfortunately my test compile seems to have hit something that broke the porter (do you want any of the pieces?)
<infinity> smb: I'm not much interested in shedir being sad.  As long as the arm64 build seemed okay.  Maybe I should throw it at a devirt PPA quickly.
<smb> infinity, Would be ok with me. I think it should be ok in general, the arm64 was ok and the x86 compiles still seemed to be what I think they should. So it mostly should fly...
<smb> infinity, I put a debdiff there as well, so you can have a quick glance on what I did
<smb> ppisati, Do you want to check on that machine or shall I just ask it to be rebooted?
<ppisati> smb: do you have a stack trace?
<smb> ppisati, yes
<jdstrand> mvo_: hey, if I declare in foo, Breaks: bar (<< 1.1), in a massive upgrade from say 12.04 to 14.04, can I expect that it is properly honored? there is some question about apt breaking things in to chunks such that it is possible that bar is upgraded and configured in an earlier chunk and foo in a later chunk
<ogra_> pitti, hey, happy birthday !
<jdstrand> mvo_: my interpretation of 7.3 of debian policy would suggest that if it did break things in to chunks as described, then that is a bug in apt
<pitti> thanks ogra_!
<jdstrand> pitti: happy birthday :)
<pitti> jdstrand: cheers!
<stgraber> mvo_: specifically the case here is lxc and apparmor in trusty. The new apparmor defines a break on the old lxc, lxc itself currently doesn't version depend on apparmor (just plain depend).
<josepht> Happy Birthday pitti!
<stgraber> mvo_: in my understanding, on complex upgrades, it's perfectly possible and allowed for apt to first upgrade lxc on its own in a first run, then upgrade apparmor on its own in the second as that'd respect the apparmor Breaks (new lxc is already there) and since lxc doesn't version-depend on apparmor, it'd be fine too
<stgraber> mvo_: (I have now uploaded lxc with a version dependency on the new apparmor to fix the problem but jdstrand isn't convinced this should be necessary)
<jdstrand> actually, I'm not saying it isn't necessary-- it might be, I'm saying it shouldn't be necessary
<jdstrand> ie, apt shoudl allow lxc and apparmor to upgrade in different chunks
<jdstrand> err shouldn't*
<mvo_> jdstrand: I haven't looked at the exact dependency relations of lxc and apparmor, but what stgraber said is true, apt may break the upgrade into chunks that consist of valid dpkg states, so if the new foo breaks on a old bar, apt may upgrade bar first and then later upgrade foo
<mvo_> jdstrand: do you have a bug reference with the real world issue?
<stgraber> mvo_: bug 1307008
<ubottu> bug 1307008 in cgmanager (Ubuntu) "cgmanager doesn't stop on shutdown" [High,Confirmed] https://launchpad.net/bugs/1307008
<stgraber> oops, wrong one
<stgraber> one sec
<stgraber> mvo_: bug 1304167
<ubottu> bug 1304167 in lxc (Ubuntu) "syntax error, trusty beta-2 cloud image" [High,Triaged] https://launchpad.net/bugs/1304167
<stgraber> that one :)
<stgraber> mvo_: this one isn't a dist-upgrade but someone who apparently got an older image (beta2) ran an apt-get update and then installed lxc which broke
<stgraber> mvo_: it's while fixing this that I figured we may see it as well during lts to lts and mentioned this to jdstrand
<mvo_> stgraber: thanks! this looks indeed like lxc should have a version dependency on apparmor if it has a ruleset that uses new syntax
<stgraber> jdstrand: so lxc is fixed (in the queue), hallyn is looking at libvirt now (which also calls the parser from postinst), it looks like lightdm may need fixing too and I don't know about easyprof. Can you take care of those last two?
<stgraber> if they do have the same, calling the parser from postinst problem that is
<jdstrand> sigh
<jdstrand> I specifically asked about this before and was told the Breaks was enough
<jdstrand> mvo_: surely the intent of the Breaks is for it to work in more than just small upgrades?
<jdstrand> mvo_: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks doesn't say anything about chunks, etc. I realize one could argue that apt is doing things ok because each chunk is consistent with itself, but taken as a whole, they are not
<Meerkat> I'm compiling a package used in xubuntu but I keep running into missing dependencies. Is there a collection package of the most common source packages for xubuntu/xfce?
<cjwatson> jdstrand: The behaviour you're describing is precisely aligned with my expectations of Breaks
<mvo_> jdstrand: sorry for your frustration, but this is version depends is needed for correctness anyway. if e.g. old apparmor is installed and the user only runs apt-get install lxc the postinst will also break because apt does not know that the new lxc also requires it to upgrade apparmor. all it knows is that the new apparmor will break on older lxc
<cjwatson> jdstrand: All that foo Breaks: bar (<< 1.1) says is that (foo unpacked) and (bar << 1.1 in a configured state) can't coexist
<infinity> jtaylor: Why did you sync the lz4 from Debian with the SOVER bump?
<jdstrand> fyi, apparmor-easyprof-ubuntu already has that Depends
<bdrung_work> stgraber, i responded to bug #1307429
<ubottu> bug 1307429 in ifupdown (Ubuntu) "Existing allow-hotplug devices do not come up" [Wishlist,Triaged] https://launchpad.net/bugs/1307429
<stgraber> bdrung_work: indeed you're right, though it's been that way for over 3 years now, so not in need of an urgent fix
<bdrung_work> stgraber, no urgent pre-release fix, but i like to get it fixed in a SRU
<stgraber> bdrung_work: ok, I'll get that fixed in 13.10 then we can sru
<bdrung_work> stgraber, the proposed fix is derived from the Debian init script behavior
<bdrung_work> stgraber, 13.10 or did you mean 14.10?
<shadeslayer> cjwatson: ping
<cjwatson> hi
<shadeslayer> cjwatson: I was looking at bug 1182784 , and noticed that /usr/lib/ubiquity/console-setup/kbdnames.gz has both "Switzerland" and "Switserland"
<ubottu> bug 1182784 in ubiquity (Ubuntu) "Install with German / Swiss Keyboard fails: "ubi-console-setup failed with exit code 141" or "Installer Crashed"" [High,Confirmed] https://launchpad.net/bugs/1182784
<shadeslayer> is that intended?
<shadeslayer> cjwatson: http://paste.ubuntu.com/7250441/
<cjwatson> shadeslayer: that looks like a translation
<shadeslayer> oh hm
<cjwatson> shadeslayer: specifically to af == Afrikaans
<shadeslayer> cjwatson: thx
<shadeslayer> cjwatson: this is what I see in the debuglog http://paste.ubuntu.com/7250467/
<cjwatson> shadeslayer: I think those are meant to look up untranslated names, but I don't recall just now
<shadeslayer> ok
<kdeuser56> pitti: would you accept a patch to apport that would introduce a new config option to include the timestamp in the crash files?
<stgraber> bdrung_work: meant 14.10 :)
<stgraber> jdstrand: ok, so we need lightdm and libvirt then
<bdrung_work> stgraber, okay. i can do the upload myself. i just want someone to have a look at my patch before the upload.
<stgraber> jdstrand: actually, libvirt is in now, so just lightdm. I'll get that one done real quick.
<jdstrand> stgraber: actually, lightdm doesn't run apparmor_parser in its postinst
<jdstrand> which is probably a bug in and of itself, but it won't be affected by this
<stgraber> jdstrand: oh yeah indeed, I did a quick grep earlier but that was the freerdp plugin matching, not lightdm itself
<stgraber> jdstrand: so lightdm-remote-session-freerdp will call apparmor_parser from postinst against the lightdm-remote-session-freerdp profile which loads the lightdm abstraction which uses signal
<stgraber> jdstrand: however it does so using || true so it won't fail
<jtaylor> infinity: see the ffe, I'll do the redep today
<infinity> jtaylor: We're already doing it for you.
<infinity> jtaylor: Because $reasons.
<infinity> jtaylor: So don't worry about it.
<jtaylor> I want a bugfix release in so I will worry
<jtaylor> I know its kind of late, but the impact on the archive is small, universe unseeded very few rdeps
<infinity> jtaylor: I meant don't worry about doing the transition cause we're on it.
<jtaylor> its a one package transition
<jtaylor> or did I overlook something?
<infinity> jtaylor: Yeah, it is.
<infinity> jtaylor: But we're on it, because we were fixing the ppc64el ftbfs.
<infinity> jtaylor: Unless you had a pytables upload to do while you're at it?
<jtaylor> of pytables?
<jtaylor> I wanted to upload pytables within a few hours
<jtaylor> but I'm not fixing ppc64
<infinity> jtaylor: Like, a new version you mean?
<infinity> jtaylor: Or just a rebuild?
<jtaylor> yes 3.1.1
<infinity> Ahh, upload away.
<infinity> jtaylor: The ppc64el FTBFS is fixed via wgrant's earlier lz4 upload.
<infinity> jtaylor: So, yeah, do your thing.
<jtaylor> oh nice
<cjwatson> could we retry pytables now in advance of that upload then?
<wgrant> It should work
<jtaylor> sure I'm just test building the new upload, that will take a while, my machine is not the fastest
 * cjwatson retries then
<wgrant> But I wasn't going to bother, since there's going to be a rebuild shortly anyway
<wgrant> And it takes forever.
<jtaylor> yes its a slow build
<cjwatson> shrug.  somebody can cancel if they want
<wgrant> jtaylor: it builds fine against the new lz4 on both amd64 and ppc64el
<cjwatson> oh, hah, retried the wrong version anyway
 * cjwatson leaves alone
<jtaylor> cjwatson: your lvm snapshot grub fix works for me too, thanks
<jtaylor> though for some reason grub-mount does not die
<jtaylor> and blocks removing the snapshot
<jtaylor> I guess that could cause issues when upgrading?
<cjwatson> Not sure, it's possible that's os-prober's fault
<cjwatson> finishing up for today now though ...
<jtaylor> grub-mount /dev/mapper/lvm-dbbackup /var/lib/os-prober/mount is hanging
<jtaylor> where dbbackup is the snapshot
<cjwatson> jtaylor: does it go away if you just "umount /var/lib/os-prober/mount"?
<jtaylor> not mounted
<cjwatson> mkay, will try to have a look tomorrow
<Mirv> xnox: did you succeed in wiping a USB stick with the latest usb-creator version you uploaded? I'm getting bug #1307622
<ubottu> bug 1307622 in usb-creator (Ubuntu) "Error trying to empty a USB stick: 'NoneType' object has no attribute 'get_cached_property'" [Undecided,New] https://launchpad.net/bugs/1307622
<xnox> Mirv: sticks with no partition table, or GPT partition table do not work.
<xnox> Mirv: sticks with an MBR/bios partition table are wipable and installable.
<Mirv> xnox: oh, right, so those were remaining bugs. the case of no partition table here. I'll mark as duplicate.
<Mirv> and the previous time I had partition table
<xnox> Mirv: i have fixed wiping in last upload...
<xnox> Mirv: before last upload it would just fail in trusty.
<Mirv> right. I had it working in February according to logs.
<Mirv> with old style partition table I get 'gi._glib.GError: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error synchronizing after initial wipe: Timed out waiting for object' instead, but still fails
<Mirv> ...which is the bug #1294877
<ubottu> bug 1294877 in usb-creator (Ubuntu) "usb-creator fails to wipe usb device" [High,Confirmed] https://launchpad.net/bugs/1294877
<chowder> I know that this channel isn't meant as the place to ask questions but if there are developers here I figure that I'll more likely get my question answered. http://paste.ubuntu.com/7250828/   http://paste.ubuntu.com/7250837/
<ogra_> xnox, hmm, are you sure your seed change is correct ? i just had an image build explode in my face (and all landings for touch need special approval)
<xnox> ogra_: ubuntu-desktop is not installed on ubuntu-touch.
<xnox> ogra_: thus which change are you talking about?
<ogra_> xnox, oh, sorry
<ogra_> i mixed that up
<xnox> ogra_: also my change is only in -proposed, and thus does not affect image builds yet at all.
<ogra_> our meta is uninstallable atm
<xnox> ogra_: well, check why or point to logs.
<Mirv> xnox: right, I needed to ext4 -> vfat and now it works. I summed up to https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1294877/comments/6
<ubottu> Launchpad bug 1294877 in usb-creator (Ubuntu) "usb-creator fails to wipe usb device when the device has ext4 partition" [High,Confirmed]
<ogra_> http://paste.ubuntu.com/7250937/
<xnox> Mirv: thanks.
<Mirv> luckily 90%+ of USB sticks probably are vfat
<xnox> Mirv: yeah, in common case it should work....
<jtaylor> wgrant: new pytables uploaded
<jtaylor> thanks for fixing ppy64, did you already forward the fix?
<jtaylor> had to fix my adtrunner for it :( lets see if adt-run can deal with two levels of local dependencies :)
<wgrant> jtaylor: I haven't had time to forward the lz4 fix today, feel free if you want. Otherwise I'll get to it later.
<jtaylor> probably better if you do it, I can't answer followup questions
<jtaylor> btw somebody else forwarded your numpy ppc64el patch to numpy
<jtaylor> I merged it upstream, though I'm still wondering if the cython test failure is related to the patch
<jtaylor> but it doesn't seem to happen in the distribution the forwarder was using
<jtaylor> forgot which one (maybe fedora?)
<infinity> jtaylor: The cython test failure is fixed now, isn't it?
<jtaylor> is it? last I heard it was ignored
<jtaylor> what was the cause?
<infinity> jtaylor: A glibc bug.  We just passed the testsuite here, reuploading with it enabled again.
<jtaylor> ok great, thanks
<infinity> jtaylor: Fixed in a commit from Alan Modra with the hugely informative commit message of "sysdeps/powerpc/powerpc64/fpu/s_copysign.S: Don't trash stack."
<jtaylor> :)
<jtaylor> and no test associated :/
<jtaylor> or was glibcs own testsuite already failing?
<wgrant> jtaylor: The cython and numpy segfaults were both that eglibc bug
<wgrant> I found it last week, and it turned out it was already fixed upstream a week earlier.
<wgrant> I'm currently uploading a cython with the test reenabled.
<jtaylor> cythons testsuite needs to be sparsed a bit, its no fun working on it if it builds for 1.5 hours :/
<infinity> Real men maintain packages that take half a day to build.
<wgrant> Only half a day?
<wgrant> But yes, that's why I hadn't uploaded it yet :)
<jtaylor> maybe one could propose a convention for DEB_BUILD_OPTIONS, e.g. fastcheck to run some tests but not all
<jtaylor> many upstreams do something like that anyway
<infinity> jtaylor: DEB_BUILD_OPTIONS="quickie"?
<jtaylor> pitti: there seems to be an issue with the armhf adt
<jtaylor> it tried to build pytables before the archive has finished
<jtaylor> https://jenkins.qa.ubuntu.com/job/trusty-adt-pytables-armhf/13/ armhf is not yet done
<slangasek> infinity, pitti: #ubuntu-meeting?
<dobey> slangasek, infinity: would one of you mind rejecting the ubuntuone-storage-protocol in saucy-proposed unapproved queue? just found out the patch needs more work, after i did all the packaging work :-/
<slangasek> dobey: done
<dobey> slangasek: thanks
<Wellark_> hi! I'm been working at Canonical for 2,5 years now and I'm wondering should I apply for Ubuntu Membership through the Ubuntu Membership Board or the Ubuntu Developer Membership Board..
<Wellark_> I've worked on various components including the HUD, Unity Action API, greeter remote desktop support, Qt..
<Wellark> and currently on unity8 indicator-network and general connectivity
<hallyn> bdmurray: arges: hi, I uploaded a libvirt for lucid-proposed;  however I can't get libvirt to actually work under the conditiosn where it would break without the update;  so i think i'd like that rejected
<hallyn> (for bug 579584)
<ubottu> bug 579584 in libvirt (Ubuntu Lucid) "setgid, setuid needed by /etc/apparmor.d/abstractions/libvirt-qemu" [Undecided,Confirmed] https://launchpad.net/bugs/579584
 * hallyn feels he's wasted his time here
<arges> hallyn: looking
<arges> hallyn: so you'd like me to reject 0.7.5-5ubuntu27.25 ?
<hallyn> arges: yeah, thanks.
<bdmurray> Wellark: for ubuntu membership that would be the ubuntu membership board. the development membership board is for being an ubuntu developer
<hallyn> i've marked the bug invalid for lucid.
<arges> hallyn: done
<hallyn> arges: thanks!
<Wellark> bdmurray: and the difference being? From the names I would guess Ubuntu Developer might be the more approriate, no? I understood from the Membership wiki page that in the end I would gain the Ubuntu Membership. Ubuntu Developers have more permissions etc. at launchpad, maybe?
<dobey> Wellark: Ubuntu Developer is for uploading packages to the archive
<Wellark> oh, like direct uploads?
<dobey> yes
<Wellark> I have no need for such power
<dobey> and you'd need a history of sponsored uploads, and/or being a debian developer, to get it :)
<Laney> the DMB can grant membership too
<Laney> such folk are called "Ubuntu Contributing Developers"
<Laney> it doesn't happen very much, and is usually for people that have worked on packaging and such things
<Laney> But it is a thing that exists
<Wellark> however I do oversee couple of projects in LP for example where I'm unable to set the ubuntu specific bug statuses to Triaged just because I'm not a member of Ubuntu Developers
<dobey> but not terribly more useful than just the normal ubuntu membership, unless you're trying to get upload privs for a specific package or such
<Wellark> which is highly irritating :)
<Laney> It isn't more
<Laney> Unrelated to upload rights
<Laney> It's for membership if your contributions are in the area of ubuntu development
<Laney> ~packaging
<Wellark> well, we don't do direct uploads anymore for any of the projects I'm overseeing
<dobey> sure
<Wellark> we have the CI train and jenkins before
<Laney> I think a regional membership board application would be easier for you
<dobey> Wellark: actually, unity-team probably needs to be added to ubuntu-bug-control or something
<Laney> as for triaging, you (or a team) can join the bug squad to get that (see their documentation)
<Laney> I mean bug control
<Wellark> dobey: that would be great and probably highly relevant
<Wellark> + I would still like to apply for Ubuntu Membership through some channel
<dobey> right, like laney said, regional membership might be the way to go for you
<Wellark> Laney, dobey: could we get unity-team added to that bug control team?
<Wellark> and also unity-api-team should be added to unity-team
<Wellark> it already has unity-ui-team
<Wellark> -api is the other half :)
<Laney> Wellark: Nothing to do with me, maybe bdmurray can advise
<Laney> (he's an admin)
<dobey> there needs to be a lot of cleanup with team membership on launchpad, especially for all the unity/dx/ps related teams
<Logan_> or hggdh jcastro ogasawara
<Logan_> (they're all admins of ~ubuntu-bugcontrol)
<Wellark> sure, but unity-api-team is an actually active one, don't know about the rest
<Laney> Logan_: I deliberately didn't ping every single person :)
<Laney> (just the one who talked here recently)
<Wellark> hmm.. RegionalBoards says "The Regional Membership Boards have been replaced in favor of time-based boards."
<Wellark> so I guess it's the normal process for me then :)
<bdmurray> I'm not too keen on adding a team with 100+ members to ubuntu-bug-control
<infinity> Logan_: +#test
<infinity> Logan_: (End of your freebsd-buildutils delta)
<Logan_> wha?
<maco> not everyone may know the bug statuses all that well
<infinity> Logan_: http://launchpadlibrarian.net/172821996/freebsd-buildutils_10.0-2ubuntu1_10.0-3ubuntu1.diff.gz
<infinity> Logan_: Oh, that might have been the Debian maintainer who introduced that, though. :)
<Logan_> that appears to be from upstream, haha
<infinity> Logan_: Nevermind, then. :)
<mdeslaur> cjwatson: I just hit bug 1274320 on a new raid trusty install...any idea why?
<ubottu> bug 1274320 in grub2 (Ubuntu) "Error: diskfilter writes are not supported" [Medium,Confirmed] https://launchpad.net/bugs/1274320
<hggdh> Wellark: there is a process in place for team membership on bugcontrol -- see https://wiki.ubuntu.com/UbuntuBugControl#Requirements_for_Teams
<mdeslaur> cjwatson: oh, actually, it does boot after a timeout and doesn't _require_ to hit a key, never mind
<Wellark> bdmurray, hggdh: because of the unholy mess we have with teams added to other teams add infinitum, what would it take to get just me added to the bug-control for time being so that I can actually control the bug statuses for "my" projects on ubuntu side?
<Wellark> including hud, unity-action-api, connectivity-api and indicator-network
<hggdh> Wellark: what is you LP id?
<hggdh> I will have a look on it and tell you :-)
<Wellark> hggdh: kaijanmaki
<hggdh> Wellark: if I understand correctly you are upstream on some packages. Correct?
<Wellark> hggdh: correct.
<hggdh> (but I do not see a lot of bug work)
<hggdh> hum 368 total bugs touched
<Wellark> hggdh: define "a lot". connectivity-api has not had a single bug filed against it in 6 months or so
<Wellark> hard to do work on non-existing bugs ;)
<Wellark> *unity-action-api
<Wellark> connectivity-api is relatively new
<Wellark> and I got plenty of indicator-network bugs assigned to me
<Wellark> and the ones that have not been are on my plate anyway
<Wellark> as I'm the upstream developer for it
<Wellark> just check my MR history
<Wellark> hggdh: i got the email. thanks!
<hggdh> Wellark: you are welcome. You are now officially in probation for bugcontrol ;-)
<Wellark> sweet.
<cjwatson> mdeslaur: the incorrect message is https://lists.gnu.org/archive/html/grub-devel/2014-04/msg00028.html and thread
<mdeslaur> cjwatson: ah, thanks
#ubuntu-devel 2014-04-15
<pitti> Good morning
<pitti> jtaylor: it failed due to "python-tables : Depends: python-tables-lib (>= 3.1.1-0ubuntu1) but 3.1.0-2ubuntu1 is to be installed", it was uninstallable at that time; I'll retry it
<pitti> doko: thanks for the apport speedup patch! I reuploaded with the missing extra import, see bug report
<dholbach> good morning
<pitti> slangasek, stgraber: sorry for missing the meeting last night, I felt quite bad; FTR, I thought I +1'ed https://wiki.ubuntu.com/Ubuntu%20Kylin/Ubuntu%20Kylin%20Archive on the ML already
<Laibsch> Is a pbuilder chroot with build-essential installed but missing the initscripts package considered complete or not (AKA broken)?
<infinity> Laibsch: How would you have created such a chroot?  debootstrap wouldn't let you, and apt would yell at you when you start removing required packages.
<Laibsch> aptitude didn't yell at me, it seems
<infinity> Oh, actually, apt won't either.
<infinity> Laibsch: So, no, that wouldn't be "broken" from a policy perspective, FWIW.  "build-essential" consists of "essential" + "build-essential", not required.
<infinity> Laibsch: From a "will Ubuntu consider that a sane and supportable system" perspective, though, it's totally broken. :)
<infinity> So, it depends on your context.
<Laibsch> so, if a package required the mountall command which is in initscripts but didn't specify that build-dependency is the package broken?
<infinity> But thanks for pointing out, in a roundabout way, that upstart is no longer transitively essential.  I can knock that out of the LP chroots for 14.10  \o/
<infinity> Laibsch: Yes.
<Laibsch> OK
<infinity> Laibsch: Though, I assume you mean in the mountall package...
<Laibsch> reopening bug 1307883, then
<ubottu> bug 1307883 in openjdk-7 (Ubuntu) "openjdk-7-jre fails to install in pbuilder chroot" [Undecided,Invalid] https://launchpad.net/bugs/1307883
<FourDollars> pitti: Hi. Could you help me check https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1303819 on precise?
<ubottu> Launchpad bug 1303819 in bluez (Ubuntu Precise) "Bluetooth menu's content disappeared after resume." [Undecided,In progress]
<Laibsch> openjdk-7-jre calls mountall in postinst but does not declare a dependency (run-time, actually)
<infinity> Laibsch: Hrm, I don't see it calling mountall.
<infinity> Laibsch: I just see it wanting /proc mounted.
<infinity> Laibsch: And a system without proc mounted is absolutely broken.
<Laibsch> sorry
<Laibsch> mountall
<Laibsch>  /var/lib/dpkg/info/ca-certificates-java.postinst: line 90: mountpoint: command not found
<FourDollars> pitti: oops. sorry.  I found it at https://launchpad.net/ubuntu/precise/+queue?queue_state=1.
<Laibsch> and now that I look at it the problem might be in ca-certificates-java, not the jre
<Laibsch> infinity: proc is mounted
<pitti> FourDollars: right, it's waiting for the SRU team to review/accept
<infinity> Laibsch: Oh, yeah, I can't read.
<Laibsch> infinity: relax, me neither ;-)
<infinity> Laibsch: So yes, indeed, that has a runtime dep on initscripts, which isn't Essential, so should be declared.
<FourDollars> pitti: I see. Thanks.
<Laibsch> infinity: thanks, I reopened the ticket.  against the correct package.
<pitti> I never quite understood how "Priority: required" packages are not actually required; it seems odd having to declare a dependency to such a package
<Laibsch> infinity: actually, openjdk-7-jre is affected as well verified by the line
<Laibsch>   /var/lib/dpkg/info/openjdk-7-jre-headless:i386.postinst: 18: /var/lib/dpkg/info/openjdk-7-jre-headless:i386.postinst: mountpoint: not found
<infinity> pitti: "required" is meant to be required for a running Debian system (ie: it's the smallest set you can expect to function meaningfully as a computer), but you still need to depend on them, and they still aren't needed for build-deps.
<infinity> Laibsch: So, this is a slight regression in that initscripts used to be transitively Essential due to things depending on upstart in the Essential set.
<infinity> That said, it was never Essential:yes, so deps should exist.
<infinity> Frankly, I think it's a glorious feature that upstart and udev aren't accidentally in the Essential set anymore.
<infinity> And initscripts isn't essential in Debian either, afair.
<infinity> Oh, no.  It is.
 * infinity ponders how and why.
<infinity> Oh, util-linux depends on it directly.
<infinity> So, that could solve other buggy packages here.
<Laibsch> I've put initscripts into the EXTRAPACKAGES variable in ~/.pbuilderrc for now but somehow it doesn't seem to get installed upon "pbuilder-dist trusty build $blah.dsc" invocation.  Am I misunderstanding "man 5 pbuilderrc"?
<infinity> I don't speak pbuilder.
<pitti> Laibsch: I don't use pbuilder either, but my suspicion is that this only applies to pbuilder create, and perhaps update, but not build
<Laibsch>        EXTRAPACKAGES="ccache lintian XXX"
<Laibsch>               Specifies  extra  packages which the system should install in the chroot on pbuilder create.  This is a space-delimited list.  Also this is installed on pbuilder build
<Laibsch> from the manpage
<Laibsch> "Also ..."
<pitti> yes, I know, but it might not actually behave that way
<Laibsch> I see
<Laibsch> it looks like it
<pitti> it's just a suspicion
<Laibsch> what are people using these days for building?
<pitti> sbuild + apt-cacher-ng + tmpfs = â¥
<Laibsch> I've heard a lot of new commands thrown around
<Laibsch> I'm already using acng
<Laibsch> love, certainly when my download speed drops to less than 10Kbit (yes, bit) out in the jungle ;-)
<infinity> cjwatson: Left here for when you get in, an opinion on sanity of approach of comment 3: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1307883
<ubottu> Launchpad bug 1307883 in openjdk-7 (Ubuntu) "ca-certificates-java misses runtime dependency on initscripts" [Undecided,New]
<pitti> Laibsch: heh, or when I build packages offline in a train or plane :) but even at home acng is over a magnitude faster than real internet
<infinity> acng + tmpfs is the best thing ever.
<infinity> Instant build-deps.
<Laibsch> how does the tmpfs come into play? I assume it's for speed reasons
<pitti> infinity: yeah, that's why I sticked 16 GB into my new laptop (also for LXC/qemu), it just rocks :)
<pitti> Laibsch: yes; muchly
<Laibsch> how to use?
<Laibsch> what do you mount on tmpfs?
<pitti> even on a 500 MB/s SSD the difference is significant, mostly due to fsync and friends
<infinity> Laibsch: Yeah, doing union (aufs or overlayfs) builds backed in tmpfs, so file ops are instant and cleanup is quick.
<pitti> /var/lib/schroot/union/overlay -> /tmp
<pitti> /var/lib/schroot/unpack -> /tmp
<infinity> pitti: I don't bother with the second one.
<pitti> infinity: I use tarballs for most of my schroots, so I need both
<geser> Laibsch: mount a tmpfs on /var/cache/pbuilder/build (if you using pbuilder)
<infinity> pitti: Oh, right.
<infinity> geser: Is that a filesystem overlay, or just the directory where the build happens?
<pitti> and of course 'none /tmp tmpfs defaults 0 0' in /etc/fstab, something which we should have done ages ago on systems with >= 2 GB RAM
<infinity> Cause I/O matters almost nothing to the build itself, it's the build-dep install that hurts.
<geser> infinity: in case of pbuilder: pbuilder extracts there the base.tar.gz, performs the build there (in a chroot) and removes it again when done
<infinity> pitti: My /tmp routinely grows a lot more than 2G of cruft between reboots.  That wouldn't be a sane default without a better cleaning cron job.
<infinity> geser: Ahh, kay.  So, the whole thing.  That would do, yes.
<pitti> and other tweaks are things like "export-dir = /tmp/build-area/" in ~/.gbp.conf
<Laibsch> My computer still has only 2G of RAM, frequently well-filled by FF.  Is mounting /var/cache/pbuilder/build on tmpfs still a good idea or is the worst that would happen that overflow would be dropped to swap and thus no gain in speed?  I wouldn't like my machine to crash or crawl to a halt when building a large package.
 * Laibsch reminds himself to get more RAM next time when back in civilization
<pitti> Laibsch: no, if /tmp is full there is no automatic overflow to swap
<pitti> things will just go haywire
<Laney> how does changelogs.u.c work?
<Laibsch> OK, I'll postpone the speed optimization, then.
<Laney> I think something has gone wrong with it updating
<seb128> Laney, mvo probably knows
<mvo> Laney: there is a lp-changelogs-crawler running on changelogs.u.c
<mvo> Laney: it appears I do not have a login anymore, hrm
<Laney> mvo: Go abuse IS into giving you it back :P
<mvo> Laney: I send a rt and asked for access
<Laney> Seems it hasn't updated since last Thursday-ish
<Laney> did a little bisect using trusty-changes
<jibel> mvo, could you have a look at bug 1307904 ? It's an edge case, only grep:i386 is installed on a 64bit system. The upgrader replaces grep:i386 by grep:amd64 on upgrade but finally refuses the upgrade because grep:i386 is removed
<ubottu> bug 1307904 in ubuntu-release-upgrader (Ubuntu) "Cannot upgrade to 14.04" [Undecided,New] https://launchpad.net/bugs/1307904
<mvo> jibel: sure
<bipul> I am looking for networking team, to work with them.
<bipul> Any one around? who can help me with my query ?
<mvo> jibel: fixed
<jibel> mvo, thanks
<mvo> jibel: thank you!
<zyga> bipul: what do you mean by 'the networking team'
<bipul> zyga, any ubuntu projects related to networking.
<zyga> bipul: I don't think there is a team of that kind
<zyga> bipul: if you can be more precise than networking then you might find what you are looking for
<bipul> zyga, or any development team, related to programming.
<zyga> bipul: ubuntu is developed by a large number of distributed people
<zyga> bipul: perhaps you should just ask your question
<bipul> zyga, I am looking for a development team where i can do contribution and also to learn.
<zyga> bipul: so hang around, there is no team pe se, there are just people that do stuff, you may be interested in signing up to the mailing list and look at discussions there, if you know programming you should look at upstream projects (the ones that ubuntu and debian package) and contribute your efforts there
<bipul> where i can get the upstream projects ?
<zyga> bipul: wherever they are hosted, for example you can find out about network-manager using:
<zyga> apt-cache show network-manager | grep Homepage
<zyga> following sbuild page on the debian wiki (https://wiki.debian.org/sbuild) I got to the part with piuparts, I used the sid chroot (as in the example) but for some reason piuparts wants to setup a saucy chroot (?!), does anyone here use piuparts along with sbuild?
<zyga> looking at the source I see this is hardcoded
<zyga> pitti: is this worth fixing for trusty?
<pitti> zyga: sounds easy enough, and it's certainly not on any image
<zyga> pitti: I have a debdiff, what should I do with it?
<pitti> zyga: subscribe sponsors for now; I'll try to have a look in the next hours
<zyga> http://paste.ubuntu.com/7254566/
<zyga> ko
<zyga> pitti: so open a bug on the trusty package, attach the debdiff and subscribe sponsors, anything else?
<pitti> that sounds like the usual approach
<zyga> ok, thanks
<pitti> zyga: if the release team is happy for it to go in without a bug, I can also just upload the debdiff
<pitti> zyga: but at least this warrants a Debian bug -- this certainly shoudln't hardcode "saucy" but use /etc/os-release
<zyga> pitti: it's more "smart" than that, it has several profiles
<pitti> meh, and it even calls lsb_release already
<geser> perhaps it should use python-distro-info instead to get the devel release
<pitti> zyga: anyway, uploaded; please do the above if the release team wants bug reports at this point
<zyga> pitti: https://bugs.launchpad.net/ubuntu/+source/piuparts/+bug/1307995
<ubottu> Launchpad bug 1307995 in piuparts (Ubuntu) "piuparts hardcodes 'saucy' as the default ubuntu version" [Undecided,New]
<zyga> pitti: uploaded as in you've fixed this in the archive?
<pitti> zyga: as in I uploaded your debdiff
<pitti> zyga: I'll reupload with that bug ref
<zyga> pitti: ah, thanks
<pitti> zyga: oh, it was auto-accepted: https://launchpad.net/ubuntu/+source/piuparts/0.56ubuntu1
<pitti> seems universe still isn't deep-frozen
<zyga> pitti: cool, thanks :-)
<zyga> pitti: so should I do anything else at this time or is this enough?
<pitti> zyga: seems fine; a Debian bug about this would be nice though
<zyga> pitti: ok, I'll try to do that
 * zyga keeps forgetting how to use reportbug on ubuntu to target debian
<Laney> pitti / jibel: Would it be a good idea to add -o IdentitiesOnly=yes to etc/config in lp:auto-package-testing?
<Laney> I was just getting the old 'too many authenticaiton failures'
<pitti> Laney: I don't know what that does, I'm afraid
<Laney> pitti: Basically makes it ignore the agent provided identities and just use the one given on the commandline
<pitti> Laney: seems to work alright here
<Laney> It happens if you have a lot of identities in the agent
<pitti> Laney: http://paste.ubuntu.com/7254656/ ?
<Laney> lgtm
<pitti> Laney: pushed
<Laney> cheers
<Laney> I ought to figure out if all of these keys are really necessary
 * Laney gives that problem to future Laney to solve
<pitti> in your agent, you mean?
<Laney> yep
<dpm> hi cjwatson, I've got a website that reports the status of translations for the packages included in a default distro installation (as opposed to LP reporting everything in main). A while ago you explained me how I could find out this list of packages for a desktop installation through the seeds. So the list of seeds to expand that you gave me for the desktop (http://bazaar.launchpad.net/~dpm/ubuntu-translations-stats/trunk/view/head:/stats/management/c
<dpm> ommands/utils/distropackages.py#L42) has worked very well so far. I'm now trying to report translation status for the phone. Can I also do this using the same method? I.e. is there a list of seeds that I can use to determine all packages from a default phone installation?
<LocutusOfBorg1> dholbach, you there?
<LocutusOfBorg1> I saw your comment on the sync request
<LocutusOfBorg1> maybe is faster to discuss here
<LocutusOfBorg1> :)
<dholbach> LocutusOfBorg1, I just wanted to generally provide some links to how to get an upload considered for backports/SRUs
<dholbach> LocutusOfBorg1, but sure... how can I help?
<LocutusOfBorg1> I would like to have it for trusty
<LocutusOfBorg1> :)
<LocutusOfBorg1> sorry leaving
<dholbach> ... ok
<dholbach> for whoever is wondering what this was about, here's the link: bug https://bugs.launchpad.net/ubuntu/+source/flex/+bug/1307604
<ubottu> Launchpad bug 1307604 in flex (Ubuntu) "Sync flex 2.5.39-1 (main) from Debian unstable (main)" [Undecided,New]
<shadeslayer> dpm: ping
<shadeslayer> dpm: https://bugs.launchpad.net/langpack-o-matic/+bug/1267763 < needs adding to langpack-o-matic
<ubottu> Launchpad bug 1267763 in langpack-o-matic "kde-config-whoopsie not localized" [Undecided,New]
<dpm> hey shadeslayer
<dpm> shadeslayer, you'll need to ping pitti for the langpack-o-matic side of things
<shadeslayer> pitti: ^^
<shadeslayer> pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1278142
<ubottu> Launchpad bug 1278142 in langpack-o-matic "kubuntu-driver-manager not localized " [Undecided,New]
<shadeslayer> dpm: https://translations.launchpad.net/ubuntu/trusty/+source/kde-config-whoopsie/+imports < templates are imported but not approved?
<dpm> shadeslayer, if the're imported, they've been approved :)
<shadeslayer> ah I see
<dpm> the workflow is Needs Review > Approved > Imported
<shadeslayer> ah ok
<shadeslayer> dpm: https://bugs.launchpad.net/ubuntu/+source/intltool/+bug/953342 < needs intltool release
<ubottu> Launchpad bug 953342 in intltool (Ubuntu) "Add support for Qt Designer UI files" [Medium,Triaged]
<geser> does somebody have any opinion what do with myspell-st (src:dict-st)? it looks like it fails in post-inst since precise (bug 980130). The package is in main but was never in Debian so is essentially unmaintained.
<ubottu> bug 980130 in dict-st (Ubuntu) "package myspell-st 20070206-4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/980130
<dpm> shadeslayer, I know. You might want to ping danilo and dobey as intltool maintainers for a new release
<shadeslayer> dobey: ^^ could we get a release pretty please :)
<shadeslayer> pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1267765
<ubottu> Launchpad bug 1267765 in langpack-o-matic "kdesudo not localized" [Undecided,New]
<shadeslayer> pitti: all 3 need to be added to langpack-o-matic
<Laney> geser: The postinst is automatically generated & a no-change rebuild gets rid of it
<Laney> I don't know if the package works or does anything useful though
<Laney> It does at least ship files in useful locations...
<geser> me neither, but I try to get a SRU for it in the next days to fix this error at least
<Laney> I think there are other myspell-* packages that do the same
<pitti> shadeslayer: hm, why aren't these in kde-l10n-*?
<pitti> shadeslayer: I thought the -base packages only contained the kubuntu specific strings?
<pitti> shadeslayer: driver-manager added
<shadeslayer> pitti: because at the very least whoopsie/driver manager are kubuntu specific things
<shadeslayer> and not part of sc
<pitti> shadeslayer: yes, I added that
<shadeslayer> pitti: whoopsie too?
<pitti> shadeslayer: I was wondering about kdesudo
<shadeslayer> ah that, I  am unsure, apachelogger ^^
<pitti> shadeslayer: whoopsie? I didn't see that bug
<apachelogger> space ships, what?
<apachelogger> kdesudo is kubuntu specific right now
<apachelogger> perhaps we'll get to change that some time not too far in the future
<pitti> shadeslayer: ah, doing now
<shadeslayer> pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1267763
<ubottu> Launchpad bug 1267763 in langpack-o-matic "kde-config-whoopsie not localized" [Undecided,New]
<cjwatson> dpm: For the phone I think it's minimal plus the sdk-libs and touch seeds in the ubuntu-touch seed collection, but sanity-check that against reality
<pitti> shadeslayer: all done
<pitti> seb128: is bug 1201485 still actually an issue?
<ubottu> bug 1201485 in Ubuntu Translations "Need to import translations for the unity daily builds" [High,Triaged] https://launchpad.net/bugs/1201485
<seb128> pitti, no, it's launchpad fix released, the other lines are probably invalid
<pitti> seb128: ah, so PPA copying copies along the translations.tar.gz now? nice
<seb128> pitti, I didn't especially check but I didn't notice outdated templates/missing translations so I think the fix is working as it should
<seb128> pitti, I think so
<pitti> the MP times out to load
<pitti> seb128: ack, thanks
<seb128> pitti, yw!
<MacSlow> Saviq, hm... the input filterarea doesn't work reliably... it's swallowing input when on the dash, but not in apps... investigating
<MacSlow> Saviq, MouseArea I meant
<Saviq> MacSlow, yeah, you need to use an InputFilterArea
<Saviq> MacSlow, as well, that is
<MacSlow> Saviq, but it (the modal-backgrounds MouseArea) swallows input for the Dash... that's confusing me a bit
<Saviq> MacSlow, those are separate surfaces
<Saviq> MacSlow, all the shell is one, so you can use a MouseArea to prevent input reaching other layers of the shell
<Saviq> MacSlow, but the apps are completely separate clients, they don't know about Shell's MouseAreas, nor does Mir
<cjwatson> pitti: Yeah, Ursula fixed LP to copy translations along with everything else back in October
<Saviq> MacSlow, InputFilterArea is communicating to Mir that input in this area should not be delivered to clients
<MacSlow> Saviq, I changed my branch to use an InputFilterArea... cross-compiling now and then testing it
<Saviq> MacSlow, you probably need both (MA for dash, IFA for other apps)
<MacSlow> hm... ok
<Saviq> MacSlow, FWIW that will change with Qt compositor, as apps there will be just as any other object in the QML scene, so MA will be enough
<dpm> cjwatson, ok, I'll try, thanks!
<dpm> cjwatson, for the core apps click packages that are installed by default: can I find them out via the seeds too? I guess not, so I'm wondering where to find out the default clicks, so that I can also use them to create the phone translation stats
<cjwatson> dpm: http://people.canonical.com/~ubuntu-archive/click_packages/click_list
<dpm> aha, perfect, thanks cjwatson
<kdeuser56> pitti: what steps would have to be taken to enable dbgsym creation for the mainline kernel ppa?
<LocutusOfBorg1> hi dholbach
<LocutusOfBorg1> still there?
<jamespage> bdmurray, if you are around, can you reject the juju-core upload from the saucy SRU queue
<jamespage> bdmurray, I need to pull a bit out after some discussion with upstream
<bdmurray> jamespage: sure, rejections are easy!
<jamespage> bdmurray, the change drops one of the 'features' introduced so it should make life a bit easier
<bdmurray> arges: speaking of SRUs could you look at whoopsie in saucy and whoopsie-daisy in precise?
<arges> bdmurray: sure
<dholbach> LocutusOfBorg1, as I said earlier... I was looking at the request generally - I don't have much of an idea of flex and can't judge it going into trusty - AFAICS trusty is "done" now
<arges> bdmurray: so how come whoopsie doesn't have an ubuntu version?
<arges> .33->.34
<bdmurray> arges: because it is only in ubuntu
<arges> bdmurray: but whoopsie has an ubuntu version?
<arges> err whoopsie-daisy doesn't but whoopsie does
<jamespage> bdmurray, OK - I uploaded a new version minus the 'update-bootstrap' plugin.
<jamespage> bdmurray, the only other bit that's a bit hand wavey is bug 1254729
<ubottu> bug 1254729 in juju-core (Ubuntu Saucy) "Update Juju to make a "safe mode" for the provisioner" [Undecided,New] https://launchpad.net/bugs/1254729
<bdmurray> arges: looks like I made a mistake in the versioning back in january
<infinity> arges: Eh?  You just mean the 0.2.24.1ubuntu1 in saucy-updates?  That's pretty much just the uploader of that SRU being silly, it should have been 0.2.24.1.1
<arges> bdmurray: infinity ack. So just leave the new version as 0.2.24.1ubuntu2 or should that be 0.2.24.2 ?
<arges> or even 0.2.24.1ubuntu1.1
<jamespage> bdmurray, for which I'm proposing smoke testing to ensure nothing regressed (bearing in mind I've been using 1.16.6 with MAAS and OpenStack since Jan I've not seen any issues)
<infinity> arges: 0.2.24.1.2, I would argue.
<infinity> arges: Note the .1 in the middle there that you missed.  I assume 0.2.24.2 already existed in history.
<LocutusOfBorg1> dholbach, fair enough, I think the same
<arges> infinity: yup that's what i meant
<infinity> Yeah https://launchpad.net/ubuntu/trusty/+source/whoopsie/0.2.24.2
<LocutusOfBorg1> so, do you think is good to sync for "u" and SRU it, right?
<infinity> arges: So, yeah, 0.2.24.1.2, and for bonus points, you could rertoactively changes the 1ubuntu1 entry in the changelog to .1.1 and wipe it out of history. ;)
<arges> infinity: sure.   bdmurray mind if i handle that for you and you can approve?
<bdmurray> arges: I'm mostly done with that change
<arges> bdmurray: ok let me know and i'll rereview
<dholbach> LocutusOfBorg1, you might want to read the SRU wiki page again
<dholbach> LocutusOfBorg1, it explains quite well what SRU material is and what isn't
<dholbach> and to me it looks like there's quite a bunch of changes in that release (even if they all / or the majority are bug fixes)
<bdmurray> arges: uploaded
<arges> bdmurray: ok accepted
<LocutusOfBorg1> dholbach, maybe I can ask to the official developer a feedback? I know there is a line between SRU and backports, and it is difficult to choose sometimes
<LocutusOfBorg1> they make many releases, but always with small changes
<LocutusOfBorg1> and only bug fix
<arges> infinity : so the new queue for precise: https://launchpad.net/ubuntu/precise/+queue?queue_state=0 these look like SRU updates, but somehow are here. should they be treated as SRUs, or is there another process these are waiting on.
<dholbach> LocutusOfBorg1, if you can explain in the bug report why it's important to have the upload and what kind of testing you've done and what the impact might be, I think that'd help a lot
<dholbach> LocutusOfBorg1, then you could get an answer from the release team
<LocutusOfBorg1> yes, anyway let's wait for the release, and the sync
<LocutusOfBorg1> after I'll try to test it as deeply as I can
<LocutusOfBorg1> with maybe some upstream help
<dholbach> ok cool
<LocutusOfBorg1> BTW do you know why network-manager in precise is still in proposed queue?
<LocutusOfBorg1> the tag verification-needed has been changed in verification-done
<infinity> arges: They're SRUs, though also new binaries, so worth a cursory NEW review before otherwise SRU processing.
<cyphermox> most likely just because nobody noticed.
<cjwatson> arges: there's an LP bug that packages added entirely new post-release tend to be mistreated as NEW thereafter
<infinity> arges: If you treat them as an SRU of the previous versioned packages (ie: debdiff against nvidia-thing-319 or whatever), you can get a pretty good idea of the state of things.
<cjwatson> because four different subtly wrong ancestry calculation implementations
<infinity> arges: And then they also need to have overrides applied, though I can do that in the queue right now.
<arges> cjwatson: infinity : gotcha. I can review them if that ok.
<mvo> jibel: re bug #1308056 - do you have that system available? what do you have in /var/lib/update-notifier/user.d/, could you pastebin or mail this to me please?
<ubottu> bug 1308056 in language-selector (Ubuntu) "language packs not installed after a non-network installation in a non-english language" [High,New] https://launchpad.net/bugs/1308056
<arges> infinity: these aren't even diffed against that there is already nvidia-graphics-drivers-331-331.20ubuntu0.0.1, this is just ubuntu0.0.2
<infinity> arges: Alright, overrides fixed in the queue, if you want to review them.
<arges> infinity: ok thanks
<dholbach> LocutusOfBorg1, no idea - sorry
<infinity> arges: Oh, those are already in in a previous version?
<arges> infinity:  nvidia-graphics-drivers-331 | 331.20-0ubuntu0.0.1 | precise-updates/restricted | source
<infinity> arges: In that case, yeah, just a lanuchpad bug that they're in NEW.
<infinity> arges: So, treat like any other SRU.
<arges> ok cool. just trying to not mess stuff up
<infinity> arges: Well, was good to ask just so an AA could fix the overrides anyway.
<xnox> GunnarHj: hey, are you around? i have a few regressions w.r.t. to incomplete language support.
<xnox> GunnarHj: i believe it's related to previous SRUs you have done, together with the recent ubiquity bug you reported and a few other things that landed in the language-selector and account services.
<xnox> specifically bug #1103547
<ubottu> bug 1103547 in language-selector (Ubuntu Precise) "drag and drop does not work language support not complete" [Medium,Fix released] https://launchpad.net/bugs/1103547
<xnox> bug #1134364
<ubottu> bug 1134364 in language-selector (Ubuntu Precise) "Check for missing language support for all installed languages" [Undecided,Fix released] https://launchpad.net/bugs/1134364
<ogra_> xnox, your "remove all py2 from touch" hasnt happened yet, has it ?
<xnox> ogra_: no, because my fixes are not getting merged and released.
<ogra_> ok
<xnox> ogra_: do you want a list of my merge proposals?
<xnox> ogra_: ditto qt4 removal.
<ogra_> just wanted to be sure, since the image scratches the 500M edge
<xnox> GunnarHj: i'm thinking of landing http://paste.ubuntu.com/7256183/
<GunnarHj> xnox: Thanks for letting me know. I'll comment on it in a few minutes.
<Laney> xnox: patching a patch?
<Laney> (0009-language-tools.patch)
<xnox> GunnarHj: please review it.
<xnox> Laney: also see plymouth - i think that patches patches of patches.
<Laney> seems unideal
<xnox> GunnarHj: please review, basically the problem is that "/usr/share/language-tools/language-options" says that "fr" is not needed to be installed, when it is not installed, but one did $ locale-gen fr_FR.utf8
<xnox> GunnarHj: (as in the state one gets into after offline installation, which configured locale, set incomplete locale flag and did not install the langpacks/hunspell/etc)
<GunnarHj> xnox: Will check it out indeed. I thought otherwise, but will check.
<Laney> Please do merge it into the first patch
<xnox> GunnarHj: interrsection is suppose to mean - desired, valid, not fully installed.
<xnox> Laney: yeah, i will. In a sec.
<Laney> Ta
<GunnarHj> xnox: Please give me a few minutes.
<xnox> GunnarHj: i'm still testing it, this is not even in the queue for the release team yet. Take as long as you need, it was not trivial for me to hunt down.
<xnox> GunnarHj: in fact, we were hoping you would show up to review this =))))
<Laney> xnox: well done finding it
<GunnarHj> xnox: Ok. ;)
<Laney> $translation_dirs{$_} = 1 for readdir $dh;
<Laney> oh perl, you so kooky
<GunnarHj> Laney: Don't pick on Perl.
<xnox> GunnarHj: Laney: updated debdiff http://paste.ubuntu.com/7256240/
<GunnarHj> xnox: Ok, thanks. Makes more sense to change the existing patch.
<tjaalton> why on earth do ppa builds insist on building indep targets on amd64 too?
<cjwatson> They don't ...
<tjaalton> do for me
<cjwatson> Your debian/rules is broken then
<tjaalton> it's krb5
<cjwatson> Example?
<cjwatson> Like a +build
<tjaalton> https://launchpad.net/~sssd/+archive/updates/+build/5911824
<tjaalton> vs https://launchpad.net/~sssd/+archive/updates/+build/5911825
<xnox> i thought loads of things will fail when doing arch build without indep build-deps.
<xnox> cause debian is not doing it.
<cjwatson> tjaalton: precise's dpkg-buildpackage didn't have the necessary smartness to honour build-arch yet
<cjwatson> Debian #229357
<ubottu> Debian bug 229357 in dpkg-dev "dpkg-buildpackage: support for Build-Options: build-arch" [Wishlist,Fixed] http://bugs.debian.org/229357
<cjwatson> (well, disregard the implied solution in the bug title)
<cjwatson> That was added in dpkg 1.16.2, so quantal
<tjaalton> ahah, that would explain it then, thanks
<GunnarHj> xnox: If I understand it correctly, what you suggest would redefine what constitutes an installed language. You would no longer be able to generate a locale without l-s starting to prompt you about installing everything.
<xnox> GunnarHj: in my testing, l-s is only asking me to install missing things.
<xnox> GunnarHj: as it's limited by "locale -a" in the first place, e.g. one typically on has en and enabled locale.
<xnox> GunnarHj: if someone will go and actually generate all locales, indeed all language packs will be requested to be installed.
<xnox> GunnarHj: at the moment, however, the bug is that _no_ language packs are ever installed at all, but "en".
<xnox> GunnarHj: this is actually revert to what the code was before one of the SRUs into precise.
<GunnarHj> xnox: Yes, but the possibility to generate a locale without installing the language is intentional. I think cjwatson can confirm that.
<xnox> GunnarHj: that's what the installer does, to trigger langpack installation....
<xnox> (possibly at a later time when network is available)
<xnox> GunnarHj: there is a separate flag to actually block the lang-pack installation.
<GunnarHj> xnox: When you have tested, did you check if the language appeared in "Installed languages" in l-s?
<xnox> I'm trying to fix bugs "System not localized after an OEM installation" and "language packs not installed after a non-network installation in a non-english language " as in no language packs installed automatically post-install.
<xnox> GunnarHj: "When you have tested, did you check if the language appeared in "Installed languages" in l-s?" at which stage? patch applied, locale generated, and no packages for that locale installed?
<xnox> GunnarHj: I can test that in a second.
<GunnarHj> xnox: Yes.
<cjwatson> it's certainly intentional that you can generate a bare locale, but I don't see a reason not to flag it as incomplete support ...
<cjwatson> can't you dismiss it and tell it to shut up?
<GunnarHj> cjwatson: No, there is no way to tell it to shut up. ;)
<GunnarHj> cjwatson: I mean, you'll be prompted whenever you start l-s if you don't install.
<xnox> GunnarHj: it shuts up after the first time.
<cjwatson> do we need another flag to check-language-support for use by the installer?
<cjwatson> GunnarHj: oh, well, sure, but I never start l-s so who cares ;-)
<cjwatson> I would care about notification spam
<xnox> yeah the auto popup goes away.
<GunnarHj> xnox: Does it?
<cjwatson> I think it would be reasonable enough for l-s to bug people with extra bare locales
<cjwatson> if started manually, which is rare
<xnox> GunnarHj: yeah, it has a separate flag which is cleared.
<xnox> GunnarHj: but i will test it again here.
<GunnarHj> xnox: I'd like to do some testing and think more about it. Can we talk more about it tomorrow?
<xnox> GunnarHj: we kind of have a release to make on thursday, and no language packs installed after OEM configuration is very bad for all our OEMs.
<xnox> GunnarHj: oem-config does not configure network and pull language packs, the way normal ubiquity installation does.
<GunnarHj> xnox: So this is going into the release??
<xnox> GunnarHj: i want this to go into release yes.
<xnox> otherwise i wouldn't be patching this now & extensively testing.
<GunnarHj> xnox: I see.
<GunnarHj> xnox: How long will you be there today?
<xnox> GunnarHj: if my testing doesn't show any regression on past fixed bugs w.r.t. this we will respin for it probably in a few hours.
<xnox> GunnarHj: if we need to further fix this post-release, we will be able to do zero-day SRU etc.
<xnox> GunnarHj: this will also will need fixing for 12.04.5
<GunnarHj> xnox: Ok, I see. Actually I have a feeling that it will lead to undesired effects that we'll need to take care of as SRUs.
<xnox> GunnarHj: hm, yeah, i don't see it do the right thing yet.
<GunnarHj> xnox: One thought I have right now is that the installer might be changed to create empty /usr/share/locale-langpack/[lang] directories when installing without the net.
<xnox> GunnarHj: it did not install anything for me now.
<GunnarHj> xnox: Ok..
<cjwatson> Would empty directories help?
<GunnarHj> cjwatson: I'm not sure. Just a thought so far...
<xnox> cjwatson: we'd need a subdir for the locale, yeah.
<cjwatson> It would certainly be possible
<xnox> cjwatson: let me test.
<cjwatson> If that fixes it it would be less invasive
<xnox> ogra_: gtk2 is back on touch image
<xnox> ogra_: and i've explicitely removed it
<xnox> ogra_: also for the same reason appmenu will get a reject now.
<seb128> hum
<seb128> would be handy to have ddeb sources on the porter boxes
<jtaylor> did something change with the python gdb extensions?
<jtaylor> they aren't loading for me anymore, they used to a week ago
<GunnarHj> xnox, cjwatson: I made a quick-n-dirty test on 13.10 where I am right now, and it looks promising.
<xnox> GunnarHj: creating directories?
<GunnarHj> xnox, cjwatson: I added the "fi" directory and did 'sudo locale-gen fi_FI.UTF-8'. It was pulled nicely after that.
<xnox> GunnarHj: hm, not doing that here.
<xnox> let me try again.
<xnox> GunnarHj: nevermind, had dirs in the wrong place.
<xnox> GunnarHj: looks good now.
<GunnarHj> xnox: That solution would make me feel better. :)
<jtaylor> doko: since the last or before last python3 update the gdb debug extensions aren't loading anymore
<jtaylor> doko: its expecing them as python3.4-dbg.py now instead of python3.4m-dbg.py
<doko> jtaylor, hmm, can't see what should have changed ...
<jtaylor> qives the changelog gives no clue
<jtaylor> I also have no idea how gdb actually tries to load it
<GunnarHj> xnox: Do you think it's doable to make the installer create such empty dirs?
<xnox> GunnarHj: yes, we are now moving bug 1307983 to d-i.
<ubottu> bug 1307983 in localechooser (Ubuntu Trusty) "System not localized after an OEM or offline installation" [High,Confirmed] https://launchpad.net/bugs/1307983
<xnox> GunnarHj: well localechooser.
<GunnarHj> xnox: Ok, sounds good. Thanks for letting me know.
<smoser> xnox, around ?
<smoser> http://paste.ubuntu.com/7257532/
<smoser> how much can i trus tthe order of that output.
<smoser> i ask because 'Clean /tmp/directory' (line 373) I think is /etc/init/mounted-tmp.conf which is
<smoser>   start on (mounted MOUNTPOINT=/tmp) or (mounted MOUNTPOINT=/usr)
<smoser> i woudl have thought that was guaranteed to happen after (and be blocked by) cloud-init-local (line381)
<smoser> which is
<smoser>  start on mounted MOUNTPOINT=/
<smoser> oh yeah, and thank you!. that output looks so much better now.
<jtaylor> doko: was bin/python3.4 a symlink before?
<jtaylor> it seems gdb just loads <filename>-gdb.py
<jtaylor> this might have worked if python3.4 was a link to python3.4m before
<jtaylor> or I' was always just using python3-dbg which is a symlink to the right named file, hmmm
<doko> jtaylor, so maybe we need two -gdb.py files
<jtaylor> or a symlink yes
<jtaylor> I added a copy with the right filename and it works
<jtaylor> out of curiousity why are there two identical python binaries installed?
<doko> these are hard links
<doko> done upstream.
<jtaylor> oh
<doko> jtaylor, does it work when you make python3.4 a symlink to python3.4m?
<jtaylor> let me try
<doko> /usr/lib/debug/usr/bin/python3.4dm-gdb.py
<doko> /usr/lib/debug/usr/bin/python3.4-dbg-gdb.py
<doko> these are there, so that's why the -dbg works
<jtaylor> no symlink of python3.4 does not work
<jtaylor> oh wait it does I linked it to 3.3 ...
<doko> ok, then I'll add the python3.4m-gdb.py symlink
<doko> I mean, python3.4-gdb.py
<jtaylor> btw the test is just: gdb python3; py-list
<jtaylor> if it gives you unknown command it doesn't work
<jtaylor> or if it gives you "add to save-load blabla" it which means it worked but you need to edit your ~/.gdbinit
<jtaylor> add-auto-load-safe-path
#ubuntu-devel 2014-04-16
<siretart> Laney: I've forwarded it upstream. ideally we'd have libav10 in trusty, but oh well...
<ypwong> slangasek, hi Steve, about the ubuntu kylin archive, are there anything outstanding?
<slangasek> ypwong: I need to reply to JackYu regarding the mirroring setup, and get final confirmation from IS; I'll make sure to push that forward this evening
<slangasek> psusi: why did you reassign bug #1308254 to the kernel?  That looks to me like a broken /etc/fstab (referencing devmapper devices by uuid instead of name)
<ypwong> slangasek, thanks, about the mirror, I think rsync should be fine
<ubottu> bug 1308254 in linux (Ubuntu) "Resume mounts /dev/mapper/${dst}_unformatted, breaks GRUB and Apt" [Undecided,Incomplete] https://launchpad.net/bugs/1308254
<JackYu> slangasek, thanks, we will upload packages to the PPA today.
<slangasek> JackYu: ok, perfect
<psusi> slangasek, he said that the output of /proc/mounts changed during suspend
<psusi> slangasek, also the uuid of the device even changed... that looks like a kernel bug
<slangasek> psusi: ah.  yeah, that could be a kernel bug, but it's more likely that when he says "suspend" he means "hibernate"
<psusi> had one name, suspend, resume, and now /proc/mounts says the device name has a _unformatted suffix ( as does the uuid ), when in fact, the device name did not change
<slangasek> because the _unformatted suffix comes from cryptsetup's userspace scripts, which only run on boot
<psusi> does that matter?  if the device is mounted when you hibernate, it's still mounted when you resume and its name should not change
<psusi> and in fact, it didn't sound like the /dev name really did change.. just what /proc/mounts shows
<slangasek> psusi: well, I replied to the bug and marked it invalid with what I believed was a plausible analysis... if it turns out I'm mistaken, we'll reopen.
<slangasek> psusi: but mountall is not triggered at all ever on suspend/resume or hibernate/resume
<slangasek> so the bug report itself is a bit suspect
<psusi> I didn't think so
<slangasek> if I'm wrong, we'll find out
<psusi> it certainly was not a bug in grub, and apt, and cryptsetup ;)
<slangasek> indeed!
<psusi> nn o/
<fhassan> is Trusty ETA decided in advance or could be anytime during the day?
<pitti> Good morning
<RAOF> fhassan: It's typically delayed by an hour each time someone asks :)
<fhassan> RAOF: lol. looks like I should zip my mouth for 24-48 hours :)
<tarpman> fhassan: test the installer a few times, to help pass the time :)
<fhassan> tarpman: I'll see what I can do. Thx.
<dholbach> good morning
<hyperair> oh god, chromium looks so goddamned fugly now
 * hyperair wonders if aura can be disabled.
<pitti> our supported default browser looks fine, FWIW (just sayin')
<hyperair> yeah it also hangs like hell
<hyperair> and the crappy ol gecko inspector thing renders with such tiny font sizes
<hyperair> what's it made for, ants?
<pitti> hm, I must be doing entirely different stuff than you then
<Unit193> Indeed, and I've got it on a single core.
<rww> hyperair: the font is webscale
<hyperair> rww: what's webscale?
<hyperair> http://imgur.com/RtnYqpR <-- this
<hyperair> this *cannot* possibly be normal
 * hyperair reins in the expletives
<jibel> xnox, I reopened bug 1307983 and filed 1308396
<ubottu> bug 1307983 in ubiquity (Ubuntu Trusty) "System not localized after an OEM or offline installation" [High,Triaged] https://launchpad.net/bugs/1307983
<jibel> bug 1308396
<ubottu> bug 1308396 in language-selector (Ubuntu) "gnome-language-selector crashed with SIGSEGV in pkgCache::ReMap()" [Medium,New] https://launchpad.net/bugs/1308396
<jamesh> mardy: would you be a good person to talk to about the online accounts infrastructure?
<mardy> jamesh: I'm afraid so :-)
<mvo> jibel: is that crash reproducible?
<jibel> mvo, apparently no
<mvo> :(
<jamesh> mardy: I was trying to set up a new service using the generic-oauth plugin.  I think I got something wrong, since the auth page isn't loading in the embedded web browser.  Is there an easy way to check what requests are being made, or even what URL the embedded web browser requested?
<mardy> jamesh: yes, start with "killall signon-ui"
<mardy> jamesh: then:
<mardy> export SSOUI_LOGGING_LEVEL=2
<mardy> export SSOUI_DAEMON_TIMEOUT=9000
<mardy> signon-ui
<mardy> jamesh: then you'll see some logs in the console, including the URL which was requested
<jamesh> okay.  I'll give that a shot
<mvo> jibel: so you run the language-selector again and it does no longer crash?
<jamesh> mardy: thanks.  That made all the difference.
<jibel> mvo, yes, I ran it several times and it didn't crash. I'm redoing a full installation
<mardy> jamesh: good! Out of curiosity, what service is it?
<jamesh> mardy: soundcloud
<jamesh> mardy: I'd set AuthPath to "/connect", when it should have been "connect"
<mardy> jamesh: yes, these things should probably be made more flexible
<jamesh> the former led to the web browser trying to display https://api.soundcloud.com//connect, which gave a 404 error
<jamesh> removing the extra slash, and I have an access token
<jamesh> mardy: also, if I want to access the accounts service from a language without a binding, would it make sense to use direct D-Bus access?
<mardy> jamesh: the D-Bus API hasn't changed for a long time, but we plan to do some changes someday
<mardy> jamesh: I wouldn't recommend using that
<mardy> jamesh: there are glib bindings, I think they can be easily wrapped in any language, can't they?
<jamesh> mardy: this is for Go.  I could probably go via the C API, but if D-Bus was similar complexity that would be easier to hook up
<jamesh> (Not actually using any other glib APIs at present)
<mardy> jamesh: for the authentication, you could probably use the D-Bus API, it would be a matter of a couple of D-Bus calls only
<mardy> jamesh: however, for the accounts part (finding the account to use), there is no D-Bus API, just a glib-based library
<mardy> jamesh: so you'd have to wrap at least that one
<jamesh> mardy: I basically just want to check for the existence of an account and get the access token if it exists.  If that's easier to do from glib, then that's what I'll do.
<jamesh> thanks again for the help.
<jibel> mvo, it seems to be a one time crash, I couldn't reproduce it.
<pitti> . o O { copying files in ubiquity is fun if your target virtio drive is on a tmpfs }
<Laibsch1> As an almost decade-long contributor to Ubuntu and DM who is overqualified and contributing too much (yep, I was denied recognition as @ubuntu.com contributor for THAT reason!) I was wondering if upload privileges that others are apparently granted easily are ever revoked in case of gross neglect?
<Laibsch> Such as sync'ing a package that obviously needed a merge and failing to even run the single command the sync'd package provides before making the upload (or else one would have realized the command fails to run due to the missing merge introduced in karmic)
<Laibsch> bug 1239912 seems to me to be such a case
<ubottu> bug 1239912 in system-config-lvm (Ubuntu) "system-config-lvm fails to start citing missing /etc/init.d/lvm2" [High,Confirmed] https://launchpad.net/bugs/1239912
<xnox> Laibsch: that bug report is valid. Upload priviledges are granted by Developer Membership Board these days, please see documentation on the wiki pages.
<cjwatson> Laibsch: might be worth a note to the DMB
<cjwatson> I'll see about getting that patch reintroduced
<cjwatson> (appreciate the heads-up)
<Laibsch> thanks, cjwatson
<Laibsch> I was just wondering if someone keeps on eye on if an individual had a history of doing things like this.  I don't actually thing any measure is needed if it was a simple mistake and certainly not for someone doing a lot of uploads.  I was simply honestly curious if there was a process in place and whether or not it is actually being used in practice.
<Laibsch> s/thing\ any/think\ any/
<xnox> Laibsch: there is email address you can contact DBM only via developer-membership-board@lists.ubuntu.com
<Laibsch> thanks, I'll consider using it if ever I came across a similar instance by the same individual.  It's my first time to see his name.
<pitti> infinity: hm, are we building ubuntu-core for arm64? http://iso.qa.ubuntu.com/qatracker/milestones/314/builds/66886/downloads has no links
<pitti> infinity: (worked fine on i386, amd64, and ppc64el)
<pitti> infinity: nevermind, found it; that just seems to be a problem in the ISO tracker
<pitti> i. e. the download link isn't set
<pitti> jibel: http://iso.qa.ubuntu.com/qatracker/milestones/314/builds/66886/downloads has no links, but there is a http://cdimage.ubuntu.com/ubuntu-core/daily/current/trusty-core-arm64.tar.gz
<pitti> jibel: can this be added to the tracker?
<pitti> jibel: (I realized that I can't actually test that as I don't have root access to arm64 or powerpc hardware, but it caught my eye anyway)
<jibel> pitti, thanks for pointing this out, I'll add the link
<infinity> tjaalton: *poke*
<infinity> tjaalton: I think dropping the transitional packages from intel-vaapi-driver was premature.  We probably want them in 14.04
<rbasak> xnox: just had a dupe of bug 1273462 and I noticed that it's still open. Is this not being fixed for Trusty now?
<ubottu> bug 1273462 in upstart (Ubuntu) "Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists" [Critical,Triaged] https://launchpad.net/bugs/1273462
<xnox> rbasak: i don't have it ready, i will push to sru it though.
<xnox> rbasak: not this week, i don't think.
<xnox> rbasak: there are ~160 affected scripts i believe
<rbasak> xnox: OK, thanks!
<tjaalton> infinity: oh..
<int_ua> Is it possible to package a click package for Tabbed UI + C++ backend?
<rickspencer3> int_ua, I  suspec that #ubuntu-app-devel may have an easier time answering your question
<int_ua> rickspencer3: Thanks a lot :)
<rickspencer3> np
<doko> Logan_, librep: you need to call dh_autoreconf after applying the patch ...
<doko> and b-d on it
<cjwatson> doko: infinity was dealing with that
<cjwatson> Logan_: ^-
<doko> ahh, ok
<cjwatson> (since it's actually a bit more complicated, with an insane stack growth direction check that's misfiring)
<infinity> Yeah, I'm on top of that, after we get the next respin going.
<doko> now preparing the openjdk-7 security update ...
<infinity> doko: post-release, I assume.
<doko> infinity, hmm, ok ... can I already upload?
<infinity> tjaalton: Can you do an upload that reintroduces those transitional packages, then you can drop them in 14.10.
<cjwatson> doko: your gts sync failed to build on ppc64el
<infinity> doko: Stage it in the security PPA with the security team, IMO.
<doko> yes, seen
<infinity> doko: Then they can release it post-release.
<infinity> doko: You're aware you've had a build going (hung, I assume) on kelsey01 since Mar28? :P
<doko> no?
<infinity> doko: Well, now you are. :)
<infinity> Logan_: librep fixed for you, you can stop worrying about it.
<Elv1313> xnox: ping
<xnox> Elv1313: hi.
<Elv1313> hi, 2 weeks ago we talked about #1303897 and #1299967
<xnox> bug #1303897
<Elv1313> you said that we could eventually apply the patches if nobody stepped in, is this still the case?
<ubottu> bug 1303897 in sflphone (Ubuntu Trusty) "sflphone-kde may hang on startup with some contact topologies" [High,Triaged] https://launchpad.net/bugs/1303897
<xnox> bug #1299967
<ubottu> bug 1299967 in sflphone (Ubuntu Trusty) "sflphone do not start" [High,Confirmed] https://launchpad.net/bugs/1299967
<Elv1313> we get a lot of emails for this, and this is understandably quite critical, so it would be nice if the patches could be merged
<infinity> tjaalton: Ideally soon. :P
<tjaalton> infinity: not before maybe 2200utc when i should be back home :/
<k1l> hi
<k1l> will the 12.04 LTS to 14.04 LTS upgrade path opened right tomorrow on the 14.04 release or will that wait until 14.04.1 (like it was on 10.04 to 12.04)?
<infinity> k1l: The latter.
<k1l> infinity: ok, thanks. than we will brief the #ubuntu team for the "but i dont see the LTS upgrade nofication" concerns tomorrow :)
<jodh> bdmurray: hi - could you take a look at bug 1300235 (and dups)? - apport is marking them as Upstart bugs, yet all the core files relate to chrome.
<ubottu> bug 1300235 in upstart (Ubuntu) "init crashed with SIGSEGV" [Undecided,Confirmed] https://launchpad.net/bugs/1300235
<bdmurray> jodh: yeah, I'll have a look
<jodh> bdmurray: thanks!
<bdmurray> jodh: it'd be neat if UpstartRunningSystemJobs was sorted
<pitti> jodh, bdmurray: ExecutablePath: /sbin/init
<jodh> pitti: sure, but try running file on the gunzip'd core file.
<pitti> jodh, bdmurray: /opt/google/chrome-unstable/chrome  -> that's not something we ship, is it?
<pitti> jodh, bdmurray: might the above actually be a symlink to upstart, or might that execve(upstart) for its session management?
<pitti> https://launchpadlibrarian.net/171353712/ProcMaps.txt looks fairly much like upstart
<jodh> pitti: ProcCmdline is "/sbin/init", and not "/sbin/init --user" so unless all these folk are running chrome as pid 1...
<jodh> pitti: agreed.
<pitti> jodh: so, this is clearly an invalid bug as it's something utterly funky
<jodh> pitti: but it's consistently funky. apport bug?
<pitti> I suppose /opt/google/chrome-beta/chrome is the upstream chrome installer
<pitti> well, it gets called on /sbin/init
<pitti> I'm really curious what kind of black magic /opt/google/chrome-unstable/chrome is
<pitti> (but then again, not curious enough to actually find and install chrome.. -- that's not even the packaged chromium-browser)
<pitti> jodh: also, it's clearly pid 1
<pitti> (see ProcStatus.txt)
<pitti> jodh: so it's system upstart indeed, not session
<jodh> pitti: right, so where have these core files come from?
<jodh> pitti: none of them has a system job that runs chrome so I'm confused
<pitti> jodh: yes, so am I
<pitti> jodh: I don't know where file takes the program from, supposedly from some memory block of the core dump
<pitti> jodh: probably best to ask the reporter for an ls -l of that chrome thing, whether it's reproducible, and an strace; like that the data isn't very helpful
<pitti> jodh: or just invalidate it, given that it's unsupported sw
<Logan_> infinity: thanks :)
<Logan_> odd that I skipped over configure
<alkisg> Hi, I downloaded the trusty daily x64 iso today, and dd'ed it to a usb stick, and it failed to load with "tried to read past end of file" and "invalid pointer" etc... should I file a bug, or is it a known one, or is it too late?
<alkisg> *on an uefi pc
<alkisg> Grub showed up fine, but it couldn't load the kernel
<shadeslayer> alkisg: sounds like a broken ISO
<shadeslayer> did you md5sum it?
<alkisg> Let me check...
<alkisg> $ md5sum trusty-desktop-amd64.iso
<alkisg> 0a884e0fe10f703493a4f8ff993be5fd  trusty-desktop-amd64.iso
<alkisg> http://cdimage.ubuntu.com/daily-live/current/MD5SUMS => same
<alkisg> It's ok...
<shadeslayer> okay, did you run the self check on the ISO?
<alkisg> It's on a USB stick, I don't think it's likely that it wasn't written ok,
<alkisg> ...I can do it in 3 hours, because I'm copying a big disk via USB and it'll take 3h to finish...
<alkisg> Ah, I can use a different PC, moment...
<alkisg> First, the error: attempt to read or write outside of disk `hd1'.
<alkisg> unaligned pointer 0xd804ac68
<alkisg> Aborted. Press any key to exit.
<alkisg> The memory test produces the same error on UEFI, let me disable it so that syslinux loads...
<alkisg> Hrm it does the check and then powers off without showing me the result, even without 'quiet splash'... /me tries to launch it in text mode...
<alkisg> ...nothing with "Boot: check" either... /me will md5sum the contents manually...
<doko> stgraber, can you update the package sets before release please? cjwatson pointed me to you (as a tb member), e.g. the core set still lists gccxml and emacs23
<stgraber> doko: we can't do automated updates at this point because the script is doing a lot of things that are wrong and need fixing, so if you give me a specific list of changes I can do it, otherwise it'll have to wait until at some point post-release
<stgraber> doko: note that core isn't tied to any upload privilege, so having it not entirely accurate isn't preventing anyone from uploading those
<doko> stgraber, well, I see these two ones at least. llvm-toolchain-3.3 too
<doko> looking at http://qa.ubuntuwire.com/ftbfs/ where these sets are used too
<doko> stgraber, can you make a note for the release process (wiki page?) that this isn't forgotten the next time?
<alkisg> shadeslayer: the md5sum of /dev/sdb was not the same as the .iso, thanks + sorry for the noise
<bdmurray> jodh: its also interesting that bug 1300235 and all its duplicates are using an old version of upstart
<ubottu> bug 1300235 in upstart (Ubuntu) "init crashed with SIGSEGV" [Undecided,Confirmed] https://launchpad.net/bugs/1300235
<seb128> bdmurray, jodh: is chrome(os?) shipping a copy of upstart or what?
<stgraber> doko: core is usually generated from the seeds so they should be all fine once we get the script to work properly
<arges> bdmurray: can I have a review of pacemaker in the precise upload queue? I uploaded so I belive I'm not supposed to accept it.
<bdmurray> arges: I'll have a look today
<arges> bdmurray: thanks
<dobey> what image build am i supposed to get if i flash right now? flashing to trusty is giving me 294, and trusty-devel says my device is not found on the server
<bdmurray> arges: accepted
<arges> bdmurray: thanks
<alkisg> Ouch the trusty .iso doesn't fit on a 1 GB USB stick...
<cjwatson> alkisg: unfortunate, but probably too late to fix
<Logan_> cjwatson: is it worth keeping trafshow if it's dead upstream?
<Logan_> ...lol
<cjwatson> Logan_: there was no mention of that in the removal request
<cjwatson> I'm not going to research upstream status for all of these :)
<alkisg> cjwatson: sure I don't think it'll be an issue, I just didn't notice the `dd` stderr the first time, and it took me a while to figure out why I had boot errors... :)
<Logan_> cjwatson: no, of course not - I wouldn't expect that
<Logan_> my "lol" was at the fact that we spoke within a second of each other
<Logan_> I added a comment to the bug :)
<tjaalton> infinity: ok I'm here
<tjaalton> uploaded
<infinity> tjaalton: Ta.
#ubuntu-devel 2014-04-17
<Laibsch1> I'm trying to recompile gimp 2.6 for trusty (I hate the new 2.8 interface and its impedance to simple workflows).  I run into http://paste.debian.net/94136/  How can I fix that?  I'm basing my work on the https://launchpad.net/~malcscott/+archive/gimp-2.6/ PPA that compiled gimp 2.6 for saucy and raring.
<dholbach> good morning
<Laney> happy distro-info-data outdated day
<Laney> :-)
<kdeuser56> it seems there are some major problems with linux-crashdump package
<kdeuser56> 1.) it does not get enabled by default ... /etc/default/kdump-tools  does set 0 and comment out vital options to make it work
<kdeuser56> (according to the wiki installing linux-crashdump and reboot should make it work, which is apperently not the default behavior with the current package)
<kdeuser56>  cat /sys/kernel/kexec_crash_loaded will show 0 after reboot
<kdeuser56> So I manually enabled the options in /etc/default/kdump-tools and rebooted
<kdeuser56> now  cat /sys/kernel/kexec_crash shows 1
<kdeuser56> dmesg | grep -i crash does not indicate memory has been reserved for the crash kernel
<kdeuser56> simulating a kernel crash just freezes the system, no kernel is started
<kdeuser56> only a kexec_cmd can be found in /var/crash afterwards
<dholbach> jamesh, happy birthday! :)
<zyga> kdeuser56: I'
<zyga> kdeuser56: I'm not sure that's the case but I believe we disable some kernel crash debugging for non-development releases
<kdeuser56> zyga: ?
<kdeuser56> zyga: my install is from the daily image days
<kdeuser56> zyga: okay how to enable it?
<kdeuser56> zyga: https://wiki.ubuntu.com/Kernel/CrashdumpRecipe and https://help.ubuntu.com/12.04/serverguide/kernel-crash-dump.html do not confirm what you say
<seb128> mardy, hey, could you have a look to bug #1194465 and reassign it if needed? it's a segfault in libsignon-glib, could be a bug in the client code or in the lib...
<ubottu> bug 1194465 in unity-scope-gdrive (Ubuntu) "scope-runner-dbus.py crashed with SIGSEGV in auth_session_remote_object_destroyed_cb()" [Medium,Confirmed] https://launchpad.net/bugs/1194465
<mardy> seb128: OK
<seb128> mardy, thanks
<kdeuser56> zyga: do you know who to ping in order to get help?
<zyga> kdeuser56: I don't know, I'm sorry
<kdeuser56> zyga: does it work for you?
<zyga> kdeuser56: I don't use that
<kdeuser56> guy with the same problem http://comments.gmane.org/gmane.linux.debian.user/459540 no solution :-(
<hyperair> yay i has non-fugly chromium again.
<infinity> happyaron: That ubuntukylin-default-settings doesn't actually contain the change it claims to.
<happyaron> infinity: re-uploading
<infinity> happyaron: So, uhm.  We had planned to release in hours.  Did you really want to respin and retest all your images?
<infinity> happyaron: Well, all two of them.
<happyaron> infinity: that really depends on the will of JackYu, not mine.
<cjwatson> JackYu didn't answer that question when I asked them on #-release
<infinity> :(
<cjwatson> So it's kind of hard to tell what their will is
<kdeuser56> sudo kdump-config load gives me "efi memory descriptor version 0 is not supported!"
<jamesh> dholbach: thanks!
<infinity> kdeuser56: ubuntu-bug kdump-tools
<kdeuser56> infinity: any idea what I could try?
<happyaron> cjwatson: they asked me in #ubuntukylin-devel for uploading
<infinity> kdeuser56: You could try filing a bug.
<cjwatson> happyaron: yeah, that's not quite the same thing as a multi-hour respin cycle
<kdeuser56> infinity: always instantly filing a bug without doing research is bad behavior
<infinity> happyaron: Can you determine if they really intend for a respin (about an hour from now, it would be), and then re-validating the ISOs, all within, say, 2/3 hours?
<cjwatson> bug 1308889 is pretty bad for polish, I'll grant
<ubottu> bug 1308889 in Ubuntu Kylin "ubuntu-kylin-docs was not installed by default in latest image" [Critical,New] https://launchpad.net/bugs/1308889
<happyaron> infinity: let me ask again
<infinity> cjwatson: I totally read your sentence as Polish, not polish, and was monumentally confused.
<happyaron> infinity: they say yes.
<infinity> happyaron: Alright.  Let's shove this through as quickly as we can manage, then.
<maclin> infinityï¼yeap, we want to check the problem before final release. We will re-validating the ISO asap
<cjwatson> rbasak: it looks as though mod-auth-mysql has been ported, and it's in trusty; see https://launchpad.net/ubuntu/+source/mod-auth-mysql/+changelog.  Do we still need to proceed with bug 1278995?
<ubottu> bug 1278995 in mod-auth-mysql (Ubuntu) "Please remove mod-auth-mysql from Trusty" [Undecided,Confirmed] https://launchpad.net/bugs/1278995
<cjwatson> dead upstream or not, it's useful enough that I'm sort of inclined to keep it if it's working
<jibel> mvo, could you look at bug 1308657 ? it is another multiarch upgrade issue similar to grep:i386 but in this case apt prefers to upgrade the foreign arch than native and fails to find an upgrade path.
<ubottu> bug 1308657 in ubuntu-release-upgrader (Ubuntu Trusty) "Ubuntu 13.10 to 14.04: failed to upgrade libsmbclient:amd64 with libsmbclient:i386 installed." [High,Triaged] https://launchpad.net/bugs/1308657
<mvo> jibel: I have seen it, I'm a bit unsure what to do about it
<mvo> jibel: but let me have another look right now
<mvo> jibel: (and thanks for making me aware of the issue)
<maclin> infinity, ubuntukylin-default-settings becomes ready, should we request a rebuild now?
<infinity> maclin: I'm going to rebuild for you in a just a second when the mirror settles.
<maclin> infinity, nice, thanks a lot:)
<rbasak> cjwatson: I'm not sure if it's working. When I looked, I got the impression that it would be functionally broken without a significant port, due to API changes
<rbasak> xnox: ^^ any thoughts? Do we have something that builds now, but is actually functionally broken?
<xnox> rbasak: which package / bug are you talking about?
<rbasak> xnox: sorry, https://bugs.launchpad.net/ubuntu/+source/mod-auth-mysql/+bug/1278995. See backscroll.
<ubottu> Launchpad bug 1278995 in mod-auth-mysql (Ubuntu) "Please remove mod-auth-mysql from Trusty" [Undecided,Confirmed]
<rbasak> xnox: looks like you fixed the FTBFS, but when I looked previously I left it because it looked like more major changes were needed to get it functional with Apache 2.4.
<xnox> rbasak: right, i found patch on upstream bug tracker and fixed FTBFS, because that was quickest way to complete a transition or some such.
<xnox> rbasak: if it's buggy we can sru fixes for it.
<xnox> rbasak: no need to remove it.
<rbasak> xnox: ok. cjwatson: I'll mark the bug invalid, thanks.
<cjwatson> jamespage: do we still want to do bug 1252375?  the samba migration issues seem to have been long since solved
<ubottu> bug 1252375 in zentyal-samba (Ubuntu) "Please remove zentyal-samba + zentyal-printers from trusty" [Medium,Confirmed] https://launchpad.net/bugs/1252375
<cjwatson> (by way of Depends: samba (>= 4) | samba4, apparently)
<infinity> happyaron / maclin: Your images are done, please test in a hurry.
<jamespage> cjwatson, hmmm - I don't actually have any way of confirming that its functional
<happyaron> infinity: thanks!
<infinity> happyaron: Please do make sure it's done very quickly, I intend to push things our quite soon.
<infinity> s/our/out/
<happyaron> ok
<cjwatson> xnox: similarly, Adam fixed node-stringprep's build a day after you filed bug 1264691 - do we still need that?
<ubottu> bug 1264691 in node-stringprep (Ubuntu) "RM from -release / demote to -proposed, not in testing, FTBFS, possibly incompatible with current nodejs" [Medium,Confirmed] https://launchpad.net/bugs/1264691
<maclin> infinity, thanks, we will do the test asap
<infinity> maclin: Ta.
<xnox> cjwatson: mark invalid.
<cjwatson> xnox: ok, will do, thanks
<cjwatson> jamespage: I guess if there's doubt I'd prefer to leave it in its current state and maybe SRU fixes
<cjwatson> running out of time :)
<jamespage> cjwatson, ok - leave it in then
<maclin> infinity, there are no zsync file?
<maclin> infinity,  I get an error when download the image:  The requested URL /ubuntukylin/daily-live/20140417.1/trusty-desktop-i386.iso was not found on this server
<cjwatson> infinity: did you let the Mythbuntu people know to mirror their images, btw?
<infinity> cjwatson: Who was asking for that?
<infinity> cjwatson: They should probably also *test* their images. :P
<cjwatson> infinity: tgm4883 and Daviey
<JackYu> hi infinity, the images of 20140417.1 for Ubuntu Kylin is still not ready, according to http://cdimage.ubuntu.com/ubuntukylin/daily-live/
<cjwatson> odd, no obvious rsync activity on nusakan
<JackYu> infinity, cjwatson, should we rebuild it again?
<cjwatson> no no no no no no no no no
<cjwatson> zaniah has plenty of space, though it is pretty low on inodes
<cjwatson> but there are only 5000-odd files on cdimage; that can't be making a huge dent there
<cjwatson> I've poked another sync to see if that helps
<cjwatson> oh, there we go, either that worked or it had caught up by itself just before
<cjwatson> JackYu: http://cdimage.ubuntu.com/ubuntukylin/daily-live/20140417.1/ looks fine now
<infinity> \o/
<cjwatson> JackYu: for reference, hitting rebuild for this kind of internal mirroring thing will be actively counterproductive, so please don't reach for that first
<JackYu> wow, great!
<JackYu> cjwatson, sure:)
<stokachu> if there is one script in a package that depends on python2 and the rest is python3 is it acceptable to use a Depends: python2 for just that package containing the file?
<hallyn> bdmurray: hi, the libvirt saucy-proposed addressed 4 bugs;  3 are verification-done, one apparently is not fixed, but nothing regressed.  i think security team wants to push something.
<hallyn> bdmurray: can we promote the libvirt to -updates, or should i push a new package without the 4th (unverified) fix?
<hallyn> (in which case i'd do it after security teampushes a new one)
<infinity> maclin: Are you happy with your ISOs?
<maclin> infinity, sorry that we are still syncing the ISOs. the network is so slow...
<infinity> maclin: I see lots of tests registered for your ISOs, so someone has tested them, I assume...
<infinity> maclin: But no one's marked them ready.
<maclin> we have submit test results of 20140417 ISO.
<maclin> I cannot confirm wheather the new ISOs would be downloaded before I mark the tracker ready.  So the results are submitted.
<anas98999> Hi
<LocutusOfBorg1> Hi people! ready for the release?
<jayaura> bad news http://geebzor.com/tech/linux/canonical-delays-release-of-ubuntu-14-04-trusty-tahr/
<jayaura> well I dont know if this is authentic, someone posted that in the other channel
<cjwatson> it's nonsense
<cjwatson> and please don't pollute #ubuntu-devel with #u-r-p madness :)
<mdeslaur> hehe
<Laney> cjwatson: Would you please voice me in #-release
<AndroUser> Hola
<cjwatson> done
<Laney> ta
<bdmurray> hallyn: how are you certain that libvirt has not regressed?
<hallyn> bdmurray: 3 other verification-done's with no regressions reported? :)
<hallyn> bdmurray: the one which was not verified was the scaries one so if you want to drop it i'm ok with that
<hallyn> scariest
<hallyn> let's just do that.
<hallyn> mdeslaur: ^ you have something to push for libvirt saucy-security?
<hallyn> pls just drop what's in -proposed
<mdeslaur> hallyn: eventually, yes
<mdeslaur> hallyn: it can still wait a while if there's a chance someone will verify it
<hallyn> mdeslaur: no verification failed on one out of 4.  so i'll have to re-push a version with only the other 3.
<hallyn> bdmurray: ^ after that do the three bugs need to be re-verified?
<bdmurray> hallyn: hmm, I'm not positive.
<hallyn> bdmurray: well i pushed a new one without the bad fix.  reverification should be simple actually.  is smb around to re-verify bug #1248025 ?
<ubottu> bug 1248025 in ubuntu-cloud-archive "[SRU] libvirt-bin fails to start inside Xen" [High,Confirmed] https://launchpad.net/bugs/1248025
<smb> hallyn, I am around
<smb> hallyn, So I should look at 1.1.1-0ubuntu8.9
<hallyn> smb: no
<hallyn> .10, if bdmurray accepts it
<smb> Ah ok
<tych0> hi all, i have a package that has both python2 and python3 code in it (related to upstream stuff that we're gluing together; I can't change either)
<tych0> is there a nice way to include these both in the same source package?
<tych0> or do i need two separate source packages?
<smb> hallyn, ok. I got a guest ready which shows to issue with current updates version. So I can verify when you yell (after it gets accepted) :)
<hallyn> smb: thanks
<hallyn> zul: bug 1304167 i intend to push a new libvirt as soon as trusty is open for srus.  do you have anything to add?
<ubottu> bug 1304167 in libvirt (Ubuntu) "syntax error, trusty beta-2 cloud image" [High,Confirmed] https://launchpad.net/bugs/1304167
<zul> hallyn:  nope
<hallyn> ok i'll just push it now then
<hallyn> infinity: if i'm pushing somethingn for trusty-proposed, i don't gum up the works for release at all do i?
<hallyn> i.e. shoudl i wait a few hours?
<infinity> hallyn: You can upload it.
<hallyn> thx
<xnox> infinity: hallyn: wrong version number, it should be 1.2.2-0ubuntu13.1 for an sru?! =)
<hallyn> gah
<hallyn> xnox: well to be fair i expect the first t+1 upload to be 1.2.3 by zul :)
<xnox> hallyn: might be ok, just being pedantic =)
<hallyn> i assume you've rejected?
<hallyn> no no i'll reupload
<xnox> hallyn: i am nobody
<hallyn> pshaw
<infinity> hallyn: I'll reject for you.
<hallyn> thanks
 * hallyn hangs his head in shame.  again
<zyga> hey, when will u-series archive open?
<hallyn> bah, i'm mor einterested in what follows z, and what sort of names can we do starting  with 'aa' :)
<hjd> hallyn: aardvark? :)
<hallyn> yeah but for an adj?  maybe we should switch to dutch
<smb> hallyn, Is libvirt for Saucy getting in foreseeable future?
<smb> in in ...
<hallyn> bdmurray: ^
<bdmurray> hallyn: accepting
<hallyn> thanks
<hallyn> smb said he'll verify asap today, i'll verify the other bug today as well
<hallyn> so hopefully we can get this thing done
 * smb jsut grabs a bite while things are building
<jcw4> Is this the right channel to ask about https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1258642
<ubottu> Launchpad bug 1258642 in gdb (Ubuntu) "gdb: Python 3 incompatible with libstdc++ pretty printers." [High,Confirmed]
<dobey> jcw4: that sounds like it might be an upstream python issue?
<jcw4> I guess.. on my machine I don't even seem to have python3 installed
<jcw4> and certainly not the files mentioned in the workaround
<jcw4> or the patches
<dobey> then what's the issue?
<dobey> are you on 12.04 or something?
<jcw4> dobey: uh. yeah I think so.
<jcw4> :(
<jcw4> Isn't that the latest LTS
<Meerkat> it is.
<dobey> no
<dobey> 14.04 is now :)
<dobey> welcome to release day
<Meerkat> !isitout
<ubottu> No Meerkat, it's not out yet. It's due out some time on the 17th :)
<jcw4> lol
<dobey> well, python3 is installable on 12.04 as well, it's in the archives, i just don't think it's installed by default on 12.04
<jcw4> actually I am on 13.10
<jcw4> I thought I was on 12.04
<dobey> oh
<dobey> on 13.10, python3 is definitely installed by default
<jcw4> S 10:52:31 [0]$ python --version
<jcw4> Python 2.7.5+
<jcw4> I certainly didn't change any python packages myself
<dobey> "python" will never be "python3"
<dobey> you have to use "python3" not "pythoN"
 * jcw4 smacks forehead
<jcw4> okay so I have python3 but I don't have the printers.py file referenced in the fix
<jcw4> dobey: thanks.  It sounds like I'll need to try and rebuild gdb
<dobey> jcw4: /usr/share/gdb/python/gdb/printing.py is probably the file referenced
<dobey> or maybe not
<jcw4> dobey: I'll look for that... locate printing.py didn't work for me before
<jcw4> ah, but after doing updatedb it did
<smb> hallyn, Ok, verification done for bug 1248025
<ubottu> bug 1248025 in ubuntu-cloud-archive "[SRU] libvirt-bin fails to start inside Xen" [High,Confirmed] https://launchpad.net/bugs/1248025
<hallyn> smb: wow it built already?
<hallyn> awesome, thanks
 * hallyn goes to verify the other
<smb> hallyn, amd64 yes
<tarpman> jcw4: didn't the error message from gdb mention the full path to the script causing the problem?
<jcw4> dobey: I did "2to3 -w printing.py" but that doesn't seem to have fixed the problem
<jcw4> tarpman: yes, but the patch in the bugreport applied to the printing.py file not the file with the syntax error
<dobey> no idead
<dobey> idea
<jcw4> dobey thanks for your help
<jcw4> :)
<hallyn> smb: bdmurray: verified bug 1287232
<ubottu> bug 1287232 in libvirt (Ubuntu Saucy) "/usr/lib/libvirt-lxc.so missing from libvirt-dev" [High,Fix committed] https://launchpad.net/bugs/1287232
<tarpman> jcw4: replied to you on the bug
<jcw4> tarpman: hmm.  The patch wasn't for the same file as the error... my error was identical to the one in the original bug report
<jcw4> tarpman you're right I'm sorryy
<jcw4> I confused Martin Olssons comment with the original report
<tarpman> jcw4: that makes more sense. :) so yeah, you'd need a different patch for go's pretty-printer than for the libstdc++ pretty-printer
<jcw4> tarpman thanks
<dobey>  the web site has 14.04 iso download now, btw
 * dobey favors do-release-upgrade though
<jcastro> well done everyone! Here's to another 5 years of trusty!
<mvo_> yeah!
<hallyn> it appears the default vmware vga mem size for pc-1.0 machine type has gone down from qemu-kvm to qemu (precise to raring+).  i.e. bug 1308756.  is it too late to add something to the release notes?
<ubottu> bug 1308756 in qemu (Ubuntu) "pc 1.0 machine type regressed with -vga vmware" [Medium,Confirmed] https://launchpad.net/bugs/1308756
<hallyn> zul: jamespage: ^
<hallyn> eh, i'll add it to https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes
<hallyn> i don't know if that seeds anything else
<bdmurray> robru: Do you know why the account-plugins version is different in the saucy proposed queue from the one in the sru staging ppa?
<chek2fire> hello. Why bitcoin-qt is not in the new version of ubuntu?
<chek2fire> is an open source programme why you have get out of the official repositories?
<tarpman> chek2fire: see the thread starting at https://lists.ubuntu.com/archives/ubuntu-motu/2013-December/007597.html
<ogra_> chek2fire, https://lists.ubuntu.com/archives/ubuntu-motu/2013-December/007597.html
<ogra_> hah
<tarpman> ogra_: ^5
<ogra_> :)
<chek2fire> yes but is a new technology and open source
<ogra_> chek2fire, but it is not nice to not respect the will of the developer of that opensource software
<chek2fire> i think is not nice when you dont follow a new technology like bitcoin
<chek2fire> and you drop it
<ogra_> even if the developer asks you to drop it because he considers his software nnot ready for wider distribution yet
<ogra_> ?
<chek2fire> bitcoin is not for spread to public?
<chek2fire> ready*
<sarnold> bitcoin is not ready to be frozen for five years.
<ogra_> did you read the mail ?
<chek2fire> yes i have
<chek2fire> this decision is only for lts versions?
<ogra_> you have to ask the developer of the software
<ogra_> the mail offers how to install it from them
<ogra_> so they are not bound to the distro release schedule
<chek2fire> ok thx i hope ppa maintainer will release the new bug fix version 0.9.1 without the hearbleed bug
<ogra_> s/offers/describes/
<sarnold> ugh, I hope they don't bundle their own openssl
<sarnold> they should just rely upon the system-supplied openssl
<ogra_> right
<tarpman> the debs in the bitcoin ppa appear (at a glance) to use the system libssl
<chek2fire> a ok
<chek2fire> for that is not need for an update?
<ogra_> 14.04 is safe ... and older releases got it with security system upgrades
<chek2fire> yes i have get the update and now in bitcoin channel they told me that is better bitcoin-qt to has its own ppa
<chek2fire> is more safe
<chek2fire> ok thx again for the info and sorry :)
<chek2fire> and keep the great work with ubuntu guys
<chek2fire> i use the distro 8+ years now
<chek2fire> kubuntu mostly.. :P
<sarnold> chek2fire: thanks :) have fun
#ubuntu-devel 2014-04-18
* infinity changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Limbo | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<blkperl> infinity: you missed one s/saucy/trusty/ in the topic :)
* infinity changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Limbo | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dupingping> Hi
<dupingping> whare is mterry?
<dupingping> Now he is sleeping?
<Unit193> henrix: Howdy.  Alive?
<jtaylor> I guess we can't do srus yet as U isn't open?
<xnox> jtaylor: sure we can.
<jtaylor> doen't they need fixing in +1 first?
<xnox> jtaylor: they do, but +1 isn't open yet. when it opens we copy trusty+trusty-updates into it.
<xnox> jtaylor: we already have 10 or so packages in trusty-updates.
<jtaylor> k thx
<jtaylor> what about packages in -proposed when u opens?
<xnox> jtaylor: follow normal sru process though in terms of version number, sru bug #, sru bug template with test case.
<xnox> packages in -proposed (the non-sru ones) are moved to u-proposed and continue try to get into release pocket
<jtaylor> oh right we have devel proposed now
<xnox> well, devel-* are aliases..... so we still need a codename to open the series.
<bigon> hi
<bigon> https://bugs.launchpad.net/ubuntu/+source/selinux << shouldn't this pkg be dropped in ubunt?
<bigon> ubuntu?
<bigon> this pkg is ubuntu specific and I'm not sure it is still releavant
<dupingping> seyon is what program?
<xnox> bigon: not sure, ask #ubuntu-hardened people about it.
<ncopa> hi
<ncopa> since ubuntu LTS is 3.13, I assume that ubuntu will maintain the 3.13 kernel?
<ncopa> any chence that ubuntu will do that via kernel.org?
<ncopa> so kernel.org can announce 3.13 as longterm?
<psusi> xnox, did the dmraid -> mdadm transition not get finished?  I've now seen at least two bugs where an isw array is still being activated by dmraid instead of mdadm and something is broken with it so the installer crashes
<hallyn> i assume 'any' (i.e. python:any) works just fine in trusty/
<xnox> hallyn: yes.
<xnox> psusi: one can install using either dmraid or mdadm, and mount using either.
<xnox> psusi: please point me to bugs.
<hallyn> xnox: thanks
<psusi> xnox, I just tagged them with "dmraid-transition"... I subscribed you to the first one a few days ago and asked if you had any thoughts on it
<psusi> I thought the plan was for new installs to use mdadm, not dmraid?
<psusi> you certainly must not try to activate it with both at the same time
<xnox> psusi: that was the plan, however the way it's implemented the user is asked twice i believe (once to activate with mdadm and once to activate with dmraid) that's in d-i. I didn't test if the second prompt gets supressed if one chooses mdadm. I should retest that with trusty final.
<xnox> psusi: right, i'll check my bug mail when i'll be back at work on tuesday.
<psusi> xnox, you don't see those prompts in ubiquity though
<xnox> psusi: correct. ubiquity has it's own raid activation script, which should still default to dmraid, i didn't switch that one.
<hallyn> hi, if someone on sru team could approve the device-tree-compiler upload for precise-proposed, i could verify it today (but otherwise am out all next week)
<stgraber> hallyn: let me take a look
<stgraber> hallyn: bad version number
<stgraber> hallyn: your upload has a version number higher than that of quantal
<hallyn> did i really do that?
<stgraber> precise is 1.3.0-2, quantal is 1.3.0-2build1, you uploaded 1.3.0-2ubuntu1
<stgraber> trying to figure out what would be an appropriate version in this case though :)
<hallyn> 1.3.0-2.12.04.1 ok?
<hallyn> no, needs ubuntu, /me checks the security wiki page
<stgraber> you'd usually use ubuntu0.1 but that'll still be higher than quantal
<stgraber> actually, I guess I could just pretend I didn't see this and accept it, quantal is going EOL anyway
<stgraber> so quantal users will have to upgrade to 13.10 at least by the time this hits -updates which will solve the problem
<hallyn> or i can upload 1.3.0-2.12.04.ubuntu1
<hallyn> not sure if the pkging would be happy with that placement of ubuntu
<hallyn> or 1.3.0-2build1~12.04 :)
<stgraber> nah, let's use the cleaner version and pretend quantal already doesn't exist anymore, way easier :)
<hallyn> ok
<stgraber> accepted into proposed
<hallyn> technically we could just use the verbatim pkg from quantal
<hallyn> it's a shame that didn't get sru'd when it originally hit quantal
<jibel> bdmurray, wrt. bug 1309484 I think it's against because there are packages from xrog-edgers ppa and libglapi-mesa cannot be upgraded
<ubottu> bug 1309484 in ubuntu-release-upgrader (Ubuntu) "upgrade to ubuntu 14.04 fails" [Undecided,Confirmed] https://launchpad.net/bugs/1309484
<jibel> s/against/again/
<bdmurray> jibel: ah, thanks. I tested with unity8 and didn't recreate it.
<jibel> bdmurray, I reviewed the upgrade reports today and clearly the winners are xorg-edgers PPA and cinnamon. I found only 1 real upgrader bug with non-ascii strings in srouces.list
<bdmurray> jibel: I saw that and plan on having a look at it next
<bdmurray> jibel: thanks for the help
<jibel> yw
<jibel> bdmurray, however bug 1309499 is a real one I think, in the transition to samba-libs in trusty
<ubottu> bug 1309499 in update-manager (Ubuntu) "Upgrade from 12.04 to 14.04 doesn't work" [Undecided,New] https://launchpad.net/bugs/1309499
<bdmurray> jibel: is that the same a bug 1308657?
<ubottu> bug 1308657 in samba4 (Ubuntu Trusty) "Ubuntu 13.10 to 14.04: failed to upgrade libsmbclient:amd64 with libsmbclient:i386 installed." [High,Triaged] https://launchpad.net/bugs/1308657
<jibel> bdmurray, I don't think so, because only the amd64 version is installed.
<jibel> bdmurray, the problem is somewhere in http://paste.ubuntu.com/7276754/ libsmbclient-raw0 shouldn't be MarkKeep
<bdmurray> jibel: can you view the aptclonesystemstate file?
<xnox> stgraber: yeah cause 1.3.0-2build1~0ubuntu0.1 is way too ugly.
<jibel> bdmurray, no it is corrupted
<stgraber> xnox: yeah :)
<bdmurray> jibel: did you see the end of main.log? 2014-04-18 14:16:58,385 DEBUG blacklist expr 'update-manager' matches 'update-manager'
<bdmurray> 2014-04-18 14:16:58,385 DEBUG The package 'update-manager' is marked for removal but it's in the removal blacklist
<jibel> bdmurray, yes it's because notification-daemon cannot be installed, but without the pre-upgrade status of the system it is difficult to find why
<bdmurray> How does one restart libvirt or lxc?
<stgraber> bdmurray: for libvirt you need to shutdown all the VMs, then restart libvirt-bin and then start them all up again (unless the change you want to apply doesn't affect the kvm instances in which case you can just restart the upstart job)
<stgraber> bdmurray: for lxc, if all the containers are auto-started, "stop lxc && start lxc" will shut them all down and start them all again
<stgraber> if you have containers which you manually started, then you'll need to manually stop and start them again
<hallyn> is it ok for qemu in main to recommend ovmf which is in multiverse?  or does that need to be suggests?
<hallyn> (it's a new recommends coming from debian)
<stgraber> needs to be suggest, recommends will attempt to pull it in main
<hallyn> ok, thx
<hallyn> then lemme fix that in the debian git tree first
<Quintasan> Hi, I'm trying to further debug https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1309611 any ideas what else I should provide?
<ubottu> Launchpad bug 1309611 in upower (Ubuntu) "UPower thinks there is no batter nor lid on Lenono ThinkPad T430" [Undecided,New]
<hallyn> infinity: i'm finishing up the 2.0.0+dfsg-2ubuntu1 for trusty-proposed, fwiw.  pkg is just about ready, time to start testing.  letting you know as i'm not sure what schedules look like or how exactly how this will be handled
<hallyn> http://paste.ubuntu.com/7277057/  the debdiff
<hallyn> zul: ^
<infinity> hallyn: It'll be handled like any other SRU, more or less, except I'll be a bit more slack about the feature/bugfix ratio.
<infinity> hallyn: I do hope that diff is at least readable, though...
 * infinity looks.
<infinity> -Provides: ${sysprovides:arm}, ${sysprovides:arm64}
<infinity> +Provides: ${sysprovides:arm}
<infinity> That seems suspect.
<hallyn> infinity: sysprovides:arm64 doesn't exist
<hallyn> iiuc
<hallyn> bc we moved all of arm64 into arm
<infinity> hallyn: Okay.  So, my plan here will be to fairly carefully review the packaging changes to see if they're all sane, then baroadly review the upstream changes.
<infinity> hallyn: An upstream ChangeLog would be nice (I don't see one, maybe a git log between rc1 and final would be nice to go over?)
<hallyn> infinity: sure, where shoudl i put it?
<infinity> hallyn: Not necessarily in the package, but perhaps tossed in whatever bug we close with this upload.
<hallyn> infinity: fwiw i'm out all next week, so trying to finisih this up today as much as possible
<hallyn> (else i'll hand over to , i dunno, zul :)
<hallyn> ok, i'll post it to bug 1309452
<ubottu> bug 1309452 in qemu (Ubuntu) "Merge 2.0.0+dfsg-2 to fix spice crashes" [High,In progress] https://launchpad.net/bugs/1309452
<hallyn> (posted the diff)
<hallyn> hm, ihave a doubt
<hallyn> oh nm
<hallyn> build went fine, running qrt
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Limbo | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<hallyn> infinity: checks all pass, so unless you have comments, i'll push?
<infinity> hallyn: I haven't had the time to have comments.
<infinity> hallyn: (As in, I haven't been looking at it at all since you first brought it up)
<hallyn> that's how i read it :)
<infinity> hallyn: But if you want to push it at the queue, I guess I can reject if I have comments. :P
<hallyn> infinity: that sounds, thanks.  hopefully in that case rharper will pick it up and address the comments
<hallyn> i'm also sort of hoping it fixes win7 on smp, but we'll have to see
<Logan_> infinity: I just set up an ifttt recipe to text me if sabdfl adds a new post to his blog :P
<infinity> Logan_: Hah.
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Limbo | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2014-04-19
<psusi> ok, so how do you bloody debug udevd?  its' stuck in an infinite loop processing change events that apparently trigger another change event ad infinitum
#ubuntu-devel 2014-04-20
<dupingping> grdesktop project is died?
<dupingping> Then What replace it?
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Limbo | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
<xnox> I'm happy to review SRU uploads, and uploads into Debian. If you have questions or need sponsorship, just ping me.
<mdeslaur> xnox: you know it's the weekend, right? :)
<infinity> mdeslaur: In Soviet Russia, week ends you?
<mdeslaur> infinity: hehe
<xnox> mdeslaur: i am bored, because somebody didn't write a blog post yet.
<mdeslaur> xnox: about what?
<xnox> mdeslaur: about getting his umbrellabird unnamed
<xnox> infinity: also ubiquitous is a real word... my pronunciation of it was complete wicked however.
<infinity> xnox: Of course ubiquitous is a real word, I'm pretty sure that's not the word you were using last week...
<xnox> infinity: that's the one i meant, i was pronouncing it more like "ubitious" which is almost half the sounds dropped.
<mdeslaur> xnox: oh wow, it took me a while to figure out what the heck you were talking about :)
<mdeslaur> nice :)
<dupingping> Hi
<dupingping> everybody
<dupingping> How to register new loco team?
<wolter> If I solve a bug in a personal branch, to which branch should I propose the merge? Stable, trunk?
#ubuntu-devel 2015-04-13
<Ionic> hi
<Ionic> stupid question: how do I get the build logs for packages built on launchpaid?
<Ionic> s/paid/pad/
<Ionic> hm, maybe via the "built" link in a package detail view
<Ionic> ah, indeed, there's a buildlog
<rbasak> pitti: in bug 1347859, there's a claim that systemd is doing things to do with biosdevname in addition to the biosdevname package on some distributions. Do you know if this is accurate for Ubuntu?
<ubottu> bug 1347859 in ubuntu-meta (Ubuntu) "Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems" [Undecided,New] https://launchpad.net/bugs/1347859
<rbasak> cjwatson: looking at ^^ bug. Am I right in understanding that the intention was to never introduce biosdevname interface renaming on distribution upgrades? The reporter seems to claim it happened, but I see no relevant code that was cause it to happen. Presumably he shouldn't have had biosdevname installed before the upgrade and not after either, as the only thing that installs it is the installer?
<mantas-baltix> hi devs ;)
<tseliot> Riddell: so, I've filed LP:Â #1443364 , which only affects hybrid graphics and systemd. All users should be affected, regardless of the desktop environment. I wrote about a manual workaround in LP: #1428328
<ubottu> Launchpad bug 1428328 in nvidia-prime (Ubuntu) "nvidia-prime needs sddm support" [Medium,Fix released] https://launchpad.net/bugs/1428328
<Riddell> bug 1443364
<ubottu> bug 1443364 in ubuntu-drivers-common (Ubuntu) "gpu-manager systemd unit doesn't always work as expected" [Critical,Triaged] https://launchpad.net/bugs/1443364
<ogra_> pitti, poke ...
<mantas-baltix> Hi, I stuck on important issue with building packages from recipe - can't build package imported from GIT - bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository
<mantas-baltix> This issue exists for few months and other people also are affected, see https://answers.launchpad.net/launchpad/+question/264781
<mantas-baltix> and bug #1433680
<ubottu> bug 1433680 in Launchpad itself "NoSuchRevision error during recipe build" [Undecided,New] https://launchpad.net/bugs/1433680
<mantas-baltix> bug is reported a month ago, 2 answers are asked, what should I do?
<cjwatson> rbasak: I haven't looked at the details, but I don't *think* we meant to introduce this on upgrades
<rbasak> cjwatson: thanks. I don't see how we might have introduced it on upgrades either, but I might have missed something.
<pitti> Good morning!
<pitti> rbasak: in Debian/Ubuntu we disable the predictable interface names (similar, but not identical to biosdevname) by default; you can enable them wit net.ifnames=1
<rbasak> pitti: OK. Thanks!
<rbasak> I'll write an initial response in the bug.
<pitti> rbasak: I'll have a look at the bug and follow up there
<pitti> ogra_: hey
<ogra_> pitti, so i just wasted half my day waiting for a one line fix in initrd to migrate from -proposed ... what is the reason we do two fill kernel builds as part of the migration test ?
<ogra_> initramfs-tools shouldnt have anything to do with kernel builds ...
<ogra_> pitti, also, while watching that, i was looking at the boot test on krillin ... it doesnt seem like we ever actually boot the initrd that gets produced by the package ... what are we testing there ?
<pitti> ogra_: ah, in urgent cases you can certainly ask the RT to push that through faster
<pitti> ogra_: apparently initramfs-tools depends on kernel packages, we do reverse dep testing
<ogra_> pitti, by doin a complet binary build of the dep ?
<ogra_> that seems the wrong way round
<pitti> ogra_: ah yes, that certainly isn't necessary for initramfs-tools uploads
<ogra_> right ... do we have some kind of overrdie file that we could add this to ?
<pitti> ogra_: we added that mostly for the purpose of testing gcc, binutils, glibc uploads
<pitti> ogra_: not right now; we can add a "reason why this test is running" once we have non-retarded infrastructure to run these tests, and indeed the linux triggers come up every other week
<pitti> but not with our current CI system, I'm afraid :(
<ogra_> :(
<ogra_> ok
<ogra_> pitti, what about the boot tests ... what do they actually test ?
<pitti> ogra_: these are vila's; I think they mostly just instsall the proposed package on a touch image and see that it still boots and ends up in unity
<ogra_> i dont see anything replace the initrd on the device (and it wouldnt be possible on krillin without a complete device tarball build)
<pitti> (I don't know what exactly they do, I'm afraid)
<ogra_> ah
<ogra_> so for initramfs-tools that would be pointelss as well
<ogra_> (at leats on phones)
<pitti> ogra_: I thought boot tests are triggered by packages which are installed on touch; is it?
<pitti> ogra_: but perhaps CI has a blacklist for such cases
<ogra_> yeah, that would be nice
<ogra_> currently that test (in case of initramfs-tools) is just uselessly wasting time
<pitti> rbasak: oh, that bug is old, and not systemd specific; so it's rathe specific to ubuntu server which has installed biosdevname for a while?
<rbasak> pitti: looking back (I've linked from the bug), all our alternate installers have been installing biosdevname for a while.
<pitti> tseliot: the u-d-c fix was just accepted by the RT team FYI
<tseliot> pitti: great. Thanks again!
<tseliot> Riddell: the fix for the hybrid graphics issue ^
<pitti> smoser, infinity: all the wolfe VMs seem to be AWOL; do you have a minute to have a look?
<fionnan> Anyone getting `ERROR: Could not generate AppArmor profile for docker_docker_1.5.0.002.json...` when installing docker on a fresh snappy instance?  Traceback here: http://pastebin.com/ChQmLUmq
<seb128> pitti, I don't remember now, did you see/reply to my ping about langpack updates in vivid?
<pitti> seb128: I don't think so
<pitti> seb128: but anyway, they should be fine again now; we just got a new export from LP
<pitti> seb128: so the next cron run (Tue morning CET) ought to work
<seb128> pitti, Colin said on friday you need to trigger an export
<pitti> seb128: it's on my radar
<seb128> oh ok
<seb128> great
<seb128> thanks
<flexiondotorg> ricotz, Do the new versions of Plank/Docky have the zoom animation when you hover/move over the dock?
<ricotz> flexiondotorg, hi, no ( btw there is #plank )
 * flexiondotorg joins #plank
<elopio> cyphermox: when you have some time, can you please take a look at https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1441893 ?
<ubottu> Launchpad bug 1441893 in network-manager (Ubuntu) "Can't connect to my wi-fi N network on vivid: authentication timed out" [Undecided,New]
<caribou> Laney: I have just rechecked Bug #1442235 regarding InDep depencancies
<ubottu> bug 1442235 in Precise Backports "Please backport openafs 1.6.7-1ubuntu1 (universe) from trusty-updates for HWE enabled systems to continue to work" [Undecided,Confirmed] https://launchpad.net/bugs/1442235
<Laney> caribou: It's uploaded
<caribou> Laney: oh, great. I reran the tests only to find out that I was overriding build_arch_all in my .rc file
<caribou> Laney: thanks a lot !
<Laney> caribou: It's a difference in which rules targets are called between precise & trusty - search for "debian/rules" in the build logs to see
<Laney> no problem!
#ubuntu-devel 2015-04-14
<Ionic> what's the difference between this channel and #ubuntu-app-devel?
<Snow-Man> this one is better
<Snow-Man> (I have no idea)
<RAOF> Ionic: From /topic - âDevel of Ubuntu (not support or app devel)â.
<Ionic> RAOF: yes, but what is "app development" specifically?
<RAOF> Development of apps that run on Ubuntu?
<Ionic> if I have problems with the ubuntu build system for building a package, where do I ask?
<RAOF> Particularly: Ubuntu Touch apps.
<RAOF> #ubuntu-app-devel
<RAOF> Unless you're developing a component of Ubuntu, this is not (the best) channel for you :)
<Ionic> (more like dh_* stuff, but the problem seems to be ubuntu-specific)
<Ionic> ok, thanks
<RAOF> Hm, dh_ stuff is more this channel's forte.
<RAOF> What's seems to be your problem?
<Ionic> well, I have a rather complex source package with multiple subpackages
<Ionic> some libraries, some binaries, some data stuff
<Ionic> one of those binaries naturally depends on libraries build off that source package
<RAOF> As is so often the case, yes...
<Ionic> dependencies are added via dh_makeshlibs/dh_shlibdeps... which works okay-ish for Debian, but seems to be problematic on Ubuntu for some reason
<Ionic> the dependencies are "okay", but incomplete
<RAOF> That's odd; we don't change that infrastructure to any great extent.
<Ionic> not really incomplete more like... minimal
<Ionic> a dependency on other_pkg is added that depends on lib_pkg{1,2,3}
<Ionic> our Debian package also depends on lib_pkg{1,2,3} directly
<RAOF> Ah.
<Ionic> the issue is weird, I'm currently using override_dh_* to run dh_makeshlibs -- -dV and dh_shlibdeps -- -v
<Ionic> (for getting more useful information)
<RAOF> Does base_pkg link directly with lib_pkg{1,2,3}, or does it only link with other_pkg?
<Ionic> I can show you what I mean once the pbuilder run is through
<Ionic> it links directly with lib_pkg{1,2,3}, that's the weird thing
<Ionic> it looks like Ubuntu optimizes this stuff, while Debian is fine leaving it unoptimized
<RAOF> Does it use any symbols from lib_pkg{1,2,3}?
<RAOF> (Directly)
<RAOF> Because we do indeed by default not add transitive dependencies of that nature.
<RAOF> (Although neither will Debian at some point)
<Ionic> of that I'm not sure
<Ionic> meh
<Ionic> -dV was a mistake, now my build failed
<Ionic> dpkg-gensymbols probably wants -d -V for some reason
<Ionic> RAOF: just for reference, can I force Ubuntu to add transitive dependencies?
<Ionic> although, to be honest, I do not understand why the specific user ran into problems anyway
<Ionic> as transitive dependencies should still be fulfilled by minimized dependencies
<RAOF> Ionic: dpkg-shlibdeps *should* be adding a dependency for everything in your DT_NEEDED sections.
<RAOF> (As dumped by objdump -x /path/to/your/thingy | grep NEEDED)
<Ionic> thanks, that will be handy
<Ionic> aha!
<Ionic> the three libraries are not showing up in DT_NEEDED
<Ionic> that's rather new though... older versions of the software have them in DT_NEEDED, so we probably broke something(?)
<RAOF> This likely means that the program doesn't use symbols from those libraries directly, and our default flags pass --as-needed throug to the linker.
<RAOF> Or possibly you broke something :)
<Ionic> ah
<Ionic> well, I can "bisect" at least
<RAOF> --as-needed shouldn't change program behaviour, though, because you'll still load the libraries, just indirectly.
<Ionic> so that's very helpful, thank you
<Ionic> when was -Wl,-as-needed introduced?
<RAOF> Quite a while ago.
<RAOF> 2010 :)
<Ionic> weird... my gentoo system is also listing the libraries in DT_NEEDED
<Ionic> and AFAIK it also uses -Wl,-as-needed by default
<RAOF> Also, -as-needed looks like it was a Wheezy Debian goal :)
<Ionic> so, probably not the cause of this
<RAOF> That's looking likely, yse.
<Ionic> does launchpad PPA have an automatic version history, or is that up to the group/person?
<RAOF> Up to the group/person.
<RAOF> It'll keep old binaries around for a small time, but it's pretty aggressively reaped.
<Ionic> http://pastie.org/private/qhuvueripuwkld2daiyna definitely linking against libNX_{damage,tst,composite} ... and not even using -Wl,-as-needed
<Ionic> hmhmhm.
<Ionic> our release builds are still fine, only nightlies are affected
<Ionic> according to https://launchpad.net/~x2go/+archive/ubuntu/stable/+files/nxagent_3.5.0.31-0%7E605%7Eubuntu14.04.1_amd64.deb anyway
<Ionic> unpacking and examining leads to "NEEDED               libNX_Xdamage.so.1" etc., which is fine
<Ionic> ok, now... what did I break?
<RAOF> :)
<Ionic> the only changes are related to the client part, and adding pointer guards to the server code...
<Ionic> weird, I cannot reproduce that
<Ionic> building myself via pbuilder-dist trusty leads to the same missing libraries in DT_NEEDED
<Ionic> off the 3.5.0.31 release branch ofc
<Ionic> just to make sure I didn't mess up by using the upstream git repo, I've checked out the bzr branch (bzr branch lp:~x2go/x2go/nx-libs_build-main), ran dpkg-buildpackage -S and am now running pbuilder-dist trusty ../nx-libs_3.5.0.31-0x2go1.dsc again
<Ionic> it's missing the "ubuntu..." tag, but I believe this to be a non-issue
<Ionic> 'lo and behold... same issue
<Ionic> at this point I can only assume it's caused by something ubuntu-internal
<RAOF> Ionic: Hm. Feel free to pastebin the pbuilder log or something.
<Ionic> uh, that's huge
<RAOF> True :)
<RAOF> That's why it's in a pastebin!
 * RAOF is going to make dinner now, but will be back later.
<StevenK> RAOF: Dinner at quarter to 4?
<RAOF> *Making* dinner. It then gets to simmer gently until we want to eat it!
<Ionic> well, that crashed my terminal.
<Ionic> www.ionic.de/x2go/ubuntu-pbuilder-paste.gz
<Ionic> I'll need to go to bed, but I'll read the backlog
<Ionic> oh, one more thing maybe
<Ionic> https://launchpad.net/~x2go/+archive/ubuntu/stable/+build/7083881/+files/buildlog_ubuntu-trusty-amd64.nx-libs_2%3A3.5.0.31-0%7E605%7Eubuntu14.04.1_BUILDING.txt.gz < this is the build log for the "same" build on launchpad about a month ago (2015-03-17)
<Ionic> and the package created through that is fine, seriously. https://launchpad.net/~x2go/+archive/ubuntu/stable/+files/nxagent_3.5.0.31-0%7E605%7Eubuntu14.04.1_amd64.deb < that's the file created by that build
<Ionic> feel free to unpack it and check with objdump
<ricotz> flexiondotorg, https://bugs.launchpad.net/ubuntu/+source/plank/+bug/1443773
<ubottu> Launchpad bug 1443773 in plank (Ubuntu) "FFe: Sync plank 0.9.0-1 (universe) from Debian experimental (main)" [Undecided,New]
<RAOF> pitti: Good morning! Would you like to upload a new colord to experimental?
<seb128> RAOF, hyey, he's in Texas this week, maybe not up yet
<RAOF> seb128: Oho!
<RAOF> Well, that invitation is open to all DDs :)
<seb128> RAOF, sorry, I don't have a debian install to build binaries and Debian doesn't accept source uploads, maybe Laney can help when he gets online in 40min or so
<RAOF> seb128: Oh, no urgency.
<tjaalton> RAOF: I can do that :)
<darkxst> cjwatson, hi, is user-setup in ubuntu forked from debian? we have a bug with Automatic Login option, but that code does not exist in debian. see bug 1412791
<ubottu> bug 1412791 in user-setup (Ubuntu) "automatic login configured in ubiquity cannot be disabled by gnome-control-center" [Undecided,New] https://launchpad.net/bugs/1412791
<darkxst> cjwatson, and relevant code: http://bazaar.launchpad.net/~darkxst/user-setup/noTimedLogin/revision/284
<Odd_Bloke> How can I map between Ubuntu versions and codenames in Python?  I'm struggling to get Google to produce anything useful.
<jamespage> Odd_Bloke, python-distro-info
<Odd_Bloke> jamespage: Ah, thanks. Is there documentation for it anywhere?
<jamespage> Odd_Bloke, "pydoc distro_info"
<jamespage> ;-)
<jamespage> Odd_Bloke, UbuntuDistroInfo is probably the class you're interested in
<Odd_Bloke> jamespage: Great, thanks!
<Anupkumar> can any one help me with this bug? https://bugs.freedesktop.org/show_bug.cgi?id=89711
<ubottu> Freedesktop bug 89711 in general "udisksctl loop-setup does not mount some ISOs" [Normal,New]
<Riddell> pitti: can you say why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html should a bunch of regressions on kde bits but when I look at the public links it's all green ?
<Laney> Riddell: Looks like it hasn't synced from the machine which runs them to jenkins.qa.ubuntu.com
<Laney> Riddell: I pinged the people who should be able to see
<Laney> (#ubuntu-ci-eng)
<Riddell> thanks Laney
<LocutusOfBorg1> hi folks :)
<LocutusOfBorg1> ginggs, sometimes people give thanks to developers
<LocutusOfBorg1> and this is for you :)
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1443152/comments/4
<ubottu> Launchpad bug 1443152 in virtualbox (Ubuntu) "BUG: unable to handle kernel paging request at 00007fe416858408" [Undecided,Invalid]
<ginggs> LocutusOfBorg1: it was all your handiwork :)
<LocutusOfBorg1> there is no work without a sponsor ;)
<cjwatson> darkxst: Automatic login is an Ubuntu addition to user-setup, yes.  It should be reasonably clear from the changelog.
<cjwatson> darkxst: You should branch from and propose merges into lp:~ubuntu-core-dev/user-setup/ubuntu, not lp:user-setup.
<cjwatson> darkxst: Then the MP might be comprehensible :-)
<cjwatson> I suspect you just need to resubmit that MP with the correct target branch.
<smoser> pitti, wolfe is back
<smoser> sorry, i was on holiday yesterday
<strikov> Hey guys. Is it possible that /run/systemd/system/ folder disappears from time to time? We're trying to fix juju bug where it can't detect systemd *from time to time* by checking if this path exists.
<strikov> I suspect that the issue is somewhere else but want to make sure that we don't do anything very wrong.
<rbasak> strikov: you know that /run disappears on boot, right?
<strikov> rbasak: yeah, i observe this issue by running juju bootstrap multiple times
<strikov> rbasak: so i don't think that reboot is our problem
<pitti> Good morning!
<pitti> smoser: cheers
<pitti> Riddell: I think the public jenkins is ridiculously behind
<pitti> RAOF: ah, can do; just from git?
<pitti> Riddell: I retried a bunch of failed tests this morning
<pitti> there's still a couple of them left, I'll keep retrying
<pitti> RAOF: want to push a release tag?
<pitti> RAOF: ah, collab-main, I'll do it I guess
<strikov> morning pitti; i just integrated your 'switch to upstart' adt code into juju-1.22.1 (1.23 won't be ready before release); it works nicely but I wonder if it's possible to run this code once during testbed setup; Right now I do this switch at the very beginning of every test and it looks messy;
<cjwatson> bdrung: Would you mind if I uploaded an sbuild merge?  There's a bug fix in Debian that affects building d-i
<bdrung_work> cjwatson, not at all!
<cjwatson> bdrung_work: Thanks.  We're very close to being able to run modern sbuild in Launchpad and it'd be nice to be using a package from Ubuntu for the purpose :-)
<pitti> strikov: (sprint meeting going on, let's discuss later)
<strikov> pitti: sure, thanks
<bdrung_work> cjwatson, why are Debian and Ubuntu have problems to use the packages from the repositories on their build machines?
<cjwatson> bdrung_work: Debian has a load of changes to buildd, nothing significant to sbuild
<cjwatson> bdrung_work: In Ubuntu's case the main blocker has been patches for ddebs, but we're almost over that hump now
<rbasak> pitti: fyi, bug 1431581 looks like it is due to systemd switch, based on https://launchpad.net/ubuntu/+source/nis/3.17-32ubuntu2 from slangasek
<ubottu> bug 1431581 in nis (Ubuntu) "NIS does not install on 15.04" [Undecided,Confirmed] https://launchpad.net/bugs/1431581
<pitti> rbasak: queueing, thakns
<pitti> RAOF: uploaded and release tag pushed
<pitti> Laney: can I ask you to review/accept my apport upload? important security update
<pitti> infinity1: or you &^
<infinity1> pitti: Looking.
<pitti> Laney, infinity1: ah, stgraber is looking already
 * Laney nods
<infinity1> pitti: You should normalize your TZ when generating ChangeLog.
<stgraber> apparently there's no bzr flag for it (we just checked)
<pitti> yeah, sorry about that massive changelog diff
<pitti> perhaps I can call bzr log with $TZ or so
<infinity> stgraber: No, but there's an environ... Yeah.
<pitti> infinity, stgraber: fixed in http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2945, so from now one this shouldn't happen any more
<pitti> except for the next upload which will put the changelog timestamps back
<infinity> pitti: Ta.  That drives me nuts.
<pitti> infinity: is a final full langpack upload okay for next Monday? We often/usually do that on Monday (final translation deadline), but just checking
<pitti> we'll get a cron'ed export on Monday; if we need/want it earlier, I'll ask the LP guys to kick off a manual run
<pitti> wgrant: can we do a manual full vivid langpack export on Thursday, so that we can upload the final packs on Fri?
<pitti> wgrant: I think the cron would only give them to us on Monday, which is too late
<pitti> seb128: FYI, we just got a langpack update for vivid, so cron is working again
<seb128> pitti, \o/
<mdeslaur> kees, infinity, stgraber, slangasek: meeting?
<pitti> kees: TB meeting?
<arges> hallyn_: bug 1444057 fyi
<ubottu> bug 1444057 in qemu (Ubuntu) "gdb in a guest VM fails to continue" [High,In progress] https://launchpad.net/bugs/1444057
<smoser> arges, does that really only fail inside a vm ?
<cyphermox> kirkland: could you please check if /usr/lib/pulse-6.0/modules contains module-bluez5-discover.so?
<arges> smoser: it fails outside a vm, i'm trying to debug a vm
<smoser> ok. that makes more sense.
<smoser> "in a guest vm" was confusing in the subject of the bug.
<arges> smoser: i'll fix that=
<arges> gdb remote target of a guest VM fails to continue Edit
<smoser> :)
<hartmans> Hi.  I made a backport request (LP: #1439215) and unfortunately the person resolving that didn't act on the debdiff I attached.  The package builds but is useless without the package.
<ubottu> Launchpad bug 1439215 in utopic-backports "Please backport moonshot-ui 0.7.1-1 (universe) from vivid" [Undecided,Fix released] https://launchpad.net/bugs/1439215
<hartmans> I could use help with the right procedure to request a new upload with the diff applied.
<hartmans> Should I use the existing bug or a new bug and if a new bug, on the package or on the backports project?
<cjwatson> pitti: https://code.launchpad.net/~cjwatson/ddeb-retriever/lp-fetch/+merge/256192
<cjwatson> debfx: ^- Could you look at hartmans's request above, since you processed that backport?
<cjwatson> hartmans: if it were me I would reopen the bug on the grounds that it wasn't completely acted upon
<hartmans> If I do that should I attach a new debdiff to update version and subscribe ubuntu-sponsors?
<hartmans> Also, do sponsor requests need a debdiff or is a branch link acceptable?
<cjwatson> hartmans: Shouldn't be necessary; any sponsor should be able to cope with trivial reformatting
<cjwatson> hartmans: And ditto I'd expect a sponsor to be able to cope with grabbing a patch from any roughly reasonable source
<cjwatson> (I'm not saying that definitely nobody will be jobsworth about it, but ...)
<debfx> hartmans: sorry, must have missed that. I'll upload a new version.
<cjwatson> pitti: We should manually create .lp-threshold for the first run set to something reasonable, say today's date, so that we don't have to scan back through everything
<pitti> cjwatson: agreed
<pitti> cjwatson: I didn't look through it with a fine comb again, but this looks very similar to the changes I've reviewed some two weeks ago?
<cjwatson> pitti: Yes, it's just bug-fixes since then
<cjwatson> pitti: And the order_by_date=True stuff which was a result of LP reviews
<pitti> cjwatson: so if you feel good about it, please feel free to merge
<pitti> or rather, push, for cleaner history
<cjwatson> pitti: will do, thanks!
<pitti> thanks to you!
<hartmans> debfx: thanks much.
<cjwatson> pitti: Done; please yell if cronspam explodes
<cjwatson> pitti: Otherwise I believe we can now flip the switch right after vivid
<pitti> cjwatson: did you already roll it out? (cron doesn't bzr pull)
<cjwatson> pitti: Yes
<pitti> ah, good
<cjwatson> And I did date -d 2015-04-14 +%s >/srv/ddebs.ubuntu.com/www/.lp-threshold
<pitti> cjwatson: so we should spot-check some ddebs which are being uploaded today
<cjwatson> Right, it should be a no-op at the moment but worth confirming
<Ionic> so... any help with the DT_NEEDED situation would be greatly appreciated
<Ionic> for debian, there's this stuff called... snapshots?
<Ionic> unstable is typically snapshotted and the state of a specific day archived
<Ionic> I don't know if the same holds for testing and stable, though
<Ionic> and if that is applicable to Ubuntu in any way
<Ionic> if I could build a base image via pbuilder-dist ... create from a specific "snapshot repo", that might be helping in debugging my issue
<Ionic> (yes, I'm kinda desperate)
<infinity> Ionic: Not at all discounting that snapshotting would be useful, I'm not sure how it would help much here.
<infinity> Ionic: If your build system is producing underlinked binaries, that's generally your build system's fault.
<Ionic> infinity: I would like it to be, but I don't see any way how that may be the case
<Ionic> infinity: checking out the bzr branch that was used for building the packages a month ago, using dpkg-buildpackage -S and pbuilder-dist trusty foo.dsc is precisely recreating the missing lib dependency situation, while the packages built on launchpad a month ago don't have that bug
<Ionic> from the same branch and everything
<Ionic> the nightlies show this weird behavior, and also they are built from master, there were no changes that would explain this behavior
<Ionic> I've been thinking about triggering a rebuild of the latest release on launchpad, but that would mean removing the "good" packages and potentially replacing them with the "bad" ones if the bug is indeed reproducable
<cjwatson> Ionic: You can always create a separate PPA for that kind of test.
<Ionic> under my account, maybe?
<Ionic> I have only been working with launchpad the past two days, so I'm still very unknowing of how to upload a package correctly, copy a build recipe and stuff
<pitti> sforshee: bug 1444166
<ubottu> bug 1444166 in systemd (Ubuntu) "closing lid does not suspend during the first couple of minutes" [Undecided,New] https://launchpad.net/bugs/1444166
<cjwatson> Ionic: It can have the same owner as the PPA you're presumably already using.
<cjwatson> Ionic: https://help.launchpad.net/Packaging/PPA
<Ionic> cjwatson: the owner is a group currently (which I'm a member of, naturally)
<Ionic> I'd just need to copy the stuff over into my own PPA to not disrupt the group
<cjwatson> Ionic: Teams can have multiple PPAs too, but as you like.
<cjwatson> Ionic: It'd be a copy either way.
<Ionic> point is that I don't want to have a test build publicly visible on the team... pages, whatever
<Ionic> I'll look into that, thank you
<Ionic> is ubuntu<version> automatically added by launchpad without me having to do anything?
<cjwatson> No.
<cjwatson> The version is up to you.
<Ionic> hum
<cjwatson> https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning
<Ionic> we do not add an ubuntu tag in our source explicitly
<cjwatson> "ubuntu" has a special meaning in the primary Ubuntu archive.  It isn't required for PPAs, and is indeed potentially confusing/undesirable in some cases.
<cjwatson> (that special meaning is precisely "this package has an Ubuntu delta and should not be overridden by an automatic sync of a newer version from Debian")
<Ionic> ok
<Ionic> for our packages, ubuntu<ubuntu-version> is being added, presumably to make the packages in the PPA unique
<Ionic> for each dist
<Ionic> I thought that to be standard behavior when building for multiple dists
<Ionic> 36
<Ionic> ... wrong command, sorry
<Unit193> Pingo!
<Unit193> ..Bingo!
<cjwatson> Ionic: That's reasonable, but Launchpad doesn't add it for you.  If it's not in your VCS, then some tool you're using is adding it.
<Ionic> cjwatson: probably. I will have to investigate.
<infinity> cjwatson: Hrm?  It's added for recipe builds, is it not?
<infinity> '--append-version',
<infinity>             '~ubuntu%s.1' % distroseries_version], env=env)
<infinity> cjwatson: I imagine that's what he was refering to.
<Ionic> I was told that "launchpad adds this", but no further explanation (because I didn't care)
<Ionic> yep, exactly :)
<Ionic> that's what I'm seeing
<infinity> Ionic: Yeah, that happens for recipes, but not for direct uploads.
<infinity> Ionic: Direct uploads get whatever version you used in debian/changelog.
<Ionic> well, the recipe is triggered by bzr updates which syncs with our git repository, or something like this
<Ionic> (so, for reproducibly, I will also use recipes)
<RAOF> pitti: Thanks muchly!
<cjwatson> infinity,Ionic: Oh, right, yeah, recipes do it.
<cjwatson> I always forget about those. :-)
<pitti> RAOF: yw!
<RAOF> pitti: Next colord job: work out why all the tests don't pass in an autopkgtest environment :)
#ubuntu-devel 2015-04-15
<Ionic> okay
<Ionic> cloned the branch to a private +junk one
<Ionic> cloned the recipe
<Ionic> let's go building this...
<Ionic> hm, that failed, looks like I'm missing something
<Ionic> hm, the failure is probably because it's missing a ppa at build time
<Ionic> via "edit dependencies" somewhere, ok
<Ionic> hmmm...
<Ionic> we are using an own version of debhelper
<Ionic> a rebuild only for lucid, though
<Ionic> the other dists are using the normal ubuntu debhelper
<Ionic> weird way to do a backport, but meh... that explains the build failure
<Ionic> ok, that worked for all builds this time... diff time
<Ionic> RAOF: yes, I can reproduce the problem by building on launchpad :(
<RAOF> Ionic: ...!
<Ionic> https://code.launchpad.net/~ionic/+archive/ubuntu/test-ppa/+packages
<Ionic> the one commit that is different is touch dummy
<Ionic> for launchpad to actually create new packages because of the first failure
<Ionic> I bet if I was also pushing a dummy commit to the X2Go release repo, the new packages would be "broken"
<Ionic> gonna diff the build logs now
<Ionic> I have seen one difference already
<Ionic> dpkg was updated
<Ionic> patch version 9 to 10
<Ionic> (I'm sorry if I'm getting on your nerves, but this is so very odd for me)
<RAOF> Nah, that's ok. It's very odd for me, too :)
<Ionic> libc versions differ, too, but that shouldn't... well, who knows
<Ionic> it's related, to some degree
<Ionic> and dpkg was updated from: Get:3Â·http://ftpmaster.internal/ubuntu/Â·precise-security/mainÂ·dpkgÂ·amd64Â·1.16.1.2ubuntu7.5Â·[18... -> Get:3Â·http://ftpmaster.internal/ubuntu/Â·precise-security/mainÂ·dpkgÂ·amd64Â·1.16.1.2ubuntu7.6Â·[18...
<RAOF> Is that using imake???
<Ionic> yep
<Ionic> it's based upon Xorg 6.9...
<Ionic> I know, I know
<RAOF> What's the underlinked library?
<RAOF> Or binary, I guess.
<Ionic> other differences: multiarch-support updated, binutils updated, dpkg-dev updated, libdpkg-perl updated
<Ionic> underlinked binary: usr/lib/nx/bin/nxagent (package nxagent)
<Ionic> actually, it's not really "underlinked"
<Ionic> the library shows up in ldd's output, but not in DT_NEEDED
<Ionic> so it's "underlinked", in quotes
<Ionic> libssl has also been updated, but I figure that's unimportant
<RAOF> Highly likely.
<Ionic> just like gpgv and gnupg
<Ionic> or libgrypt* or libtasn* or gnutls...
<Ionic> (the security team seems to be doing its job, though, so I'll give you that)
<RAOF> Have you determined whether nxagent directly uses symbols from the things in ldd but not DT_NEEDED? Because if it doesn't then this is expected (and should be harmless) behaviour.
<RAOF> Yeah, our security team is on the ball :)
<Ionic> I haven't done that
<Ionic> I'll checkout the debug symbols and take a look
<Ionic> it seems not to be using XDamage* symbols
<Ionic> (at least not according to nm ./usr/lib/debug/usr/lib/nx/bin/nxagent | grep -i XDamage)
<RAOF> You can also find that with objdump -T nxagent | grep UND; that'll give you the list of symbols that need to be resolved to load nxagent.
<RAOF> And objdump -T $CANDIDATE_LIBRARY | grep .text will get you the list of symbols exported from that library.
<RAOF> It *should* be possible to do some seddery or something to match these up; that's left as an exercise for the reader :)
<RAOF> But if the binary isn't directly using the XDamage* symbols then it shouldn't be getting a DT_NEEDED entry against the library providing those symbols.
<Ionic> looks like there are really no symbols used
<RAOF> Doesn't explain why you're only just seeing this, of course.
<Ionic> yep
<Ionic> I kinda bet it was the dpkg update
<Ionic> err, dpkg-dev
<Ionic> dpkg-gensymbols is part of dpkg-dev, sorry
<RAOF> But that's not going to change whether or not nxagent is actually linked with libnxdamage, though.
<RAOF> Hm, lunch time!@
<Ionic> yes
<Ionic> so, even while no symbols are being used, we still link to libnx-xdamage1 etc.
<Ionic> making the binary fail to start if that library is not available
<RAOF> Ionic: But I thought you said nxagent had no DT_NEEDED entry for libnx-xdamage? That would imply that it *doesn't* need libnx-xdamage (except if some library it *does* use needs libnx-xdamage, in which case that library should carry the dependency).
<Ionic> RAOF: yes, but the makefile is still linking to it
<Ionic> which is probably wrong to begin with
<RAOF> If the binary doesn't have a DT_NEEDED entry, then the binary is not linked with it. You'll be running into the -as-needed default there, I guess.
<Ionic> well, gcc is not called with -Wl,-as-needed
<RAOF> If I read the entrails of gcc -dumpspecs correctly, --as-needed is the default, so you'd need to explicitly pass --no-as-needed to disable it.
<Ionic> hum
<Ionic> looks like it
<RAOF> It might be time to circle round to... what was the actual *problem* again? :)
<Ionic> there's something else though, it also adds --no-add-needed
<Ionic> but that looks like the default behavior anyway
<Ionic> good question
<Ionic> to be honest, I do not know what the *actual* problem is
<Ionic> a user reported "it's not working"
<Ionic> after he was told to run nxagent manually to see if it even starts up, he determined libnx-xdamage1, *xfixes* and *xtst* were missing on his system
<Ionic> which made nxagent fail to start
<Ionic> the weird part is that the libraries should still have been present on the system
<RAOF> Lacking xfixes is a really âbasically everything now failsâ situation, yes.
<Ionic> wait, let me look it up
<Ionic> maybe it was damage, composite and tst
<Ionic> oh, meh
<Ionic> damage, randr and xtst
<RAOF> That's still a âApps using GTK or Qt don't startâ situation.
<RAOF> Hm.
<Ionic> the weird part is that damage, randr and tst are dependencies of libxcompshad3
<Ionic> ... which is a dependency of nxagent
<RAOF> Have they just flat out broken their system?
<Ionic> so I don't understand how the user got into his broken state in the first place
<Ionic> possible
<Ionic> because it doesn't make sense
<Ionic> I though find it odd the the 3 libraries that he mentioned the three libraries that were explicitly removed from nxagent's Depends:
<Ionic> (+ grammar)
<RAOF> Yeah, that's curious.
<Ionic> I though find it odd, that the 3 libraries that he mentioned were the packages "explicitly" (or rather implicitly though dh_shlibdeps) removed from nxagent's Depends:
<Ionic> so I'm a little bit careful to blame it on user error
<RAOF> What debugging output do you have from their system?
<Ionic> (and I still don't know what causes the removal in the first place. https://launchpadlibrarian.net/202647030/dpkg_1.16.1.2ubuntu7.5_1.16.1.2ubuntu7.6.diff.gz looks totally unrelated... and that was the dpkg change)
<Ionic> oh, don't go there
<Ionic> an incomplete list of installed packages, because he grepped wrongly
<Ionic> never told him, but the list isn't really helpful...
<RAOF> Heh
<Ionic> http://permalink.gmane.org/gmane.linux.terminal-server.x2go.user/2937
<Ionic> should have rather grepped for "nx" only...
<Ionic> wrong message though
<Ionic> http://comments.gmane.org/gmane.linux.terminal-server.x2go.user/2904
<Ionic> at that point, he installed the libraries though, so I can't just ask him for the complete "old" output...
<RAOF> And once he installed the libraries everything worked?
<Ionic> looks like it
<Ionic> "eureka" sounds like it fixed his problem
<Ionic> http://permalink.gmane.org/gmane.linux.terminal-server.x2go.user/2929
<RAOF> Ionic: Hm... you've done some package splitting recently?
<RAOF> I wonder if there isn't some combination of packages that would have satisfied dependencies without installing nx-xdamage et al...
<Ionic> yep
<Ionic> well, not splitting, but renaming
<Ionic> from libnx-xdamage to libnx-xdamage IIRC
<Ionic> err, from libnx-xdamage to libnx-xdamage1
<Ionic> basically from unversioned lib packages to versioned lib packages
<Ionic> I wouldn't know any solution set that would have been satisfied without the nx libs, though
<Ionic> and the upgrade path looked smooth for other users
<Ionic> (minus the first messup that broke stuff on ubuntu because launchpad is overriding the dist tag)
<tjaalton> shouldn't libvirt-bin shutdown guests on vivid?
<tjaalton> don't think the initscript is doing that, the upstart job did
<tjaalton> hm, that or debian (guest) doesn't log shutdown
 * mwhudson grumbles at git-buildpackage, pbuilder etc
<ericsnow> pitti: ping
<ricotz> Laney, hi, thanks for syncing youtube-dl -- would you mind doing the same for https://bugs.launchpad.net/ubuntu/+source/plank/+bug/1443773
<ubottu> Launchpad bug 1443773 in plank (Ubuntu) "FFe: Sync plank 0.9.0-1 (universe) from Debian experimental (main)" [Undecided,New]
<Riddell> pitti: can you remind me again how to make a commit to apport?
<Riddell> Sweet5hark: can we update the breeze icons in libreoffice or is it too late (asks the artists)
<LocutusOfBorg1> hi doko
<LocutusOfBorg1> you there?
<LocutusOfBorg1> gcc version 5.0.1 20150413 (prerelease) [gcc-5-branch revision 222064] (Debian 5.1~rc1-1)
<LocutusOfBorg1> I don't understand that "5.0.1" vs "5.1"
<LocutusOfBorg1> did they make a mistake?
<Riddell> pitti: I still have a couple of random breakages on proposed-migration, any thoughts on how to fix?
<cyphermox> good morning!
<seb128> h
<seb128> hey cyphermox
<cyphermox> hey seb128
<seb128> cyphermox, how is Canada?
<cyphermox> I don't know, I'm in Texas :)
<seb128> oh, ok
<cyphermox> hehe
<cyphermox> I think Catou said it was snowing yesterday again, a bit
<seb128> waouh, winter is not over yet for you?!
<seb128> here we are in summer mode
<seb128> 25Â°C sunny
<cyphermox> yeah, not quite there yet
<cyphermox> also, Summer for abolished, there was a memo
<seb128> lol
<cyphermox> it's now 8 months winter, 2 months fall and two months spring
<cyphermox> ;)
<seb128> well, no summer is fine, if it means avoiding the 40Â°C days, but that's too much winter!
<cyphermox> seb128: I agree ;)
<pitti> good morning
<cyphermox> seb128: but the fact that it's still winter and probably depressing to some people is the only way I can explain people fighting in universities in Quebec :P
<pitti> Riddell: I committed your vivid apport fix to trunk, thanks
<cyphermox> pitti: hey!
<seb128> cyphermox, they do?!
<pitti> Riddell: autopkgtest failures> which one?
<cyphermox> sadly
<ScottK> cyphermox: I always heard it was two seasons: winter and construction.
<cyphermox> ScottK: sounds about right
<Riddell> pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#knewstuff
<cyphermox> seb128: http://ici.radio-canada.ca/regions/montreal/2015/04/13/004-uqam-conflit-professeurs-critiquent-presidente-syndicat-nevert.shtml
<seb128> urg
<Riddell> pitti: but kate and okteta are both green in the builds
<pitti> Riddell: http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-okteta/lastBuild/ARCH=i386,label=adt/console
<pitti> ^ kate failure, looks like an API change somewhere?
<pitti> FTBFS
<Riddell> pitti: "Server not found"
<pitti> documentinfoview.cpp:29:23: fatal error: KIconLoader: No such file or directory
<pitti> Riddell: ah, public jenkins is broken again? le sigh..
<pitti> Riddell: I'll ask the CI team
<Laney> we pinged them earlier
<pitti> Laney: ah, thanks
<pitti> Riddell: kate: http://paste.ubuntu.com/10826776/
<pitti> Riddell: sorry, that was okteta ^
<pitti> Riddell: kate: http://paste.ubuntu.com/10826784/
<Riddell> thanks pitti
<rbasak> pitti: may I have your opinion on bug 1444502 please? Odd situation that matsubara ended up in just now.
<ubottu> bug 1444502 in sysvinit (Ubuntu) "sysv-rc uses /sbin/runlevel without depending on a package that provides it" [Undecided,New] https://launchpad.net/bugs/1444502
<rbasak> dist-upgrade fixed it, but I think it should have been prevented by dependencies
<pitti> rbasak: (sorry, sprint hectic/delay) I followed up to the bug with a quick proposal
<pitti> does that sound alright to you?
<rbasak> pitti: I think so, yes, since init pre-depends on systemd-sysv | upstart-sysv and both provide /sbin/runlevel.
<rbasak> pitti: as long as there isn't some broader way to solve this?
<pitti> rbasak: right, that was the idea; we don't want to hardcode systemd-sysv just yet, as we still want to support upstart-sysv for a while, and definiitvely need that on the phone
<pitti> rbasak: well, "init" is Essential:
<pitti> rbasak: it should really Not Happenâ¢ that you don't have it
<pitti> rbasak: it used to be not essential, so perhaps matsubara was upgraeding from intra-vivid where this wasn't the case
<rbasak> pitti: ah, but that only happened recently, right? So matsubara might have had an older init package that wasn't essential?
<rbasak> pitti: maybe safe to invalidate this bug then. An essential package does indirectly provide /sbin/runlevel.
<pitti> rbasak: yeah; but "init" didn't exist in utopic/trusty either
<rbasak> So only upgrade from beta is affected when not using dist-upgrade.
<pitti> rbasak: I mean, apt-get upgrade from a previous release is already evil, bad, wrong, and crying "broken!"
<pitti> I'm not sure if we can ever get this truly right, "upgrade" shold not exist really
<pitti> "apt upgrade" is fine, but not apt-get upgrade
<rbasak> pitti: so are you +1 to mark the bug Invalid?
<pitti> rbasak: fine with me too
<pitti> I don't think additional deps on init hurt, but I'm not sure how much of a real use case the above is
<rbasak> Beta users need to know to dist-upgrade and not just apt-get upgrade.
<seb128> tyhicks, hey, any news about the schroot/ecryptfs issues? if it's not fixed for vivid do you think we should add a note discouraging people who want to develop for ubuntu touch to enable ecryptfs?
<rbasak> Other stuff will be broken too otherwise
<tyhicks> seb128: hey - I'm hoping to get back to those bugs
<pitti> rbasak: yeah, we basically never test/support apt-get upgrade; it's probably ok for -security/-updates in many cases, but not otherwise
<tyhicks> seb128: there are some higher priority things that I've got to tend to first
<matsubara> thanks rbasak, pitti
<tyhicks> seb128: if we do add a note for users, it is important to note that it is *any* filesystem mounted at /home/USER and not just ecryptfs
<seb128> tyhicks, right, but it's likely that not many users do create a speciifc /home/USER partition, where ecryptfs is a checkbox in the installer which is sort of recommended if you want more security
<seb128> tyhicks, so ecryptfs is likely going to be the most common case
<tyhicks> agreed
<Sweet5hark> seb128: hmmm, Riddell asked about updating the icon theme for libreoffice/vivid again. Its low risk, but we are really later
<Sweet5hark> seb128:  s/later/late/ your take?
<seb128> Sweet5hark, I'm not in the release team, check with them I guess
<seb128> it looks like the sort of change that can be SRUed to me
<Sweet5hark> seb128: true. Its just replacing a tarball in ./debian ...
<Sweet5hark> seb128: so, lets punt that for an sru ...
<seb128> wfm
<seb128> it's not an installation issue so SRU should be alright
<pitti> Riddell: ah, kate succeeded now
<doko> pitti, jibel: can you have a look at the gcc-4.8 migration?
<doko> 4.9 it is
<infinity> mvo: Will the lack of newline at the end of /etc/system-image/writable-paths cause problems?
<rbasak> writable?
<rbasak> I thought that was just Samba.
<mvo> infinity: I think not, but I can double check
<infinity> mvo: Did you determine that your lack of newline on your upload was fine?
<FunnyLookinHat> Anyone else unable to reach http://kernel.ubuntu.com/~kernel-ppa/mainline/
<elfy> FunnyLookinHat: same
<FunnyLookinHat> blech.
<FunnyLookinHat> elfy, purduelug?
<FunnyLookinHat> Oh nope - close to another nick I know :D
<elfy> lol
<infinity> pitti: Where are you?
#ubuntu-devel 2015-04-16
<hrw> hi
<hrw> ubuntu does not have arm64 installer support?
<ogra_> hrw, http://ports.ubuntu.com/dists/trusty/main/installer-arm64/current/images/generic/netboot/
<hrw> ogra_: no netboot.iso? :(
<ogra_> doesnt look like ...
<hrw> ogra_: will check later than
<hrw> ok. no ubuntu then - netboot kernel does not boot in vm
<LocutusOfBorg1> good morning developers
<hrw> bye
<flexiondotorg> Is anyone sponsoring or piloting today?
<didrocks> flexiondotorg: I can handle some if needed (and if respecting processes ;))
<flexiondotorg> didrocks, Thanks - https://bugs.launchpad.net/ubuntu-mate/+bug/1444587
<ubottu> Launchpad bug 1444587 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 0.4.7 bug fix release [debdiff attached]" [Undecided,New]
<seb128> flexiondotorg, calendar says hallyn_ zul and utlemming and pilots today
<seb128> and->are
<flexiondotorg> seb128, It that calendar accessible publically?
<flexiondotorg> *publicly
<seb128> flexiondotorg, yes, https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews , "Schedule" section
<flexiondotorg> seb128, Thanks.
<seb128> yw
<didrocks> flexiondotorg: is it just a synchronization with the ubuntu-themes or did you add Mate specific things?
<flexiondotorg> didrocks, Just a sync with ubuntu-themes.
<flexiondotorg> didrocks, The MATE specific stuff was done quite some time back.
<didrocks> flexiondotorg: looking good, just a note for the future: I guess if you want to keep it forked and maintainabled, you should use some changelog with "resync on version <â¦> of ubuntu-themes, remaining diffs: <list of diff>"
<didrocks> flexiondotorg: that would help you to keep track of the diff with ubuntu-themes and recheck that you didn't drop something without paying attention
<flexiondotorg> didrocks, Thanks. Good idea.
<flexiondotorg> didrocks, One of the item for 15.10 is if I can unify, to some extent, with ubuntu-themes etc.
<didrocks> that would be nice, yeah
<flexiondotorg> didrocks, Thanks.
<didrocks> yw flexiondotorg
<mdeslaur> rbasak: looks like the new mysql 5.6 tarball is missing a file...and it doesn't look like the launchpad repo is being updated anymore
<rbasak> mdeslaur: they switched to Github I think.
<mdeslaur> rbasak: did they change where they put their code repo?
<rbasak> Or Git somewhere.
<mdeslaur> ah, found it, thanks
<rbasak> mdeslaur: which file? Is it essential in some way?
<mdeslaur> lex_token.h, referred to in https://github.com/mysql/mysql-server/blob/5.6/sql/sql_yacc.yy
<mdeslaur> and....it's not in the repo \o/
<rbasak> Lovely.
<rbasak> mdeslaur: I can follow up with upstream in #debian-mysql on OFTC if you like. ryeng is usually very helpful.
<mdeslaur> rbasak: yes, please
<pitti> Good morning
<pitti> infinity: I'm here :)
<pitti> infinity: (snappy standup)
<mdeslaur> pitti: I am releasing another apport security update in a few minutes that disables container support as there's a new root exploit out for our current fix
<mdeslaur> pitti: and we can't make this code race and pid-reuse clean for now
<pitti> mdeslaur: I know, yes; stgraber sent me a new patch yesterday, that's still not good?
<mdeslaur> nope
<pitti> mdeslaur: ah, ok; so I shold probably also make a new upstream release which disables that?
<mdeslaur> pitti: yeah, unfortunately. This is what I'm doing: http://paste.ubuntu.com/10832510/
<mdeslaur> you may have some tests to disable too
<stgraber> pitti: yeah, lets drop it from apport. I've lost enough time trying to deal with this. I'll just push a deployment-specific version of apport to the deployment PPA for the machines I care about.
<pitti> mdeslaur: ack, thanks; when do you think we'll get a CVE?
<mdeslaur> pitti: probably not this week, there's a lot of stuff in that thread for mitre to catch up on :P
<infinity> pitti: And where are you now? :)
<pitti> infinity: snappy/foundations, Lantana A
<bdmurray> Riddell: Could you have a look at bug 1443300?
<ubottu> bug 1443300 in casper (Ubuntu) "kubuntu live session standby lock prevents login" [Medium,New] https://launchpad.net/bugs/1443300
<Riddell> bdmurray: I fixed that after beta
<Riddell> bdmurray: just close it
<bdmurray> Riddell: done, thanks
<pitti> infinity: bug 1445049 FYI
<ubottu> bug 1445049 in autopkgtest (Ubuntu) "add Architecture: field" [Wishlist,Triaged] https://launchpad.net/bugs/1445049
<infinity> pitti: Ta.
<flexiondotorg> Could someone take a look at the following please - https://bugs.launchpad.net/ubuntu/+source/mate-tweak/+bug/1439388
<ubottu> Launchpad bug 1439388 in mate-tweak (Ubuntu) "Updated translations for mate-tweak [debdiff attached]" [Low,New]
<flexiondotorg> I'd like to confirm that is applies cleanly and can be merge and uploaded.
<pitti> xnox: hey, how are you? maybe you should re-post your runtime preset patch to the upstream ML? seems it fell through the cracks; and they now also seem to have a shiny new patch tracker
<stgraber> pitti, tyhicks, mdeslaur: bug 1445064
<ubottu> bug 1445064 in apport (Ubuntu) "Re-implement container crash forwarding" [Wishlist,Triaged] https://launchpad.net/bugs/1445064
<tyhicks> stgraber: looks good
<pitti> stgraber: ack, thanks; so let's disable the current implementation for the time being
<strikov> infinity: pitti: quick juju update; 1.23 (with systemd support) is still in progress, it has been released but we have 2 unresolved issues with it; i uploaded 1.22.1 over 1.22.0 which has 'revert to upstart' code in tests to be able to verify issues in dependencies.
<strikov> infinity: pitti: i'm done with 1.23 packaging-wise (d/copyright etc) so just waiting for a green light for 1.23 from juju team
<pitti> strikov: nice to hear, thanks! I saw that even the tests are succeeding again now
<highvoltage>    /win /win 13
<ogra_> double win !
<strikov> pitti: they are successful due to 'revert to upstart' code not because juju supports systemd; sigh
<pitti> yeah, I know
<ricotz> mitya57, hey, since you already touched the bug, please sync it -- https://bugs.launchpad.net/ubuntu/+source/plank/+bug/1443773
<ubottu> Launchpad bug 1443773 in plank (Ubuntu) "FFe: Sync plank 0.9.0-1 (universe) from Debian experimental (main)" [Wishlist,Triaged]
<mitya57> ricotz: synced, please close the bug manually when it's accepted
<ricotz> mitya57, ok
<bdmurray> rd
<bdmurray> ~.
<bdmurray> ~.
<bdmurray> ~.
<Unit193> Not your terminal?
<sarnold> looks like world's laggiest ssh connection :)
<Unit193> Ah right, trying to disconnect.
<cjwatson> slangasek,cyphermox: http://people.canonical.com/~ubuntu-archive/apt-mirror.cgi does time-travelling dists/ and can be used to bisect if you try hard enough; look at derive-distribution in lp:ubuntu-archive-tools for an example of how to use it
<cjwatson> slangasek,cyphermox: it's probably simplest to bring up apt-mirror-librarian locally to deal with proxying to the LP librarian for pool/; the tree we're running is https://github.com/cjwatson/apt-mirror/tree/ubuntu-archive
<slangasek> cjwatson: thanks
<cyphermox> cjwatson: thanks
* stgraber changed the topic of #ubuntu-devel to: Archive: Final Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2015-04-17
<nagromlt> I want to develope something for Ubuntu
<Noskcaj> nagromlt, Then do that ;)
<Noskcaj> I don't have time to help you right now, but the info is out there
<aschildbach> Hi everyone!
<flexiondotorg> Could a sponsor please take a look at - https://bugs.launchpad.net/ubuntu-mate/+bug/1439388
<ubottu> Launchpad bug 1439388 in mate-tweak (Ubuntu) "Updated translations for mate-tweak [debdiff attached]" [Low,New]
<aeoril> infinity were you still going to have me do some writing?
<aeoril> infinity ^
<pitti> Good morning
<infinity> aeoril: Quite possibly, if you poke me next week.
<tjaalton> doko: the binutils trusty sru seems to have a weird version (-5u13 vs -5u3.1 in -security)?
<tjaalton> pitti: hm might have rejected the ubuntu-drivers-common upload too hastily :/
<pitti> tjaalton: you can always grab it from the rejected queue again
<tjaalton> ah
<tjaalton> ok
<pitti> tjaalton: but I can also reupload, and add a -v, I didn't look at this yet
<tjaalton> pitti: oh I was right afterall, so yeah reupload :)
<pitti> tjaalton: wow, 1:0.2.91.8 hasn't been verified since Dec 10??
<tjaalton> yeah I just updated it..
<tjaalton> oh since dec 10, so over four months then
<pitti> tjaalton: reuploaded
<tjaalton> thx, I'll ack it and hope the other bug is verified soon
<pitti> tjaalton: cheers
<pitti> infinity: FYI, langpacks built and tested, looking good; uploading/self-accepting now
<infinity> pitti: Ta.
<doko> tjaalton, yes, it had a few iterations in the ubuntu-toolchain-r/ppa PPA
 * Laney wonders why apt just forgot how to verify signatures
<pitti> mvo: http://www.freedesktop.org/software/systemd/libudev/
<aeoril> infinity ok, will do.  Thanks.
<cyphermox> pitti: so, casper/plymouth are still acting up on the CD; looks like it's because in the only-ubiquity case (ie. not a live session), it's trying to set it up to run just before display-manager rather than replacing it properly
<pitti> cyphermox: yes, that's on purpose (direct translation of the upstart unit)
<cyphermox> that's broken
<pitti> cyphermox: or maybe I'm mixing that up with oem-setup
<cyphermox> then display-manager will try to start at the same time as things are trying to shutdown
<pitti> that at least should run, then lightdm should start
<cyphermox> lightdm should never start after ubiquity's install
<cyphermox> would you have a chance to take a look?
<pitti> cyphermox: ah, ok; so Conflicts=display-manager.service?
<cyphermox> specifically, ubiquity.service
<cyphermox> no
<cyphermox> I think it needs to outright replace display-manager as the display-manager, since that's what it's doing anyway
<pitti> or that
<pitti> Alias=display-manager.service ?
<cyphermox> possibly
<pitti> (sorry, talking here)
#ubuntu-devel 2015-04-18
<happyaron> any core-dev around?
#ubuntu-devel 2016-04-18
<mwhudson> why would "mk-sbuild xenial" fail with "E: Failed getting release file http://archive.ubuntu.com/ubuntu/dists/xenial/Release"
<cpaelzer> good morning
<pitti> Good morning
<pitti> doko: well, I had a look, but it's obvious that the new release breaks its tests and the current xenial one works, so this isn't any infra problem
<pitti> doko: mailed sgclark (as she isn't on IRC)
<infinity> I had a look at it last week and couldn't sort it out.
<infinity> I thought it might be missing test deps, but even adding the (optional) binaries it complains about doesn't change things, so they really are optional.
<pitti> infinity: you mean epstool and fig2dev? (as there are warnings about those in the log)
<pitti> no warning about those in the passed tests indeed
<infinity> pitti: Yeah, installing those didn't help.
<infinity> pitti: So, red herring.
<pitti> stgraber: apparently manually created lxd images not get auto-cleaned after n days (http://paste.ubuntu.com/15908394/); is there some way how adt-build-lxd can mark the older images for auto-cleanup after building a current one?
<pitti> stgraber: I don't want to remove the previous one right away, this might confuse some running tests
<stgraber> pitti: I don't believe we expose a way to set the cached property over the API, no reason why we shouldn't though
<pitti> stgraber: right, I didn't see anything in the properties of the original ubuntu image which sounds like that
<pitti> stgraber: or the other way around, would it always be safe to delete the previous adt image after creating a new one?
<pitti> stgraber: i. e. could there be running containers from that image, with snapshots or dir/btrfs/zfs which would break?
<stgraber> pitti: lxd does internal ref counting as needed
<stgraber> pitti: so it's always safe to remove the image
<stgraber> pitti: if it's still needed, lxd will renamed it to a delete/... path (on zfs) and then wipe it when refcount hits 0
<pitti> stgraber: ah, nice; I guess then I'll do just that
<mwhudson> morning europe
<mwhudson> why would "mk-sbuild xenial" fail with "E: Failed getting release file http://archive.ubuntu.com/ubuntu/dists/xenial/Release" (new xenial install)
<rbasak> mwhudson: missing proxy setting perhaps?
 * rbasak is guessing
<mwhudson> rbasak: i don't *think* so
<mwhudson> it's possible
<mwhudson> basic debootstrap works
<mwhudson> (well, gets past that point at least)
 * mwhudson runs bash -x ...
<mwhudson> oh wait, out of date proxy settings in ~/.mk-sbuild.rc
<rbasak> mwhudson: btw, I did hit 1569400 on xenial the other day. Simple workaround. Though you may not hit it unless you use Etc/UTC too.
<mwhudson> it seems to be working so far
<mwhudson> well, i made a xenial schroot and trusty is grinding away
<plars> anyone know what could cause things to get into this state? http://paste.ubuntu.com/15913154/
<plars> Running apt-get update in this schroot seems to get errors like this:
<plars> W: No sandbox user '_apt' on the system, can not drop privileges
<plars> W: GPG error: http://ports.ubuntu.com/ubuntu-ports xenial InRelease: Could not execute 'apt-key' to verify signature (is gnupg installed?)
<plars> W: The repository 'http://ports.ubuntu.com/ubuntu-ports xenial InRelease' is not signed.
<doko> seb128, Laney: is xterm-256color set by default now as TERM variable?
<seb128> urg, I don't even know what that variable is and what sets it, I'm really not the person to ask about that, but maybe Laney knows...
<pitti> doko: this has changed a while ago already, at vivid or wily or so
 * pitti noticed when his own nick suddendly switched to white in weechat :)
<ogra_> ogra@styx:~/all-snaps/rpi3$ env |grep TERM
<ogra_> TERM=xterm
<jrwren> doko: usually your terminal client sets that and its carried forward by ssh or wahtever. So it would be gnome-terminal or ubuntu-terminal or whatever. Each will set a TERM. Its not a system wide setting.
<doko> pitti: but inside screen, you get now screen.xterm-256color, which is not functional
<ogra_> not for me ...
<ogra_> seems it doesnt get migrated on updates ?
<pitti> yes, this is in libvte
<cjwatson> that really seems like something screen should fix
<pitti> configure.ac:VTE_DEFAULT_TERM=xterm-256color
<pitti> (in vte2.91)
<cjwatson> screen.xterm-256color does exist though
<pitti> gnome bug 168251
<ubottu> Gnome bug 168251 in general "add support for 256 colors terminals" [Enhancement,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=168251
<pitti> sorry, no, this was much older
<doko> ahh, only if I change into a chroot inside screen
<pitti> gnome bug 740641
<ubottu> Gnome bug 740641 in general "Change default to TERM=xterm-256color" [Enhancement,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=740641
<cjwatson> it was added in ncurses 20150627
<pitti> changed in https://git.gnome.org/browse/vte/commit/configure.ac?id=82a8b0697dd9
<cjwatson>         + comment-out "screen.xterm" entry, and inherit screen.xterm-256color
<cjwatson>           from xterm-new (report by Richard Birkett) -TD
<cjwatson> so perhaps wouldn't work with older ncurses-term
<pitti> seb128: FYI, broadly it describes to bash, curses programs or anything else that runs in a terminal what capabilities a terminal has
<doko> ncurses-term is missing there
<pitti> seb128: like "can it show colors" and how many
<pitti> seb128: that's used by things like pstree, mc, or others to decide whether to use fancy characters, colors, etc. or not
<seb128> pitti, k
<seb128> well, vte&co is not something I usually look at, larsu and La_ney have been the ones doing the changes/updates in recent cycles
<doko> so maybe we should add this entry to ncurses-base, instead of ncurses-term?
<cjwatson> dunno the rationale for that particular split
<doko> size?
<cjwatson> sure, but the positioning forof it
<cjwatson> *of it
<cjwatson> if it were me I'd consult Sven (Debian ncurses maintainer)
 * Laney nod
<doko> infinity, https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1571684
<ubottu> Launchpad bug 1571684 in libisoburn (Ubuntu) "libisoburn fails to build on powerpc" [High,Confirmed]
<doko> even the version 1.4.2-3 in the archive fails this way
<tkamppeter> infinity, hi
<infinity> doko: That looks like the same thing Steve mangles in lua.
<doko> infinity, yes, it does the same
<nacc> Pharaoh_Atem: can you test with xenial latest? (in case you haven't already) -- should be up to your version, just would like a verification from you
<doko> argh, and the same in llvm :-/
<cking> libdm0 is apparently superceded in Xenial, but I can't find the dmapi that replaces it.
<cking> any ideas?
<Mirv> pitti: ok thanks for commenting on the bug #1571353. it's a bit like I suspected but decided to ask anyway. steve retried the faulty autopkgtest in the morning for bzoltan_. we had another one last week and will certainly ping you also the next time.
<ubottu> bug 1571353 in Auto Package Testing "test requests sometimes get lost and stay "in progress" forever" [Undecided,Incomplete] https://launchpad.net/bugs/1571353
<pitti> Mirv: right, I'd rather get to the bottom of this
<seb128> bdmurray, on the daily e.u.c xenial report it seems like half of the entries don't have function names/symbols, do you know if we have issues with apport/gdb/retracers still in xenial?
<pitti> argh, LP timing out again
<seb128> pitti, ^
<pitti> seb128: obviously we do have an issue then; I haven't looked into this yet (wasn't aware of that)
<bdmurray> seb128: I've been looking into it a bit with a cdparanoia crash, but haven't found the issue.
<seb128> pitti, well, not "obviously", often it turns out that retracing fails because of packages -dbgsym are missing, or buggy, or version got deprecated or whatsoever
<seb128> I'm just wondering if there is an infra problem
<seb128> or if we are just dealing with a stack of individual unrelated issues
<seb128> I guess the answer is "nobody looked enough to say"
<seb128> bdmurray, pitti, thanks
<bdmurray> seb128: I think we'll be in better shape if we fix bug 1517257
<ubottu> bug 1517257 in apport (Ubuntu) "apport-retrace should install and use gdb for target release" [Medium,Triaged] https://launchpad.net/bugs/1517257
<seb128> oh, that's still not fixed?
<seb128> I though you identified that as an issue earlier in the cycle and said it was due to be fixed a bit after that
<seb128> could be the issue there then?
<bdmurray> I don't recall saying it was going to be fixed, and that may help.
<seb128> k, maybe I mixing that with some other issues
<bdmurray> Once we get past the release I'll look at fixing that though.
<stgraber> xnox: http://paste.ubuntu.com/15916692/
<dobey> bdmurray: does the retracer for e.u.c not install PPAs that packages might be installed from, to retrace against? ie, for landing silos, for example?
<bdmurray> dobey: it only install packages from the overlay PPA
<dobey> bdmurray: would it be terribly difficult to enable installing packages from other PPAs that might be enabled?
<bdmurray> dobey: iirc it wouldn't be that difficult, but I don't think that is the problem.
<dobey> bdmurray: not which problem? it is certainly the problem i am asking about. :)
<dobey> bdmurray: i didn't mean to imply it was related to some other problem with e.u.c
<bdmurray> dobey: oh, okay! I think slangasek had some concerns about enabling every PPA for retracing.
<smoser> hey. someone systemd boot knowledgable want to take a gander at https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1571761
<ubottu> Launchpad bug 1571761 in zfs-linux (Ubuntu) "zfs-import-cache.service slows boot by 60 seconds" [High,Confirmed]
<dobey> bdmurray: not sure what the concerns were, and i wouldn't want them all enabled all the time, but if we could include non-private PPA sources.list identifiers somehow, (maybe just a listing of /etc/apt/sources.d/*.list) and enable some to be installed for retracing when needed, that would be nice; even if we limited it to PPAs owned by ci-train-ppa-service or something
<dobey> bdmurray: i guess maybe i should file a bug about it?
<bdmurray> dobey: please about the daisy project
<dobey> yep, will do
<Pharaoh_Atem> nacc: okay, thanks, will check
<nacc> Pharaoh_Atem: thanks!
<dobey> bdmurray: bug #1571777
<ubottu> bug 1571777 in Daisy "Crashes in packages from PPAs are often invalid" [Undecided,New] https://launchpad.net/bugs/1571777
<slangasek> dobey, bdmurray: the concern is whether a hostile ppa could feed the retracers bad symbols that break gdb and compromise the retracer env.  I do not assume that gdb has been well-hardened against hostile input
<dobey> slangasek: right, but i presume we can assume the landing silo PPAs to be safe in that regard, since we do binary copies from them to archive when landing
<slangasek> dobey: yes, we can rely on that being safe
<dobey> slangasek: does my proposed solution in comment 1 of the aforementioned bug sound reasonable to you in that respect? ie, implement as a whitelist until we can ensure the other concerns are resolved?
<slangasek> dobey: "implement a whilelist" would be ok, but I don't expect we're going to get someone to audit gdb for this use case
<dobey> slangasek: well, perhaps; but then we'll just have a whitelist forever, which is probably fine too. should make it easier if we need to add more landing silos or such in the future too
<cjwatson> you'll need to bear in mind the near-future ephemeral PPA use case too
<dobey> cjwatson: i guess the PPA will exist until things have landed or been abandoned, right? i think my suggested implmentation would work for that, since it's not to always enable all those PPAs, but to include a listing in the crash report, and have the retracer decide based on that, and the crash, whether to enable a PPA and install stuff from it
<cjwatson> dobey: right, but it does mean that we want to think about ensuring that it isn't a manually-maintained whitelist of individual PPAs
<cjwatson> dobey: it might be acceptable to have it be a whitelist of either PPA owner or full PPA reference (e.g. [~ci-train-ppa-service, ~ubuntu-toolchain-r/ubuntu/test])
<dobey> cjwatson: sure
<dobey> sounds reasonable
<rharper> if a bug in ubuntu is fixed in unstable debian (and we just sync the package, no ubuntu changes) then in the bug, do we just request a sync of the package ? (Versus applying an upstream fix via debdiff) ?
<teward> slangasek: thanks for the clarification
<elbrus_> nacc: I have a php7 regression bug in cacti
<elbrus_> nacc: bug 1571432
<ubottu> bug 1571432 in cacti (Ubuntu) "Cacti package is incompatible with PHP7 on Xenial" [High,Confirmed] https://launchpad.net/bugs/1571432
<elbrus_> solution is simple:
<elbrus_> line 66 of install/index.php needs an addition "i"
<elbrus_> mysql -> mysqli
<elbrus_> I'll add you to the bug
<nacc> elbrus_: thanks, i've actually had a few bugs come in that are private right now with cacti
 * elbrus_ should be able to see private bugs
<nacc> elbrus_: will provide a debdiff and fix for cacti today
<nacc> elbrus_: ok, one sec
<elbrus_> hmm, don't see any with cacti
<nacc> elbrus_: they are gainst php7.0 right now
<nacc> elbrus_: because it's a SEGV :/
<elbrus_> nacc: a, ok
<nacc> elbrus_: LP: #1569202 and LP: #1569993
<ubottu> Error: Launchpad bug 1569202 could not be found
<ubottu> Error: Launchpad bug 1569993 could not be found
 * elbrus_ is checking
<elbrus_> nacc: your understanding of the suhosin is similar to mine: it shouldn't matter
<elbrus_> nacc: interestingly 202 is using mysqlnd
<nacc> elbrus_: ack, i don't know enough about cacti to know what exactly is happening, but didn't see anything upstream in php7.0 to indicate that it had been "fixed" obviously :)
<elbrus_> and so does the other bug... maybe good to check if this goes away with the php-mysql driver
 * elbrus_ added php-mysqlnd way later on request (Debian bug 744067)
<ubottu> Debian bug 744067 in cacti "cacti: Cacti should support php5-mysqlnd as alternative to php5-mysql" [Wishlist,Fixed] http://bugs.debian.org/744067
<nacc> elbrus_: ack, would you be able to comment that into the bug (i've duped them together right now, i think that's correct based upon the traces, that the root-cause is the same, but feel free to undupe if you disagree)
<nacc> is it possible that a python3 package has a python2 reference in the source? specifically python3-lazr.restfulclient calling urllib.urlencode directly (rather than urllib.parse.urlencode)?
<nacc> nm, bug already exists :)
<nacc> LP: #1425609
<ubottu> Launchpad bug 1425609 in lazr.restfulclient (Ubuntu) "urllib.urlencode() does not exist for python3" [Undecided,Fix committed] https://launchpad.net/bugs/1425609
<nacc> cjwatson: i guess you own the above :)
<elbrus_> nacc: stacktrace p item of item #4 of LP: #1569202 looks weird to me, is that normal ? (/me has never seen a php stacktrace before) looks like memory allocation issues
<ubottu> Error: Launchpad bug 1569202 could not be found
<nacc> elbrus_: note that i think i also duped the bugs because they were from the same person :)
<nacc> elbrus_: sorry, 'stacktrace p item' ?
<elbrus_> https://i253407377.restricted.launchpadlibrarian.net/253407377/Stacktrace.txt?token=79F8Snh3qfhwqHbcT8v9CXLk2Ld57CmG
<elbrus_> item #4
<elbrus_> p= ....
<nacc> elbrus_: ah, reading
<nacc> elbrus_: hrm, that does look like corruption?
<nacc> or the string getting fubar'd :)
<elbrus_> absolutely not sure, but it looks weird
<elbrus_> that
<nacc> elbrus_: let me pull up the source
 * elbrus removed an underscore...
<nacc> elbrus: yeah, if you look at #7  to #4, it seems like query -> p gets ocrrupted (and the length got modified)
<elbrus> indeed
<elbrus> I mean, query in #7 I recognize
<nacc> elbrus: yep
<nacc> elbrus: hrm, i'm not even sure what p is! it gets copied to but then is unused :)
<nacc> let me look upstream
<nacc> elbrus: upstream's code is different, trying to see why, as it claims to not have been changed since october :/
<nacc> elbrus: nm, that's what's pending in 7.1.0, i think (quite extensive rewrite)
<rbasak> slangasek: I think what teward is looking for is a clear understanding of the rules around packages whose sources are in main. I think he's looking for you to say that it's fine for a source package in main to now build depend on a package in universe that results in a binary package that is in universe to have a dependency on a binary package that is in universe :)
 * teward was pinged
<teward> slangasek: basically, what rbasak said (me without coffee doesn't word things clearly apparently)
<slangasek> rbasak: isn't that what I just said?
<teward> rbasak: thanks for interpreting the question :)
<rbasak> slangasek: I don't think you literally said that. I interpret what you said to mean this but I also understand why teward still isn't sure :)
<teward> not counting the coffee issue, yes :P
<rbasak> (you said it won't impact main, which isn't the same thing as "you're allowed")
<rbasak> teward: you're allowed :-)
<teward> indeed
<teward> rbasak: thanks for being the interpreter :)
<slangasek> heh :)
 * elbrus is afk
<doko> infinity, all llvm builds fixed, except for 3.6: https://launchpadlibrarian.net/254390499/buildlog_ubuntu-xenial-powerpc.llvm-toolchain-3.6_1%3A3.6.2-3ubuntu2_BUILDING.txt.gz any idea about that one?
<tumbleweed> erm, what happened to http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntustudio.xenial/ ? (seeded-in-ubuntu's crawling is complaining)
<cjwatson> tumbleweed: I've fixed the seed bug that caused that
<cjwatson> nacc: grah, guess I'll have to poke that in the distro tomorrow
<nacc> cjwatson: thanks, i just hit it using launchpadlib which is why i noticed, i haven't yet looked to see if the referenced tree has the correct fix; i don't think the one mentioned in the bug applies any longer (but the correct fix is to just do what other urllib imports did already, and then i think we can delete `import urllib`) itself
<doko> tjaalton, freeipa (4.3.1-0ubuntu1) "Sync from Debian" ???
<cjwatson> nacc: which is what was done upstream
<nacc> cjwatson: ah ok, i hadn't looked yet, thanks!
<doko> xnox, infinity: lz4 now built. the fuzzer tests works with a random seed, so this is a random test failure. Looks like a real bug for some seed values
<denlud> Hey people, my suspend at my Laptop isnt working at the moment. Everytime i wake my laptop up, my filesystem is crashing. Can someone help me?
<denlud> Already tried alot.
<teward> denlud: support in #ubuntu
<denlud> ok
<sarnold> doko: did I read that correctly? lz4's build-test fuzzer found something?
<doko> sarnold, yes
<sarnold> doko: crazy; that feels like hitting a sha-1 collision by chance :)
<doko> sarnold, look at the failed build in the test rebuild for the seed value
<slangasek> tych0: bug #1571082> /var/log/lxd, I have lxd.log and juju-b43656cd-a9d3-4c92-80ac-599997219ad7-machine-0/; did you want one or the other or both?
<ubottu> bug 1571082 in juju-core (Ubuntu) "autopkgtest lxd provider tests fail for 2.0" [Critical,Triaged] https://launchpad.net/bugs/1571082
<tych0> slangasek: lxd.log and $container/lxc.log are good, thanks!
<tych0> the second one might not exist, not sure
<tych0> depends on how far things ogt
<rbasak> The reproducible builds people will love that.
<tych0> rbasak: oh?
<rbasak> I suppose if the binary is stable...
<rbasak> tych0: sorry, I meant about lz4 above.
<tych0> oh :)
<sarnold> rbasak: hah
<sarnold> it shouldn't affect the output packages though
<sarnold> just build logs
#ubuntu-devel 2016-04-19
<Pharaoh_Atem> nacc: I've verified that the extension works :)
<darkxst> infinity, oh the symlink was borked, can you take a look at this fix http://pastebin.com/ttxZLdxP
<infinity> slangasek: ^-- Can you sponsor/review that for Tim?
<cyphermox> infinity: slangasek: I will sponsor that ^ if you haven't already taken care of it
<sarnold> cyphermox: is the destination of that symlink correct? it's still /root/etc/..
<cyphermox> the file needs to go in /root, but what it links to should be the path without /root
<cyphermox> the diff looks correct to me
<sarnold> thanks
<cyphermox> this is because casper runs outside the chroot where our live system is
<sarnold> I always think of /root as a user directory, for uid 0 .. not as a mount point. It kinda hurts my head. :)
<cyphermox> ;)
<darkxst> cyphermox, thanks!
<cyphermox> np
<tjaalton> doko: i don't have time to wait for it to get past debian NEW, there's no diff
<Mirv> pitti: morning. if you want to look at one before I publish the silo, here's one stuck Test in progress: https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-010/excuses.html
<cpaelzer> good monring
<cpaelzer> may be too early for a well typed morning :-)
<ginggs_> morning pitti, thanks for htop!
<pitti> Good morning
<pitti> Mirv: right, let me look into the logs in some 10 mins
<tjaalton> pitti: hi, you might remember working with mlankhorst 2y ago on xorg-lts-transitional? any idea why the packages were limited to just amd64 & i386?
<tjaalton> this package was added to trusty to allow upgrades from lts-foo stacks
<tjaalton> and I had no idea about it until yesterday :P
<pitti> tjaalton: yes, I think we discussed the upgrade approach back then; but no idea why it's limited to these arches
<pitti> tjaalton: perhaps because we only did the enablement stacks on those?
<tjaalton> well they are built on every arch but I guess there are no desktop images for other than these
<tjaalton> images that use an lts stack
<pitti> Mirv: I followed up to bug 1571353
<ubottu> bug 1571353 in Auto Package Testing "test requests sometimes get lost and stay "in progress" forever" [Undecided,Incomplete] https://launchpad.net/bugs/1571353
<pitti> Mirv: so the tests actually did run, but there's something between ci train and britney that doesn't pick them up
<pitti> Mirv: I asked robru about getting a debug log
<robru> pitti: Hmmmmmmm?
<robru> pitti: you want me to re enable -v on the britney runs?
<pitti> (OTP, brb)
<pitti> robru: yes, that would be nice; either in production, or an one-off run
<robru> pitti: Mirv: ok I added the -v flag back, you should see the verbose logs in the next run, maybe ~1hr
<pitti> robru: cool, thanks
<robru> yw
<Mirv> pitti: thank you for looking into it
<pitti> mwhudson: so, I started another run from your branch with -s, and will let you ssh into the testbed right after the failure happens
<pitti> mwhudson: then we can poke around
<mwhudson> pitti: yeah that would be very useful i think
<mwhudson> step 1: wtf is actually listening on 10.0.8.1:8443
<Odd_Bloke> infinity: Did you see we have powerpc images at http://cloud-images.ubuntu.com/xenial/current/? ^_^  If you have the time (you don't have much else going on this week, right?), a test would be appreciated. :)
<Odd_Bloke> (Getting them in to streams is WIP; I'm poking this along when I have a minute between tamping down release-critical fires, and it doesn't matter too much if this lands post-GA :)
<cjwatson> nacc: lazr.restfulclient fix working its way into xenial-proposed now; thanks for the nudge
<jtaylor> are there differences between debians ppc64el and ours?
<jtaylor> seems like at least some compiler macros are defined in xenial that aren't in unstable
<jtaylor> ah no the compiler reports itself as ibm oO
<Mirv> pitti: did you get better logs now?
<jtaylor> does someone have access to a ppc64el box for a quick test?
<jtaylor> not necessary as I can likely fix it without access but I am curious what the compiler doing
<pitti> Mirv: yes, I did, and I just finished writing the followup to the bug
<pitti> robru: you can disable verbosity again, thanks for your help
<pitti> Mirv: it's clear now what happened, I'll restart your lost test
<Mirv> pitti: thanks a lot! the silo is already gone through QA so I was just holding off for getting this debugged which should help people in the future.
<Mirv> pitti: interestingly the silo was already britney approved last week (which is why it went to QA queue), but at some point I noticed all of its tests, including passed ones, were restarted.
<pitti> Mirv: ah! well, nothing lost except for some additional universe heating then :)
<Mirv> :)
<pitti> Mirv: hm, that's curious -- it should see the previously passed results then
<pitti> unless the whole silo got cleared
<pitti> or did that involve a followup upload? (this would re-trigger all tests)
<Mirv> pitti: nothing happened in the silo, I guessed it was some sort of global restart of things.
<Mirv> the silo has stood still since last Wednesday
<pitti> Mirv: ok, whatever then :) I understand what's going on, I'll think about how to solve this in the least possible ugly way
<Mirv> yet something caused that. so I noticed it from the fact that suddenly bileto showed "Running" instead of "Approved"
<Mirv> thank you again for looking into it
<sveinse> What is the difference from Ubuntu core and a system which is debootstrapped?
<pitti> jtaylor: can test something for you if you want
<jtaylor> pitti: if you have time great, I already fixed the problem but my curiousity remains :)
<pitti> meh, no xenial schroot on the porter box; -- moving to a scalingstack instance
<pitti> jtaylor: so what do you want me to run?
<jtaylor> pitti: http://paste.ubuntu.com/15928177/
<jtaylor> should be cat ftest.s, not cat test.s
<pitti> jtaylor: http://paste.ubuntu.com/15928232/
<pitti> jtaylor: that's actually the first piece of Fortran that I'm looking at, from the last 20 or so years :)
<jtaylor> pitti: thx so there is an IBM in there which trips the package up
<jtaylor> and also looks like its ubuntu specific which explains why debian is not affected
<jtaylor> pitti: if only I could say the same ._.
<jtaylor> still ahve to occasionally deal with f77 code, written when f77 was actually new ...
<pitti> +  * Update the ibm branch to 20160324.
<pitti> jtaylor: ^ in https://patches.ubuntu.com/g/gcc-5/gcc-5_5.3.1-14ubuntu2.patch
<pitti> jtaylor: can I delete that ppc instance again, or do you still need anythign?
<jtaylor> pitti: no thats it thanks
<jtaylor> the ibm in the output in ubuntu is fine its just the package that does a pretty dumb check
<jtaylor> it just does essentially grep IBM = ibm compiler
<Laney> nice, I was eyeing that failure
<jtaylor> Laney: the latest upload has fixed it
<Laney> I see that
<jtaylor> I did check debian if all arches work first but this was ubuntu specific :/
<Laney> barry: sounds like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160419_041620@/log.gz is caused by the new virtualenv
<barry> Laney: see, i don't quite understand that because 15.0.1+ds-2 fixes it for me locally :(
<barry> Laney: and the same versions work in an sid chroot
<barry> *and* a xenial chroot
 * barry retries
<barry> at least it will give me time to get some breakfast and caffeine first ;)
<Laney> :(
<Laney> barry: adt-run --output-dir /tmp/virtualenv/out --timeout-copy=6000 --setup-commands 'if grep -q trusty /etc/lsb-release; then apt-get install -y build-essential; fi; apt-get purge --auto-remove -y ubuntu-snappy-cli || true' --apt-pocket=proposed=src:python-virtualenv --apt-upgrade tox --env=ADT_TEST_TRIGGERS=python-virtualenv/15.0.1+ds-2 --- qemu ~/temp/adt-xenial-amd64-cloud.img
<Laney> this makes it reproduce
<Laney> with an adt-buildvm-ubuntu-cloud thing
<barry> Laney: okay thanks.  let me see if i can figure out what's up
<barry> Laney: so the problem with your reproducer is that it doesn't pick up python-pip-whl 8.1.1-2 which is where one half of the fix is.  if you add ,src:python-pip to the --apt-pocket option, then it does pick up 8.1.1-2 and all the tests pass.  notice in the excuses log file that it is picking up pip 8.1.1-2 but it's still picking up virtualenv 15.0.1+ds-1 but the other half of the fix is from 15.0.1+ds-2.
<barry> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python-virtualenv/20160418_153721@/log.gz
<barry> Laney: so why isn't excuses picking up both pip 8.1.1-2 and virtualenv 15.0.1+ds-2?
<barry> similarly, the tox failure is picking up python-pip-whl 8.1.1-1 and virtualenv 15.0.1+ds-2
<Laney> barry: It's using the smallest amount of stuff possible from -proposed
<Laney> do you want a Breaks or something?
<barry> Laney: i guess, if that'll make sure the right versions of both are picked up
<Laney> barry: We could retry with both, but it seems correct to add it if you need both pieces to have working stuff
<barry> Laney: let me look
<barry> doesn't help that debian broke my sbuild ;)
<barry> maybe just add a Depends: python-pip-whl (>= 8.1.1-2) to virtualenv? (and similar to tox)
<barry> Laney: ^^
<Laney> barry: Probably just virtualenv is enough?
<barry> Laney: possibly.  let's try that first and see.  i'll upload to debian momentarily and syncpackage it over when lp picks it up.  if that's not good enough i'll add a version constraint to tox on virtualenv
<barry> Laney: http://paste.ubuntu.com/15929623/
<Laney> barry: That'll force the new one to be installed, which I think is Good Enough
<barry> Laney: +1
<Laney> feel free to syncpackage --no-lp imho
<barry> Laney: ack
<caribou> Excuse the noob's question but I've been running Xenial since the beginning so why is the archive pushing me >500 packages two days from release ?
<gQuigs> caribou: what packages?   I maybe got 30 in last two days
<caribou> gQuigs: well, 629 packages to be exact so most of everything including LibreOffice, vim, xorg,juju
<rbasak> caribou: are you using a mirror that has just been kicked into life perhaps or something?
<caribou> rbasak: archive.ubuntu.com
<rbasak> There have been many minor (bugfix) updates flowing through recently BTW.
<cjwatson> libreoffice was last changed in xenial on 2016-04-08
<gQuigs> caribou: I last updated libreoffice on 2016-04-13
<cjwatson> perhaps your apt-get update was failing for some reason
<caribou> cjwatson: I was on training last week, I didn't do any upgrade during this time so the dates make sense
<gQuigs> caribou: do you have IPv6 by any chance?
<gQuigs> oh ok
<caribou> gQuigs: no still ipv4 but looks like it's normal, sorry for the noise
<cjwatson> there you go, so not "two days before release" :)
<caribou> cjwatson: indeed
<pitti> stgraber, apw, smoser: FYI, I filed bug 1572188 about the underlying bug for the weird lxc test failures
<ubottu> bug 1572188 in cloud-utils (Ubuntu) ""ubuntu-cloudimg-query xenial daily" fails with "confused by argument: xenial"" [Undecided,New] https://launchpad.net/bugs/1572188
<nacc> cjwatson: thanks!
<nacc> Pharaoh_Atem: awesome, thanks!
<smoser> pitti, apt-get install distro-info
<pitti> smoser: ooh
<pitti> smoser: curious, why does it work for precise and trusty then?
<smoser> $ grep KNOWN_RELEASES /usr/bin/ubuntu-cloudimg-query
<smoser> KNOWN_RELEASES="hardy karmic lucid maverick natty oneiric precise quantal
<smoser> 	local releases="${KNOWN_RELEASES}" r=""
<pitti> some hardcoded fallback list? (I thought this queries the remote json for available releases, not distro-info)
<pitti> aah
<smoser> ubutnu-cloud-image-query just needs *really needs* to be replaced by something reading the stream data.
<pitti> smoser: thanks for this
<stgraber> I guess it recommends distro-info but doesn't depend on it or something?
<pitti> yep
<stgraber> and we somehow had some images that did have it for whatever reasons, explaining the random results
<pitti> stgraber: I think I know this
<stgraber> pitti: is distro-info something we should have in the adt image or do you prefer a new test dep on lxc instead?
<pitti> stgraber: for a while now creating adt images on lcy01 has failed
<smoser> it is a recommends.
<stgraber> ah, so old images have it, new ones do or something
<pitti> stgraber: so sometimes we run tests on full fat cloud images (on lcy01), and sometimes on adt images (on lgw01 or bos01)
<pitti> and the latter are minimized and presumably don't have distro-info
<stgraber> smoser: yeah, won't do us much good since adt doesn't pull recommends
<pitti> stgraber: well, you can tell it to
<pitti> Either add "Restrictions: needs-recommends" or add "distro-info" as a test dependency
<pitti> (just wrote that to the bug)
<stgraber> oh, then I guess I should do that everywhere because that's kinda what we expect with it being the distro default :)
<smoser> "The Recommends field should list packages that would be found together with this one in all but unusual installations. "
<pitti> well, depends what you want to test
<stgraber> I want to test the thing my users will get
<stgraber> which means, having the recommends
<smoser> unless you want to test unusual installations :)
<pitti> if you want to verify that your recommends are really optional, then you don't want that
<hallyn> for days now i've not been able to update my xenial laptop, alwyas get Hash Sum mismatches
<stgraber> well, someone installing lxc with --no-install-recommends wouldn't be getting the templates at all :)
<pitti> stgraber: anyway, let me know if I should upload lxc with that, or you want to do it from teh airpirt
<pitti> airport too
<smoser> hallyn, hm... those shoudl be gone the way of the dinosaur
<stgraber> pitti: I can do it
<hallyn> smoser: ...
<smoser> https://bugs.launchpad.net/launchpad/+bug/1430011
<ubottu> Launchpad bug 1430011 in Launchpad itself "support apt by-hash mirrors" [High,Fix released]
<smoser> and http://www.chiark.greenend.org.uk/~cjwatson/blog/no-more-hash-sum-mismatch-errors.html
<pitti> hallyn: using apt-cacher-ng by any chance?
<smoser> so that is interesting that you see it.
<hallyn> smoser: then i call that a big fat fail :)
<hallyn> yeah
<hallyn> i was thinking i should turn it off for a bit, but...
<smoser> There will still be some people who wonât yet benefit from this. debmirror doesnât support by-hash yet; apt-cacher-ng only supports it as of xenial, although thereâs an easy configuration workaround
<pitti> hallyn: I had lots of troubles with that until cjwatson helpfully pointed out /etc/apt-cacher-ng/backends_ubuntu
<smoser> (see the cjwatson link there, hallyn)
<pitti> hallyn: for me this was pointing to "de.archive.ubuntu.com",  i. e. it would divert all requests to *archive.ubuntu.com to that
<pitti> hallyn: which caused hash sum mismatches to no end
<smoser> pitti, we can update cloud-utils if yiou want.
<hallyn> pitti: so you removed it?  pointed it to locahost?
<smoser> to contain 'xenial'
<pitti> I changed that to just a.u.c. and I've never gotten it ever since
<hallyn> a?
<cjwatson> I raised this in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819852; no response yet
<ubottu> Debian bug 819852 in apt-cacher-ng "apt-cacher-ng: support by-hash index files" [Normal,Open]
<cjwatson> a = archive
<pitti> hallyn: archive.ubuntu.com
<hallyn> cjwatson: oh, so i should turn it off?
<pitti> hallyn: well, full contents is: http://archive.ubuntu.com/ubuntu/
<hallyn> pitti: ok, thats where mine is pointing
<stgraber> pitti: uploaded
<hallyn> no, us.archive...  ok lemme try dropping us.
<pitti> hallyn: hmm, so it's not that then; for me that was it
<cjwatson> hallyn: that's not what I said :)
<cjwatson> hallyn: dropping us.archive.ubuntu.com from /etc/apt-cacher-ng/backends_ubuntu will probably indeed deal with it for the moment
<pitti> stgraber: cheers
<hallyn> cjwatson: i'm having a hard time following
<stgraber> pitti: didn't test to see if we may need more than that though, not enough bandwidth for that, but since all the other tests passed, that should really be it
<cjwatson> hallyn: just interleaved IRC conversations
<cjwatson> hallyn: my last-but-one statement is in agreement with pitti, so do that
<hallyn> neither emptying the file nor using http://archive.ubuntu.com/ubuntu/ seems to help
<pitti> stgraber: should be fine
<hallyn> do i need to apt clean?
<cjwatson> hallyn: apt-get -oDebug::Acquire::http=1 -oDebug::Hashes=1 update
<cjwatson> hallyn: apt clean -> no, that's entirely useless here
<hallyn> http://paste.ubuntu.com/15931040/ and http://paste.ubuntu.com/15931043/
<pitti> that doesn't look like a hash sum mismatch
<pitti> just google's repo not being signed enough
<pitti> I had that too, I just removed it
<cjwatson> indeed, I see no hash sum mismatches there.
<cjwatson> I'm happy to debug a hash sum mismatch, but only if you can show me update output with those debug options that actually exhibits a hash sum mismatch
<hallyn> d'oh, sorry, http://paste.ubuntu.com/15931102/
<hallyn> i pasted the same file twice
<cjwatson> that's a mismatch on debs, rather than on indexes
<cjwatson> which suggests apt-cacher-ng has cached corrupt data
<hallyn> <shrug>
<hallyn> ok
<cjwatson> you may shrug but it's important!
<cjwatson> I would probably rm -rf the relevant bit of apt-cacher-ng's cache and start again
<cjwatson> it's clearly got itself hopelessly lost
<rbasak> There was an apt bug causing deb download corruption.
<hallyn> ok, lemme rm -rf its cache
 * rbasak looks
<cjwatson> those files don't change content without changing URL and never have
<hallyn> so it seems to me this should be self-healing
<cjwatson> I've seen acng corrupting data in the past, but not for a while
<rbasak> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810796
<ubottu> Debian bug 810796 in apt "HTTP pipelining is broken and causes download failures" [Normal,Fixed]
<hallyn> i'm on the road,  there's a good chance acng isn't entirely to blame,
<rbasak> Should be fixed in the archive.
<cjwatson> it can probably only be self-healing with cooperation from acng
<rbasak> But if it's regressed or soemthing, then turning off HTTP pipelining may help.
<cjwatson> if it's cached lies and persistently continues to serve them, there's not a whole lot apt can do
<hallyn> cjwatson: as a naive user, seems like it should be able to tell acng "that doesn't seem right, try again"
<cjwatson> hallyn: that still requires cooperation from acng ...
<hallyn> of course
<hallyn> why is that bad?
<cjwatson> it's not, but it's what I said above and you appeared to be contradicting me?
<hallyn> hm, no, wasn't contradicting you
<cjwatson> AFAICS apt-cacher-ng does not implement the relevant cache-busting headers at all
<hallyn> there are such headers?
<cjwatson> it just entirely ignores stuff like Pragma: no-cache and Cache-Control
<hallyn> might be something i could look into this spring
<cjwatson> https://tools.ietf.org/html/rfc2616#section-14.9
<cjwatson> the thing that's needed would be for it to implement Cache-Control: max-age=<seconds>, I think
<hallyn> is apt sending that now?
<cjwatson> no, but it's the basic mechanism that would be necessary to recover from this sort of thing
<hallyn> seems like 'fetch url1;  hash some mismatch; fetch url1?refetch' would more directly fix it
<cjwatson> apt could at least conceivably send it as an attempt to recover from a hash mismatch on a package
<hallyn> but i guess that doesn't fit into the spec
<cjwatson> hallyn: the "refetch" step in your pseudocode would need to be implemented by adding the Cache-Control: max-age=0 header
<hallyn> right
<hallyn> ok, maybe i'll look into that, thx
<cjwatson> np
<cjwatson> just for clarity, this is unrelated to any of the stuff I changed recently
<hallyn> cjwatson: right,
<hallyn> and i think i know wha thappened - damned internet provider a few days ago redirected requests to their signin page and corrupted apt-cache-ng.  so yeah i want to code the automatic fix for that
<cjwatson> right, captive portals are the work of the devil
<cjwatson> apt itself is a lot better at dealing with those than it used to be
<cjwatson> i.e. it doesn't save stuff that doesn't validate
<cjwatson> but I don't think acng is clever enough for that :-/
<cjwatson> so that's a separate fix, if acng understood the current state of the archive it's trying to fetch well enough, it could just not cache resources that can't possibly fit into it.  I don't know if that's feasible within acng's design
<hallyn> and then once google chrome gets redirected it caches that value, and send sme back to the portal every time until i go to settings to clear all cached pages :)
<hallyn> hm, yeah, that could be simpler
<hallyn> and good enough for me
<cjwatson> I suspect that right now it doesn't parse the archive's index files in enough detail to be able to do that
<cjwatson> probably something to discuss with upstream before thinking about implementing it
<cyphermox> hallyn: NM can help you distinguish if you're behind a captive portal, if it helps
<hallyn> cyphermox: NM can't even find my mr3020 hotspot half the time
<cyphermox> o.O?
<hallyn> cyphermox: but the problem is captive portals which randomly and frequently recet
<hallyn> (crappy-ass tengo internet in particular)
<hallyn> reset even
<cyphermox> yeah, but that's what I'm saying, it can poll some website of your choosing, look for a string, every $interval
<hallyn> so it's not at connect time - apt is going along fine, then it resends me to the portal
<hallyn> right but interval isn't actually regular.  sometimes it's every day, sometimes every 2 minutes (at the same location)
<cyphermox> and flip a key available in DBus that tells whether you have local or global connectivity (global meaning said website got the string)
<hallyn> they really are broken...
<cyphermox> ok
<hallyn> i had a script doing it by hand, every 5 minutes - still not good enough :)
<cyphermox> ok
<cyphermox> threaten them with less money?
<hallyn> cyphermox: now maybe i should be doing something like keeping a connection open and detecting when it's hung
<hallyn> hah, the curse of free
<cyphermox> oh ;)
<hallyn> i *should* get satelite internet.  but $$
<cyphermox> hallyn: what kind of internet right now?
<hallyn> now meanwhile, yes, i shoudl file a bug on NM and my hotspot.  soemtimes it just doesn't find it
<cyphermox> maybe you could do some keepalive magic.
<hallyn> cyphermox: at this very moemnt, it's tengo internet at an rv park in austin.
<cyphermox> right, but that's wifi?
<cyphermox> or dialup?
<hallyn> oh, yeah.
<hallyn> so a ubiquity m.2 rocket connected to tengo internet, with tp-link mr-3020 serving that to other devices
<hallyn> sometimes NM doesn't find th emr-3020, so i use scripts manually using wpa-supplicant :(
<hallyn> 'manually'
<hallyn> what kind of logs can i provide for a bug report?
<cyphermox> pretty much just syslog would have everything
<hallyn> 'sudo dmesg', or journalctl -u network-manager or something?
<cyphermox> NM just gets whatever wpasupplicant returns, but it has some issues in wily, and different issues in xenial
<cyphermox> nah, /var/log/syslog
<hallyn> i'm on xenial atm,
<hallyn> ok, i'll switch back to n-m after a meeting and file a bug when it happens
<hallyn> thx
<hallyn> i should see if nmcli usage has changed recently too....
<nacc> slangasek: fyi, debian testing may just remove php-horde-mongo; not sure if we'd want to follow suit (it's one of our two remaining known-broken packages). Only has reverse-recommends in the archive, and will probably need to add a new package (https://github.com/mongodb/mongo-php-library) which Debian is not planning on adding
<slangasek> nacc: yes, removal is fine/appropriate; file a bug?
<nacc> slangasek: ack, will do
<bdmurray> pitti: Will you be testing the SRUs in bug 1560797? If not I can do it.
<ubottu> bug 1560797 in apt (Ubuntu Wily) "apt does not configure Pre-Depends: before depending package" [High,Fix committed] https://launchpad.net/bugs/1560797
<Ajith> Hi
<Ajith> Hi my name is Ajith kumar, I am a newbie to the world of Linux environment. I started working with Ubuntu for the past few weeks and i am eager to contribute to the the vibrant community and i have absolutely no idea how to get started.Can some Guide me what to do?  P.S:I am a Computer science student and interested to work in coding part.
<Pici> !contribute | Ajith there are some good links here
<ubottu> Ajith there are some good links here: To contribute and help out with Ubuntu, see http://community.ubuntu.com and https://wiki.ubuntu.com/ContributeToUbuntu
<Ajith> Thank you for your help ubottu and Pici
<jtaylor> doko: fyi a numpy delta and the fftw delta could now be dropped due to build depends on universe for main being allowed now
<jtaylor> numpy is just for plots in the docs and fftw is an mpi library which can stay in universe
<slangasek> nacc: archive removals, ~ubuntu-archive should be subscribed (done for bug #1564103)
<ubottu> bug 1564103 in php-horde-mongo (Ubuntu) "Please remove php-horde-mongo from the archive" [Undecided,New] https://launchpad.net/bugs/1564103
<nacc> slangasek: ack, was just about to, sorry
<slangasek> nacc: ok - figured that might be the case, but you subscribed me first so I interfered ;)
<nacc> slangasek: absolutely, appreciate it :)
<pitti> bdmurray: I'll do some tests, but if you have a setup ready for doing upgrade tests with that, that'd be appreicated of course
<bdmurray> pitti: I did wily already
<pitti> bdmurray: oh wow, thanks
<tkamppeter> infinity, hi
<infinity> tkamppeter: I'm getting there.
<infinity> tkamppeter: You're in a queue.
<sarnold> .. all alike
<tkamppeter> OK
<infinity> pitti: You still around?
<pitti> infinity: I am now (for another hour or so)
<Laney> pitti: did you do anything to fix lxd before?
<pitti> Laney: sorry, before what?
<infinity> pitti:
<infinity> Apr 19 12:24:20 nosferatu systemd-fsck[574]: /dev/sda1: 7 files, 7094/489976 clusters
<infinity> pitti: ^-- That line's hitting the console on boot.   lolwut.
<Laney> It had some proxy / network problem, but then started passing
<Laney> The latest upload is failing again
<Laney> Wondering if you did some magic or if it's a real bug
<infinity> pitti: Purely cosmetic, but between that and 1 line from the kernel, we're close to a completely quiet boot.
<pitti> Laney: hm, no; my first reaction was that it might depend on whether it runs on lcy01 (standard cloud images) vs. lgw01 (minimized adt images), but we purge lxd on lcy01 too
<pitti> infinity: oh dear, I smell some plymouth ordering/race again
<pitti> Laney: not sure what you mean, http://autopkgtest.ubuntu.com/packages/l/lxd/xenial/amd64/ looks pretty good?
<pitti> Laney: or do you mean lxc?
<Laney> pitti: oh, whoops, brain fart, I mean snapd
<Laney> s/lxd/snapd/g
<pitti> Laney: don't do that :)
<pitti> infinity: oh, wait, yeah -- that's initramfs
<pitti> infinity: when we merged that from debian the last time, fsck and r/w mount of / moved into initramfs
<infinity> pitti: Oh, right.
<infinity> pitti: So, would be nice to figure out how to shut that up on !error.
<pitti> back then I mentinoed that this will give us non-pretty fsck for root fs, but we didn't seem overly concerned
<pitti> infinity: well, fsck might take several minutes, you do want to see this
<infinity> If there's an actual fsck, that's a different case than the mount-time fake fsck.
<pitti> infinity: yeah, if it's quick it would be nice to hide indeed
<pitti> infinity: ah, the thing you quoted above is a "short" one?
<infinity> pitti: Yeah, that wasn't a "real" fsck, that's the "you asked me to fsck a clean filesystem, so I didn nothing" fsck.
<infinity> pitti: ie: I see it on every boot.
<infinity> Oh!
<infinity> That's not even my root.
<infinity> That's the EFI filesystem.
<infinity> Hence having "7 files". :P
<pitti> ah ok, so that should be under the control of the real root then
<infinity> Indeed.
<infinity> Hence why it's systemd-fsck, and in the journal.
<pitti> Laney: I interpreted http://autopkgtest.ubuntu.com/packages/s/snapd/xenial/amd64/ as "1.9.3 was broken", 1.9.4 fixed, and 2.0.2 introduced another failure
<infinity> But maybe the one we saw was from the initramfs.
<pitti> Laney: and the first and second result both ran on lgw (i. e. on a minimized adt image), so not much infra difference there
<infinity> pitti: We're going to have another look before blaming systemd.  I think your theory makes more sense.
<pitti> Laney: did you already try running this locally?
<Laney> pitti: I'm suspicious because the failures look the same (i.e. what we created a debug instance for mvo to mess around on the other day)
<pitti> infinity: I'm trying to reproduce with a fake fsck which takes very long
<Laney> Didn't run it myself, will do.
<pitti> infinity: it wouldn't surprise me at all if any of this regressed :/
<pitti> Laney: the "error: no snaps found for "hello-world"
<pitti> ...thingy?
<Laney> pitti: Yeah
 * Laney runs it
<mvo> pitti, Laney: I think its a store issue, I work on this with the store team as we speak
<Laney> hey mvo!
<Laney> you mean a real bug?
<Laney> is that what you found out the other day?
<mvo> pitti, Laney: I am waiting for a new rollout, I think this will fix it
<mvo> pitti, Laney: however there might be yet another issue, but we fixed the http proxy thing so that should be ok
<mvo> the store also moved to a cdn but that should be ok with the proxy fix we did
<pitti> infinity: just FAOD, this is with "splash", right?
<mvo> Laney, pitti: so hopefulyl in ~1h we have a new store rollout and I will retrigger the tests (I hope I can actually do that)
<Laney> yeah, you can if you can upload it
<Laney> Ah yeah, this fails locally
<pitti> mvo: you can test the retry button now on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd (the machinery is mostly idle, so no harm)
<mvo> pitti: excellent, thanks. will do as soon as the store is updated
<infinity> pitti: With splash, yes (though you only catch it for a brief flickery moment), shows without too, obviously.
<pitti> infinity: hmm, I created a partition for /mnt in fstab, and I get plymouth-y pretty fsck
<pitti> (with a fake fsck that takes long)
 * pitti runs update-initramfs to get that into the initrd
<pitti> for the root fs I seem to have the opposite problem: I *don't* get the fsck output in initramfs
<pitti> oh, I see -- it uses bash, and that's not in the initrd
<infinity> And shouldn't be...
<pitti> right, I just need to change the mock to use sh
<infinity> pitti: What have we decided WRT snapd?
<pitti> infinity: AFAICT, wait for the store to get fixed (< 1 h) and retrigger the tests?
<pitti> that's what mvo asked above, at least
<pitti> otherwise I'm fine to hint it in if it blocks stuff
<infinity> pitti: Well, it sort of blocks some world rebuilds slightly.
<mvo> go and hint if it blocks stuff
 * pitti goes and hints
<pitti> I went and I hinted :)
<cyphermox> !regression-alert
<ubottu> bdmurray, cjwatson, Daviey, didrocks, doko, infinity, jdstrand, pitti, RAOF, Riddell, ScottK, seb128, skaet, slangasek, SpamapS, stgraber: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<cyphermox> https://launchpad.net/ubuntu/+source/samba/2:3.6.25-0ubuntu0.12.04.2
<cyphermox> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1572122
<ubottu> Launchpad bug 1572122 in samba (Ubuntu) "Samba upgrade break LDAP authentification only for my w7 clients" [Undecided,New]
<cyphermox> ^ someone pointed me to this
<cyphermox> mdeslaur: ^
<cyphermox> fwiw; I have two more links about the issue: http://serverfault.com/questions/771388/how-can-i-fix-samba-3-6-25-the-trust-relationship-between-this-workstation-and   http://askubuntu.com/questions/759123/samba-23-6-25-0ubuntu0-12-04-2-as-pdc-samba3-nt4-domain-windows-machines-lost
<teward> cyphermox: I should point out this sounds like a known issue in Microsoft's recent patches
<teward> (not entirely related, but lots of domain auth issues on w7 after recent patches)
<mdeslaur> cyphermox: yeah, it's broken
<teward> ^ thats what i guessed though
<cyphermox> teward: no idea, I don't know Samba well enough to know, and don't typically run any Windows machines here
<mdeslaur> have to wait for fixes from upstream/redhat
<cyphermox> mdeslaur: ok
<infinity> cyphermox: stgraber and I already yelled at mdeslaur about it.
<infinity> (After stgraber's mom yelled at him)
<mdeslaur> infinity: unrelated issue
<cyphermox> infinity: sorry, I scrolled back and didn't see.
<infinity> mdeslaur: Oh.  Two similar breakages?
<cyphermox> what's the other issue?
<slangasek> cyphermox: can you remind me where that regression-alert is documented? because I'd really like to deprecate it :)  we ought to just use the regression-updates tag on bugs
<infinity> Forcing TLS unconditionally.
<mdeslaur> infinity: the other one isn't similar, it's that the whole point of the samba update was to disable plain text ldap
<infinity> mdeslaur: Well, similar from the bug subject, I didn't click and read it. :P
<rbasak> slangasek: https://wiki.ubuntu.com/StableReleaseUpdates#Regressions
<cyphermox> slangasek: https://wiki.ubuntu.com/StableReleaseUpdates#Regressions
<mdeslaur> there are currently 4 different regression from the samba badlock updates
<slangasek> infinity: ^^ can I rip !regression-alert out of there? :)
<infinity> slangasek: Go nuts.
<Unit193> slangasek: Want the trigger gone from ubottu?
<rbasak> It is useful to be able to be heard on occasion, as opposed to wondering if somebody's about for something one things is important.
<rbasak> (and time-critical)
<rbasak> I mean not for any old regression, but one that is actively breaking users and might be worth suspending.
<slangasek> rbasak: well, the trigger in question also has a somewhat stale list of people to highlight
<rbasak> That's true.
<Unit193> Could update it.
<rbasak> I suggest updating it and updating the docs to suggest that it be used only in more restricted circumstances.
<mdeslaur> feel free to add me to that list
<cyphermox> I wouldn't mind seeing those pings either
<Odd_Bloke> Yeah, the one time I used it it was massive overkill.
<Odd_Bloke> Had I realised what it would do, I would just have mentioned it in here and seen what happened.
<rbasak> (by an Ubuntu dev perhaps, if not ask for an Ubuntu dev to check on the same channel, and only if suspending the update would be helpful)
<pitti> infinity: I finally have an initramfs compatible mock fsck, but when I  boot (the VM) with the default quiet splash $vt_handoff, I just keep the slightly purple plymouth screen and the initrd's fsck happens on VT7
<pitti> meh
<cyphermox> rbasak: I don't think it's used that often anyway
<cyphermox> and not for just any regression either
<pitti> I see it being used once a month or less
<cyphermox> right
<cyphermox> I certainly wouldn't go nuts for a NM regression ;)
<cyphermox> shim/grub/boot stuff, maybe more.
<infinity> pitti: S'ok.  I'll sort this one out with Andy, lay blame, and fix it in an SRU.  Perfectly pretty boot isn't RC, it's just nice to have. :P
<pitti> infinity: did we actually ever manage that?
<rbasak> Well, an NM regression in an SRU I'd say is important. Depending on what it is. Since it could break users from updating to a regression fix.
 * pitti still remembers some lonesome kernel driver message in quiet mode
<cyphermox> rbasak: you can usually still get wired, and the big bad regressions we do catch ahead of time
<pitti> infinity: http://people.canonical.com/~pitti/scripts/fsck-mock-initrd is the mock I replaced /sbin/fsck with, FTR
<ogra_> pitti, until u upgraded to xenial my XPS13 never showed me anything but plymouth til lightdm (now i have two  lines of fsck output since the upgrade)
<ogra_> so yes, at least on preinstalled OEM hardware we achieved it :)
<pitti> we merged initramfs-tools like three months ago, this can hardly be a new thing?
<rbasak> cyphermox: not everyone can get wired. This laptop I'm on cannot, and I don't have a dongle that'll work handy.
<pitti> so seeing fsck output was actually known; the bit that's not known is *not* seeing it, i. e. hiding it behind plymouth if fsck happens in the initrd
<infinity> pitti: Probabaly not new, I think I was blaming the kernel unti lnow.
<pitti> actually, we did know that too
<infinity> pitti: Don't worry about it.
<infinity> pitti: I'll worry for both of us. :P
<rbasak> Anyway, my point is that some regressions are bad, and I'd like to shout (and have a good chance of being heard) about time critical ones. That's all.
<pitti> infinity: okay :) I guess bedtime then
<cyphermox> rbasak: don't upgrade for my next upload then, we started dropping wifi, it was too broken ;P
<cyphermox> just kidding, of course
<rbasak> :)
<pitti> cyphermox: actually, NM 1.2 landed remarkably quietly, well done
<rbasak> "wifi support removed due to unreliability issues"
<slangasek> yeah, only joking, we've been dropping wifi forever
<cyphermox> pitti: so you say.
<cyphermox> slangasek: ah ah only serious
<rbasak> "tinfoil DoS vulnerability" (cover the aerial)
<slangasek> pitti: a little too quietly, right cyphermox?
 * slangasek looks at his empty logs
<cyphermox> it's not a murder, but it's not as pretty as it seems either
<pitti> well, it's not like I'm reading NM bugs, but I didn't hear any complaints
<cyphermox> slangasek: on that subject, would you mind bringing up logging in wpasupplicant to 11 and looking if the logging gets better?
<slangasek> cyphermox: if you give me directions how
<Odd_Bloke> slangasek: It's one louder.
<slangasek> Odd_Bloke: look over there, it's a cloud shaped like a velociraptor
<pitti> xnox: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qemu seems to make nova unhappy (uninstallable), can you have a look?
<cyphermox> slangasek: add many -d 's to the Exec line in /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service
<cyphermox> -dd or -ddd would be good
<cyphermox> it *will* log a lot more though
<pitti> meh, what's up with s390x tests
<slangasek> cyphermox: ok.  also the wireless hasn't dropped since yesterday so now it's teasing us
<Unit193> cyphermox: So that'd be add you and md, drop Riddell, Scott, skaet, and SpamapS?
<cyphermox> why do I always get the heisenbugs?
<cyphermox> Unit193: I suppose yeah, unless slangasek really wants to drop it completely
<infinity> pitti: I see no reason that should actually be true.
<slangasek> cyphermox, Unit193: I honestly don't think it's useful; I think rbasak knows how to get ahold of SRU team members without it, and generally it renders for me as a contentless highlight well after I've read the bug in email (if the bug is tagged appropriately)
<slangasek> if you want to omit me from the highlight list that is also ok ;)
<cyphermox> if it's not documented, why bother keeping it?
 * rbasak shrugs
<slangasek> if someone who knows about it wants it there and wants to use it, I don't mind it being there and won't tell other people how to run their bot
<rbasak> I don't particularly mind either way.
<rbasak> Since I can always highlight people manually if I feel the need as you point out I suppose.
<infinity> I don't read mid-line highlights anyway.
<rbasak> As long as it doesn't result in some additional delay for some serious could-have-acted regression.
<infinity> So lists don't work for me.
<rbasak> (I only recall having found one or two since I started Ubuntu development in 2011)
<Unit193> So I can talk about infinity all I want and he'd not see it?  Awesome. :D
 * Unit193 ducks.
<rbasak> I don't particularly mind either way> I suppose that's different to what I said earlier. I'm weakening my objection.
<Unit193> !forget regression-alert
<ubottu> I'll forget that, Unit193
<Unit193> cyphermox: There you go.
<rbasak> Does reverse-depends tell me about the release pocket or the proposed pocket?
<tumbleweed> release
<rbasak> OK, thanks
<pitti> The following packages have unmet dependencies:
<pitti>  qemu-system : Depends: qemu-system-s390x
<pitti> infinity: ^ my xenial-proposed schroot says there is a problem -- maybe just publisher delay from binNEW or so?
<pitti>  qemu-system-s390x | 1:2.5+dfsg-5ubuntu9 | xenial-proposed | s390x
<pitti> it doesn't exist on any arch but s390x
<pitti> but all arches depend on it
<pitti> xnox: ^
<infinity> pitti: Oh.
<infinity> pitti: Yeahp, that's a bug.
<slangasek> infinity, pitti: shall I fix?
<infinity> slangasek: Go nuts, if you know how.
<Laney> Three uploads the charm
<infinity> slangasek: The qemu packaging is whack, yo.
<pitti> is it meant to exist on all arches, or is the dep only meant to exist on s390x?
<infinity> No, it's meant to only exist on s390x due to not having system emulation.
 * pitti guesses/hopes the former, would be nice :)
<slangasek> it's a kvm implementation, should not exist on other archs
<infinity> qemu-system shouldn't depend on it.
<pitti> ah, ok
<infinity> Note qemu-system doesn't depend on qemu-system-aarch64 for the same reason, so there should be precedence in the packaging.
<Unit193> Alright, I'm confused how seed blacklists are supposed to work then, it doesn't appear to as in the manpage.  If I blacklist !foo, and it's in an inherited seed, the manpage says it should still be blacklisted and I see in the output '* Blacklisting foo from bar' but it still ends up in the bar-recommends-arch.  What gives?
<pitti> infinity: would you prefer when I fakesync python-virtualenv -3 (to fix the regression in -proposed) now, or wait until tomorrow when it published in Debian and gets imported into LP?
<pitti> (see barry's email)
<pitti> although, this change looks strange, just saw the diff
<infinity> pitti: It's not seeded, don't care about timing.
<pitti> ack
<slangasek> pitti, infinity: qemu uploaded to fix the bug introduced by that old engineer who refuses to recognize non-mainframes are real architectures
<pitti> "old"? :-)
<pitti> isn't he like the youngest of us all? :-)
<slangasek> pitti: he aged 50 years instantaneously the first time he connected to z/VM
<pitti> oh, right -- time acceleration near super-fast machines
<pitti> am I glad that this doesn't affect ssh connections
<cyphermox> ssh going too fast?
<Unit193> cjwatson: Perhaps you can tell me what I'm doing wrong, re: above?
<seb128> slangasek, Laney, infinity, /etc/X11/Xsession.d/60x11-common_xdg_path do "XDG_DATA_DIRS=/usr/share/"$DESKTOP_SESSION":"$XDG_DATA_DIRS"", and worth case if that would be missing it would only means the override doesn't work so not break much, also the Name= translations are stripped by dh_translations in favor of using gettext so we can langpacks
<slangasek> Unit193: blacklist doesn't cause the package to be un-seeded; instead it causes the seed as a whole to be considered buggy and invalid if a package is in the seed and matches the blacklist
<seb128> slangasek, oh, and please tell me what is wrong with my sed use so I do the correct thing next time :-)
<slangasek> seb128: two sed commands operating on the same file, so you're repeating the filename... you can pass multiple commands to sed, either as multiple '-e' arguments or just as commands separated by semicolons
<Unit193> slangasek: Dang, I knew it didn't prevent installation, but from the manpage it seemed like it at least prevented from explicitly being selcted. :/
<seb128> slangasek, oh, good point, I didn't think much when doing that :-/
<slangasek> Unit193: it will cause an image build to fail, which is a bit late in the process
<slangasek> seb128: and it wasn't a critical blocker ;)
<seb128> slangasek, I'm going to change it with the next upload
<Unit193> ...Wow, that's near useless.
<Unit193> slangasek: Thanks for the info.
<seb128> right, was just curious why you meant by "non-DRY"
<slangasek> seb128: DRY == Dont Repeat Yourself :-)
<seb128> ooh, gotcha!
<roaksoax> win 8
<seb128> slangasek, also I'm pondering doing another upload tomorrow (if we get a respin) to include some translations, we could strip the X-Gettext-Domain= for release and put Name[locale]=<translations> entries in the new desktop
<seb128> then go back to langpacks in a SRU when we get a new langpack export which contains translations for the string
<slangasek> infinity: ^^
<doko> cyphermox, console-setup ftbfs
<cyphermox> wat
#ubuntu-devel 2016-04-20
<sarnold> ouch 1572400
<Unit193> Not specifically new, glib/gvfs (or something) related, iirc.
<Unit193> Just use mv/cp/rm! :3
<sarnold> much easier to remember those than something complicated like 'thunar'. 'lunar'? nope 'thor'? nope 'thunder'? nope 'lothar'? nope...
<sarnold> besides, six whole chars, you've already got all of mvcprm in that :)
<alkisg> `do-release-upgrade -d` from 14.04 is prompting me [continue, details etc] in Greek, and it crashes on non utf-8 input, and it doesn't continue by pressing "y" for yes in English etc
<alkisg> Is it safe to just ctrl+c it and re-run it in english?
<sarnold> I'd expect so
<sarnold> but then I'd expect it to work in greek, too.
<alkisg> Python needs some setlocale('utf-8') or so, and apparently isn't not executed at that point...
<alkisg> Thanks, Ctrl+C'ing...
<sarnold> since it's python I'm not surprised it crashed on non-utf8 input :/ but between you and me it shouldn't do -that- either
<alkisg> python3 is unicode by default afaik, I thought 16.04 used python 3 by default
<sarnold> do-release-upgrade comes from your current release, not the newest release though :)
<alkisg> Ah, true
<sarnold> 14.04 LTS's is python3 though
<mgedmin> do you have a link to the ubuntu-release-upgrader bug about this?
<alkisg> No, I didn't file a bug about it
<mgedmin> if nobody ever did, that might explain why the bug's been unfixed for so long ;)
<alkisg> I'm still waiting for input on the last 100 bugs I've filed :)
<mgedmin> that does then to discourage bug filing
<sarnold> unfiled bugs gather no .. moss. I dunno. it's late.
<alkisg> It's a minor detail compared to other bugs that affect us... e.g. we can't even type Greek by default!
 * mgedmin is a user who once got an ubuntu-release-upgrader bug fixed
<cpaelzer> good morning
<sarnold> hey cpaelzer
<alkisg> Good morning
<sarnold> alkisg: man how can you do math if you can't type greek by default? :)
<alkisg> :)
<alkisg> Ouch, now `do-release-upgade -d` thinks I'm already in Xenial and does nothing :D
<slangasek> alkisg: python3 strings are unicode natively; this does not remove the need to do encoding handling when converting from a bytestream (such as stdin) to a string.  please do file a bug about this crash
<alkisg> slangasek: the main problem is that I cannot continue even when I type the English letter there, I'll need to dig in more to file a proper bug report
<slangasek> can't type Greek by default> Î»Î¿Î¿ÎºÏ Î³Î¿Î¿Î´ ÏÎ¿ Î¼Îµ
<slangasek> alkisg: ok
<alkisg> It's like this: Continue [y/N] ÎÎµÏÏÎ¿Î¼Î­ÏÎµÎ¹ÎµÏ [Î»] ==> I can't type "y"
<sarnold> that's already better than something like 80% of the bug reports :)
<alkisg> With "Î»" (Details), it crashed with utf8 exception, then it restarted, then "Î»" worked, but "y" still doesn't work
<slangasek> but you said it crashed, so backtrace please ;)
<sarnold> slangasek: haha, and here for a second I thought you actually knew greek. sigh :)
<alkisg> OK, moment then...
<alkisg> apport-bug /var/crash/_usr_bin_do-release-upgrade.0.crash, right? It popup up the initial window about reporting the issue, and then nothing
<alkisg> Maybe now apport crashes because it can't collect my release info, since it already started the upgrade :D
<sarnold> ubuntu-bug do-release-upgrade ought to work too
<alkisg> It says no such package installed. Then apport-bug ubuntu-release-upgrader-core does work, but it doesn't seem to pick up the trace.
<sarnold> is it still on screen? copy-and-paste is fine
<alkisg> OK let me put the .crash part to pastebin...
<mgedmin> it's ubuntu-bug $(which do-release-upgrade)
<sarnold> mgedmin: gah :) thanks
<mgedmin> it wants a package name or a full path to the program
<alkisg> paste.ubuntu.com/15941779
<alkisg> mgedmin: that works but doesn't seem to pick up the crash either
<sarnold> can you stuff the traceback into the bugreport? that way it won't get lost if the pastebin database goes away for some reason
<mgedmin> strange: Î» is 0xCE 0xBB in UTF-8, but the traceback complains about "byte 0xcf in position 0: invalid continuation byte"
<alkisg> While filing the bug, I saw LP: #1241148
<ubottu> Launchpad bug 1241148 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashes while updating from 13.04 to 13.10 when locale is ru-RU.UTF8" [Undecided,Confirmed] https://launchpad.net/bugs/1241148
<alkisg> I'm guessing it's the same bug report, slangasek do you still want me to file it?
<sarnold> interesting, 0xcf appears to be omicron, Î
<alkisg> http://www.fileformat.info/info/charset/UTF-8/list.htm
<alkisg> 0xcf is the start byte for a lot of greek characters, but not "Î»"...
<cpaelzer> I thought I remembered something very old I once had and found links like this about the "invalid continuation byte" that sounded familiar (to at least my old case) http://stackoverflow.com/questions/5552555/unicodedecodeerror-invalid-continuation-byte
<sarnold> alkisg: of course I forgot to mention.. 0xcf in iso-8859-7 is O ..
<cpaelzer> I don't have all the caht backlog, but would it make any sense to assume it not even is UTF-8 ?
<cpaelzer> bus iso-...
<cpaelzer> ah I see by sarnold you are already on iso-...
<alkisg> sarnold:  I don't think iso-8859 is related here, we're not using it, we're only using utf-8
<sarnold> alkisg: you said it crashed on non-utf8 input, so I jumped to the assumption that you're using the previous decade's encodings :)
<sarnold> alkisg: be sure to mention that in the bug report :)
<sarnold> time to bail :) have fun
<alkisg> sarnold: yeah sorry my bad, it was the error that made me say that
<alkisg> sarnold: do you think I should file a bug report even though another already exists for russian?
<alkisg> slangasek: ^ ?
<sarnold> alkisg: yeah, never hurts
<alkisg> OK, ty
<sarnold> alkisg: they're cheap enough to merge if they're really the same underlying bug, and if they aren't, having two means yours is less likely to be ignored
 * alkisg just doesn't like bugs.launchpad.net/alkisg growing all the time if some of them are to remain unresolved... :)
<alkisg> OK, I filed LP: #1572416, now on to actually do the upgrade even manually...
<ubottu> Launchpad bug 1572416 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashes in Greek locale" [Undecided,New] https://launchpad.net/bugs/1572416
<alkisg> I reverted my sources.list and  tried again do-release-upgrade in Greek, this time it didn't crash, but it doesn't accept y/N either, so I can't continue
<alkisg> Isn't N (capital) there meant to be the default, to be selected with plain enter?
<pitti> Good morning
<alkisg> Hello pitti
<mgedmin> could be a translation file bug
<alkisg> [enter] should still work....
<mgedmin> but the default is N, which is "no, don't continue, abort the upgrade"
<alkisg> Yet it doesn't accept that
<alkisg> It just prompts again
<mgedmin> are you saying Enter doesn't do anything?  that's weird
<alkisg> Well, time to run it with LANG=en_US.UTF-8 :)
<alkisg> Yey, I got it to continue in Greek by pressing the Greek letter for "y", i.e. "Î½" :)
<nhaines> dholbach, seb128: could one of you help me out with a merge proposal?  :)  https://code.launchpad.net/~nhaines/example-content/xenial-fcs/+merge/292345
<seb128> oh, and 4
<dholbach> wow... that's quite late :-(
<dholbach> seb128, are we still spinning new images?
<seb128> as said on -release I can do sponsoring
<seb128> but unsure the release team is wanting it that late
 * dholbach nods
<seb128> dholbach, we might, but even if we are I'm unsure they want to include such changes
<dholbach> I see
<seb128> as said I'm not in the release team
<seb128> so the wrong person to ask
<seb128> I'm happy to help with upload though
<nhaines> Hmm, it's too late to be split between two channels.  :)  I know it's way too late, but there were all sorts of content licensing issues with the video submissions (that I subverted by just creating original content).  It turns out installing Ubuntu 24 times takes a very, very long time.
<nhaines> In any case, I'm asking because it's a pretty low-risk change.  If there were any binary code at all I wouldn't bother for something like this.
<seb128> nhaines, is there a bug explaining the issue?
<nhaines> seb128: no, but I can certainly file one.
<dholbach> seb128, it's the winners from the free culture showcase
<seb128> dholbach, can you just upload it?
<seb128> then we can see if -release wants to get it in
<dholbach> so from a release team POV just new content
<dholbach> sure
<seb128> or if that goes as a SRU
<seb128> for .1
<seb128> nhaines, ^
<seb128> nhaines, dholbach, thanks
<nhaines> seb128: thank you!
<dholbach> nhaines, next time if there are issues like this, please bring it up on the ubuntu-community-team mailing list or elsewhere so people can help
<zyga> good morning
<nhaines> dholbach: the release snuck up on me... the 21st is also my birthday and work's been crazy too.
<nhaines> seb128: good morning!  I hope you're having a great midweek.  :)
<dholbach> nhaines, yeah... that's why I thought somebody could have helped earlier
<seb128> nhaines, lol, hey :-) yeah, a bit crazy, but that's normal in release weeks!
<nhaines> It's looking pretty good!  I've been wanting to reinstall xenial fresh on my main box a couple days early but... been too busy unfortunately.  :)  Probably this weekend though!
<nhaines> dholbach: with the video submission, something had to be done from scratch and I wasn't certain if I wanted to even attempt it.  It was too much work for me to feel comfortable asking someone else to do.
<nhaines> Which isn't much of an excuse, but it's an honest one.  :)  I hope you're having a nice midweek, too!
<dholbach> right... I understand,... I'm not blaming you or anything
<nhaines> dholbach: it's okay, I'll do that myself.  :)
<seb128> dholbach, nhaines, did the package increase in disk size?
<seb128> just checking
<dholbach> seb128, I'll let you know in a sec
<dholbach> -rw-r--r-- 1 daniel daniel 5223256 Okt  4  2013 example-content_48_all.deb
<dholbach> -rw-r--r-- 1 daniel daniel 8995738 Apr 20 10:08 pbuilder/xenial_result/example-content_49_all.deb
<dholbach> seb128, ^
<seb128> ok, another 4.7M
<seb128> I don't think it's going to make a big difference on a > 1G iso, though it's still a step in the wrong direction
<dholbach> maybe something can be done on the video?
<nhaines> I spent 2 hours trying to get the video to look good and not be 30 MB (I think it's 11.7 MB).  I'm not thrilled but the 4 MB one was not acceptable.
<seb128> yeah, it feels late to start trying to change the video format or start recompressing though
<seb128> dholbach, nhaines, just get it in like that, it's not 30M which is good ;-)
<dholbach> ok, uploading it now
<seb128> it's not the only part where we let things drift a bit
<nhaines> I'd like to see work done about that... but then again I miss the 700 MB images and of course I don't have any way to help with any of that, so...
<nhaines> I made sure the community wallpapers were all nice resolution but still 1.5 MB each.  A nice change from last time.  :)
<nhaines> dholbach: speaking of, I did all the packaging work for ubuntu-wallpapers-xenial too!  I was proud of that.  It's the first time I've caused a new package to be created in Ubuntu.  :)
<dholbach> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
<dholbach> :-)
<nhaines> dholbach, seb128: thank you very much.  I'll be thinking about a much better process for xenial+1.
<seb128> nhaines, thanks for working on those, really appreciated!
<dholbach> but yeah... next time: don't do it all alone :)
<dholbach> and keep up the good work - as seb128 said: it's much appreciated
<nhaines> Thank you both.  :)
<nhaines> I did all the work for the wallpapers because I felt guilty asking others to do that in a hurry when I waited so long.  That just didn't scale to the video (which took me like 3 days).  ;)
<dholbach> wow
<doko> seb128, Laney: what are AppStream compatible icons?
<Laney> https://wiki.debian.org/AppStream/Guidelines
<nhaines> It was fun though...  I didn't remember how bold and artistic the default wallpapers got just before the new branding in Ubuntu 10.04 LTS.  I think it'll be a fitting video for 16.04.  :)
<nhaines> seb128, dholbach: okay, this'll be the first update to example-content in like 2.5 years!  \o/  So thanks for your help, sorry for the excessive energy earlier, and now I'm going to get some sleep...
<nhaines> Because if it gets accepted then I have a blog post to write about it and the wallpapers for Thursday or Friday.  XD
<seb128> nhaines, no worry, have a good night and thanks again for the work!
<seb128> wgrant, cjwatson, not something for before the release, but would somebody consider looking at bug #1260760 in exchange of some beer rounds? ;-)
<ubottu> bug 1260760 in Launchpad itself "editing an Ubuntu (gtk+3.0) bug unsets the source" [Undecided,Triaged] https://launchpad.net/bugs/1260760
<seb128> it's a pretty annoying bug
<seb128> every time somebody edits a gtk but it gets reassigned to "ubuntu"
<seb128> I guess it has to do with the "+" in the name
<cjwatson> seb128: I'll see what I can do
<seb128> cjwatson, thanks
<alkisg> Meh, do-release-upgrade from 14.04 was a complete disaster, it errored out in the middle of the update
<cjwatson> https://launchpad.net/bugs/1260760
<ubottu> Launchpad bug 1260760 in Launchpad itself "editing an Ubuntu (gtk+3.0) bug unsets the source" [Undecided,Triaged]
<cjwatson> oops
<cjwatson> Content-Disposition: form-data; name="ubuntu_gtk+3.0.target.distribution"
<cjwatson> Content-Disposition: form-data; name="ubuntu_gtk-3.0.target.package-dWJ1bnR1X2d0ayszLjAudGFyZ2V0LnBhY2thZ2U"
<cjwatson> that looks suspicious
<seb128> alkisg, do you have details on the error?
<alkisg> seb128: I got an apport prompt, let me see if it's the correct one or the previous one...
<alkisg> (the previous was an issue with greek that I reported a couple of hours ago)
<seb128> alkisg, did you use that prompt to submit the bug?
<alkisg> (patience, it needs some time to process it... :))
<alkisg> (92% cpu apport-gtk...)
<alkisg> Nope, apport-gtk closed without explanation
<alkisg> In /var/crash I see the old crash and a new one for smbd only
<alkisg> So it was probably the previous crash that I already reported
 * alkisg has seen apport show up many times about the same bug...
<alkisg> *same crash
<xnox> pitti, i thought slangasek fixed that up for me yesterday.
<pitti> xnox: qemu/ yes, s'all good
<cjwatson> seb128: damnit, you would give me the ridiculously twisty bugs
<seb128> cjwatson, lol, sorry about that ;-)
<alkisg> So the problem was probably due to bamfdaemon, unsatisfiable dependencies for configuring, and removing it temporarily allowed the upgrade to proceed
<Mirv> xnox: please tell me if I need to stop having you as the "go to s390x guy", but I filed bug #1572496 about a s390x SEGV I'm getting with Qt 5.6
<ubottu> bug 1572496 in ubuntu-ui-toolkit (Ubuntu) "s390x build/run failure with Qt 5.6" [Undecided,New] https://launchpad.net/bugs/1572496
<xnox> Mirv, i am s390x guy.
<Mirv> now I'd also need a "go to powerpc guy"..
<xnox> Mirv, powerpc or ppc64el?
<xnox> Mirv, it would be nice if qt build would like automatically execute things under gdb and generate a traceback.
<Mirv> xnox: powerpc only https://launchpadlibrarian.net/254349222/buildlog_ubuntu-xenial-powerpc.gsettings-qt_0.1+16.04.20160329-0ubuntu2~xenialoverlay1~2_BUILDING.txt.gz
<Mirv> filed powerpc bugs bug #1572497 and bug #1572499
<ubottu> bug 1572497 in gsettings-qt (Ubuntu) "powerpc segfault with Qt 5.6" [Undecided,New] https://launchpad.net/bugs/1572497
<ubottu> bug 1572499 in qtcreator (Ubuntu) "qtcreator FTBFS on Qt 5.6 on powerpc" [Undecided,New] https://launchpad.net/bugs/1572499
<latenite> Hi folks, what is 'resolvconf' doing? What do I need it for? Why is a plain static interface in /etc/network/interfaces running 'resolvconf' to manipulate(overwrite) /etc/resolv.conf ?
<ivoks> latenite: ifupdown is just one of the sources for DNS
<ivoks> latenite: if dhclient, ppp daemon, ifupdown would write to resolv.conf, each on its own, they would owerwrite each other
<ivoks> and then... who is correct?
<ivoks> so they have resolvconf, which takes care of that
<ivoks> cool for desktops, but maybe not that cool for servers
<latenite> ivoks, I just wonder when I don't use and dhcp, ppp etc. but only a static configuration. Why is a 'resolvconf' even used for that interface then?
<ivoks> then you don't need it, you can remove it and write everything statically
<latenite> ivoks, why is it default for the server?
<ivoks> it's default in ubuntu
<ivoks> (most of the serves i deployed in last 2 years were actually on dhcp :)
<latenite> ivoks, why is it default for ubuntu?
<latenite> so you say the trend goes to dhcp in servers and that's why servers have resolvconf?!
<ivoks> i wanted to give you a technical reson why it's default and needed. i understand it doesn't cover all use cases, and therefore you can uninstall it
<ivoks> and these kind of questions belong to ubuntu-server or ubuntu; this is a development channel
<latenite> ivoks, What is the difference between uninstalling it and setting up resolv.conf and setting up /etc/resolvconv/*conf ?
<latenite> ivoks, oh ok, I understand
<Odd_Bloke> I just sent an email to ubuntu-devel@; could someone reject it?
<Odd_Bloke> I noticed something I wanted to clarify as I hit send. Â¬.Â¬
<Odd_Bloke> I've sent another one through, with the clarification added.
<Odd_Bloke> So if someone could reject the earlier one and accept the new one, I would appreciate it.
<Odd_Bloke> Oh, I'm able to self-reject; so we should be back to just one message in the queue.
<Odd_Bloke> cjwatson: If/when you have a minute, ^.  (You're listed as the owner of the list, so I don't know who else to ping :)
<Laney> Odd_Bloke: I accepted it for you
<Odd_Bloke> Laney: Thanks. <3
<Laney> not at all!
<LocutusOfBorg> how can I see who is seeding a particular package?
<LocutusOfBorg> seeded-in-ubuntu?
<Laney> yes
<LocutusOfBorg> xserver-xorg-legacy (from xorg-server) is seeded in:
<LocutusOfBorg>   mythbuntu: daily-live
<LocutusOfBorg>   ubuntu-gnome: daily-live
<LocutusOfBorg> ok I need to check with mythbuntu
<LocutusOfBorg> ubuntu-gnome is already aware
<mterry> ogra_, you're killing me with these MIRs  :)
<mterry> ogra_, what's the expectation there?  I doubt they'll all get approved before 16.04 ships
<ogra_> mterry, really sorry that they come so late ... (i was planning that earlier but tons of image issues the last week)
<ogra_> the initramfs tools and the core-libs/-config packages are surely no brainers
<mterry> ogra_, are we looking at forced promotion and dealing with MIR issues in 16.10 cycle?
<ogra_> well, snappy images will obnly release in july ...
<ogra_> so there will still be plenty SRUs
<mterry> ogra_, but flipping between universe and main can't be done in 16.04 repos, right?
<mterry> ogra_, libnss-extrausers and watchdog probably need a quick security look, which is never quick
<ogra_> right, not post release afaik
<ogra_> i dont knwo if we actually need watchdog (was seeded on a 15.04 customer request)... extrausers is definitely essential though
<superm1> LocutusOfBorg: what'st he context on looking for seeding in mythbuntu?
<LocutusOfBorg> xserver-xorg-legacy can be removed
<LocutusOfBorg> x don't need to be root
<LocutusOfBorg> just replace with virtualbox-guest-dkms
<LocutusOfBorg> superm1, ^^
<superm1> LocutusOfBorg: IIRC we're not seeding it explicitly somewhere
<superm1> some meta update needed maybe?
<LocutusOfBorg> yes I guess so
<superm1> LocutusOfBorg: according to http://people.canonical.com/~ubuntu-archive/germinate-output/mythbuntu.xenial/all it's coming from nvidia-304
<superm1> which is an nvidia driver option installable from ubuntu-drivers
<LocutusOfBorg> ok
<LocutusOfBorg> thanks
<Son_Goku> nacc: official libvirt-php 0.5.2 release: https://www.redhat.com/archives/libvir-list/2016-April/msg01337.html
<ogra_> apw, bug 1572650
<ubottu> bug 1572650 in ubuntu-fan (Ubuntu) "[MIR] ubuntu-fan" [Undecided,Incomplete] https://launchpad.net/bugs/1572650
<ogra_> apw, see the request for a team bug subscription ... i assume that should be the kernel team
<ogra_> ?
<apw> ogra_, yes, please
<ogra_> apw, heh, i cant ... needs to be th e team admin
<ogra_> (dunno who that is)
<apw> ogra_, prolly me, where do i change subs ?
<ogra_> i guess ogasawara =
<ogra_> apw, https://bugs.launchpad.net/ubuntu/+source/ubuntu-fan on the right ... "subscribe to bug mail" that gets you a popup where you can then select a team instead of yourself
<ogra_> (in a totally intuitive pulldown with only 2987538475 entries ... )
<apw> ogra_, ok done
<apw> i hope
<ogra_> thx
<slangasek> apw, ogra_: see my followup on that bug about the right bug subcriber for the MIR process
<ogra_> slangasek, ah ...
<apw> slangasek, ahh ok thanks
<ogra_> slangasek, if you make me an admin for snappy-dev i can add that team to the other packages ... (mvo doesnt react, i guess he is afk for dinner or something)
<slangasek> list of recognized teams:http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/package-subscribers#L117
<slangasek> ogra_: ah, I may have privs to do that but don't think I should be adjusting admins on the team without another admin's approval
<ogra_> hrm, i guess we need to add some snappy team to that
<slangasek> ogra_: I can however take care of the actual bug subscriptions now
<ogra_> ok
<ogra_> slangasek, yeahm thats fine too ... i'm not eager to be an admin :)
<slangasek> ogra_: snappy-dev should own all of initramfs-tools-ubuntu-core, libnss-extrausers, watchdog, ubuntu-core-config?
<ogra_> slangasek, yep, looks right
<ogra_> and the ubuntu-core.meta indeed
<slangasek> are you sure? ;)  because some of those look like things it should actually be on Foundations to maintain
<ogra_> oh, feel free :)
<slangasek> watchdog, libnss-extrausers
<ogra_> yeah
<slangasek> subscriptions done
<ogra_> thanks !
<kyrofa> cdimage.ubuntu.com still says "Warning: This image is oversized (which is a bug)." That's not actually a bug nowadays, is it?
<ogra_> depends on the size
<ogra_> iirc we bumped the size to 1G at soome point
<sarnold> I don't think "fit on a cd" has been a goal for a  very long time..
<kyrofa> sarnold, exactly
<Unit193> sarnold: Considering even Lubuntu is having issues with that? :)
<ogra_> no, but fit on 1G usb keys (or sumething along these lines was the argument when it was bumped)
<ogra_> there was a discussion on the ubuntu-devel ML ... a few years ago :)
<ogra_> probably time to re-visit it
<kyrofa> ogra_, ah, then that bug message should perhaps be revamped as it specifically mentions not fitting on a CD being the reason that it's a bug
<slangasek> kyrofa: LP #1289259, and it is a bug that our images and our declared image size limits don't match
<ubottu> Launchpad bug 1289259 in Ubuntu CD Images "Incorrect "oversized image" on the website" [Undecided,Confirmed] https://launchpad.net/bugs/1289259
<kyrofa> slangasek, ah, very good thank you
<jtaylor> doko: what was the reason for this change: https://launchpad.net/ubuntu/+source/pyzmq/15.2.0-0ubuntu3
<doko> jtaylor, syntax errors, and it's py3 only
<doko> jtaylor, what was the reason to remove the test_asyncio.py module? ;)
<jtaylor> hm its not supposed to be py3 only
<jtaylor> but indeed it is
<doko> jtaylor, 2.7 doesn't have asyncio
<jtaylor> doko: but cython has
<doko> jtaylor, well, then cython is wrong if it accepts this for 2.x, isn't it?
<nacc> Pharaoh_Atem: thanks
<Pharaoh_Atem> nacc: actually don't update to it, because I tried to make an update for the Fedora package, and the build system is doing weird things
<Pharaoh_Atem> the code has remained substantially the same, but something is wrong with the build system, so I'd leave it be for now
<Pharaoh_Atem> https://www.redhat.com/archives/libvir-list/2016-April/msg01348.html
#ubuntu-devel 2016-04-21
<rnetocombr> Somebody has news about bug: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1532226 ? It is fixed for tomorrow ? Devs need help testing ?
<ubottu> Launchpad bug 1532226 in unity (Ubuntu) "No menu bar in gtk apps on fresh boot" [Critical,Confirmed]
<cpaelzer> good morning
<alkisg> Good morning
<Unit193> alkisg: So what'd you end up doing for firefox addons?
<alkisg> Unit193: I packaged the .xpi myself, for adblock plus
<alkisg> So now it's signed and works fine, but it's against the debian's desires about compiling everything from source, so it's not a solution that can be applied there
<Unit193> So signed xpi "binary" blob?
<Unit193> Ah, yep.
<alkisg> At what time is Xenial going to be released today?
<alkisg> (Mate, specifically...)
<nhaines> alkisg: there is no set time of release.
<alkisg> Thanks :)
<cpaelzer> Hi, it might just be that this is my first release that I experience internally, but is there something smarter to get around "ubuntu-distro-info: Distribution data outdated" until it is updated than
<cpaelzer> echo "16.10,Yummy Yggdrasil,yummy,2016-04-21,2016-10-18,2017-07-18" >> /usr/share/distro-info/ubuntu.csv
<cpaelzer> since this is a public channel, I juts made something up with Y's in it - no real codenames
<cpaelzer> well even then it surely won't find a yumma
<cpaelzer> yummy, so that will only make ubuntu-distro-info happy, but not work at any later stages
<cpaelzer> the following somewhat works for me - for now "16.10,Y not here Yet,xenial,2016-04-21,2016-10-18,2017-07-18"
<cpaelzer> please let me know if there are better ways
<pitti> Good morning
<ottohak> \join #xubuntu
<darkxst> where does the grub config come from?
<darkxst> bug 1572874
<ubottu> bug 1572874 in grub2 (Ubuntu) "plymouth is disabled after upgrade from trusty due to missing "splash" kernel arg" [Undecided,New] https://launchpad.net/bugs/1572874
<alkisg> darkxst: it comes from /etc/default/grub, GRUB_CMDLINE_LINUX_DEFAULT
<darkxst> alkisg, right, what I mean is what sets the config, that is not just some static file installed by grub
<alkisg> darkxst: grub postinst uses /usr/share/grub/default/grub as a template to set that file
<darkxst> alkisg, oh I see, trusty never specified "splash"
<darkxst> and I guess it doesnt get merged in on upgrade
<pitti> indeed, the default changed in xenial during the merge
<pitti> didrocks: ^ (right?)
<pitti> so this sounds worth a plymouth SRU that adds the flag on upgrade
<yeehi> At what time today will the 16.04 final release be made available?
<pitti> darkxst: mind filing a bug?
<pitti> yeehi: 10 minutes later for everyone who asks :)
<darkxst> pitti, already did
<yeehi> haha! Thank you pitti!
<pitti> darkxst: ah, sorry, can't read 5 lines of scrollback
<pitti> darkxst: bug updated
<darkxst> pitti, what about GRUB_CMDLINE_LINUX? none of those exist on a clean xenial install
<darkxst> GRUB_CMDLINE_LINUX="find_preseed=/preseed.cfg auto noprompt priority=critical locale=en_US"
<pitti> that looks like a grub line from a live system or so, not from an install
<darkxst> it was a 14.04.4 install
<alkisg> He might have pressed f6 while installing, and inserted a --- somewhere in the cmdline, so then ubiquity copied them to the installed system
<darkxst> alkisg, no, I didnt touch f6
<alkisg> darkxst: maybe you installed via usb, made by some tool that inserted that --- ?
<darkxst> it was an ISO Attached to vmware, and pretty certain that was just installed through the usual greeter
<pitti> darkxst: hm, that looks like a very strange command line then; preseed? auto?
<alkisg> I think vmware has some wizard for installing OSes, maybe that was the source of that strange cmdline?
<pitti> ah, that could be
<didrocks> pitti: yeah, the default changed for this
<darkxst> in that case maybe vmware is also messing with the _DEFAULT value
<hikiko> hello
<rbasak> o/
<hikiko> is this the right channel to ask some questions on the SRU process? :)
<hikiko> hi rbasak :D
<rbasak> I think it's the most appropriate place given your question, yes :)
<hikiko> well, I'm trying (for the 1st time) to SRU a change in compiz
<rbasak> Could you please ask your question again to give others context? Then others can help you too.
<hikiko> I found these instructions:
<hikiko> https://wiki.ubuntu.com/StableReleaseUpdates
<hikiko> and I'm trying to follow the steps
<hikiko> basically I want to SRU the change on trusty
<hikiko> so I've downloaded the orig.tar.gz from here: https://launchpad.net/ubuntu/+source/compiz/1:0.9.11.3+14.04.20150313-0ubuntu1
<hikiko> and I applied the change with quilt following these instructions:
<hikiko> http://packaging.ubuntu.com/html/patches-to-packages.html
<rbasak> A source package actually consists (usually) of three files. You want them all, and then you can use tooling that's designed to work with them.
<hikiko> I didn't edit/change anything else except of the code
<rbasak> I suggest you use "pull-lp-source compiz trusty" to download the source package files for compiz that's current on trusty. The tool will also unpack the source tree for you.
<hikiko> so I have to apply the changes to every one?
<rbasak> The tooling takes care of all of this for you. Really your change will only go in the debian tarball and regenerate your dsc for you. The orig file is never supposed to change for a given upstream version.
<rbasak> Then add the quilt patch to the source tree that pull-lp-source unpacks for you.
<rbasak> Use the "dch" tool to add the changelog entry, or edit debian/changelog directly if you wish.
<hikiko> alright :) thank you rbasak, I'm going to start the process from the beginning, I'll ping you again if I have any problems...:D (thanks!)
<rbasak> No problem. Thank you for spending your time helping to make Ubuntu better!
<mwhudson> today i appeared to discover that quilt chokes completely on files with spaces in their name, does that sound right?
<mapreri> are we without name for the next release also this time?  so just about everything will be again blocked for days until mark announces the name?
<mapreri> or maybe i'm just worrying for nothing.
<nhaines> mapreri: don't be silly... it's xenial+1!
<mapreri> heh
<rbasak> Come up with a comedy name and use that instead.
<rbasak> "Yakkety Yak"
<Odd_Bloke> Yoloing Youngster
<mapreri> we should be able to upload stuff to the 'devel' suite :)
<nhaines> Sure, and 'grumpy' was going to be a perpetual 'devel' channel.  :)
<mapreri> #ubuntu-grumpy
<rbasak> Grumpty Gruffalo
<rbasak> Grumpy
<cjwatson> All this would be a lot easier (though still not trivial!) if the publisher were diskless, but that'll take a while.
<cjwatson> At least some of the problems are because casual distroseries name changes have quite a lot of implications for what gets slapped on disk.
<wgrant> It would still be difficult.
<wgrant> The social solution is much easier than the technical one :)
<cjwatson> Certainly.
<wgrant> I sadly can't harrass Mark in person this year.
<loganaden> hoi
<loganaden> we have a patch for nagios-plugins for 15.10, that removes support for sslv3 when openssl is compiled with no-ssl3: https://code.launchpad.net/~pirabarlen-cheenaramen/ubuntu/wily/nagios-plugins/crypto-fix/+merge/292494
<loganaden> backported from upstream
<loganaden> https://tools.ietf.org/html/rfc7568 <- SSLv3 is no longer considered secure
<loganaden> feedback welcomed
<Bluefoxicy> trying to overwrite '/usr/lib/jvm/java-9-openjdk-amd64/include/linux/jawt_md.h', which is also in package openjdk-9-jdk-headless:amd64 9~b114-0ubuntu1
* Laney changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<stgraber> \o/
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<kyrofa> jdstrand, bug #1573188 relating to the discussion yesterday
<ubottu> bug 1573188 in Snappy "unity7 interface doesn't cover indicators or notifications" [Undecided,New] https://launchpad.net/bugs/1573188
<Pharaoh_Atem> congratulations on releasing Ubuntu 16.04 LTS :)
<jdstrand> kyrofa: thanks, commented in bug
<Pharaoh_Atem> can anyone help me with this? https://paste.fedoraproject.org/358315/66065146/
<sladen> Pharaoh_Atem: can we have some context?  Is this trying to install 'ifupdown' on Fedora using 'alien' or some such?
<Pharaoh_Atem> I'm trying to add to the Open Build Service the ability to build native Ubuntu 16.04 packages
<Pharaoh_Atem> here's the full log: http://paste.fedoraproject.org/358318/61266534/
<sladen> Pharaoh_Atem: okay.  Things like 'ifupdown' are low-level networking, that are unlikely to build/run/do anything useful except on Debian-based systems
<Pharaoh_Atem> interestingly, it works fine in 15.10 and older
<Pharaoh_Atem> as well as Debian 7 and 8
<sladen> Pharaoh_Atem: those are useful datapoints to know
<Pharaoh_Atem> I'm not sure what changed to cause this to break
<sladen> Pharaoh_Atem: are you able to get into the machine?  And/or get a shell within the machine
<sladen> Pharaoh_Atem: then we can try running things manually
<Pharaoh_Atem> let me see if I can
<sladen> Pharaoh_Atem: and bisecting between a working and non-working ifupdown package
<sladen> Pharaoh_Atem: any luck
<sladen> Pharaoh_Atem: http://packages.ubuntu.com/search?keywords=ifupdown   shows the various published versions
<sladen> Pharaoh_Atem: from there it's possible to find the .deb  eg. http://mirrors.kernel.org/ubuntu/pool/main/i/ifupdown/ifupdown_0.8.10ubuntu1_amd64.deb
<sladen> Pharaoh_Atem: /etc/init.d/networking then contains '#  Required-Start:    mountkernfs $local_fs urandom'
<sladen> Pharaoh_Atem: trying to work out what 'urandom' is required for  (guessing something like IPv6 randomisation
<sladen> Pharaoh_Atem: and I'm more puzzled for 'mourtkernfs'
<sladen> Pharaoh_Atem: http://changelogs.ubuntu.com/changelogs/pool/main/i/ifupdown/ifupdown_0.8.10ubuntu1/changelog  points at "* Allow "hwaddress random" to generate a random MAC address." from pitti
<sladen> Pharaoh_Atem: (originally added by guus in Debian; merged + uploaded into Ubuntu by pitti)
<Pharaoh_Atem> sladen: brb
<Pharaoh_Atem> sladen: back
<Pharaoh_Atem> I'm unable to get into the image :/
<Pharaoh_Atem> I think I'm going to have to force it to use a chroot instead to see if I can manipulate the environment
<sladen> Pharaoh_Atem: if this is kvm, can you connect to the terminal/serial port?
<Pharaoh_Atem> when the build fails, OBS shuts down the VM :(
<Pharaoh_Atem> and I tried to run the command to start it, and that didn't work
<sladen> Pharaoh_Atem: perhaps OBS has (or needs) a --preserve option
<Pharaoh_Atem> the image is here
<sladen> Pharaoh_Atem: or --no-detach etc
<Pharaoh_Atem> I just don't know how to start it
<sladen> Pharaoh_Atem: qmeu <image>
<Pharaoh_Atem> sladen: so I was able to rebuild the error in a chroot
<dasjoe> kirkland: I stumbled over another tool you wrote, ssh-import-id. Nice!
<kirkland> dasjoe: ;-)
<kirkland> dasjoe: here's a non-comprehensive list: http://blog.dustinkirkland.com/p/open-source-contributions.html
<dasjoe> kirkland: right, I've used some of those before. Happy release day! Also, I'm a bit stuck right now, I'm trying to replace https://gist.github.com/dasjoe/d12a8061bee56a966359d046a61161c6#file-xenial-on-zfs-sh-L202-L204 with "sudo -u dasjoe ssh-import-id dasjoe" which fails due to $HOME still being /root
<dasjoe> Fixed, "sudo -Hu"
<kirkland> dasjoe: yep.
<sladen> Pharaoh_Atem: excellent.  Try commenting out the two 'dependencies' and then run it and see whether it complete
<Pharaoh_Atem> sladen: so how do I do that?
<sladen> Pharaoh_Atem: 20:44 < sladen> Pharaoh_Atem: /etc/init.d/networking then contains '#  Required-Start:    mountkernfs $local_fs urandom'
<Pharaoh_Atem> should I delete that, then?
<Pharaoh_Atem> alright, now I deleted them
<sladen> Pharaoh_Atem: rather than deleteing it completely, perhaps remove the two words 'mountkernfs' and 'urandom' that it was complianing could not be started
<Pharaoh_Atem> sladen: it set up now
<Pharaoh_Atem> so deleting mountkernfs and urandom fixed it
<sladen> Pharaoh_Atem: right, so these appear not be hard depencies
<Pharaoh_Atem> sadly, there's no chance of this getting fixed in xenial :(
<Pharaoh_Atem> I tried to bring this up when I first encountered it last month, but no one was able to figure it out
<Pharaoh_Atem> or rather, had time to
<slangasek> the xenial SRU queue is open for bugfixes
<mwhudson> ah yeah, i should stuff something into that!
<doko> where is y?
<sladen> Pharaoh_Atem: please could you review  https://bugs.launchpad.net/ubuntu/+bug/1573275  and subscribe yourself
<ubottu> Launchpad bug 1573275 in Ubuntu "ifupdown should not hard-depend upon 'mountkernfs' and 'urandom'" [Medium,New]
<Pharaoh_Atem> sladen: confirmed
<Pharaoh_Atem> I'm actually "ngompa13" on LP
<sladen> Pharaoh_Atem: I have subscribed 'Neal Gompa', but it perhaps makes it easier to follow-up on the bug report and get back in contact if it's clear what your various/preferred aliases are and the best way to make contact
<Pharaoh_Atem> sladen: done
<Pharaoh_Atem> I love LP's inability to let me edit comments </sarcasm>
#ubuntu-devel 2016-04-22
<cpaelzer> good morning
<pitti> Good morning
<rayzinnz> 'ello
<hikiko> rbasak ping :)
<hikiko> new questions on the sru
<hikiko> that's what I did so far: https://ufuntu.wordpress.com/2016/04/21/sru-process/ password:trusty used the tools you suggested, quilt and dch and I think (hope) I'm ready to create the new package
<hikiko>  and go to step 5 here: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<hikiko> the question is
<hikiko> which tools I need to create a package?
<hikiko> and how should I name it?
<rbasak> hikiko: that looks good so far.
<seb128> hikiko, did you check with Trevinho? compiz is managed by CI landing
<seb128> not normal uploads
<rbasak> seb128: including for an SRU?
<seb128> rbasak, I was looking at the most recent one, https://launchpad.net/ubuntu/+source/compiz/1:0.9.11.3+14.04.20150313-0ubuntu1
<seb128> the CI bot is the uploader
<seb128> so I guess so
<rbasak> Well that makes life quite a bit harder for hikiko :-(
<hikiko> no worries :) I want to learn the full process
<hikiko> seb128, I didn't I'm now learning the SRU process
<rbasak> I don't know the CI process.
<rbasak> seb128: can you help hikiko?
<hikiko> also, could you tell me the non-CI process?
<seb128> hikiko, can you talk to Trevinho?
<seb128> or maybe do that with him next week?
<rbasak> Or would it be sufficient for hikiko to put a debdiff in the bug and let a sponsor sort it out?
<hikiko> btw seb128 I've seen in the changelog that chris townsend had sru some changes
<seb128> rbasak, hikiko, well for things going through CI landing you just need a merge request with the change
<rbasak> "just"
<hikiko> it's not only the CI bot I think
<pitti> we do SRUs via the CI train too?
<seb128> pitti, of course
<seb128> why not?
<hikiko> Trevinho, is in Prague :D
<seb128> well, wait monday
<seb128> ?
<hikiko> alright :)
<pitti> I just don't think I've ever seen one
<seb128> you are coming next week right?
<hikiko> yes
<pitti> presumably because most touchy stuff lands in the overlay PPA
<seb128> pitti, I just gave an url
<seb128> pitti, all unity landings are done this way
<seb128> unity7
<hikiko> ok but just out of curiosity
<Laney> The only difference for the SRU team person is that it's a copy (with binaries) in the queue instead of a source upload
<hikiko> if I had to SRU it myself
<hikiko> what would be the next step?
<hikiko> how would I create a package and how would I name it?
<rbasak> hikiko: if not following the CI process, you'd adjust the version number, run "dch -r -D trusty ''" to set the metadata in the debian/changelog file.
<rbasak> Then run "dpkg-buildpackage -us -uc -S -nc -d" to create a new .dsc and .diff.gz file for the new version.
<rbasak> An uploader would then be able to use the generated .changes file to upload.
<rbasak> If you need sponsorship, you run "debdiff <old>.dsc <new>.dsc" to create a debdiff, attach that to the bug, and subscribe ~ubuntu-sponsors to the bug.
<rbasak> I've ignored testing here. You can use sbuild to build a test package locally.
<rbasak> Or upload to a PPA for testing.
<rbasak> So you'd done most of the hard part already for the usual process I think.
<hikiko> and then everything else is done on launchpad I guess
<hikiko> upload the package etc
<hikiko> rbasak, thanks a lot!
<hikiko> I'm going to note these steps just in case and wait for monday to ask Trevinho
<rbasak> 12:29 <rbasak> "Yakkety Yak"
<rbasak> Thursday, April 21st, 2016 "Yakkety yakkety yakkety yakkety yakkety yakkety yakkety yakkety yak. Naturally"
 * rbasak isn't sure if that was a coincidence, the obvious choice, or what.
<Odd_Bloke> ALL HAIL RBASAK
<Odd_Bloke> cjwatson: wgrant: FYI, there are 16.04 powerpc images in http://cloud-images.ubuntu.com/daily/streams/v1/com.ubuntu.cloud:daily:download.json now.
<wgrant> Odd_Bloke: <3
<Odd_Bloke> cjwatson: wgrant: I don't believe that infinity has had time to test them since we were building from a PPA, but they shouldn't have changed. since he last told me they were booting.
<wgrant> Booting is good.
<Odd_Bloke> wgrant: Do you pull from daily streams, or release streams?
<Odd_Bloke> (Because they aren't currently showing up in release streams, and I'm trying to work out highly to prioritise fixing that :p)
<wgrant> Odd_Bloke: Do I look like a stable OS sort of person to you?
<wgrant> We've been tracking wily dailies for a while.
<wgrant> No reason not to use xenial dailies now :)
<Odd_Bloke> OK, cool.
<Odd_Bloke> I'll throw fixing that on our backlog then.
<wgrant> Thanks!
<caribou> Laney: would installing all the reverse deps of a backported package considered adequate testing for a backport request ?
<caribou> Laney: I'm testing a script that installs each of the rdepends in a container where the binaries to be backported are installed & checking if it installs correctly
<caribou> curious to know if this would be considered sufficient
<pitti> rbasak: btw, would you mind having a look at my response in bug 1569434 ? If this is real, it'd drive me nuts :)
<ubottu> bug 1569434 in autopkgtest (Ubuntu) "adt-run fails with "dpkg-genchanges: error: cannot read ../akonadi_15.12.1-0ubuntu4.dsc: No such file or directory"" [Undecided,Incomplete] https://launchpad.net/bugs/1569434
<Laney> caribou: Just /installing/ doesn't sound enough to make sure that they aren't busted
<caribou> Laney: apache2 has more than 100 rdepends, you would test all of them manually ?
<rbasak> pitti: I can try to reproduce again.
<Laney> caribou: In this case, does installing enable them?
<Laney> and restart apache to get them used?
<caribou> Laney: I'll check the logs once all of them run but most of them do, yes
<caribou> Laney: I think tests must be specific to each backport context though
<caribou> Laney: but in that specific case, that's how I ran over a know issue & fixed it : LP: #1286882
<ubottu> Launchpad bug 1286882 in mpm-itk (Ubuntu Trusty) "libapache2-mpm-itk postinst failed" [Medium,In progress] https://launchpad.net/bugs/1286882
 * caribou is just trying to get a better understanding of the backport requirements
<Laney> pitti: do you need to teach autopkgtest about yakkety?
<mgedmin> welp, update-manager (15.10 -> 16.04) froze after unpacking gir1.2-atspi-2.0 and "processing triggers for man-db"
<mgedmin> says it's preparing to configure python-cairo, but it's idle
<mgedmin> pstree shows it has one zombie child (dpkg)
<mgedmin> strace shows it's bloked trying to write "pmstatus:libde265-0:16.8172:Inst..." to a pipe on fd 14
<mgedmin> ah, it's an internal pipe used to communicate between threads?  lsof shows that it's the upgrader itself that has the other end open for reading
<mgedmin> the GUI window is not responding to events either
<mgedmin> ... I might've hit Ctrl+Shift+I to open the GTK+ inspector
<mgedmin> while trying to see if it uses GTK2 or GTK3
<pitti> Laney: yes, in the sense that I need to update distro-info-data
<pitti> Laney: also, retracers etc.
<Son_Goku> ah, the joys of using a fresh linux distro release :/
<seb128> dpm, pitti,  I've the feeling we have been there before but any idea why evolution-3.18.mo are missing from langpacks? it makes evolution untranslated in xenial :-/ ( (bug #1566750)
<ubottu> bug 1566750 in evolution (Ubuntu) "16.04: translations completly missing" [High,In progress] https://launchpad.net/bugs/1566750
<seb128> mdeslaur, do you/security team want to be notified about regressions due to the samba trusty security update? and in which way (bug assign? subscribe?) bug #1571854 is another of those
<ubottu> bug 1571854 in evolution-mapi (Ubuntu) "Recent samba updates broke mapi" [High,Confirmed] https://launchpad.net/bugs/1571854
<mdeslaur> seb128: you can tell me about them
<mdeslaur> seb128: that particular one is problematic though as I don't believe there's an openchange package that actually works with samba 4.3
<seb128> indeed not
<seb128> we should at least delete -mapi
<mdeslaur> seb128: thanks for pointing them out, I'll see if there's any other way to fix it when I get a minute
<seb128> or turn it into a "sorry, being removed"
<seb128> thanks
<TJ-> any ideas why 16.04 "apt-get install --no-install-recommends" breaks Unity desktop, in that there is no 'System' menu-icon, and Dash is unable to find any applications via navigation or via a typed search. Also, All Settings > Universal Access > typing > on-screen keyboard doesn't actually provide the on-screen keyboard, and there's no nm-applet shown
<seb128> TJ-, that command shouldn't do anything? or do you mean starting from a base system and installing the desktop without recommends ... that might lead to some component missing yes, don't do that
<TJ-> seb128: Yes. I did a debootstrap install for a 4GiB Flash drive, used that to get the basic desktop, and discovered many issues with missing basic functionality
<seb128> don't do that
<seb128> download the iso and dd it to the stick
<TJ-> seb128: can't; I need an installation on the USB
<TJ-> my point is "--no-install-recommends" shouldn't leave out vital parts of the interface
<dobey> they aren't "vital"
<TJ-> dobey: I disagree. there being no system icon, no nm-applet, no access to applications via dash are pretty serious deficiencies
<TJ-> I discovered this whilst trying to workaround the broken bluetooth GUI PIN-entry agent which prevents pairing with external keyboard/trackpad... have to do it via CLI with bluetoothctl
<seb128> TJ-, you put them as depends and users with no bluetooth complain that they can't remove the bluetooth components
<seb128> can't win
<TJ-> seb128: I'm not on about BT with regard to recommends - that is a separate issue
<rbasak> I think it's reasonable to QA only the default (including recommends case).
<TJ-> seb128: even with all the BT GUI components installed on a *full* install from ISO, gui bluetooth PIN agent is broken, never works,
<rbasak> If there are specific recommends that should be depends, then...patches welcome?
<seb128> +1
<TJ-> First time I've used Unity in about 6 years, surprised its not more mature
<seb128> ?
<rbasak> Otherwise you're basically requiring the doubling of QA effort for what?
<seb128> TJ-, you call it not mature because you did some weirdy install, ignored recommends and then are complaining it's incomplete? or is that an orthogonal statement?
<rbasak> You're welcome to hack your system but when you break it you get to keep the pieces.
 * dobey confused
<rbasak> If you want mature, don't do weird things.
<TJ-> this isn't hacking this is a regression
<dobey> what is a regression?
<TJ-> Bluetooth *used* to work fine; was broken several releases ago  bug 1490347
<ubottu> bug 1490347 in bluez (Ubuntu Wily) "[Regresision] 15:10 - Cannot pair with devices using PIN codes" [High,Triaged] https://launchpad.net/bugs/1490347
<dobey> the bt agent has nothing to do with unity
<seb128> TJ-, that has nothing to do with unity
<dobey> and i can pair with devices that use PINs just fine
<seb128> TJ-, you seem confused?
<TJ-> dobey: bet you can't!
<TJ-> dobey: bet you *can* pair with devices that use *passphrase* ... because bluez ripped out the *pin* support
<dobey> TJ-: except for the many times i've done it in the many years i've been using ubuntu
<dobey> you must be confused
<seb128> TJ-, I doubt bluez removed pin support
<dobey> if bluez removed pin support you wouldn't be able to use bluetoothctl either
<TJ-> I was deep in the source-code last year trying to fix it and the related kernel bugs breaking other devices, but had to give up because it was too involved and I had other things to do. the kernel bug is bug 1491988
<ubottu> bug 1491988 in linux (Ubuntu) "15.10: BT Command List not created: bluetooth:__hci_req_sync:298: hci1 end: err -ETIMEDOUT" [High,In progress] https://launchpad.net/bugs/1491988
<dobey> well i just paired a headset in xenial with no problem
<seb128> TJ-, k, so there is a kernel bug, it's different from being bluez ripping out support
<dobey> had no problem pairing my obd-ii scanner in 14.04, so i expect no problem in 16.04 either
<TJ-> dobey: yes, headsets and so on seem to work but anything that has to enter the PIN in response to the PC fails. E.g. in the GUI for BT, when you discover a device, there's an option to select the PIN method (0000, 1111, 1234, custom) ... none of those will work with the keyboard even if typing them blind (because there's no GUI prompt for the number as there used to be). Using the bluetoothctl it
<TJ-> generates a 6-digit PIN. The thing is, although we call it PIN this is actually using the underlying BT 'passphrase' authentication.
<TJ-> I'll dig my notes out on the debugging I did last year on this, I think I also logged some additional bug reports but will have to track them down
<seb128> TJ-, anyway on the unity issue, I guess it would be fine to move the files/applications lens from Recommends to Depends, feel free to propose a patch for that or to open a bug
<TJ-> seb128: is that why I had no applications listed? so I can manually install that to get over the current impass?
<seb128> TJ-, I guess so
<seb128> unity-lens-applications
<dobey> and indicator-session
<dobey> should probably be Depends of ubuntu-desktop
<seb128> and onboard and
<TJ-> seb128: I shall do.. currrently fighting to get everything working on a 2-in-1 Asus T300chi (touchscreen tablet/laptop hybrid with docking BT keyboard. Not being able to have the BT come up at greeter-time is currently a major issue so using a USB connected keyboard, or ssh in (now I've created a wifi profile in nmtui-edit) :)
<seb128> network-manager-gnome
<dobey> i don't think onboard should be depends
<TJ-> seb128: dobey thanks, I'll install those (already did n-m-g and ubuntu-keyboard - for the on-screen keyboard backup)
<dobey> i'm not sure ubuntu-keyboard is the one you want for that
<TJ-> Full install has all those
<TJ-> dobey: hmmm, really? it looked the most likely candidate!
<seb128> TJ-, ubuntu-keyboard is the one used on ubuntu touch, onboard is the desktop one
<dobey> TJ-: i think onboard is the one used for ubuntu-desktop
<dobey> well, you could just install unity8-desktop-session-mir instead, and use unity8 instead of unity7, then ubuntu-keyboard would make sense perhaps :)
<TJ-> dobey: ahhh! OK, I think you're correct since enabling on-screen keyboard still didn't show anything!
<TJ-> dobey: oh, is that what it's for?
<dobey> i wonder if indicator-network is a usable replacement for nm-gnome now
<dobey> TJ-: yeah, ubuntu-keyboard is the phone/tablet (unity8) osk
<dobey> also, ubuntu-keyboard is in universe
<dobey> no way it would be installed on the ubuntu-desktop iso :)
* cjwatson changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<TJ-> ouch! without --no-install-recommends onboard wants to install tonnes of packages, including a mass of Perl!
<dobey> lol
<TJ-> right.. I needed 2 of the onboard recommends: gir1.2* ... now the greeter shows the keyboard, athough as a shrunken image in a sub-area of the bottom of the screen
<seb128> TJ-, you might want onboard-data
<TJ-> yes, got that earlier, thanks
<TJ-> this is what the greeter shows: https://iam.tj/projects/misc/ubuntu-1604-greeter-onboard-keyboard.jpg
<TJ-> once the user is logged-in the keyboard fills the entire area
<seb128> unsure why it does that
<TJ-> and this is after log-in, showing the empty dash 'applications' tab, and the lack of system icon top-right, plus onscreen keyboard
<TJ-> https://iam.tj/projects/misc/ubuntu-1604-user-onboard-keyboard.jpg
<de-facto> Hey guys im fighting to compile http://packages.ubuntu.com/de/xenial/easystroke via "apt-get source easystroke" then "apt build-dep easystroke" then inside the source dir "dpkg-buildpackage" it gives me this error that i also found in https://bugzilla.redhat.com/show_bug.cgi?id=1302917
<ubottu> bugzilla.redhat.com bug 1302917 in easystroke "easystroke FTBFS in rawhide" [Unspecified,Closed: rawhide]
<TJ-> ahh, and noticed that there's no icon to control the onscreen keyboard
<de-facto> Does someone have an idea how the ubuntu repo managed to compile this?
<cjwatson> It probably built at some point in the past, just not with the current state
<cjwatson> It failed in our latest build test
<cjwatson> But that doesn't mean we throw away the existing binaries
<cjwatson> https://launchpad.net/ubuntu/+source/easystroke indicates that it was built last August
<cjwatson> (https://launchpad.net/ubuntu/+source/easystroke/0.6.0-0ubuntu5/+build/7771352)
<seb128> TJ-, you probably lack indicator-application as well
<seb128> for the onboard indicator
<de-facto> cjwatson yeah that is what i suspected, some incompatible changes in the toolchain, im trying to build it because it has some gfx glitches and also a bug which prevents it from storing its settings correctly. First i want to be able to build the original ubuntu package then upgrade the sources from https://github.com/thjaeger/easystroke to fix those issues (he did not raise the version number unfortunately)
<TJ-> seb128: thank-you seb128 I'll chase that one down. I was about to do a diff between the (full) SDD install and the USB image to figure it out.
<seb128> yw
<TJ-> hehehe and with a 'restart lightdm' greeter doesn't show the onboard keyboard, only the lower blacked-out area :)
<TJ-> just got to find the system-menu indicator icon now
<de-facto> any ideas what i could play around with to fix the error ctions.cc: In constructor 'TreeViewMulti::TreeViewMulti()':   ctions.cc:57:39: error: group' is not a member of 'sigc'   get_selection()->set_select_function(sigc::group(&negate, sigc::ref(pending)));
<de-facto> i guess its something from libsigc++
<LocutusOfBorg> de-facto, libsigc++ version??
<LocutusOfBorg> you might want to test the new upstream release (in debian)
<de-facto> LocutusOfBorg libsigc++-2.0-dev Version 2.6.2-1 on Xenial release currently
<LocutusOfBorg> maybe 2.8.0 works=
<LocutusOfBorg> did it worked before=
<de-facto> i used to compile it on previous versions of ubuntu (dont remember the exact versions though)
<LocutusOfBorg> seems that the group has been removed between 2.4 and 2.6
<LocutusOfBorg> https://anonscm.debian.org/cgit/collab-maint/libsigc++-2.0.git/commit/?id=fa41e72a2a68239a84839e59f763e0f49c0ca098
<LocutusOfBorg> - * @deprecated Use C++11 lambda expressions or %std::bind() instead of libsigc++ lambdas and sigc::group().
<LocutusOfBorg> I think you did get a lot of warnings with the previous release
<de-facto> could very well be the case, i dont remember exactly anymore, but i got a working binary on previous versions of ubuntu
<dobey> TJ-: indicator-session is the "system menu" indicator
<TJ-> dobey: thanks... I've been walking the rdepends/depends paths to try to figure out why it was missed
<Unit193> slangasek: Got time for a quick PM?
<slangasek> Unit193: prime ministers are never quick
<Unit193> Nope, certainly not.  Thankfully, I'm referring to a private message.
<mapreri> pitti: I'm looking at http://autopkgtest.ubuntu.com/packages/p/pbuilder/ and i just noticed the 'i' sign points to tracker.d.o.  I guess this is fine and cool for the debian instance of debci, but probably shouldn't ubuntu link the launchpad page instead? (actually, I'd love to have both links to tracker.d.o and lp)
<bdmurray> lamont: Could you have a look at bug 1552801?
<ubottu> Error: Launchpad bug 1552801 could not be found
#ubuntu-devel 2016-04-23
<doko> cjwatson, for ghc, adding -fPIC like the -fno-PIE arg seems to work around this error. local build still running. nothing found yet for the ppc64el ftbfs
<lamont> bdmurray: will do
<lamont> bdmurray: on the bright side(?) it's dying during service shutdown...  OTOH, It's a &(&*&)P memory leak
<doko> cjwatson, https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/6352952/+listing-archive-extra  local build succeeded, no idea yet where to pass -no-pie on ppc64el
<lamont> bdmurray: sadly, it's quite reproducible
<doko> cjwatson, adding this -fPIC doesn't work. I messed up my local build
<fooctrl> when could we expect Snappy support for Raspberry Pi 3?
<sits> Is it possible for âUnable to install epson printer driversâ to the release notes?
<sits> (https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1536353 )
<ubottu> Launchpad bug 1536353 in lsb "[regression] Printer drivers install is broken as lsb package is not available anymore" [Undecided,Confirmed]
<pasta> Hi
<pasta> Virtualbox dkms doesnt work on 16.04 LTS
<pasta> http://askubuntu.com/questions/760671/could-not-load-vboxdrv-after-upgrade-to-ubuntu-16-04
<pasta> Shouldnt the package maintainers sign the modules?
<cjwatson> doko: I have no time for this, sorry
<doko> ok
<doko> sbeattie, ^^^
<LocutusOfBorg> [13:46:02] <pasta> Hi
<LocutusOfBorg> [13:46:20] <pasta> Virtualbox dkms doesnt work on 16.04 LTS
<LocutusOfBorg> [13:46:51] <pasta> http://askubuntu.com/questions/760671/could-not-load-vboxdrv-after-upgrade-to-ubuntu-16-04
<LocutusOfBorg> [13:47:53] <pasta> Shouldnt the package maintainers sign the modules?
<LocutusOfBorg> damn, didn't the kernel got fixed?
<doko> Mirv, https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-16ubuntu8
<Mirv> doko: looks like something in yakkety is already causing four unit tests to fail :( some image reading, directory sort and a timed process handling related test on amd64 at least
<doko> Mirv, remember amd64 and ppc64el now have -fPIE by default
<doko> Mirv, ohh, image reading? likely libpng1.6
<bipul> Hello, I was trying to install pbuilder , and i am stuck at "I: Retrieving Packages "
#ubuntu-devel 2016-04-24
<akira_> Hello. I am running artificial intelligence heuristic tests at the kernel level on a virtual machine and I was wondering if there was a way to make it so that my user's account doesn't require me entering the sudo password all the time. Is this possible in any way?
<jtaylor> akira_: man sudoers, support is in #ubuntu
<akira_> jtaylor, in #ubuntu I was discouraged from doing this...
<akira_> Also I have added the line "myuser ALL=(ALL:ALL) NOPASSWD:ALL" to /etc/sudoers, but to no avail.
<_heimdall> " _heimdall: possible, not recommended."
<teward> _heimdall: you were discouraged from editing if you don't know what you're doing
<_heimdall> teward, that's so derogatory...
<_heimdall> Of them I mean.
<teward> _heimdall: some of those people are also here mind you
<teward> _heimdall: on the Security / Sysadmin side, I agree with them - people who don't know how to edit sudoers by reading manpages shouldn't be editing things.  However, I also understand the other side why you would want this
<teward> _heimdall: support is still in #ubuntu though
<teward> sorry
<_heimdall> Hurg.
<siretart> _heimdall: you should try to find out why they discourage you from doing that. by then, you'll have found out how to achieve exactly what you want.
<_heimdall> Thank you, old wizard :|
<_heimdall> I mean I did that already, found out that root was locked, I unlocked root, didn't work.
<_heimdall> work/do what I wanted to achieve
<TJ-> I've just noticed that after adding a keyring in /etc/apt/trusted.gpg.d/ and confirming the keys contained are reported by "apt-key list", that "apt{,-get}" report 'public key not available' for those keys. What am I missing?
<maxb> I'm experiencing a bluetooth regression in xenial, can someone suggest where I can go for some assistance in refining a useful bug report?
<TJ-> maxb: support is generally in #ubuntu
<maxb> I feel I'm more looking for assistance helping combat a regression rather than user support, but I can see how that could be a matter of opinion
<TJ-> that's what we do in #ubuntu too
<TJ-> re: the apt 'public key not available' issue - just found out that the processes must be running as a user other than UID 0 when checking, because "chmod -R o+r /etc/apt/trusted.gpg.d/" solved it
<infinity> maxb: Just file a bug ('ubuntu-bug linux'), provide as much descrition of the problem as you can, and iterate there.
<infinity> maxb: If it feels like it'd be a pretty widespread issue, perhaps ping jsalisbury to help you triage it.
<TJ-> I'm done some in-depth BT debugging and fixing but I keep the triage process in #ubuntu
<infinity> TJ-: It likely is running as the _apt user at that point.
<maxb> Interesting, I would not have thought to report it against the kernel package
<infinity> maxb: Well, depends on if it's a driver issue or userspace tools.  Report the bug where it seems most plausible?
<TJ-> infinity: ahhh... that makes sense. I've got a system set up so I have a portable /usr/local/... for multiple machines that then gets various content either symlinked or bind-mounted into the regular package file-system, and I'd got /usr/local/etc/apt/trusted.gpg.d bind mounted to /etc/apt/trusted.gpg.d and thought it was something to do with that!
<infinity> TJ-: Yeah, I believe trusted.gpg switched from 600 to 644 when apt moved to dropping privs in most of its subprocesses.  To be fair, 600 was always silly anyway, since they're public keys. :P
<infinity> Oh, actually, trusted.gpg was always (correctly) 644, it's trustdb.gpg that used to be 600, and is now just gone.
<infinity> Good riddance, silly trustdb.
<TJ-> yeah, I vaguely remembered that and was wondering if I'd accidentally deleted it :D
<TJ-> anyone know where I should be focusing my attention to figure out how to get touchscreen gesture support working? aside from the xserver mtrack driver I've not been able to find any clear indication of where the action is. All the ubuntu-touch related packages in the archive confused the issue too
<lfaraone> xnox: I see you grabbed LP #1387908 -- are you actively working on it, or would a patch to import the ``70-u2f.rules`` from Yubico's libu2f-host be useful?
<ubottu> Launchpad bug 1387908 in systemd (Ubuntu) "[udev] FIDO u2f security keys should be supported out of the box" [Undecided,Triaged] https://launchpad.net/bugs/1387908
#ubuntu-devel 2017-04-17
<infinity> kees: "More general purpose registers on armv7 than i386" wins understatement of the year.
<infinity> kees: And if the compiler's smart enough in the armhf case to see -mfpu=vfpv3-d16 and notice it's just been gifted another 16 registers on top of the 15 it already had to play with, whee.
<doko> infinity, kees: -mfpu=vfpv3-d16 is for floating point registers only
<infinity> doko: I know what it means. ;)
<doko> but you argue as if these were general purpose registers ...
<infinity> doko: armhf already violently abuses it to store function arguments in the vfp registers, PIE could pull similar tricks.
<infinity> doko: (Not saying it does, saying it could)
<nacc> Zta: does the upstream tarball contain a binary file?
<nacc> infinity: for a bugfix for a package in zesty which has been fixed in debian, is it appropriate to upload for z the SRU version now (and similar for X and Y)? And then sync it immediately when AA opens?
<infinity> nacc: Yep.
<nacc> infinity: ok, thanks!
<Zta> nacc: there's not upstream tarball; I'm cloning a git repo and then using dh_make to create the initial upstream tarball (?).
<nacc> um, then there *is* an upstream tarball
<nacc> Zta: even if you are making it, there is one when dpkg is building the package
<Zta> Okay, just making sure we were (or I was) on the same page =).  I don't think there's a binary it in, but I'll check to make sure.
<Zta> Urgh, I just wiped the entire working directory by accident.  I might as well create a whole new Docker image then.
<Zta> I'm reading a little in the manpage of dpkg-buildpackage.  I'm currently running: dpkg-buildpackage -S -nc -d -uc -us    Maybe -nc is causing trouble with existing binaries?  Since it's not cleaning.
<nacc> Zta: wait, are you building in the tree first aand then running dpkg-buildpackage?
<Zta> Hm, running dpkg-buildpackage -S -uc -us (with and without -nc) successively works.
<Zta> I've started from a clean clone of the source.  Then I ran  dh_make -s --createorig -p ${APP_NAME}_${APP_VERSION} -y   and now  the above.
<Zta> (Uh, I modified d/control inbetween) those two commands
<nacc> Zta: once you create a source package, it doesn't really make sense to keep creating it
<Zta> Ok.  That's a one time thing?  Even after I update the sources?
<nacc> Zta: so your debian/ directory doesn't generally need to change because upstream changes
<nacc> or, at least, not the whole thing
<nacc> you'll wanto insert a new changelog entry referring to the new upstream
<nacc> (and then dpkg-buildpackage will look for an appropriately named orig tarball in ..)
<nacc> and if the upstream changes the dependencies, you'd update d/control, of ocurse
<Zta> Okay, makes sense.  Is there a dpkg-tool for adding a change log entry?  I see the first line in my current/changelog contains "aseprite (1.2-dev-master-6829b3d-1) unstable; urgency=medium"  That "-1" appended to my version is not mine, so I either have to be able read that from somewhere or "dh_addchlog".
<nacc> Zta: dch
<nacc> Zta: dch -i to insert (but note it won't detect the version correctly when you are bumping upstreams)
<Zta> I tried to build the source package *with* signing, but it fails.  I did make a gpg key though.
<Zta> ah, nevermind gpg
<nacc> ok
<Zta> nacc: Ok I have a .deb now, so I don't want to experiment with building a new version just now.  But perhaps you can help me with my next step: To setup a repository.  I've used reprepo to create this https://www.dropbox.com/sh/ppx2zr5gf2dx4rz/AAC7x0WK9sS1Xmn7sJjU9KgSa but when I add "deb https://www.dropbox.com/sh/ppx2zr5gf2dx4rz/AAC7x0WK9sS1Xmn7sJjU9KgSa xenial main" in my /etc/apt/sources.list.d/aseprite.list and run "apt update" I get: Clearsigned file 
<Zta> E: Failed to fetch https://www.dropbox.com/sh/ppx2zr5gf2dx4rz/AAC7x0WK9sS1Xmn7sJjU9KgSa/dists/xenial/InRelease  Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
<Zta> Oh no, it's some sort of Dropbox issue.  That last URL should return 404 but it doens't.
<nacc> Zta: sorry, was afk -- i dont have any experience with repos that aren't PPAs :)
<Unit193> nacc: They're really fun!  More so if you use people.ubuntu.com! :P
<nacc> Unit193: :)
<Zta> Unit193: Perhaps I should look into that.  Or there's always github or bitbucket.
<Unit193> Zta: That's not to say it can't be done in Dropbox.
<Zta> Unit193: Can it?
<Unit193> Zta: I have never tried, but if you're using the Public/ folder, I don't see why not.
<Zta> I'm using a shared link to a folder within Dropbox.
<Zta> You can try out the above url if you like. I can't make it work.  But I think Dropbox is to blame because I don't get 404 when I should: https://askubuntu.com/a/475202/344227
<nacc> Zta: i get a 404 for the InRelease file
<Unit193> nacc: It's a 404 page, without the 404 code, right.
<nacc> oh fun
<nacc> lame, 200 return code wrapping 404
<nacc> so dropbox = fail :)
<Zta> I think so. But why does dpkg rely on a page to return 404?  Why contact it to begin with?
<nacc> it doesn't rely on it returning 404
<nacc> it's trying to read that page and it's giving bad data
<Unit193> apt*
<nacc> *apt* is asking for that page to give the InRelease data
<nacc> (dpkg doesn't talk to the network)
<nacc> and that page, rather than reporting an error, is saying here's some garbage that wraps a 404 response code :)
<nacc> but not actually expressing an error in the code
<Zta> I don't have a file named InRelease in my generated repository.  Is that a problem?
<Unit193> I presume you have Release and Release.gpg?
<Zta> Release, yes.  Release.gpg no.
<nacc> iirc, InRelease can fail and it falls back to Release but Release needs to be signed (hence Release.gpg)
<nacc> InRelease = signed inline release
<Unit193> nacc: Well, pretty much.  You can cheat and have [Trusted=yes], but I wouldn't recommend it.  But yeah, InRelease will fall back (unless, 200...)
<Zta> Okay, that all makes sense.  I'll try signing it.  Tomorrow.
<nacc> Unit193: right, since the InRelease isn't saying 404, i think apt can't fallback correctly
<nacc> Unit193: ah yes, I forgot about Trusted= :)
<Unit193> Zta: What are you using to create the repo?
<nacc> Unit193: reprepo, i think
<Zta> reprepro -b $ASEPRITE_DIST includedeb xenial $ASEPRITE_ROOT/*.deb
<Unit193> Ah, well in that case you should be able to configure a signing key and be done.
<Zta> If only I could get sufficient entropy out of my Docker container =)
<Zta> Zzz..
<Unit193> (For public.u.c, I recommend 'lftp mirror')
<dmj_s76> cyphermox: So, we're still testing, but we've gotten several reports of 16.04 -> 17.04 upgrades leaving ethernet unmanaged by network manager.
<Unit193> bug 1676547?
<ubottu> bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547
<dmj_s76> We suspect a missing netplan policy snippet is at issue: there's no /etc/netplan/01-network-manager-all.yaml
<dmj_s76> Unit193: That looks like it could be the same bug.
<nacc> slangasek: fun (non sequitur, apologies), but qemu 2.0.0+dfsg.orig.tar.xz apparently cannot be imported by `gbp import-orig` with pristine-tar: "pristine-xz failed to reproduce build" ... will report to debian, but thought you'd like to know :)
<nacc> s/like/be interested/
<slangasek> ahhhh
<slangasek> nacc: will be interesting to see the Debian response
<slangasek> though "cannot import" is certainly a less severe class of bug than "you want me to reconstitute what now?"
<nacc> slangasek: yep
#ubuntu-devel 2017-04-18
<nacc> rbasak: if you happen to be around, ping -- or in the next few hours, have an importer question for you
<pitti> xnox_: DNSSEC> that smells like an SRU then? it should mostly be alright, but some devices still have trouble with it; and we don't do portal detection; so I'd disable it again
<ackk> join #server
<xnox_> pitti, yes, there is inflight bileto, hoping for unapproved queue SRU today/soon (need to fix up missmerged cherrypick first though)
<rbasak> nacc: o/
<rbasak> slashd: ~ubuntu-sru-developers should work now (thanks slangasek!). Could you perhaps review and upload some suitable SRU from the sponsorship queue to test?
<LocutusOfBorg> hello jbicha I suppose I can close lp: #1657924
<ubottu> Launchpad bug 1657924 in virtualbox (Ubuntu) "Clicking the file chooser button crashes VirtualBox on Zesty" [Medium,Expired] https://launchpad.net/bugs/1657924
<xnox> ok, systemd sru refix; and thrown into bileto - coffee time
<jbicha> LocutusOfBorg: that's fine, my config file was broken so maybe some day I'll look into it more
<LocutusOfBorg> thanks
<LocutusOfBorg> will keep it as expired
<slashd> rbasak, morning, I think my ACL is now set by the TB --> https://lists.ubuntu.com/archives/technical-board/2017-April/002302.html but I still can't approved series nomination, do you think it is something we can arrange ?
<rbasak> slashd: can we check that uploading SRUs works first please?
<slashd> rbasak, that was my second question, is there a way I can easily check before doing an real upload ?
<rbasak> slashd: use ubuntu-upload-permission
<slashd> rbasak, so far I checked with this : http://people.canonical.com/~ubuntu-archive/archive-permissions/individuals and I don't see my name, will try with ubuntu-upload-permission
<nacc> rbasak: heya, I think I figured it out last night, but will see if i remember today
<slashd> rbasak, seems like ubuntu-archive-tools indicate :
<slashd> == All rights for slashd ==
<slashd> Archive Upload Rights for ubuntu-sru-developers: archive 'primary', pocket 'Proposed
<slashd> but ubuntu-uploader-permission doesn't reveal much
<rbasak> slashd: it looks like ubuntu-uploader-permission can't check for a specific pocket.
<rbasak> slashd: can you perhaps check the sponsorship queue and try and review and upload an SRU from there?
<jbicha> slashd: quick, fix some bugs! :)
<slashd> jbicha, rbasak, sure will have a look this week, and once having 1 upload I'll ping back for the series nominations ?
<rbasak> Yes
<slashd> rbasak, sound like a good plan, thanks
<rbasak> I don't want to chase up series nominations until we know the upload actually works. Since otherwise it could just be that.
<slashd> rbasak, totally make sense thanks
<nacc> bdmurray: slangasek: looking at LP: #1654008, it seems like the SRU of update-manager isn't actually available (but was at some point?). rmadison indicates it's a source only package now in t-u.
<ubottu> Launchpad bug 1654008 in update-notifier (Ubuntu Zesty) "/usr/bin/update-manager:OverflowError:/usr/bin/update-manager@117" [High,Fix released] https://launchpad.net/bugs/1654008
<bdmurray> nacc: cjwatson mentioned fixing in #ubuntu-release
<nacc> bdmurray: oh ok, someone was asking in #ubuntu
 * nacc will go look at logs
<cjwatson> I forgot to accept my copy apparently
<nacc> cjwatson: :)
<nacc> rbasak: re: LP: #1680064, can you change the default branch back so i can debug?
<ubottu> Launchpad bug 1680064 in usd-importer "git repos pushed by the importer do not have HEAD set sensibly" [Medium,Fix released] https://launchpad.net/bugs/1680064
<rbasak> nacc: it won't let me do it as it doesn't exist :-/
<rbasak> I wonder if I should delete the repo and then re-push it.
<nacc> rbasak: i'm testing with my own repo, let me see
<nacc> rbasak: that's strnage as i was able to change it on the existing repos (when i was testing this)
<rbasak> Oh.
<rbasak> I have a hunch as to what failed.
<rbasak> nacc: sorry, my fault. I didn't actually check if "usd import" had claimed success, only that the repo appeared pushed (as I'd switched machine)
<rbasak> Looks like it did actually fail, so never got beyond the push.
<rbasak> Sorry for the trouble.
<nacc> rbasak: ah!
<nacc> rbasak: yeah :) now why did it fail?
<rbasak> lazr.restfulclient.errors.PreconditionFailed: HTTP Error 412: Precondition Failed
 * rbasak shrugs
<rbasak> Never seen that before.
<nacc> ah ... lp something something?
<rbasak> Usually it hangs at that stage.
<nacc> hrm, i've also not seen that
<nacc> rbasak: fyi, i'm working on or retooled patches-applied algorithm (LP: #1662325)
<ubottu> Launchpad bug 1662325 in usd-importer "Update algorithm for patches-applied" [Undecided,New] https://launchpad.net/bugs/1662325
<cjwatson> "precondition failed" is normally code for mid-air collision
<nacc> cjwatson: ah ok, thanks
<cjwatson> the etag sent in your request to represent the state of the object you're modifying doesn't match the current state
<rbasak> nacc: so that was from:
<rbasak>   File "/home/robie/Code/Canonical/usd-importer/usd/importer.py", line 1092, in main
<rbasak>     lp_git_repo.lp_save()
<rbasak> If that matters.
<nacc> rbasak: the 412 ?
<nacc> rbasak: hrm, well that's what updates the default branch :)
<rbasak> Yep :)
<nacc> hrm, it's odd, because the lp_git_repo object is obtained from lp just before that
<nacc> so i'm not sure why there would be a collision
<nacc> rbasak: did you keep the directory? is it reproducible (it should try to adjust the default branch on every push)
<rbasak> Yes I have the directory
<rbasak> I can try another clone
<rbasak> Uh, import
<nacc> yeah
<rbasak> It reran without error
<nacc> hrm, ok -- so i'd presume to say lp something something for now ...
<rbasak> But I can't change HEAD back.
<rbasak> "This repository does not contain a reference named 'refs/heads/master'."
<rbasak> I can try delete and recreate if you want?
<nacc> rbasak: ah so it can be already set to an invalid value, but you can't set it to one
<rbasak> Right
<nacc> rbasak: up to you -- would be good to see, as in my testing it was fine, so if it's reproducible, should be easy to debug and fix
<rbasak> OK I'll try delete and recreate now.
<nacc> rbasak: thanks
<rbasak> It failed again
<rbasak> Different error
<nacc> heh
<rbasak> http://paste.ubuntu.com/24408024/
<rbasak> Race between Launchpad getting the push and processing the repo?
<nacc> that's what i'm wondering now
<nacc> which would makes sense as to why you got the 412 before based upon cjwatson's comment
<rbasak> Yeah
<nacc> cjwatson: --^ after a push to a repository, is there a way to ensure it's 'settled' on the lp side before we grab a reference to that repository and change state?
<cjwatson> You could certainly be racing with the scanning job
<cjwatson> What attributes do you need to change exactly?
<nacc> the default branch
<rbasak> Just the HEAD symbolic ref.
<rbasak> Since we don't have a "master".
<rbasak> Incidentally, a bunch of other stuff assumes that HEAD exists, such as git-build-recipe. I hit that today.
<cjwatson> Can't you just push HEAD?
<rbasak> (even when I don't need to to exist)
<cjwatson> I forget exactly how that works, I know it's weird in git
<rbasak> It used to be that you couldn't do that.
<rbasak> But it might have changed more recently.
<cjwatson> Ah yes, I had to implement an extension for that for git-to-git imports
<cjwatson> OK, so I think you should probably just loop-and-retry-on-412
<nacc> got it
<nacc> i can do that
<rbasak> Or 404
<rbasak> (this second error was a 404)
<nacc> right, and in our case, presuming push() passed, we know it should exist eventually
<nacc> rbasak: something like http://paste.ubuntu.com/24408055/
<nacc> rbasak: as i think we need to re-grab the repo object to avoid the 412
<rbasak> nacc: looks good. Do we need a timeout?
<nacc> rbasak: not sure :)
<nacc> rbasak: probably? but i'm not sure how to do that
<nacc> rbasak: i think not for 412, but for 404 maybe we should?
<rbasak> Probably easiest to just loop until timeout and ignore all 412 and 404.
<nacc> rbasak: yeah, but what timeout? :)
<nacc> rbasak: 1m?
<rbasak> 30s? 60s?
<cjwatson> nacc: .lp_refresh() would work too
<cjwatson> (well, that doesn't work with 404, only if the .lp_save() fails)
<nacc> cjwatson: got it
<cjwatson> I'd do something like lazr.restfulclient._browser.Browser._request_and_retry does if I were you
<cjwatson> exponential backoff with a limit
<nacc> cjwatson: thanks, will look
<nacc> rbasak: can you test http://paste.ubuntu.com/24408457/ ?
<nacc> i'm not sure if the default is sensible (3 retries with exponential backoff)
<rbasak> ack
<nacc> rbasak: thanks
<rbasak> nacc: it worked
<rbasak> I had to try twice because the first failed on the push, which I think is a bug in libgit2 in Xenial.
<rbasak> The second time (after deleting the repo from LP again) it worked fine.
<nacc> rbasak: ok cool, i'll push it up then
<rbasak> Thanks!
<nacc> rbasak: thanks for the quick test
<hjd> Has it been announced anywhere when the AA-archive will open? :)
<cjwatson> hjd: Nobody can give an estimate until we have a name from Mark
<hjd> ah, ok
<jbicha> and it's usually at least a few days after that
<sarnold> nacc: thanks, I'm not sure where 1678349 fell through the cracks.
<nacc> sarnold: thanks! yeah, i can't see it, so I can't tell it either, but figured a ping here was the right way to get it to your team
<slashd> rbasak, I got added to the ~ubuntu-release-nominators team, I think I'm all set now, thanks again
<rbasak> slashd: great!
<jbicha> slashd: are you looking for stuff to SRU? are you able to SRU anything in main?
<jbicha> if so, I recommend bug 1550210 which was worked around by both Ubuntu GNOME and Ubuntu Studio, but see my comment at the end
<ubottu> bug 1550210 in imagemagick (Ubuntu Yakkety) "Desktop file does not open ImageMagick from the menu" [Medium,Triaged] https://launchpad.net/bugs/1550210
<slashd> jbicha, haven't tried yet, will give it a try this week
<ricotz> jbicha, just released Thunderbird 52 is GTK3 ;)
<jbicha> ricotz: great, I encourage you to reply to the list. Do you have an opinion on the email client question?
<ricotz> jbicha, I guess I am too old school to have a objective opinion
<ricotz> aka using thunderbird for over 15 years
<infinity> mutt 4 lyf, yo
<infinity> *gang sign*
<rbalint> infinity:  :-)
<nacc> rbasak: interesting, i think with very few changes, i've got the spph from a ppa now, just need to figure out how to get to the files with the right object (.dsc, etc). Also in doing some digging, ubuntutool has a UbuntuCloudArchiveSourcePackage object (need to look still what it defines)
<tsimonq2> infinity: I recently started playing with mutt, and it's impressive, IMHO. I'll still use Thunderbird when I'm on my main system, though.
<infinity> tsimonq2: mutt's a complete non-starter for people who need to read a lot of html email, especially with embedded images.  I, however, have the luxury of being able to say "I'm a nerd who won't read your mail if the majority of the content is in images, kthx."
<nacc> heh
<tsimonq2> Hahaha.
<sladen> infinity: this is a feature
<tsimonq2> infinity: Well all the mailing lists I'm subscribed to are *explicitly* set to use only plaintext, and when I need to view HTML mail (rare nowadays) I just use Roundcube Webmail (which is an AWFUL program for doing anything but reading non-encrypted, HTML emails)
<stgraber> what, e-mails can contain images? :)
<tsimonq2> The only things I can think of that send me HTML emails are confirmation emails for signing up to things, and Viagra spam. (the latter of which I have an imapfilter + SpamAssassin setup to deal with, but it's not PERFECT)
<tsimonq2> infinity: But if I'
<tsimonq2> Grrrrrrrrrrrrrrrrrrrrrrr
<tsimonq2> If I'm sending patch mail, mutt hands-down
<infinity> stgraber: It can, yeah, but it helps if you're tall enough to read above the signature footer.
<tsimonq2> HAH
<stgraber> infinity: haha, when I wrote that I was thinking, "how will Adam turn that into a short joke?", that's how :)
<infinity> stgraber: Man, it wasn't easy.
<infinity> stgraber: But I powered through.
<tsimonq2> XD
<infinity> I'm going out to buy all the hamburgers in a 2 mile radius.  Anyone need anything?
<tsimonq2> infinity: Funny enough, I work at McDonald's, so if you give me 10 minutes I can tell you about all our deals in detail. XD
<Zta> Crikey... Both Dropbox (https://www.dropbox.com/sh/l0vzh88wq0lipjv/AABUIgRsUCNFjI2QoC_fiJhma) and Bitbucket (https://bitbucket.org/stephan-henningsen/aseprite-dist) are giving me a hard time with deep-linking from a shared link.  That is, https://www.dropbox.com/sh/123/ works but https://www.dropbox.com/sh/123/dists/xenial/InRelease gives 404 even though the path technically exists.
<Zta> Ah, getting there: deb https://bitbucket.org/stephan-henningsen/aseprite-dist/raw/master xenial main
<Zta> Yay!  Success!
<cjwatson> infinity: ":auto_view text/html" works fine as long as the formatting of the email isn't particularly important ...
<infinity> cjwatson: I use sometihng along those lines, yes.
<cjwatson> (what I normally do is do nearly all my routine mail handling with mutt, and use K-9 on my phone for anything that's too awkward to read that way)
#ubuntu-devel 2017-04-19
<pitti> Laney: I think http://autopkgtest.ubuntu.com/running has been stuck for a while; this page should grow a time stamp at the bottom
<Laney> pitti: hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm!
<pitti> Laney: amqp-status-collector might have crashed?
<pitti> Laney: and good morning!
<pitti> Laney: there is a cronjob which is supposed to restart it, but IIRC that didn't work for some reason
<Laney> yes I'm in there
<Laney> it crashed a little while ago
<Laney> pitti: i restarted it manually & apw is checking why the cron thing didn't work
<pitti> Laney: cheers
 * Laney stabs tmux
<davmor2> Laney: why what did tmux ever do to you...and use byobu instead :P
<Laney> davmor2: it is via byobu
<Laney> ah, F6 worked
<davmor2> Laney: I could of told you that :P
<apw> F6 ... jez
<bdrung_work> pitti, i tested apport-retrace. why is the source package needed?
<pitti> bdrung_work: it creates a StacktraceSource: field; but that's not really essential, it could be made optinal
<bdrung_work> pitti, the logic in _search_contents (packaging_impl.py) is broken.
<bdrung_work> pitti, you assume the presence of specific Content-%s.gz files
<bdrung_work> pitti, e.g. you try http://ftp.de.debian.org/debian/dists/jessie/Contents-amd64.gz, but that exists in the main, contrib, or non-free subdirectory
<pitti> bdrung_work: ah, could very well be that this needs adjustment for debian's layout; for Ubuntu's, Contents is in that location (http://archive.ubuntu.com/ubuntu/dists/xenial/)
<pitti> and not in the component/ dir
<bdrung_work> that could be derived from the Release file
<bdrung_work> or does apt provide this mapping information somewhere?
<pitti> right, looking at Release sounds good
<bdrung_work> pitti, i stumbled over another issue: 'apport.packaging.get_file_package(report[path]' make_sandbox() returns the wrong package name (since two different packages provide the same binary file)
<pitti> bdrung_work: I suggest filing them as bugs, so that someone interested can work on those; I can help with reviewing MPs, but I can't/won't work on those myself
<bdrung_work> pitti, any chance to get apport switched from bzr to git?
<pitti> bdmurray: ^ any objections? I'm fine with that
<bdrung_work> pitti, the naming of the config path is not very good
<bdrung_work> example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845208
<ubottu> Debian bug 845208 in apport-retrace "apport-retrace crashed with IOError in _get_primary_mirror_from_apt_sources(): [Errno 2] No such file or directory: u'Debian GNU/Debian testing/sources.list'" [Normal,Open]
<bdrung_work> or in my case "Debian GNU/Linux 8/sources.list"
<slashd> rbasak : good morning, do you have any update about the isc-dhcp (split into 2 binary packages) LP: #1176046 ?
<ubottu> Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress] https://launchpad.net/bugs/1176046
<rbasak> slashd: see https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/46. I did try to ping you about that too.
<ubottu> Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress]
<slashd> rbasak, reading
<slashd> rbasak, will update the lp bug in a few minutes
<slashd> rbasak, done
<slashd> rbasak, sorry for missing your update on Apr 11.
<bdrung_work> pitti, first one: https://bugs.launchpad.net/apport/+bug/1684117
<ubottu> Launchpad bug 1684117 in Apport "apport-retrace determines wrong package providing a file" [Undecided,New]
<rbasak> slashd: thanks. Just glancing at it now.
<rbasak> slashd: in verif-xenial.debdiff, shouldn't the Replaces line be unversioned?
<rbasak> slashd: currently I don't think it'll have any effect?
<rbasak> slashd: if you do end up editing it, there are a couple of typos in d/changelog that you might as well fix while you're there.
<pitti> bdrung_work: followed up on that one, please confirm
<rbasak> slashd: also the xenial changelog needs a bug reference please.
<pitti> bdrung_work: oh, nevermind
<bdrung_work> pitti, do you still need more information?
<bdrung_work> i can't give away my test case since that involves inhouse packages which i do not want to name
<rbasak> slashd: also, please could you detail some upgrade tests in the bug description? Some variations of what to do on Trusty, upgrade to Xenial, and then what to check that the upgrade path worked as expected. Including things like not doing anything special on Trusty and installing -noddns on Trusty, and so on. I think these should be documented in the bug and explicitly checked during SRU verification.
<bdrung_work> pitti, do you run any checks on the code? flake8? pylint?
<rbasak> slashd: this is in respect of the packaging changes specifically, to check that the metadata does what we want it to do. Checking the binary behaves as expected needs verifying too, of course.
<pitti> bdrung_work: nope, it's clear, I just missed the param; yes, test/run runs pyflakes and pycodestyle (and the tests of course)
<slashd> rbasak, the upgrade worked on caribou and I test as noted on comment #42 --> https://bugs.launchpad.net/ubuntu/trusty/+source/isc-dhcp/+bug/1176046/comments/42 ... but I'll detailed more if needed #2 for the typo, I'll review it and do the necessary modification #3 I'll add bug reference
<ubottu> Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress]
<rbasak> slashd: I appreciate that you did it in comment 42. What I want is to make sure that it's done for SRU verification too, so the test plan should really be in the SRU information.
<bdrung_work> pitti, and max line length = 99 chars?
<slashd> rbasak, sure
<rbasak> slashd: and of course if we change the Replaces, it'll need retesting.
<pitti> bdrung_work: not enforced (see invocation in test/run), it just ignores the line len error (historic reason, would be fine to use --max-line-length)
<slashd> rbasak, yep I'll give it a with a unversion Replaces:
<slashd> rbasak, ok tks for your input
<rbasak> jbicha: around?
<rbasak> jbicha: in graphviz in the trusty queue...
<rbasak> ...shouldn't the new dependency be (= ${binary:Version}) like the others?
<rbasak> Looks like that's what you did for Xenial, and the binary is created from the same source?
<rbasak> (and matches the others)
<jbicha> rbasak: yes, are you to able to fix that? I don't have upload rights for graphviz/trusty and that's a very old SRU candidate now
<rbasak> jbicha: sure, I'll fix up. Are you planning on doing SRU verification? As long as we have some volunteer.
<jbicha> yes, the test case is pretty easy
<rbasak> OK, thanks!
<pitti> bdrung_work: btw, bug 1639427 might be your contents.gz  issue?
<ubottu> bug 1639427 in apport (Debian) "cannot determine package name from file" [Unknown,Confirmed] https://launchpad.net/bugs/1639427
<bdrung_work> pitti, nope. i patched that contents part
<bdrung_work> oh, wait
<bdrung_work> let me read that bug report
<bdrung_work> pitti, that might be my contents.gz issue (but that manifested in a backtrace in my case)
<bdrung_work> pitti, i have patches for the contents.gz issue in my git repository
<bdrung_work> pitti, what do you prefer. Having CoreDumpFile which contains a string pointing to the core dump file or allow to specify a file in CoreDump?
<pitti> bdrung_work: you can already have a file pointer in a Report object
<pitti> bdrung_work: ... by assigning a tuple; see http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/problem_report.py#L315 for the format
<bdrung_work> pitti, the thing is that i need to put the path into the file on disk
<pitti> not a fan, I must say -- the point of .crash files is to be self-contained, and people copy them around (from a locked-down server to a desktop) to report them, etc.
<pitti> apport-retrace has an option for specifying an external core dump
<pitti> but if I have to pick, CoreDumpFile: for sure -- doing guesswork on a key is bad
<nacc> rbasak: re: LP: #1684112, i think it'd actually be pretty straightforward
<ubottu> Launchpad bug 1684112 in usd-importer "Cannot restrict import to supported releases only" [Wishlist,New] https://launchpad.net/bugs/1684112
<rbasak> nacc: thanks. But really, not urgent. It'll become moot when we import everything.
<nacc> rbasak: yeah, understood, but also in the meanwhile it'd be nice )
<rbasak> :)
<slashd> rbasak, I did the necessary modification and tests (re: LP: #1176046)
<ubottu> Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress] https://launchpad.net/bugs/1176046
<slashd> and update the lp bug accordingly
<rbasak> slashd: thanks. I'll add it to my list
<slashd> rbasak, thanks
<pitti> bdrung_work: need to leave, cu tomorrow!
<bdrung_work> cu
<rbasak> slashd: I didn't mean to ask you to test the upgrade paths now. What I want is the SRU information to make it clear that they will be tested from the proposed pockets during SRU verification.
<slashd> rbasak, ok but it's still worth it to test before anyway as an extra security and obviously I'll test again once in -proposed
<rbasak> slashd: sure, but can you add this plan to the SRU information please?
<rbasak> slashd: since some other ~ubuntu-sru may process this after verification is marked done, it should be made explicit in the bug exactly what we agreed needs to be tested.
<slashd> rbasak sure
<rbasak> Thanks!
<slashd> rbasak, done
<JonelethIrenicus> when trying to build apps what is init tool merge?
<JonelethIrenicus> getting not found error
<nacc> JonelethIrenicus: context? "build apps"?
<JonelethIrenicus> nacc: build ubuntu unity 8 apps
<nacc> JonelethIrenicus: ok, you might ask in a unity channel? (see /topic)
<JonelethIrenicus> unity channel on freenode?
<nacc> !alis | JonelethIrenicus
<ubottu> JonelethIrenicus: Alis is an IRC service to help you find channels. For help on using it, see "/msg Alis help list" or ask in #freenode. Example usage: "/msg Alis list http"
<JonelethIrenicus> does ubuntu still have an sdk channel for app development
<JonelethIrenicus> nacc: any idea?
<nacc> JonelethIrenicus: did you look in alis?
<JonelethIrenicus> nacc: the giant list of channels?
<nacc> JonelethIrenicus: you can search alis, did you read the faq above?
<JonelethIrenicus> nacc: its in the topic
<JonelethIrenicus> #ubuntu-app-devel
<JonelethIrenicus> damn dude that was difficult
<JonelethIrenicus> haha
<vtapia> ping rbasak
<nacc> rharper: ooh, i think i finally got ppa imports working :)
<rharper> nice!
<nacc> rbasak: should we have patches-applied -devel branches?
<nacc> rbasak: i can't see a reason not to, at least currently, but we don't
<nacc> rharper: yep, it's working, i'm fixing up my commits and pushing
<nacc> only about 273 insertions to add the new subcommand
<nacc> some/most of which can be abstracted back out to common functions, tbh
<rbasak> nacc: I think we absolutely should in order to meet the use case for patches-applied branches for drive-by contributors
<rbasak> nacc: not sure about namespacing though
<nacc> rbasak: yep, i can fix that now
<nacc> rbasak: i think it'd fit with the rest of them, as-is
<nacc> but i need to make sure the code can do it :)
<rbasak> OK :)
<nacc> rbasak: if around, have time for another quick question?
<rbasak> nacc: o/
<nacc> rbasak: just so i don't forget, we need to figure out namespaces for import-ppa. Right now, push is disabled for it
<nacc> but if it's meant to be say, ppa_nacc/.... in the lpusip repository (potentially) or lpmep (obviously possible)
<nacc> that starts to leak into `usd clone` which brings in all the remote branches and tags
<nacc> i think it's an argument for gitnamespaces so they don't collide
<nacc> they will stitll share objects
<rbasak> nacc: I've been swinging my opinion the other way and away from gitnamespaces as it happens. We should figure out the use cases and then see if we can come up with a single namespace plan that can encompass them
<nacc> rbasak: yeah, the alternative it to not do the remap we do now
<nacc> where the 'lpusip' remote gets the branches put into refs/heads
<nacc> i'm not sure
<rbasak> nacc: we might be able to adjust things with sensible push and fetch refspecs
<nacc> rbasak: yeah, that's what i'm struggling to come up with
<nacc> i'm pushing what i have now, as it doesn't change anything
<rbasak> nacc: HO tomorrow?
<nacc> well, with regards to this issue
<nacc> but maybe ..
<nacc> yeah
<nacc> :)
<nacc> and we can just hammer it out
<nacc> i think the primary issue is we have too many special cases :)
<nacc> and so we just need a 'policy' for what the git refspec should look like generally that's unambiguous to determine where a given refs/head or refs/tags comes from
<rbasak> More generally, it should be what "owns" the name, rather than where it comes from.
<nacc> fwiw, with the latest push, we have the 'namespace' stored in one place in antying that deals with a git repository now
<rbasak> I think.
<nacc> so we have a better means of doing something with that value easier (chagnes/improvements)
<nacc> rbasak: err, yes 'owns' in the process sense, yep
<nacc> rbasak: the primary thing i was getting mixed up on is that both lpusip and lpmep can have, say, ubuntu/devel branches
<nacc> and we don't want them to accidentally mix
<rbasak> http://pad.ubuntu.com/git-importer-namespaces
#ubuntu-devel 2017-04-20
<rbasak> nacc: I wrote up some notes as they occurred to me. A starting point for tomorrow at least.
<nacc> rbasak: thanks
<nacc> rbasak: i think i got your active-series-only function in 18 lines of code :)
<nacc> rbasak: ok, i'm off for the night, i just merged your changes for queue and pushed out the active-series feature, although it's not working for applied yet, probably something obvious
<bdrung_work> pitti, good morning. do you have time to discuss apport-retrace?
<pitti> bdrung_work: good morning! a bit
<bdrung_work> pitti, point one: i have some commits for you in git. may i wait until you switched to git or should i dig out my rusty bzr knowledge to apply the changes to bzr?
<pitti> bdrung_work: I pinged bdmurray yesterday whether he was fine with switching to git; I defer to his judgement, as he is the primary maintainer now
<pitti> bdrung_work: alternatively, attach the format-patches to the LP bug, and it's easy enough for me to apply to bzr :)
<bdrung_work> i have 9 patches right now.
<arune> newbie questions, I have imported 3 patches with quilt, but they are applied in the wrong order when building, how do I change the order?
<pitti> arune: in debian/patches/series
<bdrung_work> arune, debian/patches/series
<pitti> but they get applied in the same order as you created them
<arune> I just change the order there? thanks
<arune> seems like that list is the reverse of the order I imported them
<arune> nice, now they applied clean
<bdrung_work> pitti, attached the patches to #1684535
<bdrung_work> https://bugs.launchpad.net/apport/+bug/1684535
<ubottu> Launchpad bug 1684535 in Apport "Please support CoreDumpFile in crash file" [Undecided,New]
<bdrung_work> pitti, point two: #1684117 isn't easy to solve. I have 3 local patches that make it work with debian, but this is still not ideal and working correctly.
<bdrung_work> pitti, there are two ways to solve #1684117. option one: install all specified dependencies in the sandbox and only search for files that are missing (i.e. not specified in the dependencies). option 2: restructure apport.packaging.get_file_package to return a list of (package,version)
<bdrung_work> pitti, and another issue: https://bugs.launchpad.net/apport/+bug/1684690
<ubottu> Launchpad bug 1684690 in Apport "sandbox: __AptDpkgPackageInfo.get_distro_name() returns host distro name" [Undecided,New]
<nacc> rbasak: fyi, --active-series-only is fixed now, was a missed namespace change on my part
<rbasak> nacc: thanks. OK to start pushing imports as needed again, or is that still on hold? (No problem if it is)
<nacc> rbasak: i think it's ok, my bastion is up again i just haven't restarted the cron job yet
<rbasak> OK
<nacc> rbasak: and merged your reuqest
<nacc> rbasak: but yeah, you can run imports you need by hand for now, i'll start the job again after i'm back later today -- i need to verify ssh and stuff
<rbasak> OK thanks
<nacc> rbasak: np
<nacc> rbasak: and sorry for the delay on that, lots of churn lately :) but patches-applied working again is a big-win
<rbasak> It's fine. What delay? :-)
<rbasak> (really!)
<nacc> i think i've had my bastion for > 24 hours :)
<sil2100> bdmurray, cyphermox: could any of you include the relevant SRU information for bug LP: #1676547
<ubottu> Launchpad bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547
<sil2100> ?
<sil2100> Wanted to review it
<cyphermox> sil2100: ack
<sil2100> cyphermox: thanks!
<drab> hi, trying to test some versions of ubuntu with qemu, but can't get the installer to work in text mode. anybody knows what magical parameter I need to pass on the command line or something?
<drab> I'm running qemu in console with -curses so I need things to work in text mode. I tried DEBIAN_FRONTEND=text,but that didn't do it
<tomreyn> drab: use the server install iso or mini.iso
<drab> tomreyn: I am already, I'm using mini.iso
<drab> somehow qemu thinks that's graphical mode, not sure why, but if I don't specify "text" at boot time (and it uses the framebuffer) it also think that's gfx mode
<tomreyn> well those don't use X, but output text, then i don't seem to be getting the issue
<drab> and shows nothing in curses
<drab> fair enough, I thought ti was strange and maybe it's something else I don't get
<drab> I see the pxe boot part, the menu, the kernel booting and then bam, it goes black
<drab> and all I have is that msgs saying it's in graphical mode 640x480
<drab> which is the same thing I get with pxe if I use vesamenu.c32
<drab> so I was thinking that "text" didn't matter if it was somehow triggering the framebuffer or something
<tomreyn> vesa is a graphics mode
<drab> it's not a GUI, but it's not pure text either
<tomreyn> 640x480 is vga
<drab> yeah, understand,which is why I put "text" on the cmdline
<tomreyn> you can't output text if you don't have a means of graphical output
<tomreyn> (except on a serial console, i guess)
<drab> but that seems to be ignored once pxe hand it over to the installer
<drab> qemu has a -curses mode, which shows fine everything up to the installer starting
<tomreyn> hmm, yes, i'm not sure what this issue is you're running tinot there, haven't experienced it
<drab> if I take the same command/img and run it on my desktop but remove the -curses it show the installer at that point, so pretty sure something is going on when things are handed over to it
<drab> just can't figure out what
<drab> it looks like something is autoloaded because it thinks it's a graphic mode
<tomreyn> what is it you're trying to achieve there anyways, why are you running those tests?
<tomreyn> http://download.qemu.org/qemu-doc.html lists all qemu options and their meanings in case you don't have that available, yet
<drab> tomreyn: just trying to test some stuff with nfs-kernel-server, so I'm spinning up some qemu instances on test server, ie no gui
<drab> I'm ssh'ing into the server and using a command that includes -curses
<drab> yeah I looked at those options, especially the -display section
<tomreyn> you could add a vnc interface and access that from a graphical desktop
<tomreyn> you could use the serial console output instead to get a text only output
<drab> I tried to look at serial console, but then it seems I have to provide a kernel to qemu on the cmdline, which is kind of backwards
<drab> but maybe I misunderstood how to set that up
<tomreyn> the default installer doesn't work over serial, i think, if that's what you mean
<tomreyn> there's no requirement to use PV instead of HVM to achieve serial output though
<drab> right, that too, altho I meant to get qemu to use the serial console to begin with
<drab> but really, it sounds like VNC is my best option at this point
<drab> and it's all preseeded so it's really for debugging until I figure out why my postinst script is failing
<drab> tomreyn: any chance you have a quick hint on setting up vnc?
<tomreyn> maybe you should just install virt-manager on your desktop which has ssh access to the virtualization host, and use this to get a better idea of how qemu is meant to work
<tomreyn> it helped me to get started
<drab> tomreyn: I looked at that too, but it seems like in order for virt-manager to work you need to get the whole libvirtd shebang
<drab> and create another bridge, etc etc... and that test host has already its own bridge and some lxc stuff for testing
<drab> I was trying not to make disruptive/major changes to that host
<tomreyn> hmm right it has a bunch of dependencies
<drab> I might be asking too much to, so I'll try VNC and see what I get and if not maybe I'll try to find another host to experiment with
<drab> thank you for your help
<tomreyn> welcome, you could also ask those questions in #ubuntu-server or #ubuntu, might be more suitable
<drab> tomreyn: yeah, I'm in -server, I asked there first and no asnwer and thought some of the devs might have been familiar with the installer frontend question
<tomreyn> oh that had scrolled off my screen since
#ubuntu-devel 2017-04-21
<FourDollars> Hi, I would like to solve https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1685062. Could you help to review my merge proposal?
<ubottu> Launchpad bug 1685062 in unity-settings-daemon (Ubuntu) "Brightness step down can not reach the lowest brightness level." [Undecided,In progress]
<bdrung> pitti, hi. how do you detect duplicates? do you just use StacktraceAddressSignature?
<pitti> bdrung: the client side uses that, unless a hook set a custom DuplicateSignature:; the server side uses a signature built from the symbolic stack trace, which is usually more reliable
<pitti> bdrung: see apport/report.py crash_signature()
 * juliank finally remembered to verify the apt SRU for yakkety, and just did it :)
<bdrung> pitti, would be nice if apport-retrace would add the crash signature to the crash file
<ricotz> infinity, hi, looks like dpkg in artful generates invalid *.changes files, the Files section doesnt list *.buildinfo as in Checsums-*
<infinity> ricotz: http://launchpadlibrarian.net/316412144/dpkg_1.18.23ubuntu1_1.18.23ubuntu2.diff.gz
<infinity> ricotz: Entirely intentional, as there was a bug in launchpad's handling of buildinfo files on upload.
<infinity> ricotz: The feature will be restored in a few days when the LP fix is QAed and deployed.
<infinity> ricotz: Though, I'm curious what you mean by "invalid".
<infinity> Perhaps you meant "unexpected"? :P
<ricotz> infinity, launchpad rejected my upload which looks like https://paste.debian.net/plain/928699 with 1.18.23ubuntu3
<ricotz> so Files does not contain buildinfo
<infinity> ricotz: Oh.  I didn't check source builds.  Binaries are behaving correctly.  Bother.
<infinity> Although.  Huh.
<ricotz> yeah, this is a source build
<infinity> The testsuite does check source builds.
<infinity> And it works correctly.
<infinity> ricotz: How did you generate that?
<ricotz> with "dpkg-buildpackage -S -sd -d"
<infinity> ricotz: Oh, gross.  If you sign with dpkg-buildpackage, it screws up.  If you don't (ie: pass -uc), then it DTRT.
<infinity> ricotz: Might fix, or might not care, since I can revert that bit Very Soon anyway.
<ricotz> infinity, I would prefer a fix ;)
<infinity> ricotz: :P
<infinity> ricotz: Quick workaround for now is to build with "-uc -us", and then "debsign foo.changes"
<ricotz> hmm, not really applicable here, I want to avoid altering my scripts
<ricotz> infinity, what is "Very Soon"?
 * ricotz downgraded to the zesty packages already
<infinity> ricotz: Early next week at the latest.  Not sure how long it'll take to QA and deploy the LP fix.
<ricotz> alright
<cjwatson> I'll get it deployed today
<cjwatson> Assuming nothing explodes horribly
<cjwatson> BTW do we have a new enough debsign that signs buildinfo?
<cjwatson> infinity: ^-
<infinity> cjwatson: Possibly not.
<infinity> cjwatson: Definitely not.  I'll sort that.
<infinity> ricotz: http://paste.ubuntu.com/24426912/ might solve your issue for right now.  But looks like we'll be fixing things properly by EOD.
<ricotz> infinity, thanks, dropping buildinfo from changes works too ;)
<infinity> cjwatson: New devscripts uploaded.
<infinity> cjwatson: Well, devscripts uploaded, but it'll be FTBFS until you do your thing to LP and I do my thing to dpkg. :P
<cjwatson> Yeah, just QAing stuff in https://dogfood.paddev.net/~cjwatson/+archive/ubuntu/dogfood-buildinfo/+packages now
<infinity> cjwatson: Shiny.  I'm going to go find a very large coffee and install it in my face.  Back soon.
<mdeslaur> chiluk: FYI, I agree with your comment in the qemu bug, but I saw it too late
<nacc> rbasak: fyi, i'm starting up the importer job again, using the snap only :)
<rbasak> \o
<rbasak> \o/
<cjwatson> buildinfo should be fixed on LP production now.
<infinity> ricotz: dpkg 1.18.23ubuntu4 should behave correctly now (and LP will accept the uploads, too!)
<juliank> slangasek: re bug 1615482 - not sure why we ended up with 6am/6pm +/- 12 hours randomized delay. It's kind of odd. I think there's an IRC backlog for it in #debian-apt, but not looked yet. I suggested some improvements I recently thought about in the bug.
<ubottu> bug 1615482 in apt (Ubuntu) "apt-daily timer runs at random hours of the day" [High,Triaged] https://launchpad.net/bugs/1615482
<slangasek> juliank: right; long before this code landed in apt upstream, Ubuntu had integrated a carefully designed experience and this has very much regressed
<juliank> slangasek: Well no
<juliank> slangasek: I mean, we shared the cron job before. mvo replaced that with the systemd timer.
<juliank> Because people complained that the apt cron job was delaying other cron jobs by up to 30 mins
<slangasek> juliank: shared a cronjob that began in Ubuntu, was merged upstream to Debian, and then regressed without discussion in Ubuntu ;)
<juliank> slangasek: Well, mvo switched from the cron job to the timer mostly to fix a ton of bugs in launchpad :D
<slangasek> heh
<juliank> There was also the funny ones like cron job runs sleep, that sleep process eats to much memory
<slangasek> juliank: aiui the move to the systemd timer also loses the anacron support for catching up if the system was offline at the appointed time
<juliank> slangasek: No, that's built into systemd (see the Persistent option)
<slangasek> s/offline/powered off/
<juliank> systemd will retry at resumes and boots
<juliank> I think anacron only does boots
<slangasek> er, anacron absolutely did on resume also
<slangasek> though it's not impossible that *that* regressed as well :P
<juliank> Hey, I don't know, I just guessed :D
<slangasek> (that may have been a pm-utils integration that got lost in a migration; I don't know if it was lost, just saying it's possible)
<juliank> So the idea is to go down from 12 hours of randomized delay to like 30 mins and have the accuracy reduced too
<juliank> like 5 minutes or so
<slangasek> Persistent=true - cool, that makes sense
<slangasek> but AFAICS, on boot this will start before the network is up
<slangasek> because timers.target is DefaultDependencies=no
<slangasek> whereas cron starts much later (runlevel 2 / multi-user.target)
<juliank> slangasek: Yes. We can add an After=network.target. That does not help with resumes, though.
<juliank> anacron also delays these catch up events by 5 minutes,  which systemd does not https://github.com/systemd/systemd/issues/5659
<juliank> That's a reason why we run twice a day, BTW.
<juliank> The script itself checks a stamp file too, so it will only run actual stuff once a day
<slangasek> yeah, but running twice a day is a bad workaround
<juliank> slangasek: If we find consensus on some better values, then we can probably push that into a 1.4.1 release :) - if Debian RT says it's OK - I'd like to get this improved a few weeks ago, but I forgot about it
<juliank> Then we can also SRU that back into yakkety and xenial with another fix pending from 1.4
<juliank> (after the current SRUs migrated)
<slangasek> juliank: can we agree that being able to assert that timers running on resume can rely on the network being up first is something that systemd should be guaranteeing? (<-- xnox)
<juliank> Well, it sort of does with network.target, but that does not really cover non-server use cases
<juliank> Like on a laptop with NetworkManager, network.target by default does not wait for you being connected
<juliank> And on resumes, the target is considered started already, so no wait at all
<juliank> You can work around the resume scenario with this job: https://github.com/julian-klode/dotfiles/blob/master/.config/systemd/user/nm-online-exit.service
<juliank> This is like the normal NetworkManager-wait-online.service, but with RemainAfterExit=no instead of RemainAfterExit=yes
<slangasek> juliank: you want network-online for this, not network.target
<slangasek> it's perfectly appropriate to say "don't try to do apt updates unless you're online"
<juliank> Ah makes sense.
<slangasek> so that's just After=network-online.target
<slangasek> which the network provider will implement
<juliank> Yes.
<juliank> Only for boots though
<slangasek> yes; the resume case is more difficult
<juliank> And I think it the NetworkManager one might be disabled by default, not sure
<slangasek> but I think that needs to be solved in systemd, *not* in this uint
<slangasek> unit
<juliank> slangasek: Sure. We need a target that shuts down when there is no network. And then we can bind network needing jobs to that
<juliank> So, after a resume, the target comes back once the network is up again, and then network-needing units get started again
<juliank> slangasek: OK, so that seems to be the right thing to do: https://github.com/Debian/apt/compare/master...julian-klode:lp1615482?expand=1
<juliank> After + Wants on network-online.target
<juliank> We can also start it After=multi-user.target to get some more delay during boot to fix "slow" boots
<slangasek> juliank: fwiw I don't see any reason to use a non-default value for AccuracySec vs. the default of 1m
<juliank> "slow" = 5 second slower on an HDD machine...
<slangasek> juliank: yeah, I responded to that comment on the bug log - as far as I'm concerned "my boot is slower because my machine has to check for critical security updates" should be wontfix
<juliank> slangasek: It's just that we don't really need that kind of accuracy, so we decided back than to just be generous and allow it to merge with any hourly cron job in the near time
<ricotz> infinity, works, thanks!
<juliank> manual page says: "To optimize power consumption, make sure to set this value as high as possible and as low as necessary."
<juliank> But 5m vs 1m does not make a huge diff
<slangasek> juliank: we don't want millions of Ubuntu machines to all wake up on exactly the 5 minute mark and hit the mirrors
<juliank> Well sure, with a 30m randomize, 1m probably makes sense.
<juliank> I think we can calculate this out, how many machines on average would update at the same time
<slangasek> my point is we want it smoothed as much as possible over the interval, and this swamps any benefit of reducing wakeups... especially when we're talking about a single wakeup per day per machine
<juliank> Assuming an update takes about 1m, with 30m random delay, we would have N/30 machines hitting at the same time (or well, more like N/60, as the job runs twice a day)
<slangasek> (the fine controls of the systemd timer design are useful, just not for this)
<juliank> That's like it was before, basically, just running at 6/18 instead of 0.
<juliank> (I think cron ran at midnight, right?)
<slangasek> no
<slangasek> this was *always* in the 6am-7am window
<slangasek> 25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
<juliank> Ah, OK, great
<slangasek> and, I do think the 2x-daily frequency needs to be dropped back down to 1x
<sarnold> I suspect even 30m smearing isn't 'enough' -- our network always gets saturated start of every europe work day, heh
<slangasek> sarnold: there are some hotspots based on population centers, but that part is a conscious tradeoff
<juliank> slangasek: I think that needs some more digging in the backlog and possibly interrogating mvo to figure out why we have 2 tries at all
<sarnold> slangasek: heh, I guess i'm only ever awake for the one hotspot then :)
<drab> hi, anybody familiar with the process of starting ssh in a chroot from an ubuntu-install?
<slangasek> sarnold: I think you can ask IS for graphs that show the big EU peak, followed by two smaller US-East/US-West peaks
<drab> I'm trying to automate one last step that requires ssh install, but starting ssh from late-command fails
<slangasek> drab: basically unsupported
<drab> so preseed does its job, fires off late-command which creates a user, installs a pub key part and then tries to start ssh
<slangasek> you could start the daemon manually, but you can't start services via systemd units inside of a chroot
<slangasek> (and certainly not within d-i, which does not run systemd as init AFAIR)
<juliank> slangasek: Another fancy alternative would be to have unattended-upgrades drop in some overrides to tighten things up, but have apt run randomly during the day if u-u is not installed
<drab> slangasek: yeah, so I tried to just run /usr/sbin/sshd
<slangasek> juliank: I disagree that this behavior should be tied to unattended-upgrades
<drab> and in fact, it also works if I do /etc/init.d/ssh start
<drab> but it doesn't work if I do it from the late-command
<drab> or rather
<juliank> Well, the other stuff (running update and maybe clean up) is not that hurtful, it could have more flexibility than running an upgrade
<drab> if I run /usr/sbin/sshd it actually runs, process is there, but ssh in fails
<juliank> Probably not as much as now, but still
<drab> slangasek: complaining that /var/run/sshd does not exist even tho I just mkdir'ed it
<drab> so I'm really confused because if I do it manually it works, but if I do it from the script it doesn't
<drab> and I don't see the difference
<drab> especially for something as simple as mkdir, which btw works to create stuff in the homedir of the user I create
<slangasek> juliank: I have in fact had an apt update in the middle of the day on my laptop disrupt my work when it was *not* installing any packages, just because of the memory usage of all of the bits involved with updating indices
<slangasek> juliank: that was what prompted my comment on the bug back in March
<slangasek> (the apt indices themselves are probably fine, but then there are supplementary things like apt-xapian-index and appstream(?))
<juliank> yep
<juliank> slangasek: I think the reason not to do 1800 is that the admins go home at that point, rather than arrive at work around that time, so it takes longer to fix breakage?
<slangasek> juliank: for my part, the reason not to do 1800 is that I'm still using my computer at 1800 ;)
<juliank> slangasek: That makes sense too
<juliank> slangasek: I hope mvo is around next week, he has insight
<juliank> Unless it was pitti's idea to run twice a day
<juliank> slangasek: sarnold: If 30 minutes turns out to be a bit low, it might make sense to just go to 5:30 with a 1 hour random delay
<juliank> That's basically 6:00 +/- 30 minutes then
<sarnold> I like the sound of that
<juliank> The imaginary queue for the next SRUs has https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=2ce15bdeac6ee93faefd4b42b57f035bef80c567 and https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=5094697fe4b2459ff6f706a22006d3028369f3fa for now basically
<juliank> + the timer change would make a nice short SRU :D
<juliank> (The config change is only needed for yakkety)
<juliank> (that is, the "Fix and avoid quoting in CommandLine::AsString")
<juliank> It will be really fun to see how many stable apt series I can maintain longer term. 2 works OK, soon it's 3 for a few months.
<juliank> I think I have a sheet somewhere
<juliank> Yeah at https://docs.google.com/spreadsheets/d/12C3rcJBYc3tUHYUVOW_6Z_mqGqmFmGh4kV921ClbiJs/edit?usp=sharing
<juliank> Well, I also do security updates and on-demand critical bug fixing for 1.0.9.something in addition to the 1.2 and 1.3 stable series.
<juliank> I'd be happy to hear some more opinions on how the 1.2 and 1.3 series went so far. I know I sometimes waited too long between updates, causing a larger amount of fixes to accumulate, but if there's anything else to improve, let me know.
<infinity> juliank: I've had no complaints about the stable series' in general.  Given we used to have pretty much 0 apt updates except for security and when we encountered a world-ending critical, it can't get worse. :P
<infinity> juliank: If you're worried about signing up for too much work there, though, you might want to dial back the knob for what you consider a critical enough bug to warrant a cherry-pick, especially for non-LTS/non-Debian-stable release branches.
<rbasak> While we're talking about apt, nacc and I have a feature request. "apt-cache bin2src". Trivial enough I think, or would apt-cache be the wrong place?
<infinity> grep-dctrl?
<infinity> rbasak: I assume you mean "tell me this binary's source"?
<rbasak> Right, like chdist does it.
<juliank> infinity: I think the load is OK on my side. It will mostly be interesting to see how the cherry-picking scales :)
<rbasak> I appreciate that other tools exist, and I can easily use them.
<rbasak> But for new contributors, it seems like a simple enough question that should have a one command answer, instead of having to look up Packages files or set up other tooling.
<rbasak> As for grep-dctrl, it also needs a "well, if there's a Source header, then it's that, otherwise it's the same as the binary name" logic that isn't present there.
<juliank> rbasak: more source based stuff will come with the next ABI break. I want to add Source fields into the cache
<juliank> or rather, a source hash table.
<juliank> Although, that does not really help here as it's Src -> Binary
<juliank> we already have the information for Binary -> Source, I wasn't sure of tha
<rbasak> Thanks. Just thought I'd mention it as it came up in a conversation just now, and I saw you were here :)
<cjwatson> It *is* actually in grep-dctrl (-XFSource:Package), but I agree it would be useful to have a simple way to query the apt cache for it
<juliank> rbasak: I'm always here. If I'm not actually connected to my ZNC, it's supposed to send me a push message if someone highlights me, but that seems broken right now.
<rbasak> Oh, you can do that? Useful to know, thanks.
<juliank> :D
<cjwatson> If only because grep-dctrl often isn't installed in the sort of minimal contexts I want this
<infinity> To be fair, just adding "Source" to every binary stanza, even when it's identical to Package, would clear up a lot of confusion.  People's concerns about their 2400 baud modems likely shouldn't trump useful data in 2017.
<infinity> I get why it was deemed redundant data, but people have been confused about it since 1999.
<juliank> well it's just ${source:-$package}
<juliank> after you read both source and package fields into variables (in shell syntax)
<infinity> juliank: Sure.  The people discussing this know that.
<infinity> juliank: People new to it don't seem to find it so obvious. ;)
<nacc> and we want it for the case of a drive-by developer who wants to help provide a fix for a binary package and may not necessarily realize the distinction -- or know about the mapping and we'd like like to do something like "We couldn't find that source package, but did find a binary package with that name, that is built from this source package. Maybe you meant that one."
<infinity> "Why do some binary packages not have a Source field?"
<juliank> We should synthesize the field in apt show output
<nacc> we can just wrap grep-dctrl for this case in the meanwhile :)
<infinity> nacc: Well, apt-get source does that.
<nacc> infinity: good point! :)
<juliank> That makes the automatic lookup easier.
<infinity> juliank: Right, that's do it.  No need to have it on the disk or wire, if you can synthesize it at lookup time.
<infinity> s/that's/that'd/
<infinity> I don't think complicated tooling is needed when we *should* be encouraging people to read and understand "apt-cache show", but that one tiny change would be a large quality of life improvement for first-timers.
<infinity> And even for people attempting to do quick shell loops.
<infinity> Well, look at that, proposed-migration works.
<infinity> And autopkgtests are autopkgtesting.
<infinity> Will wonders never cease.
<infinity> juliank: SPEAKING OF...
<infinity> juliank: I *still* have a hint in place for test-apt-download-progress sucking.
<infinity> juliank: I feel like the time you've wasted on that test could have been better applied to perhaps several more graduate degrees or perhaps starting a few families around the world.
<juliank> infinity: that is an odd test for sure
<infinity> "odd" is probably not the adjective I'd choose.
<juliank> Yay, push notifications work again
<juliank> infinity: There actually is of course a somewhat fix for that: Throttling in the web server.
<juliank> But that's a situation where unit tests would be much nicer
<juliank> The test was to check that One method was called when downloading stuff
<juliank> Speaking of autopkgtests, the failures in reverse deps for the 1.3.5 and 1.2.19 SRUs are the usual unrelated ones.
<infinity> juliank: But it is entertaining that autopkgtest fails its autopkgtests.
<juliank> Yes, it sure is.
<juliank> The fix is probably simple but I never bothered looking at it.
<juliank> The autopkgtest autopkgtests fail as soon as the next development cycle has started
<juliank> infinity: I feel like that always delays the SRUs a bit
<infinity> Yeah, it does.
<infinity> I investigated the sbuild "regression", and that looks like a simple enough fix.
<infinity> The autopkgtest one, I'm not as intimately familiar with.
 * infinity scratches his head at britney's logs...
<infinity> I: [Fri Apr 21 22:16:14 2017] - gcc-4.7-arm-linux-gnueabihf on s390x has no source (NBS?)
<infinity> I mean, sure, it has no source.  But it also has no binary.  So what are you on about?
<juliank> The current SRU got a bit weird because 1.2 entered proposed a week before 1.3 and was verified quickly, but then nothing happened when 1.3 was accepted, because I was busy doing Android development
<juliank> infinity: lol
<juliank> Android community is a lot more different and more engaged than anything I've seen before
<infinity> Young communities usually have a very different feel.
<infinity> Not enough grumpy old guys like me (or just the right number).
<juliank> But the engagment is mostly testing and feature requests, not code contributions.
<juliank> Will aptdaemon go away this cycle?
<juliank> or rather, is someone trying to make it go away?
<juliank> it's like vampire code or something
<infinity> juliank: I think people wanted it to die, but I'm not entirely clear on what one replaces it with.
<juliank> Well, drop sessioninstaller, switch g-s to packagekit, live with the reboot-to-upgrade nonsense, and call it a day?
<infinity> juliank: update-notifier and update-manager are the two interesting ones I see.
<jbicha> bug 1673258 bug 1643134
<ubottu> bug 1673258 in update-notifier (Ubuntu Artful) "Remove aptdaemon and drop or port its reverse-dependencies" [Undecided,New] https://launchpad.net/bugs/1673258
<ubottu> bug 1643134 in gnome-software (Ubuntu) "Switch gnome-software to use PackageKit backend" [Wishlist,Triaged] https://launchpad.net/bugs/1643134
<jbicha> juliank: I expect the reboot-to-upgrade feature could be patched out but there are other concerns about switching GNOME Software to PK
<juliank> Honestly, I'd basically just kill update-notifier and update-manager, and just have a special tool for release upgrades.
<jbicha> I like the idea of switching it to PK but apparently it's slower for some use cases
<juliank> (Not sure if there was anything else in there that's really needed, have not looked at that in a long time)
<juliank> jbicha: Well, yes, it's likely slower, but at least it's more maintained than just kept barely alive :)
<jbicha> and the Ubuntu Desktop team is somewhat risk-averse so they would rather not knowingly introduce regressions if they can avoid it
<infinity> juliank: update-manager is pretty iconic part of the Ubuntu experience, IMO.  gnome-software is super clunky in comparison.
<jbicha> juliank: you're welcome to bring up the topic on the ~ubuntu-desktop list or wherever
<juliank> infinity: I'm not a huge fan of gnome-software either. But I'm not sure it's worth it to fight it. There's also something to gain by potentially having one software center like thing where you can schedule/do upgrades for all kind of formats (not sure if snap backend exists yet, does it?)
<juliank> I only ever used gnome-software to update flatpaks, though
<jbicha> juliank: if you have questions about gnome-software in Ubuntu, you should talk to Lan_ey or robert_ancell
<juliank> sure. Or I could look it up myself :)
<jbicha> well I mean to say that Ubuntu's Desktop Team is putting work into integrating g-s into Ubuntu but it's a big project
<juliank> I know
<infinity> juliank: snaps upgrade without human intervention.
<juliank> infinity: oh yes, right. otherwise my "server" laptop would have had issues ...
<infinity> But aside from the update-manager UI being about 1000 times better, I also have no idea what an "apt upgrade via packagekit" actually looks like.
<infinity> Does it abide by the same resolver constraints we carefully chose in update-manager?  Can it be made to?
<juliank> infinity: I only know the UX: It's click, it reboots, applies updates, and then boots to the system.
<infinity> Uhm.  Ew.
<juliank> I know, it takes some time to get used to that.
<infinity> Even Windows doesn't force me to reboot for most updates anymore.
<infinity> That feels like a step rather far backward for apt/dpkg systems.
<juliank> I don't use it, but I do almost always reboot after an upgrade
<infinity> I've decided I need to go eat a whole pizza and wallow in software-induced depression.
<juliank> because library changed and were loaded, or kernel changed, or well, just to see if the machine still boots
<infinity> juliank: If we did a "patch Tuesday" thing like Microsoft, that might be acceptable.  Given that we push SRUs daily, however, and you may well get one a day, it's pretty much a non-starter to suggest that users be forced to reboot when it's not necessary.
<jbicha> I think that feature was driven by Fedora where maybe upgrade problems are more common? I don't really know enough about rpm/yum/dnf
<juliank> jbicha: basically *Everything* is driven by Fedora :D
<infinity> rpm, in theory, is about as error-prone (or not) as dpkg.  RPM distros (especially Fedora) have historically lacked the policy and general anal retention of the Debian community that insisted on smooth upgrades.
<jbicha> lol
<infinity> Honestly, most Debian people consider it a bug if you're doing a release upgrade and you can't keep working through it.
<infinity> Me, I think our release upgrader should actually bounce you to a minimal session.
<infinity> But taking that logic to daily updates is not sane, IMO.
<juliank> infinity: You have to see it like this: If an update gets pushed that breaks boots, you'll immediately notice it! :D
<jbicha> yeah, the Unity>GNOME upgrade in particular would be nice to do offline
<sarnold> heh, I once upgraded a machine to oldstable, then stable, then unstable, all in one go, and it didn't disrupt the machine's use. (minimal at the time, but still.)
<juliank> I fail quite spectacularly at Debian upgrades. Hit Ctrl+C at the wrong moment, dpkg gets interrupted, and I play half an hour with --force and --unpack and -i options recovering from my mess.
<jbicha> infinity: you should try the GNOME Software offline upgrade feature in like Fedora 25 or Debian stretch, I believe it uses systemd to apply the upgrade
<infinity> juliank: Have you considered not doing that?
<juliank> But it's probably still smoother than a Windows update.
<jbicha> it might be something we would be interested in for release upgrades
<sarnold> juliank: you like living on the edge :D
<juliank> infinity: It's not that bad. Last time I just run dpkg --unpack --recursive /var/cache/apt/archives a few times, and then the system was OK enough for apt to function again and calculate the rest.
<infinity> jbicha: Of course it does.  If systemd isn't involved (and if we can't make up more excuses for jamming it in the initrd while we're at it), it's not modern Linux, right?
<infinity> juliank: Still, not interrupting it sounds like it would be a better option. :P
 * infinity -> pizza.
<juliank> infinity: true. but it's like "oh, it's still reading package lists for a huge upgrade and I just noticed something I missed"
<Unit193> infinity: What type?
<juliank> a round one?
<Unit193> Square ones are rather sub-par, yes.
 * Unit193 waves to juliank.
 * juliank does not eat much pizza. And most people might not even consider something without cheese and only vegatables on top of it a pizza.
<sarnold> at that point it's just vegetables on flat bread
<sarnold> might be alright as it goes but i'm not sure you still get to call it pizza ;)
<juliank> sarnold: I think the core point of the pizza is the bread, and just a drop of vegetables for fun.
<Unit193> What about "white" pizzas?  White chicken, ranch, etc?
<jbicha> juliank: if you add a piece of bread on top, that sounds like a sandwich to me
<juliank> Pizza is basically just Focaccia with stuff on top that's baked with it
 * juliank should visit his pizza baker tomorrow
<juliank> they speak Italian
<juliank> or maybe they just pretend, I can't tell :D
<sarnold> it's all in the hands anyway, right? :)
<Unit193> sarnold: There's a place here that bakes them in a stone/wood oven, I hear that's sooo much better.
<sarnold> Unit193: that's almost always a good sign
<tsimonq2> I think it's annoying that my mom cuts pizzas into squares sometimes...
<juliank> You basically need like 500C to bake pizza
<tsimonq2> It just bugs me because someone has to get the corner pieces
<juliank> and then bake at something like 60 to 90 seconds
<tsimonq2> With triangle pizza, you have to share it :P
<juliank> Let's make Ubuntu pizza
<juliank> the logo should work fine as a pizza
#ubuntu-devel 2017-04-22
<notinuse> leave
* infinity changed the topic of #ubuntu-devel to: Zesty Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<juliank> infinity: Yay. I assume auto syncs don't run yet? Want to fix bug 1681231 (sync package, and upload it as an SRU to yakkety)
<ubottu> bug 1681231 in cracklib2 (Ubuntu) "package cracklib-runtime 2.9.2-3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [Undecided,Triaged] https://launchpad.net/bugs/1681231
<Unit193> ...Is there a way to mark a package as expected to fail to build on an arch?
<infinity> Unit193: Let it fail?
<infinity> juliank: autosyncs probably won't be on for a day or two while people do some manual merges first.
<Unit193> Right, but it keeps emailing me...
<juliank> Great. I synced manually now, and will prepare an SRU for yakkety shortly.
<juliank> Also I'm not sure how we can have a reproducible test case here
<juliank> s/yakkety/zesty/
<juliank> Or well, both even it seems
<juliank> Although: If we only see the issue in zesty, probably no need to work around it in yakkety too
<acheronUK> no artful template yet in /usr/share/python-apt/templates/Ubuntu.info
<acheronUK> I know it's a bit early to nag about that :P
<juliank> acheronUK: It's not been that long :D
<acheronUK> but it did just break our CI builds
<acheronUK> juliank: yep. I know. :)
<juliank> Oh well, I'll SRU cracklib2 to both yakkety and zesty it seems, one of the linked bug reports complains about yakkety
<juliank> If no one is working on the python-apt thing, I can do this quickly
<acheronUK> juliank: if you have the time, that would be great
<Unit193> Actually, if I'm looking at this correctly then the issue should be fixed with golang 1.8
<juliank> Change is committed, upload is coming
<juliank> acheronUK: Uploaded
<acheronUK> juliank: thank you :)
<juliank> Hmm, I guess I should just SRU (more parts of) cracklib 2.9.2-4 to xenial (2.9.2-1) too.  (-2 fixes a CVE, -3 fixes a buffer overflow)
<jaydemir> do programs written in java make it onto the ubuntu repos? or is it usually just c and python?
<juliank> lol
<LocutusOfBorg> cpaelzer, will you take care of strongswan please? :) (I'm listed as last uploader, but I just did a no change rebuild)
<acheronUK> juliank: test regression on python-apt against update-notifier on s390x
<juliank> acheronUK: retried it
<acheronUK> thx. hoping it is just random weirdness of s390x
<juliank> It's definitely not a python-apt regression
<juliank> Could not connect to localhost:52117 (127.0.0.1). - connect (111: Connection refused)
<juliank> Ah no, that happens everywhere
<juliank> Anyway, no downloading changes anywhere
<acheronUK> ooh. new retry button http://autopkgtest.ubuntu.com/packages/u/update-notifier/artful/s390x
<juliank> yeah, just saw that too
<juliank> acheronUK: And it passed
<acheronUK> juliank: yep. just saw :)
<juliank> acheronUK: Oh well, now snapcraft failed, but no new regression, already happened in prev build too (for squashfs-tools)
<acheronUK> juliank: can that get through then?
<juliank> Some tests are still in progress AFAICT
<acheronUK> juliank: I meant the snapcraft fails being badtested
<acheronUK> as at the moment looks like they would hold it back, regression or not
<juliank> It looks like snapcraft itself regresses on armhf
<juliank> On amd64 the upload run worked, but the python-apt caused one failed.
<juliank> on armhf the upload run failed, with different errors than on amd64
<acheronUK> fun!
<acheronUK> ok. if python-apt is going to be stuck in proposed for a bit, will have to start thinking about workarounds for our CI
<Unit193> ginggs: I don't suppose you're around?
#ubuntu-devel 2017-04-23
<Unit193> As it stands, /etc/X11/Xsession.d/60x11-common_xdg_path appends the session name to XDG_CONFIG_DIRS, but with wayland I presume this won't be done?  Perhaps /etc/profile.d/?
<jbicha> Unit193: are you asking about Xfce or what?
<Unit193> jbicha: ....No, Xfce has nothing to do with Wayland.
<jbicha> I didn't think so, but I'm really confused
<Unit193> juliank: I know you said you don't touch ftparchive, but for your next SRU to Xenial I don't suppose you'd change 'SetExts(".deb .udeb");' to 'SetExts(".deb .ddeb .udeb");'  ?
<juliank> Unit193: I most certainly won't. It has to be part of the newer series first before I can push anything to xenial :D
<Unit193> juliank: Dowh, but I poked you with that too. :P
<ryao> Would anyone care to contribute to an attempt at breaking the most reviewed patch in OpenZFS record? https://github.com/zfsonlinux/zfs/pull/6054
<ryao> I would need to look it up, but given the remark about needing more reviewers, I couldn't help myself in making the challenge. We'll take reviewers from other projects. :D
<Son_Goku> ryao: hello again :P
<ryao> Son_Goku: Hello.
<juliank> acheronUK: [ubuntu/artful] python-apt 1.4.0~beta2ubuntu1 (Accepted)
<acheronUK> juliank: :) thank you
<acheronUK> juliank: FYI, that update fixes source builds for artful in kubuntu's CI docker containers, so x2 on that thank you
<juliank> :)
<mwhudson> does launchpad sync from debian experimental?
<mwhudson> i guess not, i don't see anything on https://launchpad.net/debian/+source/golang-defaults
<mwhudson> (which does have a package in experimental)
<Unit193> You can with syncpackage,of course.
<mwhudson> can i?
<Unit193>   -d DISTRIBUTION, --distribution=DISTRIBUTION
<Unit193>                         Debian distribution to sync from.
<mwhudson> hm
<mwhudson> syncpackage: Source golang-defaults -> artful/Proposed: current version 2:1.7~1ubuntu1, new version 2:1.7~5
<mwhudson> that new version is from unstable, not experimental
<mwhudson> "golang-defaults | 2:1.8~1        | experimental     | source"
<mwhudson> from rmadison -u debian golang-defaults
<mwhudson> i wonder what's going on
<Unit193> mwhudson: unit193@Sigma:~$  syncpackage -d experimental --simulate golang-defaults
<Unit193> syncpackage: Source golang-defaults -> artful/Proposed: current version 2:1.7~1ubuntu1, new version 2:1.8~1
<Unit193> syncpackage: Error: --force is required to discard Ubuntu changes.
<mwhudson> oh i said -D experimental
<mwhudson> which is --debian-mirror, which i guess is ignored when talking to lp
 * mwhudson sighs and makes more coffee
<Unit193> Heh, I'm just about to finish mine.  Also saw you had that in a test ppa, thanks.  Allowed me to test a rebuild (still failing.)
<mwhudson> i can sync now that powerpc is dead
<mwhudson> oh no, not quite, still need shared lib bits
<mwhudson> fooey
<mapreri> please remember me: what's the ubuntu's equivalent for archive.debian.org ?
<sarnold> mapreri: http://archive.ubuntu.com/
<mapreri> nope, that one is for the current releases, not the old ones (which is what archive.d.o is about)
<Unit193> http://old-releases.ubuntu.com/
<sarnold> oh :) http://old-releases.ubuntu.com/ubuntu/
<Unit193> (*Remind)
<mapreri> oh, right!
<mapreri> Unit193: thank you (also for the correction, I keep mixing remember and remind :S) !
<Unit193> Of course, 'welcome!
#ubuntu-devel 2018-04-16
<Whoopie> LocutusOfBorg: Hi, I found the root cause why ldconfig doesn't take the virtualbox libraries into consideration. They are found after the "official" GL libraries. Here's the patch: http://paste.debian.net/1020547/
<Whoopie> But be careful, don't fix this bug before you have a solution for the glFramebufferTexture2D -> https://www.virtualbox.org/ticket/17623
<Whoopie> LocutusOfBorg: I guess, this must also be fixed in the mesa GL packages.
<mdeslaur> bdmurray: are you looking into the apport autopkgtest failure?
<LocutusOfBorg> Whoopie, who is adding that x86_64-linux-gnu_EGL.conf file?
<Whoopie> LocutusOfBorg: virtualbox-guest-x11 in the postinst.
<Whoopie> LocutusOfBorg: look at the diff, it's all there. http://paste.debian.net/1020547
<LocutusOfBorg> Whoopie, I need to understand why the file changed in path
<LocutusOfBorg> because that change is not retro-compatible
<LocutusOfBorg> I don't apply random patches over the internet just because somebody points me at them without an appropriate rationale.
<LocutusOfBorg> rationale might be "mesa/nvidia folks changed filename because new glib requires the overrides to start with a number like "00_" so we had to follow the same reasoning and change them too
<Whoopie> LocutusOfBorg: totally agreed. I changed it to 00_ so that it's picked up as the first one.
<Whoopie> LocutusOfBorg: otherwise, /etc/ld.so.conf.d/x86_64-linux-gnu.conf is picked up first and the libGL and libEGL points to /usr/lib/x86_64-linux-gnu
<Whoopie> LocutusOfBorg: and as I said, don't fix it before you fix the 3D issue.
<willcooke> doko, hi, are you waiting on anything else for this one?  https://bugs.launchpad.net/ubuntu/+source/ubuntu-report/+bug/1759540
<ubottu> Launchpad bug 1759540 in ubuntu-report (Ubuntu) "[MIR] ubuntu-report: send telemetry data to ubuntu server" [Undecided,New]
<LocutusOfBorg> Whoopie, this has been handled with update-alternatives approach, not with 10 different files in the same location, with different filename start bit
<LocutusOfBorg> so, we have priorities for update-alternatives and this is the right approach
<LocutusOfBorg> if mesa or whoever places that file changed the approach, yes I have to follow the change
<Whoopie> LocutusOfBorg: sorry, you don't understand it, there's a default file called x86_64-linux-gnu.conf which points ldconfig to /usr/lib/x86_64-linux-gnu
<LocutusOfBorg> yes, and update-alternatives changes that link to somewhere else
<Whoopie> as soon as ldconfig finds libs for GL and EGL, it throws away all other.
<LocutusOfBorg> it doesn't add a new one
<Whoopie> no
<Whoopie> LocutusOfBorg: update-alternatives changes x86_64-linux-gnu_GL.conf, not x86_64-linux-gnu.conf
<LocutusOfBorg> ohhhhhhhhhhhhhhhhhhh ok
<Whoopie> LocutusOfBorg: and  x86_64-linux-gnu_EGL.conf
<LocutusOfBorg> sure
<LocutusOfBorg> got it now
<LocutusOfBorg> so, who damnly put the libEGL into that path in first place?
<LocutusOfBorg> what is the rationale of having an override and not using it?
<Whoopie> LocutusOfBorg: I don't understand.
<Whoopie> LocutusOfBorg: I could find an update-alternatives removal in libegl-mesa0 and libglx-mesa0, not and adding.
<Whoopie> not an adding
<LocutusOfBorg> update-alternatives --query x86_64-linux-gnu_gl_conf
<LocutusOfBorg> what does this return?
<LocutusOfBorg> it should return the virtualbox version
<LocutusOfBorg> if not, what is the point of providing a file named x86_64-linux-gnu_EGL.conf when the first x86_64-linux-gnu.conf picks the stuff?
<LocutusOfBorg> I would expect the various lib*GL* implementations to go in /usr/lib/<triplet>/something/ so they are not picked up automatically unless specified in that conf file
<Whoopie> right
<LocutusOfBorg> Whoopie, how do you reproduce all the issue? from the begin
<LocutusOfBorg> I'm installing a bionic vm
<LocutusOfBorg> bionic amd64
<Whoopie> LocutusOfBorg: regarding the ldconfig issue, you can check e.g. "ldd /usr/bin/glxinfo" and see that libGL.so.1 does not point to /usr/lib/virtualbox/additions/libGL.so.1
<Whoopie> LocutusOfBorg: then copy /usr/lib/virtualbox/additions/00vboxvideo.conf to /etc/ld.so.conf.d/, run "sudo ldconfig" and check again. It shoud point to /usr/lib/virtualbox/additions/libGL.so.1
<Whoopie> LocutusOfBorg: then reboot (be aware that you won't get the gdm screen) and check /var/log/syslog regarding the undefined symbol  glFramebufferTexture2D
<Whoopie> LocutusOfBorg: or do you also mean the cheese/gstreamer issue?
<bdmurray> mdeslaur: I will be yes
<mdeslaur> bdmurray: cool, thanks!
<LocutusOfBorg> Whoopie, I can reproduce now
<LocutusOfBorg> so, everything works just because I can't really make my module load
<Whoopie> LocutusOfBorg: which module?
<LocutusOfBorg> my so libraries
<Whoopie> right
<LocutusOfBorg> Whoopie, even the official upstream binaries are not overriding GL anymore...
<bdmurray> andyrock: Did you get a chance to test that plymouth in my ppa?
<andyrock> bdmurray: fix confirmed
<andyrock> let me comment on the bug too
<bdmurray> andyrock: I seem to reclear you exprienced it at every boot, is that right?
<bdmurray> s/reclear/recall/
<andyrock> bdmurray: right
<gpiccoli> Hi folks, I was trying to bootstrap an ISO image of ubuntu-server using qemu, in my server
<gpiccoli> Struggled to pass console=ttyS0 for it, --location didn't work (was using virt-install)..ended-up giving up and using netboot
<gpiccoli> Is there any reason to not have console=ttyS0 as default in grub.cfg of our amd64 server images?
<sarnold> iirc on smartos the first serial port is used for hypervisor<->guest coordination
<gpiccoli> sarnold, sorry what is smartos?
<gpiccoli> might be a silly question
<sarnold> gpiccoli: joyant's cloud platform
<sarnold> gpiccoli: it's an Illumos OS distribution designed for easy cloud hosting stuff -- you boot to e.g. a USB memory stick or netboot, and the main zone loads configs for all the other zones, zfs pools, and starts vms in the other zones as needed
<gpiccoli> awesome! but sarnold, seems like a distro right?
<gpiccoli> you're saying that a ubuntu ISO running in KVM inside smartos will have issues by setting the console= by default?
<sarnold> gpiccoli: think of them as similar to aws or scaleway ..
<gpiccoli> oh great sarnold
<gpiccoli> so, they do use isos to bring-up guests..and we would have issues there
<Whoopie> LocutusOfBorg: they do here.
<sarnold> is something extra-special broken with ca-certificates? or is this just the usual amount of "meh debs don't upgrade well"? 1764060 1764061 1764106 1764313 1764431 1764533 1764551
<Faux> There's a bug.
#ubuntu-devel 2018-04-17
<jbicha> LocutusOfBorg: please push your latest gtk3 changes to the bzr branch
<tsimonq2> Nice, Debian 12 is "bookworm"
<lathiat> slangasek; Are you able to sponsor (or suggest someone to sponsor) this upload for bionic? Causes major issues for network bring-up and boot for some bionic upgraders.  https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1752411
<ubottu> Launchpad bug 1752411 in bind9 (Ubuntu) "bind9-host, avahi-daemon-check-dns.sh hang forever causes network connections to get stuck" [High,Confirmed]
<LocutusOfBorg> jbicha, .
<popey> I have done a clean install of 18.04, when I updated it today it pulled in networkd-dispatcher from universe. Why? Shouldn't my install *only* have things from main?
<cjwatson> popey: networkd-dispatcher is on the list of component mismatches and has a pending MIR: https://people.canonical.com/~ubuntu-archive/component-mismatches.html
<popey> ooh, thanks. new url for me to remember :)
<ahasenack> hi, did something change recently in the toolchain in bionic? I'm getting this link error now, and it was working last thursday:
<ahasenack> https://pastebin.ubuntu.com/p/nBFFhwgSpf/
<ahasenack> although I can't promise the container was up-to-date last thursday
 * ahasenack checks apt log
<ahasenack> https://pastebin.ubuntu.com/p/BD47FjrnWR/ is what I installed/upgraded/removed this morning
<ahasenack> ah, but yesterday there was a much bigger dist-upgrade, and I didn't attempt a rebuild then
<ahasenack> and I see libc in there
<Laibsch> Can somebody help me understand what's going on in bug 991471? It still affects bionic and I'd like to see what I can do to get it fixed. IOW, how does the automatic mounting happen?
<ubottu> bug 991471 in udisks2 (Ubuntu) "multi-device btrfs filesystem automatically mounted once for each device" [Medium,Confirmed] https://launchpad.net/bugs/991471
 * sil2100 hugs Laney for the FTBFS fixes in bionic
<Laney> sil2100: â¥
<krytarik> "golang-github-ubuntu-ubuntu-report-dev" - did someone typo this in the first place..? :3
<cjwatson> krytarik: No - Go package names are constructed in a regular fashion from the import path, so that arises from https://github.com/ubuntu/ubuntu-report
<krytarik> Ah, that makes sense then!
<caravena> Hello, bug in polari.  Problem with apport-cli "Invalid core dump: BFD: warning: /tmp/apport_core__fhxvqfo is truncated: expected core file size >= 180617216, found: 26279936" https://imgur.com/a/YTE7V
<sarnold> is your /tmp/ filesystem full?
<sbeattie> sarnold: I think bug 1764848 has tracked down at least some of the ca-certificates failures, due to a conflicting certificate included in ubuntu-sso-client, which is no longer in bionic, but isn't uninstalled until after the fact when upgrading from xenial to bionic.
<ubottu> bug 1764848 in ca-certificates (Ubuntu) "Upgrade to ca-certificates to 20180409 causes ca-certificates.crt to be removed if duplicate certs found" [Undecided,New] https://launchpad.net/bugs/1764848
<sbeattie> bdmurray: ^^^^ should probably be on your team's radar.
<bdmurray> sbeattie: looking, thanks
<sarnold> sbeattie: nice find!
<ehashman> tsimonq2: jbicha: looks like everything is built, synced, and accepted! thanks so much for all your help ^_^
<tsimonq2> ehashman: Thanks for maintaining the packages :)
<sarnold> wonderful :)
<bdmurray> I take it there are other reports like this?
<sarnold> bdmurray: 1764060 1764061 1764106 1764313 1764431 1764533 1764551
#ubuntu-devel 2018-04-18
<quidnunc> Shouldn't avahi-daemon.service Daemonize the process? I see avahi-daemon -s
<quidnunc> doesn't avahi-daemon -D make sense
<quidnunc> 0.7-3.1ubuntu1
<alkisg> ricotz, Wimpress: hi, Firefox is still crashing on Raspberry Pis in Ubuntu 16.04 and 18.04. It's been that way since Firefox 52. Is there any work underway to merge the patches proposed in https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1711337 ?
<ubottu> Launchpad bug 1711337 in firefox (Ubuntu) "Firefox crashes at start on armv7L after 55.0.1 update" [Undecided,Confirmed]
<ricotz> alkisg, did you try firefox 60 yet?
<ricotz> alkisg, https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next/+build/14768714
<alkisg> ricotz: no, I only have firefox 59 in bionic, ..., thanks, I'll try from there
<ricotz> alkisg, did you gave it a try yet?
<jibel> slangasek, Hi, could you have a look at bug 1763739 ? Reverting this patch https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6604 fixes it.
<ubottu> bug 1763739 in ubiquity (Ubuntu) "ISO boots directly to desktop" [Critical,Triaged] https://launchpad.net/bugs/1763739
<alkisg> ricotz: firefox 60 from the ppa seems to run fine in ubuntu-mate 18.04, rpi2. Great, hope to see it in main soon!
<teward> is someone updating Perl and breaking things in Bionic?
<ricotz> alkisg, nice, final version should be in bionic in 3 weeks
<alkisg> ricotz: great, thank you :)
<teward> I just saw a weird perl breakage on one of my autopkgtests for nginx that had something to do with perl, hence asking...
<cjwatson> there was a perl security update in bionic
<cjwatson> but I mean you can check the publishing history as well as I can :)
<teward> could if LP weren't timing out on me
<teward> *kicks internet*
<slangasek> jibel: as flocculant said on the bug just now, I've already pushed the fix for this; it's included in 18.04.6 which is present in bionic now
<slangasek> jibel: closed the bug
<bdmurray> Is there somebody from kubuntu who can have a look at bug 1622499?
<ubottu> bug 1622499 in kaccounts-providers (Ubuntu) "[master] package kaccounts-providers (not installed) failed to install/upgrade: trying to overwrite '/etc/signon-ui/webkit-options.d/accounts.google.com.conf', which is also in package account-plugin-google 0.13+16.04.20160719-0ubuntu1" [High,Confirmed] https://launchpad.net/bugs/1622499
<jibel> slangasek, it is not fixed. The log I pasted is with Ubiquity 18.04.6 and I tried with today's iso
<slangasek> jibel: ack, sorry for missing that - reopening and looking
<Whoopie> LocutusOfBorg: did you think about how to fix the update-alternatives issue?
<slangasek> jibel: which image did you test with?
<LocutusOfBorg> Whoopie, I did
<LocutusOfBorg> and the grapphic is slooooow
<slangasek> jibel: 'xfsettingsd' so I guess xubuntu
<slangasek> jibel: needs X logs and journal output from the related services (plymouth-quit*, ubiquity-dm, getty*) to understand what's happening.  Do you have those logs handy, or should I start downloading the xubuntu iso here?
<slangasek> jibel: (also 'xubuntu' as the hostname so I suppose that should've also been a clue to me about which image you were using)
<Whoopie> LocutusOfBorg: I experienced the same. but if a user enables 3d in the VM, it should work nevertheless.
<jibel> slangasek, I tried xubuntu desktop 20180418, Ubuntu works fine
 * slangasek nods
<jibel> from the logs ubiquity starts before the display is ready
<tsimonq2> bdmurray: Kubuntu> That'd be me or acheronuk. Passed on; thanjs
<tsimonq2> *thanks.
#ubuntu-devel 2018-04-19
<slangasek> jibel: blah, 'getty1' is not the name of a tty.
<Laibsch> Can somebody help me understand what's going on in bug 991471? It still affects bionic and I'd like to see what I can do to get it fixed. IOW, how does the automatic mounting happen?
<ubottu> bug 991471 in udisks2 (Ubuntu) "multi-device btrfs filesystem automatically mounted once for each device" [Medium,Confirmed] https://launchpad.net/bugs/991471
<eoli3n> Hi
<eoli3n> will bionic netboot installer be realease the same day that desktop installer ?
<jibel> slangasek, thanks for the fix. Tested and merged.
<joelkraehemann> nacc: hi
<joelkraehemann> https://tracker.debian.org/pkg/gsequencer
<joelkraehemann> ^^ we could basically sync
<xnox> kirkland, hi, Re:subiquity installer options. At the install path choice, we have "Install Ubuntu", <thing for maas region (full)>, <thing for maas rack>
<xnox> kirkland, previous suggestion was for us to switch and call the product "Install MAAS bare metal cloud" but how is that supposed to be multiplexed into rack & region?
<xnox> "Install MAAS bare-metal cloud (region)" & "Install MAAS bare-metal cloud (rack)"
<xnox> kirkland, a comment on https://github.com/CanonicalLtd/subiquity/pull/309 would be appreciated. Thanks a lot.
<dpb1> xnox: the wording?
<dpb1> xnox: what vorlon has suggested looks right...  And is british english cased, so we are good there too.
<xnox> dpb1, ack
<hallyn> xnox: github.com/CanonicalLtd?  omg
<sarnold> hey hallyn :)
<hallyn> hey :)
#ubuntu-devel 2018-04-20
<xnox> hallyn, a more canonical name was taken
<Unit193> The confusion exists with github.com/ubuntu/ \o/
<xnox> Unit193, that's the other half of the company we don't speak to =)
<xnox> muahahahahhaha
 * Unit193 makes note to give xnox a good sanity check. :>
<dpb1> hallyn: :)
<slangasek> Unit193: like an autopkgtest, when the sanity check always comes back negative, it doesn't do you much good
<Laibsch> Can somebody help me understand what's going on in bug 991471? It still affects bionic and I'd like to see what I can do to get it fixed. IOW, how does the automatic mounting happen?
<ubottu> bug 991471 in udisks2 (Ubuntu) "multi-device btrfs filesystem automatically mounted once for each device" [Medium,Confirmed] https://launchpad.net/bugs/991471
<Faux> The ticket says udisks2, presumably driven by gvfs or some other gnome automounting component. You've asked before, so presumably read the ticket. What else is there to know?
<Laibsch> Well, it's me who set the component to udisks2 ;-)
<Laibsch> I'm not entirely sure that's correct, but seems like the most likely candidate.
<Faux> Presumably reproducing the problem isn't too hard if you have a system you don't mind installing udisks2 on, and a usb stick.
<Laibsch> What I'd like to know for example is why in the case of a 2-device btrfs the automounter mounts it twice.  What is the command-line I can check where this goes astray.
<Laibsch> Faux: I *am* affected by the problem
<Laibsch> no need for a test system.
<Faux> I imagine the automounter is very much "for device in new_devices; do mount $device /media/automounted$i; i=$((i+1)); done".
<Laibsch> then the question is what populates $new_devices
<Laibsch> I have to admit I simply don't know enough of what's going on under the hood.  That's why I'm here to ask.
<Faux> The fact that those devices just appeared on the system? I don't think this is the appropriate place to discuss it, nor do I know anything about udisks2.
<Laibsch> a 10-device btrfs is still just a single FS and should be mounted only once
<Faux> I have a multi-device btrfs here and mount using /etc/fstab and it works fine. :)
<Laibsch> In the past I've experienced it that one additional mount was added every hour or so.  You appear awfully non-chalant about this.  I can tell you it's highly annoying.
<Laibsch> Yes, multi-FS btrfs in /etc/fstab are excluded from the problem
<Laibsch> But then again, they do not show up in nautilus, etc. as automounts anyhow.
<Faux> I don't mean to be rude, but this is almost certainly the wrong place, and I'm the wrong person.
<Laibsch> OK
<Laibsch> What is a better place?
<Laibsch> I've already asked ubuntu+1.  And posed this question several times over the last few years.
<Laibsch> somebody must know HOW automounting happens
<Laibsch> that's all I'm trying to understand
<xnox> Laibsch, it's just a property of btrfs, that all btrfs drives are added together to the total pool, no?
<xnox> Laibsch, as in you cannot connected two sets of drives, with distict / disjoint btrfs pools and operate them separately.
<Laibsch> not sure I get your question right, but other FS are also affected
<Faux> xnox: No, you can have many btrfs filesystems made from many different partitions in a machine; it's not systemwide like that.
<xnox> Laibsch, i don't see how any other FS is also affected. the bug is very btrfs specific, as far as I can tell.
<xnox> or, the fact that generic functionality, doesn't work as expected with a special-case of advanced btrfs features.
<Laibsch> I have to concede that in the bug tracker there is no mention of other FS, it's just something I seem to recall, but I've seen this for years now so I might be wrong
<xnox> we used to have bugs with lvm snapshots being shown in nautilus over and over and over again, which was a bit ugly. that was fixed. but again, was specific to lvm features in that case.
<Laibsch> what's a good place to discuss this?
<bdmurray> xnox: Have you seen bug 1765724?
<ubottu> bug 1765724 in cryptsetup (Ubuntu) "Xenial -> Bionic - System fails to boot after upgrade - <email address hidden> fails to start" [Critical,New] https://launchpad.net/bugs/1765724
<xnox> bdmurray, lovely
<xnox> bdmurray, will debug
<bdmurray> xnox: thanks!
<ahasenack> hi, has anybody seen debhelper (or one of its tools) do this to a manpage:
<ahasenack> ./usr/share/man/man3/pmem_deep_drain.3.gz.gz -> pmem_flush.3.gz
<ahasenack> pmem_deep_drain.3 contains just a .so reference, so dh_installman correctly creates a symlink
<ahasenack> but the package in the end is getting this double .gz :/
<sarnold> .gz.gz ?
<ahasenack> yeah
<ahasenack> I used dh_installman -v
<ahasenack> and it showed this:
<ahasenack>         rm -f debian/libpmem-dev/usr/share/man/man3/pmem_deep_drain.3.gz
<ahasenack>         ln -s pmem_flush.3 debian/libpmem-dev/usr/share/man/man3/pmem_deep_drain.3.gz
<ahasenack> so up to that point it all seems correct
<ahasenack> I also added -v to dh_install, and it all looks fine
<ahasenack> but after the build, debian/*/usr/share/man/man3 has the double gz
<ahasenack> I'm now adding find -type l to some build stages in d/rules via overrides to try to catch it
<cjwatson> what does the .so line say?
<cjwatson> ahasenack: ^-
<ahasenack> checking
<ahasenack> cjwatson:
<ahasenack> $ cat doc/generated/pmem_deep_drain.3
<ahasenack> .so pmem_flush.3
<cjwatson> huh, I was at least half-expecting to see an extra .gz extension on the .so line there, but that seems correct.  in that case I have no immediate explanation, sounds like a debhelper bug then
<ahasenack> ok, thanks anyway
 * ahasenack intercepts dh_compress
<cjwatson> ahasenack: just export DH_VERBOSE=1 for the whole build, no point messing around with individual commands
<ahasenack> I also injected a find -type l before and after
<ahasenack> ok, getting close
<ahasenack> so, I was following the "life" of pmemlog_create.3*
<ahasenack> the .gz.gz happens in dh_compress
<ahasenack> https://pastebin.ubuntu.com/p/TmyKycSkGK/ (search for pmemlog_create to follow)
<ahasenack> er, pmemlog_close
<ahasenack> not create
<ahasenack> http://people.ubuntu.com/~ahasenack/build-log is the whole build log (2.6Mb)
<jbicha> ahasenack: I can't see the source but I suspect the upstream build system is compressing the manpages and Debian doesn't expect that
<ahasenack> jbicha: yep, upstream's Makefile is definitely compressing them
<jbicha> you can use override_dh_compress but I suggest also filing a bug against debhelper to tell it not to compress a file if it's already compressed!
<ahasenack> this is surprisingly annoying
<ahasenack> dh_compress is not just about manpages
#ubuntu-devel 2018-04-21
<LocutusOfBorg> intilinux :)
<infinity> roaksoax: Uploading NEW source packages less than a week before release?  Convince me to care about candid.
#ubuntu-devel 2018-04-22
<tsimonq2> In case nobody saw it yet: https://lists.ubuntu.com/archives/ubuntu-release/2018-April/004438.html
<Guest31513> I'm downloading the image now to give it a try. Would like to investigate the hyper-v enhanced session functionality
<Laibsch> Can I still make an upload to a package with a targetted bugfix backported from upstream to a package in universe, a package I maintain in Debian where I have upload rights?  I have upload rights as PPU.  Should I target bionic or bionic-proposed?
<Laibsch> I did read https://wiki.ubuntu.com/FinalFreeze and it is not entirely clear to me what I should do now.
<Laibsch> I am trying to fix bug 1345605
<ubottu> bug 1345605 in fslint (Ubuntu) "error when searching bad symlinks" [Medium,In progress] https://launchpad.net/bugs/1345605
<Laibsch> BTW, the topic of the channel needs an update, doesn't it?
* tsimonq2 changed the topic of #ubuntu-devel to: Archive: Final Freeze | 18.04 final beta released | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Artful | #ubuntu-app-devel for app development on Ubuntu
* tsimonq2 changed the topic of #ubuntu-devel to: Archive: Final Freeze | 18.04 Final Beta released | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Artful | #ubuntu-app-devel for app development on Ubuntu
* tsimonq2 changed the topic of #ubuntu-devel to: Archive: Final Freeze | 18.04 Final Beta released | Devel of Ubuntu (not support or app devel) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Artful | #ubuntu-app-devel for app development on Ubuntu
<tsimonq2> There.
<Laibsch> tsimonq2: Hi! In case you responded to me, I missed everything except the "There" due to internet outage.
<tsimonq2> I didn't.
<tsimonq2> :)
<Laibsch> good, so I assume you just wanted to announce that you're back.
<Laibsch> Welcome back!
<Laibsch> I had posted a question that I will then assume that you missed and that I believe you might be able to answer.
<tsimonq2> Ah, looking.
<Laibsch> Can I still make an upload to a package with a targetted bugfix backported from upstream to a package in universe, a package I maintain in Debian where I have upload rights?  I have upload rights as PPU.  Should I target bionic or bionic-proposed?
<Laibsch> I did read https://wiki.ubuntu.com/FinalFreeze and it is not entirely clear to me what I should do now. I am trying to fix bug 1345605. BTW, the topic of the channel needs an update, doesn't it?
<ubottu> bug 1345605 in fslint (Ubuntu) "error when searching bad symlinks" [High,In progress] https://launchpad.net/bugs/1345605
<tsimonq2> Is it seeded? (hint: run `seeded-in-ubuntu $package`)
<Laibsch> Oh, I see you just did the update of the channel tagline.
<tsimonq2> Yep. :)
<Laibsch> I doubt it would be seeded, it is in universe
<Laibsch> let me check
<Laibsch> indeed, it is NOT seeded, so I can make the upload?
<tsimonq2> Yep, if it isn't seeded, Feature Freeze applies.
<tsimonq2> (Which is less strict.)
<Laibsch> Yes, this only fixes a broken but current feature.
<tsimonq2> OK.
<tsimonq2> So, go ahead. :)
<Laibsch> Thanks
<Laibsch> Much appreciated
<tsimonq2> No problem.
<tsimonq2> And as to which you should target, target bionic.
<Laibsch> good
<tsimonq2> The only time you include a pocket in the changelog is for -backports or -security.
<tsimonq2> It doesn't /hurt/ to target -proposed but it's just a tad bit weird. :)
<Laibsch> well, the wiki says a bit otherwise.  apparently, you're supposed to target -proposed for main now
<Laibsch> https://wiki.ubuntu.com/FinalFreeze
<tsimonq2> That hasn't been edited since 2012.
<Laibsch> Well, maybe it hasn't changed since then
<tsimonq2> Notably, before we implemented https://wiki.ubuntu.com/ProposedMigration
<Laibsch> I wouldn't know the processes well enough
<tsimonq2> I know for a fact it has changed. ;)
<Laibsch> good
<Laibsch> I'm happy I can rely on your knowledge
<tsimonq2> Believe me when I say I've had to cut it close with some uploads. :P
<Laibsch> One more question, am I correct to assume that binaries are thrown away after upload?
<Laibsch> I'm used to Debian where I used to upload and then sync
<tsimonq2> You can only do source-only uploads to Ubuntu.
<tsimonq2> So syncs throw away binaries.
<Laibsch> But what happens if you do include debs in your changes file and upload?
<Laibsch> things break or the binaries simply get thrown away and rebuilt?
<tsimonq2> The upload will get rejected.
<Laibsch> OK
<tsimonq2> cjwatson might have more specifics; I'm only an Ubuntu developer and don't have upload access to Debian (yet). :)
<darkxst> tsimonq2, hi
<tsimonq2> darkxst: Hello, how are you?
<darkxst> I am good
<tsimonq2> Good to hear, what's up?
<darkxst> tsimonq2, just wondering if grasp the value in archive freezes, doesnt seem you do from your reply
<tsimonq2> I do understand the importance of them, but I disagree that they're still needed.
<tsimonq2> If flavors can just upload whatever they want and respin, you won't ever get a release, because flavors can just keep respinning.
<tsimonq2> Why even turn off the dailies? :)
<tsimonq2> The archive freezes are to create a stable image, true, but the day after, the fixes people have been holding off on get uploaded.
<tsimonq2> Thus, a stale image over that weekend.
<darkxst> well flavours could just choose to leave the dailies on if they want
<darkxst> but really having a semi-frozen archive where the flavours choose what to upload but universe etc is blocked out in general would allow you to make the most of your QA week
<valorie> darkxst: can you say more about what you value in the freezes?
<valorie> because I've not heard the release team argue for keeping them
<tsimonq2> darkxst: So, an inverted freeze?
<tsimonq2> That's an interesting idea.
<darkxst> valorie, I am not release team, I was Ubuntu GNOME tech lead
<valorie> that blocks the release team
<valorie> yes, read your email just now
 * valorie is the kub release manager and not so techy
<tsimonq2> darkxst: Thinking about it though, the inverted freeze would just create a headache for non-flavor Ubuntu developers.
<tsimonq2> The goal here is to not require any intervention from ~ubuntu-release.
<valorie> I get why we need deadlines for new features, string freezes, etc.
<darkxst> valorie, assuming its on a similar schedule to previous milestones is that a problem
<valorie> that's obvious
<valorie> right, but I fail to see the value in freezing
<tsimonq2> Me too.
<valorie> if you are testing and finding bugs, then the devels are fixing the bugs
<valorie> then you can test those fixes right away
<valorie> not wait until freeze is over
<darkxst> valorie, if you don't freeze, other bugs may well creep in
<valorie> but I want to hear the argument for what freezes bring
<valorie> such as?
<tsimonq2> Right, but that's where testing comes in.
<darkxst> valorie, you have a moving target, who knows what will change
<valorie> well
<tsimonq2> darkxst: But that's the development release...
<valorie> you are testing AN iso
<darkxst> freezes give a point in time image, testers identify issues, the dev's can focus on fixing those issues
<valorie> that's one moment in time
<tsimonq2> Right.
<valorie> for this RC somehow kub. managed to test all the test cases
<valorie> so respinning tomorrow would be cool
<darkxst> the point the milestones become stale is after the release, not when they are released
<valorie> because we could at least partially re-test
<tsimonq2> And often times, people report bugs after the release.
<tsimonq2> With the release ISO.
<tsimonq2> And they don't update.
<tsimonq2> That's a problem.
<tsimonq2> Much less so once you've entered a point where the archive is more stable.
<darkxst> tsimonq2, even if you don't release milestone images, I think there is value in freezeing for your QA week (well days really)
<valorie> I'm waiting to hear the advantages
<valorie> can you give an example?
<darkxst> valorie, I can;t give a real example, because its never been done before (unfrozen test weeks)
<valorie> I meant a case where freezing was a benefit
<valorie> all the people who test the dailies don't have freezes
<valorie> although I don't have many DO that
<valorie> I mean, I don't know how many do that
<darkxst> and how much QA is done on the dailies?
<alkisg> Freeze is a good signal for "everyone, please test now". I develop some packages and I want to test them 1-2 times for the new LTS Ubuntu version, but I can't test on a daily basis.
<tsimonq2> alkisg: But is that a technical argument or a social one?
<valorie> we do have a few people who test a daily maybe one a week
<tsimonq2> The point of this is to not have the technical downsides while keeping the social benefits.
<valorie> or when a devel asks
<valorie> because they did a fix on the installer for instance
<alkisg> I don't think it matter how I would categorize it; that's how much time I'm able to spend in helping/testing the newer Ubuntu; it's up to the release team to somehow tell me when they want me to do those tests
<valorie> or something else easier to test on an ISO than in a ppa
<valorie> alkisg: I think part of the point of this is to take that pressure off the release team, and have us flavors helping one another out
<tsimonq2> alkisg: Exactly. And if the Release Team said "test at this time" but didn't actually freeze anything, would that change things?
<valorie> all getting together to do testing weeks
<tsimonq2> valorie: Exactly.
<alkisg> tsimonq2: a new package upload might break other packages, making my tests useless
<alkisg> So it would make sense for me to test at a point when the new uploads were minimal
<alkisg> Now, minimal or frozen, no, it's not a big deal, but they should be minimal
<valorie> I'm still not seeing your point
<valorie> does it matter when this new package upload is made, if it is going to break your stuff?
<valorie> I mean if you test before and everything's cool
<valorie> and then the upload is made later, your stuff is broken.....
<darkxst> valorie, often things break on upload, only to be fixed a few days later
<darkxst> not you just wasted time debugging that breakage
<darkxst> s/not/now/g
<valorie> right, and that's why we shouldn't freeze!
<valorie> lol
<darkxst> which would have been fixed anyway
<darkxst> rather than focusing on your flavours QA
<alkisg> valorie: that's exactly my point, that that new upload that breaks stuff shouldn't be made. That's the point of the freeze, that only minor changes should be made after that, so that the big bulk of tests don't need to be done again
<valorie> well, I think that is the point of doing the new auto-testing *first*
<tsimonq2> alkisg: Only seeded packages for some flavors are frozen.
<valorie> so there are *never* uploads that break stuff
<Laibsch> valorie: that's never going to happen
<alkisg> You can't test how your packages affects other packages with unit testing; they may not even be installed at all when you're testing
<Laibsch> autotests are nice, but "no bugs" is utopia
<tsimonq2> alkisg: I'm not saying we should get rid of the Final Beta freeze. I'm saying we should get rid of the freezes for just some flavors.
<valorie> no, no
<tsimonq2> That's the point here.
<darkxst> valorie, what I was suggesting was more let flavours upload bug fixes as required, but otherwise freeze the archive for the few days
<valorie> software has bugs
<valorie> ah
<valorie> so imo that is probably what flavors would be doing anyway that week, right?
<valorie> testing week is fixing bugs
<alkisg> tsimonq2: I don't mind at all if it's complete freeze or partial freeze or just "advice for fewer uploads"; but as a developer/user that wants to help make things better, I do like having a specific point in time where "my tests have additional value, because from that point on, little changes are going to be made"
<valorie> I dunno if we need a formal freeze
<tsimonq2> alkisg: The Alpha and Beta 1 freezes just aren't that.
<tsimonq2> alkisg: It's putting a name on a daily, really.
<valorie> but I do see a value on Fixing Bugs
<valorie> for a week
<tsimonq2> alkisg: You could grab any ISO from any point in the month and say "I'm going off of this"
<tsimonq2> alkisg: And with those freezes, changes can and will be made in the underlying stack, but just those flavors hold off.
<tsimonq2> alkisg: So this new procedure does just that.
<darkxst> if there is no formal freeze, churn will continue
<tsimonq2> Churn continues regardless.
<valorie> personally I would rather not block the release team
<tsimonq2> People just hold their breaths and then blast it at the archive once the freeze is done.
<tsimonq2> So why even freeze?
<valorie> because it is hell to have major stuff still happening the last week of the cycle
<darkxst> tsimonq2, because it you a specific point to focus on
<darkxst> you can fix the bugs addressed, before more are raised
<valorie> I think we are all stating positions here
<valorie> rather than thinking together
<darkxst> without having to worry about what else churns
<valorie> we all want more quality
<valorie> we all want fewer bugs
<valorie> and we all want the shiny new stuff too
<valorie> so what is the best way to get there?
<valorie> we have only 6 months to make each batch of sausage
 * alkisg sees little value in the non-LTS releases, but that's another story :D
<valorie> really?
<valorie> I do not like to be on stale anything
<tsimonq2> darkxst: The only bugs fixed during that time are release-critical ones. Not just plain old bugfixes. So I still think it's pointless.
<alkisg> Yeah, I would much prefer having only LTS releases, and some method for package maintainers to more easily push new versions of their packages to LTS releases
<valorie> I ran artful from the day the toolchain was uploaded
<valorie> alkisg: that removes the value of LTS
<valorie> imo
<alkisg> I think it adds additional value
<alkisg> I'm hearing a lot of users that would prefer newer versions of *some* packages in LTS releases
<darkxst> tsimonq2, which is way I was saying to relax it a bit
<valorie> well, there is always backports
<valorie> that is what kub provides
<tsimonq2> Regardless of the talk we're having right now, I've received ACKs from everyone with skin in the game. So I think it's worth trying, at least for a cycle. We can tweak it as we go, and as we see how it turns out.
<alkisg> Indeed; but backports aren't used as much as they should...
<valorie> I dunno if our users use them enough, but I often urge them to try them out
<valorie> because if it doesn't work out, ppa-purge is your friend
<alkisg> Backports aren't in ppas
<alkisg> They're in the official archive
<valorie> we test those too
<darkxst> tsimonq2, valorie, I was only only offering my thoughts based on 5 years of releasing Ubuntu GNOME milestones, I have no vested interest in the outcome of these discussion, but if you are all going to be so defensive I will just get on with the others thing I need to get done
<valorie> in Kubuntu, we have a backport PPA
<alkisg> valorie: that's usually a bad idea, mate does that too and I hate it
<valorie> no, I wanted to hear your reasons
<alkisg> It would make a lot more sense to use backports there, rather than a PPA
<valorie> I just didn't hear reasons
<valorie> or examples
<tsimonq2> darkxst: I'm not being defensive, I just see the idea being shot down before there's a chance to try it, that's all.
<tsimonq2> s/being/trying to be/
<valorie> I know that Simon didn't develop the idea alone; he discusses pros and cons with quite a few people (not me) before making the proposal
<valorie> I spoke only after the release team said that they supported it, because to me that is the most important opinion
<darkxst> tsimonq2, shot down by who?
<tsimonq2> darkxst: Maybe I'm using the term liberally, but this discussion is happening as a result of making it official.
<tsimonq2> (It seems like it, anyway.)
<tsimonq2> I gave a good three weeks between the discussion and doing so.
<darkxst> tsimonq2, no this has nothing to do with that, just I didnt get a chance to comment earlier
<valorie> I'm glad to hear differing opinions
<darkxst> again I have no vested interest in the result
<valorie> just wish they had been stated earlier
<valorie> groupthink can be an issue when people don't push back when they have reservations about a new idea
<darkxst> valorie, unfortunately I have full-time job unrelated to ubuntu, which makes me kind of busy
<valorie> yeah
<valorie> anyway, creeping carrot will be a non-LTS
<valorie> so if it doesn't work out well, we have time to revert to milestones and freezes, or modify slightly
<tsimonq2> *Calculating Camel
<tsimonq2> And, right.
<darkxst> freezes are useful even if there is not an official milestone image to come out of it!
<valorie> well, the lack of them might prove you right, darkxst
<Laibsch> What do you guys use to prepare the changes file to upload?  For uploads to Debian (that requires binaries to be included) I used to use pbuilder and now cowbuilder.  But now I need a source-only changes file and haven't quite figured out yet how to do that.
<Laibsch> I only build in a chroot like pbuilder, my main machine has very few if any dev-packages installed.
<Laibsch> answering for myself, looks like it might be as easy as "dpkg-genchanges" even if the manpage says the source needs to have been built which outside of the chroot it hasn't been.
<darkxst> Laibsch, sbuild
<Laibsch> darkxst: thanks, I will look into. Never used it so far and never had to.
<Laibsch> "debuild -S -d" or even simply "dpkg-buildpackage -S -d" (AFAIU, debuild calls dpkg-buildpackage)
<darkxst> Laibsch, see sbuild-launchpad-chroot it produces almost identical environment to the Ubunutu archive and PPA builders
<darkxst> Laibsch, and in chroot, so your not mutating your package sources
<Laibsch> dpkg-buildpackage seems to do it
<darkxst> you can also bootstrap debian into sbuild quite easily
<Laibsch> well, same is true for pbuilder and I'm more familiar with that
<Laibsch> but in the end, I think it seems to be necessary for Debian since you need to actually build the code and ship the binaries, the requirements for Ubuntu infrastructure apparently are already fulfilled by a lower-level tool like dpkg-buildpackage
<darkxst> Laibsch,  are you uploading to ubuntu?
<Laibsch> yes
<darkxst> then use sbuild-launchpad-chroot
<darkxst> to test
<Laibsch> test what?
<cjwatson> debuild -S or any near-enough equivalent is fine, indeed.  Just building a source package doesn't usually need much in the way of build-deps.
<darkxst> package builds, before uploading
<Laibsch> thanks for confirming, cjwatson
<Laibsch> darkxst: I already built and started the package
<cjwatson> And indeed, tsimonq2 is correct, if you attempt to include .debs with an upload it will be summarily rejected.
<Laibsch> cjwatson: I tried ;-)
<Laibsch> or actually, what I tried was to fiddle with the changes file, remove the lines for the binary files so they would not be uploaded but it was still rejected (I assume because the changes file name had "amd64" in it, indicating an arch-dependent build)
<cjwatson> Editing .changes manually is fiddly.  Not recommended.
<Laibsch> I know
<cjwatson> And for Debian nowadays you should really do source-only uploads too, except in unusual circumstances.
<Laibsch> First attempt
<Laibsch> really?
<Laibsch> didn't know
<cjwatson> Really.
<Laibsch> Well, no more uploads to debian for me anyhow.
<tsimonq2> cjwatson: When can we have source-only NEW in Debian? :P
 * tsimonq2 wishes for that.
<Laibsch> looks like the upload was successful and accepted
<cjwatson> tsimonq2: Do I look like a Debian ftpmaster?
<acheronuk> kirkland: byobu no longer shows a ubuntu logo in bionic?
<tsimonq2> cjwatson: I was joking there. :P
<tsimonq2> Right, time for bed.
<Laibsch> tsimonq2: are you in Hawaii or something?
<tsimonq2> No, Wisconsin.
<Laibsch> ouch
<Laibsch> interesting time to go to sleep ;-)
<Laibsch> happy Zzz
<realies> the novnc package is missing its launch script, any clues why?
<realies> https://github.com/novnc/noVNC/blob/master/utils/launch.sh
<realies> ^
<realies> also is very old, the newer releases have great improvements
<ken2812221> load C:\Users\User\AppData\Roaming\HexChat\addons\google_translator.py
<ken2812221> sorry
<ginggs> file not found
<valorie> the /topic is weeks out of date!
<cjwatson> In what way?
#ubuntu-devel 2019-04-15
<AnAnt> hello
<AnAnt> test
<AnAnt> bye
<dosaboy> sil2100: hi, is there any way you could review the neutron upload in https://launchpad.net/ubuntu/cosmic/+queue?queue_state=1
<dosaboy> im keen to get the regressed prior sru all sorted with the new patch
<dosaboy> sahid: ^^
<sil2100> dosaboy: o/ on a sprint here, but I think I can do that today no problem
<dosaboy> sil2100: many thanks
<sahid> dosaboy: i don't have the privilege :)
<dosaboy> sahid: i know, was just adding you for awareness ;)
<sahid> ok cool thanks :)
<xnox> zyga, should python-guacamole be removed from debian/ubuntu? it seems to have only been used by checkbox&friends.
<zyga> yes
<xnox> zyga, is it "stable" and used from the archive?
<zyga> please
<xnox> zyga, ack.
<zyga> I don't think it got picked up by anything, I'm no longer interested in it
<cyphermox> tsimonq2: packageset> sure; but I'd be careful with that part; there are a few reasons why golang was showing up there.
<tsimonq2> cyphermox: More than just ubuntu-report?
<cyphermox> IIRC yes
<cyphermox> or was it for ubuntu-mate?
<cyphermox> anyway, I'll update and see
<cyphermox> that said, I don't think you should compromise on things you want to include on the image because some other bits are showing up in the packageset list
<cyphermox> (assuming you care about ubuntu-report)
<teward> does anyone knokw if there's a way to have an at-boot SystemD unit that can be interrupted with a specific keypress?
<teward> asking because of something that was asked of me from the Lubuntu guys
<cjwatson> Maybe something involving plymouth watch-keystroke?
<cjwatson> Will likely involve some assembly
<bdmurray> infinity, vorlon: I forget where does sarnold's bug belong? bug 1824597
<ubottu> bug 1824597 in Ubuntu "unrelated information in our Releases files?" [Undecided,New] https://launchpad.net/bugs/1824597
<infinity> bdmurray: It's a non-bug.
<bdmurray> infinity: but is there a project for archive type issues?
<infinity> launchpad?
<cjwatson> I agree that's a non-bug, and it would be Launchpad yes.
<cjwatson> I'll reassign and close
<cjwatson> (maybe should've been wontfix, but either way)
<cyphermox> Laney: need help with casper?
<Laney> cyphermox: definitely
<Laney> I got distracted but also I don't have much clue anyway
<cyphermox> ok
<cyphermox> I'm not sure I'll have much more of a clue, but willing to have a look
<Laney> what's a good way to be able to do stuff in that environment?
<Laney> like why does plymouth show the completed message but not the in-progress ones? it is a mystery to me
<Laney> but I don't know how to poke at stuff in there either so it's hard to get started
<cyphermox> yeah
<tsimonq2> cyphermox: ubuntu-report> We have no userspace tool that uses it, and I'm not sure why I seeded it in the first place.
<cyphermox> tsimonq2: *shrugs*
<tsimonq2> cjwatson: involving some assembly> Sounds fun. Is there anything particularly notable about implementing such a program, or do I just dig in Plymouth libraries? Our goal here (at least, a tentative idea for what we'd like to see) is here: https://phab.lubuntu.me/T32
<tsimonq2> tl;dr every time someone comes to #lubuntu with failed installation problems, we usually ask them to verify the checksum of their media, and that's the problem a lot of the time. Therefore, making it automatic where verification is done on boot (and can be exited via the Esc key) would theoretically reduce installation problems.
<tsimonq2> Fedora already implements this; I haven't actually looked at how they implement it, but it seems possible if you don't think it's an insane idea.
<tsimonq2> (Of course, this is something to look at post-release, and Lubuntu would drive development/testing of it, but if it would be cool if it could be more generally used.)
<sil2100> mvo: hmmm, looking at the snapd SRU humm
<mvo> sil2100: you don't like it?
<sil2100> mvo: strangely, the xenial snapd package FTBFS on powerpc (re-run didn't help, let me look at the build-log)
<sil2100> mvo: we probably wouldn't care normally, but we did build for that arch previously
<mvo> sil2100: yeah, its a sad story, there is no go-1.10 for powerpc
<mvo> sil2100: I talked to vorlon about this too, the agreement was that powerpc for snaps was always not really supproted, we don't have a powerpc core snap for example. so we ignore the powerpc failure
<mvo> sil2100: its unfortunate, I wish I could keep it alive
<sil2100> mvo: ah, now I actually see that we indeed don't have it for that arch, ok
<mvo> sil2100: sorry for the confusion
<pedahzur> rbasak: You around? I finally have some time to work on the SRU for https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1821242
<ubottu> Launchpad bug 1821242 in adcli (Ubuntu Bionic) "adcli delete dies with free(): invalid pointer" [High,Triaged]
<infinity> mvo: I think from the POV of making migration tools less grumpy (but also a bit of a best practice for making packages clearly "unsupported") you should produce empty packages on powerpc.
<rbasak> pedahzur: what do you need?
<infinity> Althought, vorlon seems to have made britney happy somehow.
<infinity> "happy"
<mvo> infinity: indeed, I can do that
<infinity> Ahh, fuaxpackages.
<infinity> faux.
<infinity> mvo: Yeah, I think empty packages would be better than the FauxPackages entry in britney.
<infinity> mvo: But certainly can wait for the next release.
<mvo> infinity: yeah, thanks for the suggestions, thats totally reasonable
<pedahzur> We had talked the other day about walking through the SRU process for that bug. It's all new to me. I've never submitted a deb-diff, etc.  If there are docs I've missed, feel free to point me in that direction. :)
<tsimonq2> pedahzur: The (lowercase c) canonical docs for SRUs are here: https://wiki.ubuntu.com/StableReleaseUpdates
<xnox> slashd, jamespage - what am i missing about https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1822872 ? =)
<ubottu> Launchpad bug 1822872 in ceph (Ubuntu Bionic) "Bionic: Luminous radosgw incompatible with libssl1.1" [Medium,Confirmed]
<xnox> slashd, jamespage - libssl/libcrypto 1.0 and 1.1 are coinstallable and both are support in bionic, in main from now and until forever.
<xnox> so what's broken?
<pedahzur> tsimonq2: Thanks I have read through that. Most of it makes sense. Creating the deb diff is something I've never done. Is there a HOWTO for that?
<xnox> slashd, jamespage - sound slike load_dll should be dll opening libcrypto.so.1.0 if that's what it expects?
<xnox> slashd, jamespage - imho we should builddepend on libssl1.0 and set CIVETWEB_SSL_SSL_LIB and CIVETWEB_SSL_CRYPTO_LIB to versioned sonames of libssl.so.1.0 and libcrypto.so.1.0
<tsimonq2> pedahzur: I don't think so; the manpage should have details, but the short of it is, you have the dsc and associated files for the package in the archive, and after you run debuild with your changes and new version, have another set of files. You just run debdiff EXISTING.dsc NEW.dsc - that's the gist of it.
<jamespage> xnox, slashd: tbh I think that's fine
<jamespage> I'm easy either way - slashd are you ok to SRU that?
<slashd> jamespage, yeah I can SRU the libssl-dev downgrade to 1.0
<xnox> jamespage, well reading the code, it sounds slightly harder. cause WITH_RADOSGW tries to build with SSL_INCLUDE_DIR
<jamespage> slashd: great
<slashd> jamespage xnox thanks
<xnox> slashd, if it works. cause it does look that radosgw, rgw, civetweb all need to use libssl1.0-dev then.
<xnox> slashd, ah, and that's all that does ssl there, so it's fine.
<cjwatson> tsimonq2: I dunno, sorry, just wanted to give an initial pointer
<slashd> xnox, jamespage : what about this https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1794589 do you think it might be a problem ?
<ubottu> Launchpad bug 1794589 in nodejs (Ubuntu Bionic) "libssl1.0-dev conflicts libssl-dev" [Undecided,Confirmed]
<xnox> slashd, that's intentional yes. won't fix.
<slashd> ok
<xnox> slashd, and we reverted and forced to use libssl1.0-dev with nodejs 8 in bionic
<xnox> slashd, and one should use libssl-dev (aka 1.1) with nodejs in disco.
<slashd> xnox, ok
<xnox> vorlon, infinity ^^^^
<slashd> xnox, no regression came up of nodejs ?
<pedahzur> tsimonq2: OK. I'll see what I can figure out. Thanks!
<xnox> slashd, everywhere, including upstream uses 1.0 for 8.x series, and 1.1 for 11.x series (or whatever the new lts series is)
<vorlon> yeah, I had already wontfixed that bug and someone reopened it for bogus reasons and I didn't bother fighting it
<vorlon> the only regression is that the set of packages whose build-dependencies are coinstallable is reduced
<tsimonq2> pedahzur: No problem! Let me know if you have any other questions :)
<vorlon> seb128: have I filed LP: #1824855 in the right place?
<ubottu> Launchpad bug 1824855 in gdm3 (Ubuntu) "very long delay to display login prompt if there are a large number of uncleared desktop notifications" [Undecided,New] https://launchpad.net/bugs/1824855
<seb128> vorlon, hey, good enough, it's more likely to be gnome-shell which does the rendering but I guess Daniel will reassign tomorrow when he does his daily triaging round ... do you have an idea of the number of notifications you had? were they mostly from the same source? (jouirnal log might be useful maybe also) (why diddn't apport attach it?)
<vorlon> seb128: journal> no idea, maybe it would've attached something different if I'd filed it against gnome-shell instead?  number of notifications> well my desktop is configured to produce a notification for every single IRC highlight, so I guess several
<vorlon> seb128: 141 of those since my last reobot
<vorlon> reboot
<vorlon> seb128: hi, another fun bug: LP: #1824874
<ubottu> Launchpad bug 1824874 in policykit-1 (Ubuntu) "undismissable, unclickable authentication dialog left on screen after policykit authentication" [High,New] https://launchpad.net/bugs/1824874
<seb128> vorlon, screenshot/screencast done from your phone could be useful, looks like probably a shell issue (journal log could be useful as well)
<vorlon> seb128: screenshot attached
<vorlon> what exactly do you want out of the journal?
<seb128> vorlon, I couldn't reproduce the notification issue, I tried with a for loop with notify-send -u critical (so they show on the lock screen) and some hundred notifications, the unlock prompt displays like in a second on a slow inspiron 11 machine
<seb128> vorlon, gnome-shell potential warnings
<vorlon> seb128: ok I'll wait and see if I can reproduce the lock screen issue again
<DurkeyWorm> is there any documentation on how the iso files are generated?
<DurkeyWorm> the ones for public release?
#ubuntu-devel 2019-04-16
<rlaager> I'm just popping in to point out that packages.ubuntu.com is broken again.
<Unit193> \o/
<Unit193> rlaager: Broken in what way?
<rlaager> Unit193: Apparently only some queries break it. Sorry. Everything I had tried was broken. Here's an example: https://packages.ubuntu.com/search?keywords=pidgin
<rlaager> I'm getting an Internal Server Error on most searches.
<wxl> rlaager: probably best to report that to #canonical-sysadmin
<Laney> cyphermox: can you explain how you managed to get to be able to debug that casper thing?
<mwhudson> any idea what i've done here?
<mwhudson> mwhudson@ringil:~/isos$ zsync http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/disco-live-server-amd64.iso.zsync
<mwhudson> cdimage.ubuntu.com: No such file or directory
<mwhudson> failed on url http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/disco-live-server-amd64.iso.zsync
<mwhudson> could not read control file from URL http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/disco-live-server-amd64.iso.zsync
<cjwatson> nc
<cjwatson> oops
<cjwatson> that zsync command line works for me
<cjwatson> (on bionic anyway)
<cjwatson> maybe it has some kind of fallback on a connection failure?  I'd probably try strace
<ricotz> juliank, hi, are you aware of this problem? -- "Can't stat /usr/local/*: No such file or directory at /usr/share/perl5/Dpkg/Vendor/Debian.pm line 469."
<juliank> ricotz: no, but well, do you have no /usr/local?
<ricotz> juliank, I don't have those folders, but I guess this scripts seems trying to use it without care?
<juliank> ricotz: well, they are mandatory
<ricotz> this is output on every dpkg-buildpackage
<ricotz> oh they are?
<juliank> well, base-files creates them on install
<ricotz> hmm, I see
<juliank> so apt install --reinstall base-files
<juliank> and they should be there again
<Faux> (It's not in base-files.)
<Faux> At least, not as a listed file, maybe a script?
<mwhudson> cjwatson: i'd broken my network
<ricotz> yeah, "dpkg -S /usr/local/" doesn't match anything
<mwhudson> cjwatson: the error message was, uh, not clear
<mwhudson> (not entirely sure how the messages made it to the channel ...)
<Faux> debian/postinst.in:  install_local_dir /usr/local
<ricotz> ah thank youÂ°
<ricotz> how can I trigger this script in a safe way?
<seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html hasn't been updated for a day, unsure who to report that to?
<cyphermox> Laney: looking at it for many hours, some use of break=casper-bottom to have a quick look at the messages as they speed to the console, lots of swearing and a bit of luck, tbh
<Laney> /o\
<cyphermox> I thought I had seen ever so slightly more messages printed when using tty1 vs. tty8
<cyphermox> so; essentially I used break=casper-bottom, edited the 01integrity_check script to change the tty, check that out more
<cyphermox> I also noticed the script couldn't possibly really be checking for integrity; so it took a few hours to figure out the %as vs %ms thing
<Laney> right, I'd have recognised that one if we got far enough
<Laney> $di_component_what_i_fixed had that bug so I was aware of it
<cyphermox> ok
<Laney> anyway, well done
<cyphermox> thanks
<cyphermox> but yeah, I wasn't aware, seeing 'a' looked reasonable enough for auto-allocation
<Laney> glibc 2.29 done broke that
<Laney> might be a good idea to scan the archive for this ...
<cyphermox> true
<infinity> juliank: Yo.
<infinity> juliank: Laney tells me that you can tell me where my nss-mdns test (triggered by base-files) went.
<infinity> juliank: Nevermind. :P
<cyphermox> rbasak: when non-VCS uploads happen what I would typically do is get the diff from LP and apply the patch
<cyphermox> then commit / tag
<cyphermox> perhaps just making this automated / less error-prone would be good? one thing to watch out for is not forgetting to add any new files
<rbasak> cyphermox: yeah that works. You could now cherry-pick from git-ubuntu which might be easier.
<cyphermox> especially when you need to apply more than one such diff
<cyphermox> ah, true
<rbasak> git-ubuntu does have some "rich history preservation" though that I'm looking to improve.
<rbasak> I think it may be possible for a team to stay in sync with git-ubuntu using that.
<tsimonq2> Unit193: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927231
<ubottu> Debian bug 927231 in pastebinit "ITS: pastebinit -- command-line pastebin client" [Important,Open]
<tsimonq2> I can add you as a co-maintainer if you would like.
<rcj> bdmurray: Can you take a look at bug #1824227 for promotion to -updates today?
<ubottu> bug 1824227 in console-setup (Ubuntu Cosmic) "console-setup failure due to race with systemd-tmpfiles" [High,Fix committed] https://launchpad.net/bugs/1824227
<bdmurray> rcj: Generally we let SRU's age for 7 days and this is at 5. Is there a reason it should be released early?
<rcj> bdmurray: we're seeing a high rate of failures on xenial at least in a cloud.  I've verified each of the releases and I was hoping to avoid the release day business when it would turn 7 days old.
<rcj> s/business/busyness/g
<bdmurray> rcj: Okay, looking at the patch again its pretty small / reasonable so okay.
<bdmurray> okay!
<rcj> Thanks for reviewing it.
<bdmurray> cpaelzer: with bug 1817665 to be clear libsodium and python-libnacl should not be released yet correct?
<ubottu> bug 1817665 in pymacaroons (Ubuntu Trusty) "Please SRU the pymacaroons stack to Trusty" [Undecided,Incomplete] https://launchpad.net/bugs/1817665
<rbasak> bdmurray: cpaelzer will be EOD now but that's my understanding. It's awaiting the consumer package to be SRU'd.
<cpaelzer> bdmurray: the three packages are all three ready, but yet miss the dependency that needs them
<cpaelzer> so they are held back for now
<cpaelzer> bdmurray: for the time being they are all ready to be released but meant to held back (all three of them)
<bdmurray> cpaelzer: if all are meant to held back then the tasks could reflect that by being incomplete, as it is they show up as "ready" in the SRU report
<bdmurray> they being 2 of the 3
<cpaelzer> IIRC sil2100 set one of them to incomplete after the same discussion
<cpaelzer> I'm fine setting all three to incomplete for the same reason if that makes more sense
<cpaelzer> bdmurray: murry should I change the task states?
<cpaelzer> as I'm actually not here, I did the update to be able to leave again
<cpaelzer> I'd also have a comment to state the reason, but LP currently shows timeouts
<bdmurray> cpaelzer: I added a comment, thanks
<DurkeyWorm> quick question
<DurkeyWorm> it seems the d-i preseed/late_command in my preseed files aren't working
<DurkeyWorm> is there something weird about them in the ubuntu version of the installer?
<gQuigs> DurkeyWorm: check the logs to see if it's trying to run at all
<DurkeyWorm> it does seem to try to run, but it also seems to be skipping earlier commands
<DurkeyWorm> weird, seems to be working now
<DurkeyWorm> whatever
<DurkeyWorm> haha
<gQuigs> that works :)
<DurkeyWorm> yep i didn't realize you could only do a single line
#ubuntu-devel 2019-04-17
<seb128> how often are git ubuntu imports done? like casper 1.403 was uploded almost a week ago and https://git.launchpad.net/ubuntu/+source/casper?h=ubuntu%2Fdevel still has 1.402
<seb128> or does that need to be manually updated?
<tarzeau> seb128: there's a freeze?
<tarzeau> seb128: 19.04 to be released shortly. see http://bootes.ethz.ch/bts/
<seb128> tarzeau, that package was accepted, see https://launchpad.net/distros/ubuntu/+source/casper
<cjwatson> That doesn't seem hugely relevant in the case of something that's already in the archive though?
<cjwatson> Snap
<seb128> :)
<tarzeau> ah sorry then i have no idea
<rbasak> seb128: in a loop, but reliability is still a bit limited. Let me check casper.
<seb128> rbasak, thx, is there any log/service where I can check mysefl maybe for next time?
<rbasak> seb128: there's a ML you can subscribe to
<seb128> rbasak, do you have the name on the list? I'm unsure where to look at
<rbasak> Looking for it
<rbasak> seb128: looks like the importer hung a week ago :-/
<rbasak> I have plans to add a watchdog, but de-prioritised that when it seemed more reliable.
<seb128> DOH
<rbasak> I will need to bump the priority of that now
<seb128> k, well I guess it also means you will look at restarting it now
<seb128> thx for poking :)
<rbasak> I'm running casper manually for you now, then I'll restart
<rbasak> cpaelzer, ahasenack: ^ FYI
<rbasak> It had been doing so well!
<seb128> rbasak, thank you!
<rbasak> It seems to be hanging still. I'm investigating.
<rbasak> seb128: this is going to take a while, sorry. The hang is reproducible, and it's during a completely innocuous seeming Launchpad API call.
<cjwatson> Even if the API call times out or something it should, well, time out rather than hang
<cjwatson> Unless it's retrying indefinitely
<rbasak> cjwatson: here's the bottom of the backtrace: https://pastebin.ubuntu.com/p/DkDNbDKN2y/ and call details: https://pastebin.ubuntu.com/p/FzdKNM9bdG/
<rbasak> I've seen hangs before that never time out. I never figured out if I was calling something wrong, so I never raised it with you.
<rbasak> (hard to reproduce etc)
<rbasak> What's odd about this is that we're possibly calling the API repeatedly when we should just cache the result.
<rbasak> And I'm pretty sure it's not the first call with these parametrers that is hanging
<rbasak> I need to run an errand. Back later.
<cjwatson> rbasak: Gotta be a client-side problem, maybe incorrect timeouts being set somewhere or something
<rbasak> cjwatson: can you think of any easy way for me to record all API interactions via launchpadlib, and then replay them from outside my application?
<rbasak> (replay using launchpadlib again, I mean)
<cjwatson> rbasak: I don't have a complete answer, but I'd start with "import httplib2; httplib2.debuglevel = 1" at the top of your program
<rbasak> That's useful. Thanks!
<cjwatson> didrocks: hi - when there's a comment in a file saying "make sure <thing> remains the last entry", would you mind not adding things after it? :-)  https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=4e86b50e3d368718cd8b0afbc0bc041554bd905d
<cjwatson> (fixed now)
<didrocks> cjwatson: ah, as it's not the last line, I missed it, I guess it's not possible to add the comment as the last one?
<didrocks> (thanks for fixing, I guess this created side-effects?)
<cjwatson> The comment could be moved to the end
<cjwatson> I'm not sure that would reliably help people not reading it though :)
<cjwatson> And yes, it broke source image generation for arcane reasons
<didrocks> cjwatson: oh, ok :) TBH, I think comment as last item would have really helped (in my case at least)
<cjwatson> I've moved it to the end
<didrocks> thx!
<cjwatson> thanks for the suggestion
<didrocks> (and sorry to have broken it)
<didrocks> only tested binary iso build, not source one (not even sure how this can be done locally)
<cjwatson> Pretty hard
<cjwatson> A slightly more immediate consequence (on the chain of events) was that https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.disco/desktop-minimal-default-languages+build-depends currently exists instead of https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.disco/supported+build-depends
<jamespage> hey sil2100 - any chance we can get the bionic part of bug 1818614 accepted into proposed?
<ubottu> bug 1818614 in neutron (Ubuntu Cosmic) "[SRU] Various L3HA functional tests fails often" [High,Fix committed] https://launchpad.net/bugs/1818614
 * sil2100 looks
<jamespage> and....
<jamespage> sil2100, bdmurray: any chance we can get the fix for https://bugs.launchpad.net/oslo.cache/+bug/1812935 fastracked to the updates pocket - that's blocking rocky deployments under python 3 right now which is impacting the charm release alongside 19.04
<ubottu> Launchpad bug 1812935 in oslo.cache "oslo cache mempool issues with python3" [High,In progress]
<bdmurray> sil2100: do you want me to look at those?
<jamespage> and then I see verification has not been done for cosmic - sorry - let me do that now....
<sil2100> bdmurray: I'm reviewing the bionic neutron
<sil2100> I mean, I'll finish reviewing it once I find the terminal with it
<sil2100> It's somewhere there...
<Logan> vorlon: I see you going through all of my removal tickets. Appreciate it :)
<vorlon> Logan: managed to get the ~ubuntu-archive subscribed bugs list long enough to go through some of them, yeah ;)
#ubuntu-devel 2019-04-18
<juliank> tsimonq2: Trying to find hmollercl, you sponsored two software-properties uploads for him, and pushed commits to git, but no tags. I can add some myself, but if possible I'd like to get signed tags from the person who uploaded it.
 * juliank just loves signed tags :)
<juliank> Wimpress: Why'd you change ubuntu-mate-welcome in bug 1673258 to "Opinion"? Are you committing to keep maintaining aptdaemon? ;)
<ubottu> bug 1673258 in update-notifier (Ubuntu) "Remove aptdaemon and drop or port its reverse-dependencies" [Undecided,New] https://launchpad.net/bugs/1673258
<juliank> "Opinion" being a nicer word for "Won't fix" and all
<Wimpress> Well, we are currently implementing PackageKit support in the new version.
<juliank> I just don't see how Opinion fits here
<Wimpress>  But vorlon made a comment on that bug last night which suggests we have to choose between two unmaintained options.
<juliank> Well, that's true-ish
<Wimpress> Hence 'Opinion'
<juliank> PackageKit is still better supported than aptdaemon
<juliank> It just does not really get any features :)
<Wimpress> Because I'm not certain which is the right path forward now, even though we're currently working towards PackageKit
<juliank> I think the important point is to get rid of aptdaemon for 20.20
<juliank> Whether we end up with PackageKit + a new apt daemon, or just a new apt daemon is less worrying
<juliank> s/20.20/20.04/
<juliank> I gotta do some more speccing on that and some prototyping
<juliank> Really I think everything except update-manager can be ported to PackageKit to at least reduce aptdaemon impact
<juliank> I don't think the changes are really huge
 * juliank just ported software-properties to it
<juliank> I think the blocker for update-manager is that PackageKit can essentially only install _or_ remove packages, but you can't specify both in one transaction.
<juliank> well, major blocker anyway
<juliank> That said: We use a hybrid approach: Use apt.Cache() to calculate the changes, and then apply them using PackageKit.
<juliank> It's a bit racy
<juliank> But PackageKit's always racy anway
<juliank> ugh, my port is not done
<juliank> I gotta translate from apt package names to packagekit package-ids
<juliank> (which are essentially name;version;arch;repo - I think the flags are optional)
<Wimpress> Thanks for the info. We're planning to land the new version of Software Boutique for 19.10 and the current backends are PackageKit and snapd-glib
<juliank> Huh, I just realized apt.Package.architecture is a function; but it should be a property.
<juliank> ugh.
<tsimonq2> juliank: Join #lubuntu-devel and ping him by typing @HMollerCl (via Telegram)
<tsimonq2> Our channels are bridged.
<juliank> I see
<juliank> how odd
<tsimonq2> heh
* Unit193 changed the topic of #ubuntu-devel to: Archive: FF, DIF | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<Odd_Bloke> I'm updating a package to install its bash completion scripts in to /usr/share instead of /etc.  What is the right way to clean up the old /etc file on upgrade?
<rbasak> Odd_Bloke: rm_conffile? Or are you wondering how to deal with local modifications?
<rbasak> If you're looking for rm_conffile, see dh_installdeb(1) on package.maintscript, and also dpkg-maintscript-helper(1), but I'm not sure if that's what you're asking, or already know that and are asking more specifically about the move.
<Odd_Bloke> rbasak: It's not something I've had to deal with before, so that is what I was asking. :)  Thanks!
<ahasenack> Odd_Bloke: I *think* install the new one in /usr/share, and use rm_conffile on the etc one
<ahasenack> there is mv_conffile,
<ahasenack> but maybe it's just for renaming
<ahasenack> and I'm not sure it supports moving to /usr/share
<ahasenack> but I would look into that too
<Odd_Bloke> My feeling is that rm_conffile is the right move, because it being in /usr/share is pretty much a declaration that we no longer consider bash completions to be conffiles, right?
<ahasenack> right
<ahasenack> also moving it from etc to usr/share, and at the same installing the default one in usr/share, looks weird and prone to failure
<rbasak> Agreed.
<rbasak> The only thing you're losing is that you're not preserving user modifications to the file in /etc, which is normally the intention.
<rbasak> s/intention/expectation/
<Odd_Bloke> And rm_conffile will leave a backup behind in the unlikely event that someone has felt the need to customise their cloud-init bash completions.
<rbasak> Right
<rbasak> IMHO that's sufficient if the package is reorganising like that.
<Odd_Bloke> Cool, thanks again!
<bladernr> was python3-guacamole dropped from Ubuntu for disco, or is it just an oversite that it's missing?
<Odd_Bloke> bladernr: https://irclogs.ubuntu.com/2019/04/15/%23ubuntu-devel.html#t12:42
<bladernr> Odd_Bloke, thanks!  sigh...
<seb128> cyphermox, bug #1825206 claims to be a SRU regression
<ubottu> bug 1825206 in netplan.io (Ubuntu) "No wifi adapter present in Gnome after upgrade to 0.96-0ubuntu0.18.10.2" [Undecided,New] https://launchpad.net/bugs/1825206
<seb128> bdmurray, SRU team, ^
<seb128> also bug #1825402 claims to be an other SRU regression
<ubottu> bug 1825402 in systemd (Ubuntu) "Regression. Recent updates to cosmic broke hybrid-sleep " [Undecided,New] https://launchpad.net/bugs/1825402
<seb128> ddstreet, ^
<seb128> vorlon, ^ unsure if people are still around/if tomorrow is off for them/if we should do something about those SRUs before the long w.e?
<bdmurray> seb128: its not a long weekend for people in the US
<seb128> k, I was unsure
<seb128> bdmurray, thx :)
<vorlon> seb128: looking at it; I am skeptical that this is a regression introduced by the netplan SRU
<vorlon> oh he says he verified by re-downgrading
<vorlon> hmm
<seb128> vorlon, the user said that downgrading fixed it though... but yeah
<cyphermox> it's odd; I certainly don't expect this to be the case, but I'll have a look
<seb128> cyphermox, thx
<seb128> on that note calling it a day here, have a good evening/night :)
<gaughen> cyphermox, create a card please
<gaughen> or i can
<gaughen> (just tell me)
<vorlon> cyphermox: there's enough here that I am going to roll back the SRU while investigation continues
#ubuntu-devel 2019-04-19
<neyder> hi, how to compile kernel with config modifications i run  " fakeroot debian/rules editconfigs" and says: dh: Unknown sequence editconfigs
<plongshot> My:  https://www.skullcandy.com/shop/headphones/bluetooth-headphones/hesh-2   suddenly quit working after4 I updated my computer. I am running ubuntu 18.04. Here is a screenshoit of the settings. The headphone is not showing up in teh settings as it has been up till now.  Screenshot -    https://imgur.com/a/VrRS4bv
<plongshot> Please someone help I can not use my headphonees any loneger
<plongshot> It stopped
<plongshot> It says "piring" audiibly over the headphponbes but it does not show listed in settings and does not connect or work
<sarnold> plongshot: do you have any error messages that look related in your dmesg output? or journalctl?
<plongshot> sarnold: I don't know how to do it to diagnose
<plongshot> It just happenbed
<plongshot> If you tell me where to look ( eg:: /var/log  ?? ) whatev
<sarnold> plongshot: run "dmesg" and look near the end ..
<plongshot> idk
<plongshot> sarnold: I'm on it...
<sarnold> plongshot: okay.. you could install the pastebinit package, then run "dmesg | pastebinit", and copy-paste the link in here
<plongshot> sarnold: Idk what that all means - it looks like gibberish to me but here is a link: http://paste.ubuntu.com/p/RdSzwFrHGN/
<plongshot> thx
<sarnold> plongshot: alright... there's an answer here that looks worth trying: https://askubuntu.com/a/1128904/33812
<sarnold> plongshot: try running those three commands given in the box.
<sarnold> plongshot: if it's unrelated then it shouldn't make things worse; and if it is related, then we'll have a good idea what to do next
<plongshot> sarnold: yes
<plongshot> And I have time to stick it out
<plongshot> ty
<plongshot> sarnold: Idk what this means but the op's opening styatement is " I had the same problem after upgrading the system. I found following error in /var/log/dpkg.log  "  so I ran "ls -al /var/log/dpkg.log | grep status"   and got a new command line (ie: no result).
<plongshot> I guess I donb't have thet output into my log?
<sarnold> plongshot: start with sudo apt-get install --reinstall pulseaudio-module-bluetooth
<plongshot> yes
<plongshot> ty
<plongshot> sorry I missed that
<sarnold> (the ls -al just does a directory listing, it doesn't actually open the log file)
<plongshot> sarnold: I'm a bit newb. I didn't relaize it  :)
<plongshot> There was no change after issuing the command sudo apt-get install --reinstall pulseaudio-module-bluetooth
<plongshot> Should I need to restart?
<plongshot> I have also been rebooting the headphone (so to say)
<sarnold> plongshot: alright, now run the next line, pulseaudio -k
<sarnold> plongshot: and then the last one: sudo alsa force-reload
<plongshot> sarn
<sarnold> plongshot: yeah?
<sarnold> any luck?
<plongshot> sarnold: sorry - have run all 3 commands and no change (can porvide additional screnshot if needed). When I shut off the hedphone with it's power button and then turn back on I hear it audibly say "pairing" but the indicator light on the power button flasheds rad/ blue (indicating a problem).. The device shows up as "connected" in settings but when I click the item and then click "sound settings" the device does not show up
<plongshot> listed. Only the internal speakers show up now but no longer the headphones.
<plongshot> the headphones were working fine until I ran sudo apt updat && sudo apt upgrade (aprox an hour ago now?)
<plongshot> I have an IBM Thinkpad T420 is about 5 yrs old I guess
<plongshot> Ubuntu 18.04 via a command line "upgrade" from 16.04 about a month ago
<sarnold> plongshot: okay... what's the output of journalctl -S today | wc -l
<plongshot> sarnold:   will get
<plongshot> sarnold:
<plongshot> $ journalctl -S today | wc -l
<plongshot> 20899
<sarnold> ohhhhhhmy
<plongshot> huh?
<plongshot> :p
<plongshot> I know I know, but I appreciate you... :)
<sarnold> well, I checked on my server first sine that was the easiest shell I had, there were only 1400 lines...
<plongshot> omg!
<sarnold> but turns out my desktop has 54000 lines, so maybe 21000 isn't too bad :)
<plongshot> Well I guess I go without for now. It's ok becuse between the two I choose ubuntu. But I gonna have to get a new set of headphones if this doesn't work and I bought these onlly one day og now
<plongshot> Barnd new hesh 2 wirless (bad a$$ headphones!)
<sarnold> plongshot: how about journalctl -S today | grep blue ?
<plongshot> yes - one mmt
<plongshot> sarnold: with the word "blue" in them?
<plongshot> the command
<sarnold> yeah
<plongshot> ok
<sarnold> a lot of the bluetooth tools are known as 'bluez', and hopefully error messages from anything else would have "bluetooth" somewhere in them..
<plongshot> sarnold: Should be here:  http://paste.ubuntu.com/p/Md5p3mBs2n/
<plongshot> I'm trying to look
<plongshot> sarnold: I can see the problem output there at the end. It saying the headphone tries to connect but is deneid access or somethign like that.
<sarnold> plongshot: how about the output of systemctl status bluetooth.service   ?
<plongshot> sarnold: I am back - I had a family issue arise
<plongshot> ok
<plongshot> will run and return
<plongshot> I hope it all copied...
<plongshot> $ systemctl status bluetooth.service
<plongshot> â bluetooth.service - Bluetooth service
<plongshot>    Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
<plongshot>    Active: active (running) since Thu 2019-04-18 19:38:59 PDT; 1h 2min ago
<plongshot>      Docs: man:bluetoothd(8)
<plongshot>  Main PID: 971 (bluetoothd)
<plongshot>    Status: "Running"
<plongshot>     Tasks: 1 (limit: 4915)
<plongshot>    CGroup: /system.slice/bluetooth.service
<plongshot>            ââ971 /usr/lib/bluetooth/bluetoothd
<plongshot> Apr 18 20:12:53 countingdaisies bluetoothd[971]: Endpoint registered: sender=:1.129 path=/MediaEndpoi
<plongshot> Apr 18 20:13:46 countingdaisies bluetoothd[971]: Authentication attempt without agent
<plongshot> Apr 18 20:13:46 countingdaisies bluetoothd[971]: Headset Voice gateway rejected D0:8A:22:AC:D5:8A: or
<plongshot> Apr 18 20:13:46 countingdaisies bluetoothd[971]: Authentication attempt without agent
<plongshot> Apr 18 20:13:46 countingdaisies bluetoothd[971]: Access denied: org.bluez.Error.Rejected
<plongshot> Apr 18 20:39:35 countingdaisies bluetoothd[971]: Endpoint unregistered: sender=:1.129 path=/MediaEndp
<plongshot> Apr 18 20:39:35 countingdaisies bluetoothd[971]: Endpoint unregistered: sender=:1.129 path=/MediaEndp
<plongshot> Apr 18 20:39:35 countingdaisies bluetoothd[971]: LEAdvertisingManager skipped, LE unavailable
<plongshot> Apr 18 20:39:35 countingdaisies bluetoothd[971]: Endpoint registered: sender=:1.129 path=/MediaEndpoi
<plongshot> Apr 18 20:39:35 countingdaisies bluetoothd[971]: Endpoint registered: sender=:1.129 path=/MediaEndpoi
<plongshot> lines 1-20/20 (END)
<sarnold> hehe, a pastebin would have been better :)
<plongshot> But also the headphones themselves time out and shut down
<plongshot> Idk if that effects anything
<plongshot> To look and make sure if they on or off ??
<sarnold> plongshot: I'm out of ideas.
<sarnold> plongshot: if it doesn't work on the other side of a reboot, please run "ubuntu-bug bluez" and fill out a bug report
<plongshot> sarnold: They were working before the update
<sarnold> plongshot: .. hmm. no. run that *before* doing the reboot.
<plongshot> sarnold: run ubuntu bug blues where?
<plongshot> In my browser? On the command line?
<sarnold> plongshot: command line
<sarnold> plongshot: it'll do some stuff then open a browser window to launchpad..
<plongshot> thanks for you help
<sarnold> I just wish we'd figured this one out first
<sarnold> I don't like not solving problems
<sarnold> but it's time for me to take off
<plongshot> sarnold: I will tell you the truth. I am not that technical. I run what you tell me to run and I report the rusults. idk how much help I can be.
<plongshot> sarnold: I am a hobby programmer. I love programming bc it challenges me like that.  :>
<sarnold> plongshot: well, a bug report is already pretty good. the tools collect some data for the bug report, mostly just a  statement like "this worked until I ran apt update && apt upgrade"
<sarnold> plongshot: excellent :)
<plongshot> np
<plongshot> I do it
<plongshot> I hope I can use my headphonese soon
<plongshot> sarnold: I am going to reboot my computer an return. I think (intuitively) that is smart. It will log me off her but I''ll come back
<plongshot> ty
<plongshot> sarnold: Thank you so much for you help. The headphones are working perfefctly after a rebboot
<plongshot> God bless you sir
<sarnold> plongshot: I'm glad they're working, but it's so frustrating to not know why :)
<sarnold> plongshot: thanksf or reporting back :)
<sarnold> plongshot: have a good day or night :)
<plongshot> I have my family calling I have to go but I really appreciate you help isr ty'
<tsimonq2> Unit193 (cc rbasak, who filed the bug): SRU bug for pastebinit is in bug 1812232.
<ubottu> bug 1812232 in pastebinit (Ubuntu Eoan) "Deprecation warnings" [Medium,In progress] https://launchpad.net/bugs/1812232
<tsimonq2> I think it's annoying enough to SRU.
#ubuntu-devel 2019-04-20
<Unit193> It's most certainly annoying enough to fix one way or another! :)
<tsimonq2> hah :)
<sarnold> back to python 2 everyone!
<sarnold> this silly warning was the last straw
<tsimonq2> hahahahaha
<Unit193> sarnold: I think it's the 124M bot or 119M daemon that do it for me. :(
<Unit193> A bot shouldn't be using 12% of system ram. :(
<sarnold> Unit193: oww
<Unit193> I'm a little worried when deluge converts to py3, how much is that going to take. :3
<infinity> Unit193: python has never been known for its efficient RAM usage, especially for long-running processes, but if you've noticed something getting drastically worse between 2.7 and 3.x, Ubuntu, Debian, and/or Python upstream might not mind a bug with some investigation.
<infinity> While some in-memory structures may have grown here and there (for, say, better charset handling), I'd expect things to be about the same, ish, unless you're tripping on a memory leak or really, really lazy garbage collection.
<infinity> Unit193: Unless you're just talking about the size of the interpreter itself, not how much it uses beyond initial binary/library mapping.  That might be something we can't do much about.
<infinity> Unit193: But at least you can relax a little knowing that most of those python (and library) copies in RAM are all pointing at the same location in memory, rather than 32 copies? :P
<infinity> Well, the libraries would be.  Maybe not the python binary itself.  But it's not huge in comparison.
<Unit193> Heh, yeah I'm trying to move everything over to py3 anyway, but several of the daemons are just memory intensive.  I'm pretty sure it's due to lack of code optimization on the specific things (fail2ban and irker are *very* small, still.)
<Unit193> infinity: As far as bug reports, both things are mostly unmaintained, so I'm out of luck there.  Thanks for considering it though!
<infinity> Unit193: I didn't mean bug reports on the applications, I meant on python itself, if you're finding that converting simple daemons leads to awful results.
<infinity> fail2ban is a perfect example.  While maybe they could pack their data better or something, there's really not much it juggles in memory to start with, so if a naive conversion is making its usage explode, that seems suboptimal.
<infinity> (Though, I think a fail2ban rewrite in a compiled language is long overdue, personally)
<Unit193> Nah, it's a 2K line daemon with a lot of baggage.
<infinity> Maybe a good "My first Rust/Go/C/C++/whatever project" for someone.
<Unit193> Yes, I'd agree there..
<Unit193> Though rusty things are somewhat annoying to package..
<tsimonq2> Unit193: Pun intended, I hope. :P
<sarnold> oh man. a rust rewrite of fail2ban would be nice.
<infinity> Rust and Go can get nasty if you involve half the ecosystem.
<infinity> fail2ban is so simple that you could probably write it with nothing but a stdlib dependency.
<tsimonq2> "involve half the ecosystem" did someone say node.js? http://devhumor.com/media/node-modules-1
<Unit193> What mostly annoys me about golang is that libs don't have releases, and they have breaking changes between git commits such that the applications which *do* have releases depend on a specific commit. >_<
<infinity> Unit193: The golang/github development workflow is actively hostile to people who like stable interfaces, yes.  I've never been a fan.
<infinity> I mean, fine, "kids these days" have to re-learn lessons of the previous generation the hard way, but they seem to be taking their sweet time with it.
<Unit193> infinity: Given that ISOs can seed whole stacks of software in squashfs (snaps) and that packages use xz by default, is there really any reason for debhelper to have the delta to exclude upstream changelogs at this point?
<infinity> Unit193: Excluding upstream changelogs isn't about compressed package size, it's about pointless junk on the installed system.
<infinity> Unit193: Same reason we trim everything but the first 10 Debian changelog entries.
<Unit193> I wouldn't say they're pointless, but alright.  I got the impression it was somehow from back when people were trying to keep it CD sized.
<adrian15> Can anyone with Secure Boot enabled run: "mokutil --sb-state" and share with me its output ?
<tsimonq2> slashd: Hi, did you plan on taking another look at bug 1803385? I'm going through the sponsoring queue and saw it was last updated in November.
<ubottu> bug 1803385 in debian-installer-utils (Ubuntu Cosmic) "fetch-url does not use --no-check-certificate on HTTP to HTTPS redirects" [Medium,In progress] https://launchpad.net/bugs/1803385
<tsimonq2> slashd: I'm not entirely comfortable touching the debian-installer stack, otherwise I would look myself.
<tsimonq2> Laney: Hi, did you plan on sponsoring bug 1763520 to Bionic and Cosmic as well, or did you want to roll it in with some other fixes?
<ubottu> bug 1763520 in gtk+3.0 (Ubuntu Cosmic) "after upgrade to bionic, printing fails without explanation / logs / debuggability" [High,In progress] https://launchpad.net/bugs/1763520
<tsimonq2> juliank: Hi, did you plan on sponsoring bug 1762572?
<ubottu> bug 1762572 in dput (Ubuntu) "sftp method no longer uses temporary file name during upload" [Low,Triaged] https://launchpad.net/bugs/1762572
<alkisg> Hi guys, I'm at a loss concerning LP bug 1811496. I proposed a bug fix, ahasenack seemed interested, then the chat with vorlon  there got sidetracked to UEFI secure boot, and finally tsimonq2 just now unsubscribed the Sponsors team as there are no debdiffs.
<alkisg> The bug is still there, and my fix fixes it. My question is, should I provide a debdiff, or will the effort be in vain for some reason I didn't understand?
<ubottu> Launchpad bug 1811496 in ipxe (Ubuntu) "Make grub-ipxe work under UEFI" [Medium,New] https://launchpad.net/bugs/1811496
<tsimonq2> Hi alkisg! Looking again.
<alkisg> Thank you tsimonq2
<alkisg> The short story is that under uefi, the grub-ipxe package tries to load ipxe.lkrn whichis a linux16 binary, so the PC fails to boot with an error; and a small shell script change makes it load the correct ipxe.efi instead
<tsimonq2> alkisg: I was looking at this purely from the perspective of the Ubuntu Sponsors Team; there is no debdiff to sponsor, and thus, the Ubuntu Sponsors Team shouldn't be subscribed (it shouldn't be in our queue). If you attach another debdiff, the Ubuntu Sponsors Team can take a look. That being said, I was not personally working on this, and I would like another look from vorlon before sponsoring
<tsimonq2> (unless he would like to do it).
<tsimonq2> s/ another//
<tsimonq2> (You get my point :) )
<alkisg> tsimonq2: I understand; and AFAIK vorlon doesn't object for the patch and leaves it up to the maintainer, which I believe is ahasenack,
<alkisg> so my question was mostly directed to him; ...well, unless it's possible for debdiffs to get approved otherwise... dunno
<alkisg> This package is ubuntu-only, not in debian, so I'm not sure of the correct procedure...
<tsimonq2> alkisg: I have the technical ability to sponsor your debdiff as an Ubuntu Core Developer, but if you already are discussing it with other Ubuntu Developers, I don't want to step in and sponsor something first.
<alkisg> I'm not
<tsimonq2> Right, so I defer to ahasenack.
<alkisg> I think that everyone agrees that the fix is fine, but noone is interested in pushing it
<alkisg> ahasenack hasn't provided any input in the last months...
<tsimonq2> As for the actual fix, you're looking at a use case for UEFI-without-secureboot only, correct?
<alkisg> Right
<alkisg> (hmmm apt changelog doesn't show ahasenack; I'm not sure if he's involved directly in that package)
<tsimonq2> Okay, so to be clear, is this change needed in the configuration for GRUB, or in ipxe itself? The bug is against ipxe but the description only mentions GRUB configuration files.
<alkisg> tsimonq2: the change is in the grub-ipxe binary package, which is build from the ipxe source package; so only ipxe is involved
<alkisg> ipxe does ship an /etc/grub.d/ script, but the grub source package isn't involved in the fix
<tsimonq2> The package is in Main, and the Ubuntu Server Team is responsible for it. He wears a hat there, so that's where he fits. Steve is a member of Foundations, which is responsible for GRUB.
<tsimonq2> Oh, that makes sense, okay.
<alkisg> But grub isn't involved...
<tsimonq2> I am simply stating the rationale on the bug report for him being involved in the first place. :)
<alkisg> OK
<tsimonq2> Anyway, please attach a debdiff to the bug report.
<alkisg> Thank you; will do it on Monday morning from work
<tsimonq2> Thanks!
<alkisg> I also add a small "feature" there; I'm not looking for any SRUs/backports, hope that's ok to go in a singe debdiff
<alkisg> The feature is that in the BIOS case, ipxe supports loading an ipxe script as initrd; it's just one line
<tsimonq2> Yeah, sure. As long as you have a rationale on the bug report/in the patch description/in the changelog, and that rationale can be understood, if it's just going to the development release (which should open Soon), I don't see a problem with it.
<alkisg> Great
<alkisg> Thanks again!
<tsimonq2> No problem. :)
 * tsimonq2 finds some lunch before working on the sponsorship queue some more...
<tsimonq2> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: FF, DIF | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots: tsimonq2
<tsimonq2> There we go.
<juliank> tsimonq2: yes, but it seems I frogot ,will add it to my list
<tsimonq2> juliank: Thanks!
<tsimonq2> sarnold: Hi, did you plan on following up on bug 1821811?
<ubottu> bug 1821811 in flatpak (Ubuntu Cosmic) "New upstream microrelease flatpak 1.0.8" [Low,New] https://launchpad.net/bugs/1821811
<Unit193> tsimonq2: Since you seem to be patch pilot, you should merge debhelper. :>
<tsimonq2> Unit193: I wanted to get all the way to the bottom of the sponsors queue first. ;)
<tsimonq2> But, sure.
<tsimonq2> I also have yet to file a bug against debootstrap in Debian for my earlier upload.
<tsimonq2> TIL Japan is starting a new era... https://japan.kantei.go.jp/98_abe/statement/201904/_00001.html
<tsimonq2> Unit193: Is debhelper the only one you see? :P
<Unit193> Pardon?
<tsimonq2> The only package you'd like merged.
<tsimonq2> gusnan: Hi, thanks for the quick turnaround on bug 1804865! I'll go ahead and sponsor it, but could you please add a [Regression Potential] section in the bug report description?
<ubottu> bug 1804865 in scite (Ubuntu Bionic) "Lua dynamic libraries isn't enabled" [Low,New] https://launchpad.net/bugs/1804865
<Unit193> I don't think there's anything else in Main, nope.
<tsimonq2> Cool.
<Unit193> (gandi-cli requires 12.1, I merged it in a PPA for a disco build then backported it as well.)
<tsimonq2> Ahh, got it.
<tsimonq2> Yeah, probably a good idea before Adam flicks on the autosyncer. :P
<tsimonq2> Unit193: I want to send an email to ubuntu-devel first detailing where we're at with the sponsorship queue.
<Unit193> OK?
<tsimonq2> Meaning, it'll be a bit. :P
<Unit193> https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/10042159/+listing-archive-extra fwiw.
<tsimonq2> Alright.
<tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel/2019-April/040665.html
<tsimonq2> Looking at devscripts now,
<tsimonq2> s/,/./
<tsimonq2> Er, debhelper.
<Unit193> I'm going to presume there's no progress on backports?  I have a dh 12 ready for that too.
<tsimonq2> Not that I know of. :(
<Unit193> I guess that's what PPAs are for.
<tsimonq2> heh
<tsimonq2> Unit193: debhelper> .
<tsimonq2> https://salsa.debian.org/installer-team/debootstrap/merge_requests/29
<tsimonq2> And with that...
<tsimonq2> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: FF, DIF | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<tsimonq2> Off to get some fresh air or something.
#ubuntu-devel 2019-04-21
<tsimonq2> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: FF, DIF | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots: tsimonq2
<tsimonq2> Some more items came into the sponsoring queue overnight, I'll be patch pilot for a bit again today. :P
 * tsimonq2 slides a beer to whoever is doing SRU reviews the next few days ;)
<tsimonq2> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: FF, DIF | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
#ubuntu-devel 2020-04-13
<themill> cjwatson: it is indeed the backports for launchpad that I was thinking about there ;)
<cjwatson> themill: In that case 2.7/3.5 are our current minima
<themill> and it sounds like 2.7 is needed for the time being there too
<themill> I assume launchpad hasn't rewritten itself in python 3 yet ;)
<cjwatson> themill: Yeah.  I mean if you were to ditch 2.7 I'd understand and you wouldn't be the first, but it would probably entail some more transitional work on our end
<cjwatson> themill: As I say, we're working on it but it's a fairly giant job
<cjwatson> You would probably not be amazed by how many yaks can show up to suddenly need shaving when you're trying to port a million-line codebase
<themill> :)
<themill> Are there new things that you'd like to have appear in python-debian at this stage for the migration, or is sticking with what you've got for the time being reasonable?
<cjwatson> We have no immediate needs there that I know of
<themill> I suspect that I'm going to struggle to run the test suite against python2.7 reasonably soon and so even if we don't start ripping out the "if six.PY2" code, we'll end up accidentally breaking things soon enough
<themill> There presumably is a way of running things in gitlab-ci against two different docker images, but I'm yet to find it
<cjwatson> (I made a bit more progress on the port this weekend.  A particular pile of test failures turn out to be fixed in zope.security 5.1.0.  Upgrading Zope dependencies is usually best done by upgrading to new commits from github:zopefoundation/zopetoolkit, since that way at least the whole set has been tested together.  So I try that, and so far I've had to fix failures due to zope.interface now ...
<cjwatson> ... disallowing assignment to __module__ on interfaces, a semantic change somewhere in transaction affecting after-commit hooks, and there's some other weird problem that may require finishing the work to move away from system-site-packages.  This is not an atypical experience.)
<cjwatson> Right, if you drop it and we turn out to need some new feature then we'll probably just have to backport it for now.
<cjwatson> I don't think that'll be a huge deal.
<themill> I'm keen to make it easy for you to contribute things though, particularly since as you port and refactor you'll probably spot things :)
<cjwatson> I think python-debian is probably one of the least of my worries TBH - we might indeed spot the odd thing, but Launchpad's use of it isn't all that exotic really.
<cjwatson> Most of the problems there are likely to be just tedious bytes/text stuff on our end.
<themill> yes, I know the dance
<themill> I have a local branch in which I've sprinkled a lot more type annotations through python-debian and that has helped shake out some byte/str mistakes
<cjwatson> I don't currently recall how many python-debian-related tests manage to run in https://git.launchpad.net/~cjwatson/launchpad/log/?h=py3
<themill> I was looking at some other polyglot code bases recently and contemplating that the next thing to do is to migrate from six to Python 3 code... ;(
<cjwatson> Anyway.  Hopefully a fair bit more progress over the next few months, now that we're over the "make it possible to start up the test suite at all" hump.
<cjwatson> (To get that far you need most of the codebase and more significantly most of your dependencies to be at least minimally syntactically compatible, which is more effort than you might think in a big codebase.)
<jphilips> hi all. a tester tried to install gtk-recordmydesktop, but it is set as a conflict to recordmydesktop, likely as python-gtk2 isnt in the repo. is there any intention to resolve this issue for 20.04 so there is a GUI version of the app.
<jphilips> https://bugs.launchpad.net/ubuntu/+source/gtk-recordmydesktop/+bug/1872406
<ubottu> Launchpad bug 1872406 in gtk-recordmydesktop (Ubuntu) "package not available in 20.04" [Undecided,New]
<kryten> https://launchpad.net/ubuntu/+source/gtk-recordmydesktop/+publishinghistory - as per here, deleted from Focal because of Debian #943983.
<ubottu> Debian bug 943983 in ftp.debian.org "RM: gtk-recordmydesktop -- RoQA; dead upstream, unmaintained, depends on legacy libs" [Normal,Open] http://bugs.debian.org/943983
<jphilips> thanks kryten
<frechdachs69> is the 20.04 netboot installation going to support the new autoinstall mechanism, too?
<AsciiWolf> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1872434 - looks like one bad looking gnome-shell regression made it into Focal :/
<ubottu> Launchpad bug 1872434 in gnome-shell (Ubuntu) "Utilities folder labeled as "X-GNOME-Utilities.directory" on Ubuntu 20.04" [Undecided,New]
<AsciiWolf> kenvandine, hi, I have tried the new snapd build (2.44.3+20.04) that is in proposed, but classic Ubuntu packages still do not show in Snap Store, only snaps
<AsciiWolf> kenvandine, see: https://imgur.com/5hibN56
<AsciiWolf> kenvandine, (I have latest Snap Store from latest/stable/ubuntu-20.04)
<kanashiro> thanks Unit193
<kenvandine> AsciiWolf: what does "snap version" say?
<ahasenack> tjaalton: hi, I'm trying to come up with a test case for apache tlsv1.3 POST pha with tls1.3 (so many acronyms!): https://pastebin.ubuntu.com/p/hVZJQMZ7PW/
<ahasenack> tjaalton: I'm not sure I'm triggering all the right bits, as this message isn't logged:
<ahasenack>                 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(10228)
<ahasenack>                               "could not buffer message body to allow "
<ahasenack>                               "TLS Post-Handshake Authentication to proceed");
<ahasenack> I thought I could be needing a bigger body to post, but I tried with an attachment of 10Mb and surprisingly it then works even without the patch
<ahasenack> ah,
<ahasenack> ./modules/ssl/ssl_private.h:#define DEFAULT_RENEG_BUFFER_SIZE (128 * 1024)
<ahasenack> still
<frechdachs69> is the 20.04 netboot installation going to support the new autoinstall mechanism, too?
<ahasenack> aha, got it
<santa_> hello everyone
<santa_> rbalint: if I can steal you a few minutes I would like to tell you about an issue with the systemd packaging and virtualbox
<ahasenack> frechdachs69: hi, I think so, did you check https://discourse.ubuntu.com/t/please-test-autoinstalls-for-20-04/15250/1 ?
<ahasenack> "Iâd be especially interested in tests on real hardware (possibly in conjunction with netboot)"
<santa_> rbalint: after this change https://salsa.debian.org/systemd-team/systemd/-/merge_requests/61/diffs?commit_id=d6483013d5779d4d465a1e174e44a754b941d0e6 it's impossible to install virtualbox-guest-utils inside a virtualbox VM, this way it's no longer possible to use some virtualbox features such as shared folders
<santa_> rbalint: so what would be the solution for this. should virtualbox-guest-utils provide the virtual package 'time-daemon'?
<ganso> vorlon: Hello! I've been working on a bug in nfs-utils and found the fix in the code upstream, I'm working on doing a SRU for it right now, but I noticed running "rmadison nfs-utils" that all packages since bionic are using 1.3.4 code base. I saw that debian has this same version pinned so I realized this is likely the reason ubuntu's version is also pinned, but I'm wondering what is the specific reason for debian to not update the version, if any. If
<ganso> there is a special bug, or a major breaking change >1.3.4, etc. Do you know the reason it hasn't been updated past 1.3.4?
<mwhudson> good morning
<ahasenack> ganso: you would have to ask the debian team or maintainer about that
<ahasenack> ganso: what is the latest upstream version? Maybe upstream changed owner, and debian isn't following the new owner?
<ahasenack> I've seen that happen before
<ganso> ahasenack: vorlon is one of the maintainers, src: https://packages.debian.org/source/sid/nfs-utils
<ganso> ahasenack: latest upstream version is 2.4.3
<ahasenack> check if the homepage in d/control points to the same place where you saw this 2.4.3 being available
<cjwatson> ahasenack: This is easily checkable - go to https://tracker.debian.org/pkg/nfs-utils, right at the top it says "A new upstream version is available: 2.4.3", so the metadata clearly points in the right direction
<ahasenack> indeed
<cjwatson> https://bugs.debian.org/917706 and https://bugs.debian.org/952446 already exist
<ubottu> Debian bug 917706 in src:nfs-utils "nfs-utils: New upstream release available" [Wishlist,Open]
<ubottu> Debian bug 952446 in src:nfs-utils "nfs-utils: Please update to latest nfs-utils" [Wishlist,Open]
<cjwatson> (I know nothing about it; I would assume it's difficult for some reason ...)
<ganso> yup, I saw those entries, however there is no response and I am wondering if there is a specific issue that prevents it from being updated
<AsciiWolf> kenvandine, sorry, I was away... the snap version command returns this: https://pastebin.com/gVY4TAJM
<kenvandine> AsciiWolf: can you please pastebin /var/lib/snapd/apparmor/profiles/snap.snap-store.ubuntu-software
<RikMills> LP: #1872551
<ubottu> Launchpad bug 1872551 in software-properties (Ubuntu) "kubuntu-driver-manager: nvidia driver version switch fails" [Undecided,New] https://launchpad.net/bugs/1872551
<RikMills> SoftwarePropertiesQt.py", line 895, in on_driver_changes_apply
<RikMills>     for dep in get_dependencies(self.apt_cache, pkg.shortname, 'nvidia'):
<RikMills> NameError: name 'get_dependencies' is not defined
<RikMills> juliank: that is something in python-apt?
<chiluk> what's the name of the installer that isn't ubiquity (?debian-installer?).. Also is there a way to specify to use debian-installer instead of ubiquity when using the desktop image?  I'm basically needing to do a dual boot 18.04+20.04 with encrypted roots and homes on a smallish drive.  So Im' having to be creative with partitioning and the 18.04 ubiquity leaves a bit to be desired *(20.04 ubiquity is vastly improved)
<sarnold> subiquity?
<sarnold> there is a debian-installer, but I'm not sure if we've made discs with it for 20.04 or not
<RAOF> Is the netinst image still d-i?
<sarnold> oh good question
<chiluk> yeah I'm using the netinst on 18.04, but I thought I remember seeing a kernel command line arg that could be passed to force the desktop image to use d-i
<sarnold> chiluk: there's also using debootstrap to install a skeleton of a system into a directory; you're a long way from a working system with that starting point, but if you've already got 20.04 booting and working okay, it might be tolerable to get the rest of the way
<chiluk> you are a glutton for punishment..
<sarnold> why yes, that is how I installed my current laptop..
<chiluk> I think I'll stick with the netinst if no one knows the correct kernel command-line-fu to launch in text/di mode
<chiluk> this really only applies to 18.04 as 20.04 worked like a champ last I checked.
<chiluk> anyhow thanks folks...
<sarnold> see ya chiluk :)
<chiluk> good to see you too sarnold!
<sarnold> chiluk: yeah, nice to see your name around again :)
<chiluk> I'll put messing with the ubuntu installer encryption options on my "if I ever have time I might want to mess with this list"
<sarnold> heh, my version of that list is sooo long..
<chiluk> tell me bout it.
#ubuntu-devel 2020-04-14
<tjaalton> ahasenack_: hey, I see that you got your review already :) that's cool, thanks for working on it, and the test looks fine to me
<juliank> RikMills: no
<RikMills> juliank: seems to be there. python-apt-1.9.10/apt/package.py: def get_dependencies(self, *types):
<RikMills> or you mean the issue is not there?
<juliank> RikMills: That's a function that'sd being called, not a method
<juliank> It has the same name, but it's a different thing
<juliank> softwareproperties/gtk/SoftwarePropertiesGtk.py
<RikMills> right
<juliank> 100:def get_dependencies(apt_cache, package_name, pattern=None):
<RikMills> where is that?
<juliank> So, the function needs to move into SoftwareProperties class as a method
<juliank> it says right there
<juliank> softwareproperties/gtk/SoftwarePropertiesGtk.py line 100
<juliank> older checkout, though
<juliank> Now it's line 147
<RikMills> so was no done in software-properies-qt by the lubuntu porter of the driver page?
<RikMills> if so, just surprised only getting bugs now
<RikMills> juliank: anyway, thanks. I'll pass that on to the lubuntu guy
<seb128> rbalint, hey, bug #1870930 sounds like a regression/new issue since 245.2-1ubuntu2
<ubottu> bug 1870930 in systemd (Ubuntu) "systemctl crashed with SIGSEGV" [High,New] https://launchpad.net/bugs/1870930
<mantas-baltix> hello all :)
<rbalint> seb128, yes, will check it soon
<seb128> rbalint, thanks
<mantas-baltix> I've updated and fixed lots of snap store translations five days ago, but I don't see new translations in latest snap-store 20200413.ac9047f from latest/beta channel :(
<santa_> rbalint: nvm, vorlon already pointed out the solution for virtualbox-guest-utils installation here: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1872485/comments/2
<ubottu> Launchpad bug 1872485 in systemd (Ubuntu) "virtualbox-guest-utils fails to install on 20.04" [High,Triaged]
<santa_> https://salsa.debian.org/systemd-team/systemd/-/commit/02e27e24e4f84335f360c085d1e8c3f11bd12349
<santa_> â this should work :)
<rbalint> santa_, i'm testing the next systemd upload that has the fix at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3801
<AsciiWolf> kenvandine, are the classic packages showing in Snap Store for you with latest snapd?
<AsciiWolf> I reverted my testing vm snapshot to a beta clean install, fully updated the system (including latest snapd that was previously in proposed), made sure I have latest Snap Store from stable branch and still no luck :/
<santa_> rbalint: thank you very much, I tested with that package and it's possible to install virtualbox-guest-utils + shared folders work
<rbalint> santa_, thanks for testing!
<kenvandine> AsciiWolf: with core from the beta channel it is working for me
<kenvandine> AsciiWolf: can you please pastebin /var/lib/snapd/apparmor/profiles/snap.snap-store.ubuntu-software
<kanashiro> locutus__: I applied the ruby2.7 delta (riscv related) we carry in Debian and also did a minor update in the symbols file: https://tracker.debian.org/news/1118113/accepted-ruby27-270-5-source-into-unstable/
<kanashiro> should we sync this version before the release?
<Laney> mdeslaur: stgraber: vorlon: (TB people): wdyt about creating a 20.04.1 milestone on Launchpad?
<Laney> I'd like us to be able to target bugs to it, to commit to them after the .0 release
<ogra> GRRR ... so the focal installer just trashed my grub on the laptop... when installing from one USB device to another, seems the grub on my nvme disk is now wiped completely and i can only boot from USB stick
<ogra> during partitioning the USB disk was picked as target for both, rootfs and grub installation
<ogra> (which means i wouldnt expect *anything* to touch the installed grub on the nvme disk)
<seb128> ogra, sounds like worth a bug report and maybe a rls-ff-incoming tag
<ogra> okay
<ogra> against ubiquity i guess ?
<Laney> ogra: bug #1847898 ?
<ubottu> bug 1847898 in ubiquity (Ubuntu Focal) "System doesn't boot after installation - Legacy mode / 2 disks" [High,Triaged] https://launchpad.net/bugs/1847898
<ogra> Laney, let me sse (i just filed https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1872736 but will duplicate if needed)
<ubottu> Launchpad bug 1872736 in ubiquity (Ubuntu) "install from USB to USB device wipes grub setup on NVME disk" [Undecided,New]
<ogra> hmm, not sure thats the same
<Laney> it probably is
<Laney> or https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379 which is related
<ubottu> Launchpad bug 1396379 in ubiquity (Ubuntu) "installer uses first EFI system partition found even when directed otherwise" [High,Confirmed]
<ogra> from 2014 ?!?!?!
<ogra> WOW
<ogra> that could be it though
<AsciiWolf> kenvandine, sorry for the late reply, here is the pastebin of snap.snap-store.ubuntu-software apparmor profile: https://pastebin.com/anaNsxEZ
<ogra> not really sure if the EFI partition was mounted from NVME or not during install
<kenvandine> AsciiWolf: should work
<kenvandine> AsciiWolf: /usr/share/metainfo/{,**} r,
<kenvandine> /usr/share/appdata/{,**} r,
<kenvandine> AsciiWolf: kill the current process and run snap-store --verbose
<kenvandine> does the appstream show as disabled?
<AsciiWolf> kenvandine, here is the full verbose log: https://pastebin.com/XLHt4epE
<AsciiWolf> it seems so: "15:20:06:0469 Gs  disabling appstream as setup failed: No AppStream data found"
<AsciiWolf> looks like there is some apparmor issue
<AsciiWolf> I will try downloading the latest nightly focal iso and reinstalling the vm using this iso instead of the beta iso
<kenvandine> AsciiWolf: i'm trying to reproduce it now
<kenvandine> AsciiWolf: my download from friday works
<AsciiWolf> most likely something gone wrong when updating the packages to latest versions... bad thing is that I tried it multiple times and it was the same every time so it is possible that this will happen for every user who installed the official focal beta iso, then upgraded the system instead of installing latest nightly/final focal build :/
<AsciiWolf> kenvandine, try this official beta iso: http://releases.ubuntu.com/20.04/
<kenvandine> AsciiWolf: we'll get it fixed :)
<AsciiWolf> this is what I used
<kenvandine> AsciiWolf: ok, i've reproduced it
<kenvandine> i think it's a mix of my VM had previously had the 3.34 code base installed but now the 3.36 code base is in that channel
<kenvandine> and i think the components cache is already there for me
<kenvandine> but starting fresh with an empty cache isn't working with the 3.36 codebase
<kenvandine> AsciiWolf: i think...
<AsciiWolf> I was also reproducing the issue on an older Snap Store build that was 3.34 based
<kenvandine> AsciiWolf: i think that was the apparmor thing that is now fixed in snapd
<kenvandine> that was affecting both
<kenvandine> but racy
<kenvandine> i'm doing a new build of the 3.34 branch now to verify
<AsciiWolf> hmm, so I have tried the latest daily build iso and have the same issue... but I think I have made one mistake: I have ran Snap Store right after the Ubuntu installation without upgrading the system first...
<AsciiWolf> there were updates for snapd and apparmor, I have installed them, rebooted the system, but Snap Store does not show any classic packages, just snaps... just like on the old vm
<Eickmeyer> I need help. I have a critical bug 1872555 with Ardour (repo at https://code.launchpad.net/~ubuntustudio-dev/+git/ardour). It uses CDBS for its build system. I can't get the patch I made to apply correctly.
<ubottu> bug 1872555 in ardour (Ubuntu) "the included a-* plugins can not load because of the new version of the GNU C Library" [Critical,In progress] https://launchpad.net/bugs/1872555
<Eickmeyer>  It applies correctly using dh_quilt_patch but CDBS doesn't want to apply it correctly.
<Eickmeyer> How can I override CDBS to apply the patch correctly?
<cjwatson> Eickmeyer: Is the bug present in current master of that repository?
<cjwatson> Eickmeyer: I mean, the patching bug
<Eickmeyer> cjwatson: Yes. The plugins build, but will not run with the new libgcc-s1.
<cjwatson> Eickmeyer: Not quite what I mean - I mean, how can I reproduce the CDBS problem you're describing?
<Eickmeyer> cjwatson: The patch I made is a cherry-pick from the Ardour github repo. I could get it to build with launchpad's autobuild, but building locally with debuild -S isn't working.
<Eickmeyer> We were also able to verify the autobuild with the patch worked.
<cjwatson> This repository is super-confusing.  Probably needs to be converted to git-buildpackage or git-dpm's patching system.  Let's see if I can work out exactly how it's out of sync
<cjwatson> Whoa, what on earth is this .orig
<cjwatson> It's a tarbomb!
<cjwatson> Scribbled all over the current directory when I unpacked it rather than unpacking into a single directory
<Eickmeyer> I'm not surprised. Ardour has been around for over a decade. It's our premiere DAW for Studio.
<cjwatson> Eickmeyer: The .orig was apparently built by you though
<Eickmeyer> Oh, it had to be a repack, iirc.
<cjwatson> And tarbombs have been very thoroughly out of style for well over two decades
<Eickmeyer> Had to do the repack because the actual orig contains a binary waf.
<cjwatson> Yeah, but you didn't have to do it like that :)
<Eickmeyer> Terribly sorry.
<Eickmeyer> I'll remember that for next time. :)
<cjwatson> The basic problem here is that the git tree, after "quilt pop -a", doesn't agree with the .orig
<Eickmeyer> So, something got screwed-up in the tree?
<cjwatson> I have no idea how you maintain this tree, but basically
<kenvandine> AsciiWolf: i have a reproducer, debugging
<Eickmeyer> Ok, I'll give that a whirl.
<cjwatson> I see it's imported from Debian, let me see if there's anything suspicious in the delta
<cjwatson> Hm, does look like it's maintained with something automatic
<cjwatson> Hold off a minute while I dig further
<Eickmeyer> Yeah, Debian was too slow to fix it after the gcc/fluidsynth update/Python2 removal.
<Eickmeyer> I had to take matters into my own hands.
<Eickmeyer> But, holding.
<cjwatson> Eickmeyer: So can you explain this repack thing a bit more?  Your orig differs from Debian's but has the same upstream version number, which is very strange
<cjwatson> Eickmeyer: And I don't see a binary waf in Debian's orig
<Eickmeyer> I don't quite remember. I *can* grab Debian's orig, if you think that will help.
<Eickmeyer> I'm pretty sure Debian's is a repack as well. I may have only duplicated the effort.
<Eickmeyer> cjwatson: ^
<cjwatson> I think it may help, given that that's the baseline that the git repository is relative to.  But I'll investigate a bit more first ...
<cjwatson> Eickmeyer: Yeah, the source package builds fine if I move your ardour_5.12.0.orig.tar.gz into a different directory and put Debian's ardour_5.12.0.orig.tar.bz2 there instead.  (The uploader will need to pass the -sa option to debuild -S to force it to include the .orig in the upload.)  Do test-build the actual resulting source package first though, as there were a number of other (hopefully ...
<cjwatson> ... inconsequential) differences between the two orig files.
<Eickmeyer> cjwatson: Ok, I'll give that a shot. One thing:
<Eickmeyer> cjwatson: I'm trying to get the tarball with "pristine-tar checkout ardour_5.12.0.orig.tar.bz2" but it is failing. Am I doing it wrong?
<Eickmeyer> That might be why I did the repack in the first place.
<cjwatson> Eickmeyer: Yeah, pristine-tar does seem to fail to reconstruct the tarball for a reason I can't see, but you can always fetch it directly from the Debian archive.
<Eickmeyer> Ok
<cjwatson> Eickmeyer: e.g. in a temporary directory run "pull-debian-source -d ardour"
<Eickmeyer> Ok, I'll give that a shot.
<cjwatson> With this repository layout, the key is that the orig needs to match the "upstream" branch in git
<Eickmeyer> Ok, I'll recommit the "upstream" branch with that tarball.
<cjwatson> No, don't!
<cjwatson> The upstream branch matches the Debian orig
<Eickmeyer> Er... no.
<cjwatson> So just use the Debian orig :)
<cjwatson> Then the source packaging will match git
<Eickmeyer> Ok.
<Eickmeyer> Waddya know, it worked.
<cjwatson> (It's also slightly more than just committing on top of the upstream branch - for a new upstream release, you'd need to manage it using gbp (a bit like https://wiki.debian.org/Python/GitPackaging#New_upstream_release, only obviously not Python).  But no need for that here AFAICS
<Eickmeyer> teward: We were using the wrong tarball.
<cjwatson> )
<Eickmeyer> You're right, it matched and was happy.
<Eickmeyer> Dunno how my .tar.xz got so screwed-up.
<Eickmeyer> I'll see if I can pristine-tar commit this thing. Should I?
<cjwatson> No
<Eickmeyer> Ok.
<cjwatson> I would leave the pristine-tar branch alone and just ignore it
<Eickmeyer> Ok
<cjwatson> Fortunately since the file names are different you can still upload this without having to change the upstream version number
<cjwatson> .gz vs. .bz2
<cjwatson> Bit of a cheat but it works :)
<Eickmeyer> Yep, but I need teward to upload it first since ERR:NoPackagesetYet (Fix coming Monday).
<Eickmeyer> Unless you have an extra cycle, cjwatson.
<cjwatson> I might do but it would be later this evening
<Eickmeyer> You're... what time zone?
<teward> that's about how soon I could get to it too so :P
<teward> (~4hr+ from now)
<cjwatson> Europe/London
<cjwatson> Laptop's needed now for my daughter's ballet class though
<Eickmeyer> Ok, cool. Just let me know. I'll assign you the bug. :)
<kenvandine> AsciiWolf: ok, i've sort of figured it out.  I found the failure, which is a query of the appstream components cache.
<kenvandine> and i've tested a workaround that fixes it but has an annoying side effect
<kenvandine> AsciiWolf: i'm going to discuss this with robert_ancell when he comes online in a couple of hours to get a proper fix
<AsciiWolf> kenvandine, nice, good work!
<AsciiWolf> thanks
<cjwatson> Eickmeyer,teward: uploaded
<Eickmeyer> cjwatson: Thanks! :)
<vorlon> ganso: my "maintenance" of nfs-utils is largely hypothetical, sorry
<vorlon> Laney, sil2100: do we have a target date for the 20.04.1 milestone?  It's not on https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule
<vorlon> Laney: anyway, https://launchpad.net/ubuntu/+milestone/ubuntu-20.04.1
<ganso> vorlon: hmm is there someone you know that I could ask and would be able to answer my question about nfs-utils version pinning/update ?
<vorlon> ganso: one or more of the other people listed as uploaders of the package ;)
#ubuntu-devel 2020-04-15
<Laney> vorlon: Good point, I'll add it to the agenda for the release sprint
<Laney> had planned to add a GG-cycle discussion there too
<mwhudson> jibel: thanks for reviewing my^WLaney's code :)
<Laney> sil2100: ^- can you share the link to the doc you're prepping so I can add those items please? :-)
 * Laney elbow bumps mwhudson 
<Unit193> Hrm, is there somewhere I can push a package to see how Ubuntu's autopkgtest would handle it?
<Laney> if you can upload: bileto, or you can trigger from a PPA: https://wiki.ubuntu.com/ProposedMigration/#Testing_against_a_PPA
<jibel> mwhudson, np
<Unit193> I'm only MOTU, so the second it is.  Thanks, Laney!
<Laney> Unit193: Test using autopkgtest-buildvm-ubuntu-cloud locally first, though
<Laney> For most cases that's close enough to what you'll get
<Unit193> Laney: This shouldn't be one of those cases, I'm testing a specific quirk of the Ubuntu ADT stuff.  In theory, one should pass and one should gracefully skip.
<Laney> I'm interested what quirks we have there
<rbasak> cpaelzer: so on upgrade from Bionic to Focal, chrony is being removed in favour of systemd-timesyncd?
<rbasak> cpaelzer: ^?
<rbasak> Have I understood the bug correctly?
<cpaelzer> hi rbasak
<cpaelzer> rbasak: what you mention is bug 1872902
<ubottu> bug 1872902 in ubuntu-release-upgrader (Ubuntu) "Upgrade to Focal now removes chrony" [Critical,Confirmed] https://launchpad.net/bugs/1872902
<cpaelzer> which rbasak works on to fix in do-release-upgrader
<cpaelzer> rbasak: if due to that (or any other condition) you have the new sytemd of focal and the old chrony
<cpaelzer> rbasak: and then you remove the old chrony (which also happens on upgrade)
<cpaelzer> then the crash triggers
<rbasak> I think I follow, thanks.
<cpaelzer> because the chrony postrm in bionic isn't tolerant to the case if systemd-timsyncd might be unsinatlled/masked/otherwise not there
<rbasak> So this bug is still valid because if you remove chrony there's no longer any guarantee (and with the Conflicts it's impossible) that systemd-timesyncd will be available
<cpaelzer> we added hardening a while ago but never needed it in bionic
<rbasak> For 1872902, would a Conflicts/Replaces on chrony help?
<cpaelzer> rbasak: for 1872902 no, that is what caused all of this  - it was properly split out of systemd to be a package on its own with proper conflicts/breaks and so on
<cpaelzer> rbasak: the issue is the dependency resolution in d-r-u it seems
<rbasak> "Replaces allows the packaging system to resolve which package should be removed when there is a conflict"
<cpaelzer> a blunt bionic/focal upgrade without do-release-upgrade will not remove it
<cpaelzer> rbasak: this is multi-dimensional with openntp/ntp/chrony/sytemd-timesyncd
<rbasak> OK
<cpaelzer> xnox:  and rbalint work on it and I'll leave it to them to pick their fix for 1872902 in focal
<rbasak> Anyway, let me resolve the current SRU then
<rbasak> Have I broken "git ubuntu clone chrony" in the edge channel?
<cpaelzer> I only fetched in the recent days
<cpaelzer> let me try
<rbasak> Oh
<rbasak> I think I might be running out of my source tree by accident
<cpaelzer> it works for me on edge
<cpaelzer> yep clone complete
<rbasak> Thank you for checking
<rbasak> Yep I've broken it in master I think, not published to edge yet
<rbasak> Accepted, thanks!
<Laney> bdmurray: any chance you could review https://code.launchpad.net/~marcustomlinson/update-manager/update-manager/+merge/382291 for marcustomlinson please? I got a bit close to writing the code for this one so I don't feel like a good reviewer any more. :-)
<cpaelzer> mvo: stgraber: since it now re-occurred I guess I better ask you, is lxd being lockged (all lxd commands hang) until snapd was restarted a known issue
<cpaelzer> I'm seeing this on s390x in 20.04
<cpaelzer> I can't really reproduce, but it is the second time I found the system in that state
<cpaelzer> I'd mostly want to know what to look out for next time I might hit the case
<stgraber> Hmm, not something we've seen reported so far. Having to restart snapd is pretty suspicious though, maybe related to the apparmor profile ordering change that went into snapd recently?
<cpaelzer> any logs in particular that you'd want?
<cpaelzer> last time I saw it maybe 4 weeks ago, so I'd not look for a recent change
<stgraber> 'ps fauxww', 'systemctl -a', 'snap changes' and the journal output would be a good start I think
<bdmurray> Laney: sure, I can have a look at that
<cpaelzer> stgraber: mvo: I filed bug 1873004 for now
<ubottu> bug 1873004 in snapd (Ubuntu) "lxd interaction blocked until snapd was restarted" [Undecided,New] https://launchpad.net/bugs/1873004
<mvo> cpaelzer: if you have the system in this state, does "SNAPD_DEBUG=1 lxc ..." show anything useful? can you attach the output of that as well?
<mvo> cpaelzer: when you saw it last time, was it on s390x as well?
<cpaelzer> mvo: yeah it always was on s390x so far
<cpaelzer> I'll note the extra debug request on the bug for when it hangs agin
<cpaelzer> again
<hallyn> argh.  my ubuntu-core-dev membership expired :(
<hallyn> the reminders were lost in spam
<hallyn> do i have to go through the whole process again ? :(
<hallyn> (i noticed bc people.ubuntu.com/~serge-hallyn seemed to disappear :( )
<Laney> hallyn: email devel-permissions@lists.ubuntu.com and ask to be re-added
<Laney> but if you haven't used your permissions in a while, maybe you want to ask for membership instead of upload access
<hallyn> Laney: yeah, that's probably agood idea.  i wouldn't want to push anything without lots of review these days anyway
<hallyn> thanks
<gQuigs> xnox: did you see this? https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC   I read that as systemd giving up on DNSSEC..
<xnox> gQuigs:  we have extra patches to make downgrade work better.
<xnox> which i think are still not upstreamed
<xnox> it is true the dnssec doesn't work still.
<xnox> we do "maybe"
<xnox> which i think is above DNSSEC=no, but below allow-downgrade.
<xnox> not surprised
<xnox> gQuigs:  i don't know if we need to change any of our defaults. But my guess is that dns-over-tls is taking over, because that works, and dns-sec does not.
<gQuigs> rgr,I don't see as dns-over-tls doing the same thing, but I guess it's something.. thanks
<cpaelzer> rbasak: FYI https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1872183/comments/12 in case you want to tweak the aging period anywhere that is the post to reply to
<ubottu> Launchpad bug 1872183 in chrony (Ubuntu) "package chrony 3.2-4ubuntu4.2 failed to install/upgrade: installed chrony package post-removal script subprocess returned error exit status 1" [Undecided,In progress]
<rbasak> cpaelzer: I commented. I think it's appropriate to release to bionic-updates now, if you're happy?
<rbasak> cpaelzer: do we need the Focal fix to land first for this to be effective? I think not?
<rbasak> ^ I'd appreciate a second opinion on skipping the ageing period for this SRU please, if someone's around.
<cpaelzer> rbasak: the change has no dependency on anything else it has to wait on
<popey> Is there some reason why we point directly to specific mirrors on a default install, and don't use mirrors://mirrors.ubuntu.com/mirrors.txt to load balance things? Is it something we have considered?
<rbasak> cpaelzer: it does look like there are unrelated autopkgtest failure
<rbasak> s
<cpaelzer> rbasak: taking a look
<cpaelzer> I was just working on the related test failures in focal :-) see bug 1873031
<ubottu> bug 1873031 in systemd (Ubuntu) "245.4-2ubuntu1 has broken dhcp based NTP updates" [Undecided,New] https://launchpad.net/bugs/1873031
<cpaelzer> looking at bionic now
<cpaelzer> I know that bug, it seems someone backported some changes to linux headers into bionic
<cpaelzer> rbasak: I can fix it but no more today
<cpaelzer> rbasak: I'll provide a follow on upload to go over the current one once I had the time for it
<cpaelzer> rbasak: I'll let you know tomorrow
<rbasak> cpaelzer: sure, though is it necessary to fix this current bug?
<cpaelzer> no it is unrelated
<rbasak> I'm open to ignoring the test if appropriate
<rbasak> What do you think?
<cpaelzer> I think waiting a day is fine
<rbasak> OK, I'll wait then
<rbasak> Thanks!
<cpaelzer> rbasak:  I added a comment to the bug so that anyone coming by knows
<bdmurray> marcustomlinson: Can you explain a bit what happens in the cache.get_changes() loop?
<bdmurray> re https://code.launchpad.net/~marcustomlinson/update-manager/update-manager/+merge/382291
<bdmurray> or Laney ^^
<marcustomlinson> bdmurray: we're looping through all packages that would be removed as a result of removing the replaced deb. If any of those have been manually installed we abandon the removal
<marcustomlinson> e.g. in the case of snap-store replacing gnome-software. One may install ubuntu-software manually causing gnome-software to be marked auto
<bdmurray> so ubuntu-software depended on gnome-software? I guess that's the part that wasn't clear to me.
<marcustomlinson> bdmurray: yes
<bdmurray> got it, okay I'll merge and upload
<marcustomlinson> we'll run into more of this in the future. e.g. if we decide to replace libreoffice with the snap
<marcustomlinson> we may look at libreoffice-core as the replaced deb
<marcustomlinson> but one can install that via libreoffice, libreoffice-writer, etc.
<marcustomlinson> thanks bdmurray
<bdmurray> coreycb: If bug 1855890 is fixed can you update the status?
<ubottu> bug 1855890 in nova (Ubuntu) "drop netcat dependency" [High,Fix committed] https://launchpad.net/bugs/1855890
<coreycb> bdmurray: done, thanks for the nudge
<hallyn> Laney: hm, i suppose my ubuntu.com account was also tied to ubuntu-core-dev, so i won't get a response :)
<hallyn> i'm so sad
<hallyn> hm, no, that's not how this mail is set up.  oh well
<CarlFK> wifi regression - hp laptop    Realtek  RTL8188EE cosmic is fine.  focal randomly (i guess) 261.278152] wlo1: deauthenticated and [ 2917.206570] rtlwifi: AP off, try to reconnect now
<CarlFK> it just did that a bunch for a min or two, now is stable again.
<CarlFK> what package should I log a bug?   dpkg -S rtl8188ee gives me a bunch of hits
<rbasak> Where's the script that generates https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.yaml? It outputs a !!python/object/apply:collections.defaultdict which is a pain to parse safely. I'd like to switch it for a regular dict.
<jbicha> infinity: mmm, I kinda want debhelper 13 in focal. That way we can build packages that have set debhelper-compat = 13
#ubuntu-devel 2020-04-16
<xnox> Laney: hm somehow $XDG_SESSION_ID is not set for me, yet i thought it should be. Or is my pam_systemd missconfigured?
<xnox> jbicha:  it's not out yet.
<xnox> jbicha:  is it?
<xnox> jbicha:  and debhelper in focal, can do 13 compat level.
<jbicha> you can't currently use focal to build a package that Build-Depends on debhelper-compat (= 13)
<xnox> jbicha:  and one cannot do that in debian either, debhelper-compat (= 13) is not out yet
<jbicha> xnox: it's in unstable now
<xnox> jbicha:  ah, i see.
<xnox> jbicha:  i was looking at tracker, and it's not yet in trackers' unstable minde
<xnox> right only built 6h ago
<xnox> rbasak:  lp:ubuntu-archive-scripts generate-team-p-m i think
<xnox> aka "archive reports repo"
<xnox> and it's bzr one
<mwhudson> rbasak: it's in ubuntu-archive-scripts or ubuntu-archive-tools, i can never remember which is which
<mwhudson> scripts probably
<xnox> jbicha:  uploaded merge, i guess it's up to release team to accept it.
<rbasak> xnox, mwhudson: thanks!
<Unit193> !info debhelper unstable
<ubottu> debhelper (source: debhelper): helper programs for debian/rules. In component main, is optional. Version 12.1.1 (unstable), package size 992 kB, installed size 1609 kB
<xnox> it's built, but not published yet
<Unit193> ...Well looks like ubottu doesn't update for 'unstable'.
<jbicha> xnox: ð
<Laney> xnox: no, it shouldn't be, most things aren't run inside a logind session
<Laney> rbasak: lp:ubuntu-archive-scripts generate-team-p-m
<RikMills> could someone review and perhaps upload? https://code.launchpad.net/~hmollercl/software-properties/+git/software-properties/+merge/382349
<RikMills> I cannot
<RikMills> juliank perhaps, as you pointed the right way the other day?
<juliank> RikMills: This works, but it's not nice
<Laney> mapreri: did you intend to drop all of the ubuntu delta in that inkscape sync?
<Laney> looks to me like it's still wanted ...
<RikMills> juliank: well, it mirrors the implementation in the gtk version, so what can I say?
<juliank> RikMills: Like I wrote in the comment (and on IRC the other day), this should be shared, not duplicated, so I'll just do that now
<RikMills> juliank: sorry. I am effectively being intermediary here, so that message may not have been communicated well
<RikMills> thanks for the help
<RikMills> juliank: you are correct timezone is an issue here, as the author is in the US (AFAIK)
<juliank> RikMills: Anyway, I uploaded a nicer version, it's in unapproved now
<RikMills> juliank: much appreciated! thank you :)
<AsciiWolf> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1639863 - any chance this appstream-generator bug could be fixed? the issue was opened in 2016 and there was no visible progress since... it is blocking Firefox and Thunderbird from showing in GNOME Software / Snap Store
<ubottu> Launchpad bug 1639863 in thunderbird (Ubuntu) "Firefox and Thunderbird don't appear in the (new) appstream metadata" [Undecided,Confirmed]
<sil2100> mvo: hey! I was wondering, how is lp:ddtp-ubuntu updated? Is that automated, or do you press some button manually?
<mapreri> Laney: yes, that was my intention because I thought I had already included the python2 bits.  looks like I forgot, so I'm now uploading a ubuntu1 variant
<mapreri> did you reject it?  no mail reached me, but I can't see it in the queue anymore.
<Laney> think so
<Laney> there's some bugs around mail for rejected syncs
<cpaelzer> rbalint: as I've seen no triage on it yet from the systemd POV I wanted to ping you about https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1873031
<ubottu> Launchpad bug 1873031 in systemd (Ubuntu) "245.4-2ubuntu1 has broken dhcp based NTP updates" [Undecided,New]
<cpaelzer> another one for the context of timesyncd
<mvo> sil2100: I press some button and usually there is a bit of baby-sitting because of LP, let me quickly have a look
<rbalint> cpaelzer, looking right now
<cpaelzer> thank you
<rbalint> cpaelzer, at first glance a reboot fixes it
<sil2100> mvo: thank you :)
<mvo> sil2100: this should probably become a service just like the command-not-found stuff :/
<rbalint> cpaelzer, no, not fully
<cpaelzer> rbalint: as long as the service stays masked this issue will occur
<cpaelzer> that even could have happened before
<cpaelzer> due to intentional config changes
<cpaelzer> but now due to the conflict between packages and conffiles staying behind is more common to happen
<cpaelzer> rbalint: if in the script it would checked to be unmasked and enabled before restarting - that seems like a good fix to me
<rbalint> cpaelzer, yes, but i think even a 2> /dev/null would do it, too, i just want to play with it locally, also to make sure that when systemd drops the old config file and timesyncd does not install the new one it still gets fixed somehow
<rbasak> I need an example of a source package that exists in Debian but has never been published in Ubuntu (so no publication history whatsoever). Any ideas?
<rbasak> Apparently such a thing exists because git-ubuntu has an existing code path for this.
<rbasak> And I want to know I haven't broken it.
<ahasenack> check the sync "blacklist" in lp, if such a thing exists?
<Unit193> Would a new package not in any Ubuntu release count for your test?
<rbasak> Unit193: unfortunately not
<Unit193> Odd.
<rbasak> It's because we walk the publication history itself
<Unit193> rbasak: iceweasel? :P
<rbasak> That looks good. Thanks!
 * rbasak tries
<rbasak> ...and it failed, and I have a bug to fix. Mission successful :)
<rafaeldtinoco> didnt fail.. it just didnt work as planned
<rafaeldtinoco> half of the glass full developing style
<xnox> not a regression, as it has never worked => suitable for release
<xnox> ship it
<rafaeldtinoco> lol
<Odd_Bloke> xnox: Exactly the attitude we want 7 days before release. ;)
<bdmurray> xnox: should bug 1871268 be Fix Released?
<ubottu> bug 1871268 in ubiquity (Ubuntu Focal) "Installation fails with Could not configure 'libc6:i386'. , E:Could not perform immediate configuration on 'libgcc-s1:i386'" [Critical,Confirmed] https://launchpad.net/bugs/1871268
<xnox> bdmurray:  yes that's fixed now with debian-cd
<ladyfriday> I'm running focal, and the update from kernel 5.4.0-21 to 5.4.0-24 broke my ethernet controller (Realtek RTL8111/8168/8411 according to lspci) - is this a known issue? if not, where do I report it?
<ladyfriday> dmesg gives "realtek.ko not loaded, maybe it needs to be added to initramfs?" / "r8169: probe of 0000:03:00.0 failed with error -49"
<ladyfriday> (might not be exact, typed them out since I'm on a different machine so can't copy/paste)
<RikMills> doko: is the upload to make something 'Provides: python' happening?
<doko> RikMills: it's in the archive
<RikMills> doko: ok, so the person here is wasting their time LP: #1873299
<ubottu> Launchpad bug 1873299 in xboxdrv (Ubuntu) "Several packages recommend the "python" package, which doesn't exist in Focal " [Undecided,New] https://launchpad.net/bugs/1873299
<cjwatson> RikMills: It's still good to fix those since those packages probably actually mean python2
<RikMills> point taken
<cjwatson> Tracking bugs like that are deprecated though
<cjwatson> A separate bug per package works better when it's really multiple bugs with similar manifestations/fixes, as opposed to a single bug that needs fixes in several places
<cjwatson> Or tags, as I've suggested in the bug
<doko> RikMills: no, because installing python-is-python2 locks you down on python pointing to python2. we just got rid off the last dependency last week
<RikMills> ah, yes, it installs the symlink as well!
<RikMills> so as you say, not desirable
#ubuntu-devel 2020-04-17
<cpaelzer> jamespage: coreycb: is https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/n/nova/20200417_024435_6868f@/log.gz a known issue?
<cpaelzer> I see that particular fail in four of the last five tests
<cpaelzer> seems unrelated to the particular upload that is tested
<tjaalton> how can I nominate a bug for a series, when the series was previously removed from the bug by clicking the 'minus' icon..
<wgrant> tjaalton: It can be complicated. Which bug?
<tjaalton> 1872569
<tjaalton> tried a few tricks but didn't work :)
<wgrant> I thought I fixed it like a decade ago to remove the nomination when the last corresponding series task is removed, but it's possible I misremembered.
 * wgrant checks the code.
<wgrant>         # When a task is deleted, we also delete it's BugNomination entry
<wgrant>         # if there is one.
<tjaalton> well, in this case I'd add focal but it's still listed for 'linux'
<tjaalton> so should I remove it from there, and then add back?
<wgrant> tjaalton: Oh, this isn't even that
<wgrant> tjaalton: So there's one widget on the bug page that behaves differently based on which target is in the URL: Target to seriess
<wgrant> If you change the URL to say linux-oem-osp1 rather than linux, I think you'll get focal in the targeting page
<wgrant> Or linux-oem-5.6 or whatever
<wgrant> Some target that doesn't currently have a focal task
<tjaalton> nope :/
<wgrant> Huh, you're right. That is interesting.
 * wgrant checks the history.
<wgrant>  bug task deleted linux-oem-osp1 (Ubuntu Focal)
<wgrant> I think that should have triggered that code :/
<wgrant> tjaalton: Ah, so that code did trigger, but there's an additional check that won't let you nominate again if there's an existing series task, which there is... but only on one source package. Easiest thing is to delete the remaining focal task, then renominate and restore the task's state
<jamespage> cpaelzer: I'm going to work on our autopkgtest failures today as coreycb is out for the day
<tjaalton> wgrant: right
<tjaalton> wgrant: yep that worked, and it even remembered the bug assignee when it was added back :)
<wgrant> tjaalton: Hah, I didn't even think of that, but due to the conjoined bugtask rule it will remember its state, yet
<wgrant> yes
<wgrant> (because it's the development series task, its state is synced with the non-series task that is hidden when the series task exists)
<wgrant> series. tasks. are. weird.
<tjaalton> hehe
<cpaelzer> jamespage: it worked on a retry
<cpaelzer> but the history suggests that something is going on ...
<cpaelzer> it wasn't a one off failure
<jamespage> cpaelzer: no - I uploaded a change to fixup the tests
<jamespage> basically we're getting to the point where services won't test OK without the rest of openstack being running as well
<AsciiWolf> jbicha, hi, I have changed the name/description of #1866841 to a SRU... let me know if there is anything else I should do or change
<AsciiWolf> jbicha, anyway, I need to go away for a hour - two, feel free to edit if there is anything incorrect/incomplete in https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1866841
<ubottu> Launchpad bug 1866841 in gnome-shell (Ubuntu) "[SRU] Move gnome-shell-extension-prefs to universe and add chrome-gnome-shell to its recommends" [Undecided,New]
<seb128> hum, launchpad just showed me 'you have been logged out' ubuntuone page while editing a bug, rude!
<hallyn> hey rbasak  - i accidentally let mey ubuntu-core-dev membership expire.  reminders got lost in spam.  is that re-set-able?
<hallyn> (Laney had suggested emailing the perms list, but my ubuntu.com mail fwd seems to have gone berzerk so i can't tell if that worked or not :)
<seb128> speaking of DMB, could someone do a refresh of the persmission (as by https://git.launchpad.net/~developer-membership-board/+git/packageset/tree/README)?
<seb128> ddstreet, slashd, rbasak, ^ unsure if there is a DMB alias or what's the right place to ask for that? (also where do we ask for exceptions to be added?)
<Laney> hallyn: your mail worked https://lists.ubuntu.com/archives/devel-permissions/2020-April/001482.html
<Laney> seb128: devel-permissions@lists.ubuntu.com as well IME
<seb128> Laney, thanks
<hallyn> Laney - oh, cool, thanks.
<hallyn> hm, i should fix that from address
<Laney> still, perhaps pinging will make action happen faster :-)
<seb128> Laney, the refresh is useful but didn't add things like yaru-theme (because it's in desktop-minimal and that's not consider? or because it's a recommends only?)
<Laney> I doubt it's either of those reasons but you'd have to dig in specifically to find out why
<seb128> k, maybe after release if I get some quiet cycle
<Laney> maybe they'd consider adding an exception for it
<Laney> here's a guess: gnome-shell needed an exception because it was ending up in desktop-core for some reason
<Laney> and yaru-theme-gnome-shell is in gnome-shell-common's Recommends
<Laney> that script (probably wrongly) doesn't transitively apply its exceptions
<seb128> Laney, thx for the investigation/hints
<rbasak> hallyn: I've seen it, just not looked at it yet, sorry.
<rbasak> We make sure to catch up on outstanding ML requests every meeting.
<Laney> seb128: if you mail, tracker -> ubuntugnome looks wrong too these days
<hallyn> rbasak: i'm not in a hurry, thanks :)
<seb128> Laney, thx, I will probably do a review of the list/things missing before emailing
<Laney> (that one is in the exceptions)
<Laney> ok
<Laney> cool
<bdmurray> RikMills-M: Where is the fix for bug 1872551 committed?
<ubottu> bug 1872551 in software-properties (Ubuntu) "software-properties-qt: nvidia driver version switch fails" [Undecided,Fix committed] https://launchpad.net/bugs/1872551
<hallyn> rbasak: Laney: so would this be why people.ubuntu.com/~serge-hallyn would have disappeared?
<hallyn> or do i need to chase down something else :)
<Laney> sounds likely, assuming that caused you to lose Ubuntu memberrship
<Laney> s/rr/r/
<rbasak> I didn't even know that existed
#ubuntu-devel 2020-04-18
<xnox> xnox[m]: hey
#ubuntu-devel 2020-04-19
<CarlFK> I seem to have this too; https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871182
<ubottu> Launchpad bug 1871182 in initramfs-tools (Ubuntu) "[RTL810xE] No ethernet connection" [Undecided,Confirmed]
<CarlFK> Could you try to: 1. remove 'realtek' ....
<CarlFK> I have some time to help - is that a good direction ?
<RAOF> xnox:
<RAOF> you
<RAOF> xnox: You *have* joined the somewhat overloaded matrix.org server. It is often a little slow.
<xnox> RAOF:  thanks
<RAOF> I'd suggest you try again from our testing server, but that's got federation disabled so you can't join #freenode_#ubuntu-desktop:matrix.org from it â¹ï¸
